Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly
draft-ietf-pwe3-fragmentation-10

[Note]: '3/20/06: Fixes for discusses are well-understood.  Waiting for an RFC editor note or updated document from Mark (who is the author).' added by Margaret Wasserman

IANA Comments:
We understand this document to NOT create any new registries.

The IANA will update the reference for the Fragmentation Indicator interface parameter which is registered at the following:
http://www.iana.org/assignments/pwe3-parameters

Upon appproval the IANA will assign the following new values -
2 Control Message Attribute Value Pairs (AVPs) for the following:
    TBD1 - Maximum Receive Unit (MRU) AVP
    TBD2 - Maximum Reassembled Receive Unit (MRRU) AVP
 
2 Default L2-Specific Sublayer bits for the following:
    Bit 2 - B (Fragmentation) bit
    Bit 3 - E (Fragmentation) bit

2 Leading Bits of the L2TPv2 Message Header for the following:
    Bit 8 - B (Fragmentation) bit
    Bit 9 - E (Fragmentation) bit
   
These registrations will take place at the following location:
http://www.iana.org/assignments/l2tp-parameters

[Ballot comment]
I'd like to echo Sam's unease with L3 fragmentation on an L2 device.  It is reminiscent of all the problems caused by FDDI<->Ethernet or Token Ring<->Ethernet Bridges - some were buggy implementations (because it's fundamentally hard to get this right? I dunno), some were purely L2 devices that couldn't send ICMP errors when dropping.

Were the potential problems with fragmentation discussed in the WG?

[Ballot discuss]
I'll drop this discuss if there is not significant support from the
rest of the IESG This document recommends that PWE3 NSPs look into l2
packets, find an IP packet, extract it, fragment it and send as
multiple L2 packets.
>    A PE's native service processing (NSP) MAY choose to fragment a
>    packet before allowing it to enter a PW. For example, if an IP
>    packet arrives from a CE with an MTU which will yield a PW packet
>    which is greater than the PSN MTU, the PE NSP may perform IP
>    fragmentation on the packet, also replicating the L2 header for the
>    IP fragments. This effectively creates two (or more) packets, each
>    carrying an IP fragment preceded by an L2 header, for transport
>    individually across the PW. The receiving PE is unaware that the
>    originating host did not perform the IP fragmentation, and as such
>    does not treat the PW packets in any special way. This ultimately
>    has the affect of placing the burden of fragmentation on the PE
>    NSP, and reassembly on the IP destination host.












We've been having enough trouble with this sort of deep inspection and
modification in the ECMP MPLS case.  I do not think we want to
encourage this level of deep modification because it is likely to
introduce architectural fragility.

[Ballot discuss]
MUST, SHOULD, MAY (etc) language used without a citation and
reference to RFC2119.

If I look to sect 5.3 (as an example, 5.4 worries me too):

  5.3 L2TP Maximum Receive Unit (MRU) AVP

      0                  1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              MRU              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  MRU (Maximum Receive Unit), attribute number TBD1, is the maximum
  size in octets of a fragmented or complete PW frame, including L2TP
  encapsulation, receivable by the side of the PW advertising this
  value. The advertised MRU does NOT include the PSN header (i.e. the
  IP and/or UDP header). This AVP does not imply that PWE3
  fragmentation or reassembly is supported. If reassembly is not
  enabled or unavailable, this AVP may be used alone to advertise the
  MRU for a complete frame.

  This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M)
  bit for this AVP SHOULD be set to 0. The Length (before hiding) is
  8. The Vendor ID is the IETF Vendor ID of 0.

Then I am confused, since earlier today I was reading document
draft-ietf-l2tpext-l2vpn-06.txt , and in there, an AVP looked like:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M|H|0|0|0|0|    Length        |              0                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              TBA              |      SAII (variable length)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So here I had expected something aka:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M|H|0|0|0|0|    Length        |              0                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              TBD1            |      MRU                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or am I completely misunderstanding something here?