Subject: PE Fragmentation and reassembly

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 19 Apr 2002 09:16:33 +0200

I have been thinking about the fragmentation and reassembly problem a great
deal, and want to summarize my thoughts in hopes of it provided a basis for
consensus moving forward.

First, I think that we should very clearly understand that fragmentation and
reassembly should be avoided entirely whenever possible. When absolutely
necessary, is is best to be distributed throughout the network as much as
possible rather than performed at an aggregation point such as the PE. 

I think Eric's point that attempting fragmentation beyond anything but in-order
received packets is a sound base level of requirements for realistically
supporting PE reassembly for anything but the most marginal number of packet
fragments. This requires that the fragmentation method have PW-specific context.
Thus, PSN (IP) fragmentation does not meet this requirement.

FRF.12 fragmentation could be performed "in the NSP" and the existing FRF.12
fragmentation header sent with each FR fragment. If Frame Relay is the only
framing type in the world that we will ever want PE fragmentation in, we should
just do this and not even try to define our own PW-specific method (even if it
saves a few bytes on the wire by doing so). However...

If FR is *not* the only framing type in the world that we will want to perform
PE fragmentation with, then we should support a common method. We have even
talked about having fragmentation built into L2TP for carrying PPP as far back
as 1997. We have managed to avoid it thus far, but honestly we have leaned a bit
on IP fragmentation for some cases which is admittedly not as optimal as a PW
method which has PW-specific context for reassembly. So, my experience here
would suggest that a PW-specific fragmentation and reassembly method would not
be completely out of order.

I would hope to see the following items agreed to if we do this:

1. Other methods of PE fragmentation be disallowed. e.g. that FRF.12 at the PE
will be called out as a MUST NOT. What I would hate to see is a combination of
FRF.12 fragments and PW-fragments received at the PE, all to be reassembled,
perhaps even within their own heirarchy. This would be a terrible failure.

2. Sequence numbers be required on all PW fragments sent, but not necessarily on
non-fragmented packets.

3. Please, please, please continue to encourage CE fragmentation over PE
fragmentation. One of my biggest hesitations in creating a general method for PE
fragmentation is that it will be relied on too heavily, and we will end up
building too much reassembly processing at aggregation points when everyone
would be better served overall by distributing this same functionality out to
the CEs.

4. The PW fragmentation and reassembly method be defined in its own document(s)
where the above points may be called out specifically. The header constructs
used may be tailored to the specific tunneling method being used for the PW.

Comments?

- Mark

---

From: "Claude Kawa"<[email-masked]>
Date: Fri, 19 Apr 2002 05:55:17 -0400

Let us put the fragmentation on the back burner now until we see how the
changes I proposed to the draft progress to avoid doing a lot of things at
the same time with the bandwidth we have. 

After that we can address this issue of fragmentation. There have been a
number of emails yesterday and today with important ideas that should not be
lost.

Claude

---

From: Sasha Vainshtein <[email-masked]>
Date: Sat, 20 Apr 2002 14:38:29 +0200

Mark and all,
Please see some comments inline.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 9:17 AM
> To: [email-masked]
> Subject: [PWE3] PE Fragmentation and reassembly
> 
> 
> 
> PE fragmentation with, then we should support a common 
> method.
> 
I would like to note that FR is the only packet payload type service
covered by PWE3 Charter that provides some "native" solutions for
the fragmentation problem - i.e., Ethernet tnor AAL5 do not (unless
you consider Cell Relay as the AAL5 fragmentation solution).
On the other hand, the FR draft is the only one that tried to deal with
the fragmentation problem.
I would really like to understand the meaning of that, e.g., 
does it mean that no one of the Eth over Packet people
has ever considered carrying jumbo Ethernet frames over a PW?
Should such an application be explicitly exculded from the PWE3
considerations? And if so, why?
> We have even
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 20 Apr 2002 11:46:01 -0400

Sasha,

>considerations? And if so, why?

Excellent point.  We (the kamapabhava authors) just took the requirement 
for FR fragmentation as a given because we had prior experience with its 
necessity, thus the creation of FRF.12 in the first place.

If we do want to have a general solution for PWE3, which is a very good 
idea, there's an excellent precedent to start from, MLPPP (RFC 
1990).  That's what we based FRF.12 on in the first place, since there was 
no reason to reinvent the wheel when we did FRF.12, and there's no reason 
here either.  A sequence number and two bits are all you need for the 
MLPPP-style fragmentation and reassembly, and we already have a sequence 
number in the control word (at least for MPLS).

Cheers,
Andy