Subject: [PWE3] comments on draft-ietf-pwe3-fragmentation-08.txt

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 Jul 2005 20:16:11 +0100

I was doing a final review of draft-ietf-pwe3-fragmentation-08.txt
and have the following comments.

- Stewart

SB> The draft fails nits

SB> We need to pass the next version to L2TPext for their review.

     Fragmentation takes place in the transmitting PE immediately prior
     to PW insertion, and reassembly takes place in the receiving PE
     immediately after PW extraction.

SB> Insertion and extraction are not the terms we normally use in PWE3.
SB> Perhaps encapsulation and decapsulation?

     A PE MAY choose to fragment a packet before allowing it to enter a
     PW.

SB> For consistency we should say that this happen in the NSP function.
SB> We should at this point emphasize that the action is PW and maybe
SB> payload specific.

  4. PWE3 Fragmentation With MPLS

     When using the signaling procedures in [MPLS-Control], there is a
     Virtual Circuit FEC element parameter ID used to signal the use of
     fragmentation when advertising a VC label:

        Parameter   ID Length    Description
             0x09           2    Fragmentation indicator

SB> The formal name of this group of allocations is  "Pseudowire Interface
SB> Parameter Sub-TLV type"

  5.1 PW-specific Fragmentation vs. IP fragmentation

     When proper MTU management across a network fails, IP fragmentation
     and reassembly may be used to accommodate MTU mismatches between
     tunnel endpoints. If the overall traffic requiring fragmentation
     and reassembly is very light, or there are sufficient optimized
     mechanisms for IP fragmentation and reassembly available, IP
     fragmentation and reassembly may be sufficient.

SB> Because of the earlier example, you might want to emphasise that you
SB> are describing IP PSN frag, not payload frag here.

     Deployments should avoid a situation which relies upon a
     combination of IP and PW fragmentation and reassembly on the same

SB> Again - should make it clear that this is IP PSN. Perhaps we
SB> need a global statement that there are three places that it
SB> can be done for L2TP, and it SHOULD only be done one place.

     L2TPv3 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6]
     for automatic adjustment of the PW MTU.

SB> Of course when the payload is IP that should be running PATHMTU.

     All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length,
     and Vendor ID.

SB> Do we need to say the above - the reader has to understands L2TP
SB> to implement this. It would be less tutorial if the bit definitions
SB> were included in the following para

     This AVP may be hidden (the H bit may be 0 or 1).
     The 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.

SB> How about something like this:

     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.

SB> Same comment on the following text

     All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length,
     and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1).
     The 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.

  5.5 Fragment Bit Locations For L2TPv3 Encapsulation

     The B and E bits are defined as bits 2 and 3 in the L2TPv3 default

SB> We don't know what the B and E bits are as there were defined in MPLS
SB> specific text. The BE deinitions should be put in a tunnel neutral
SB> subsection, or you should move the ref to Secition 4.1 to the
SB> beginning of the section

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |x|S|B|E|x|x|x|x|              Sequence Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: L2TPv3 over IP Header

     The S bit is as defined in [L2TPv3]. Location of the B and E bits

SB> Does S bit have a name?

     See section 4.1 for the description of the use of the B and E bits.

SB> Alternatively, this sentence needs to be the first sentence in section 5.5

     See section 2 for the description of the use of the Sequence Number
     field.

SB> I can't see it in section 2.

  5.6 Fragment Bit Locations for L2TPv2 Encapsulation

     The B and E bits are defined as bits 8 and 9 for the L2TPv2 header

SB> Again we don't know what the B & E bits are

     as depicted below (subject to IANA action), using the values
     defined in section 3.1:

SB> It's not clear what IANA action you are asking for, and this text
SB> will need to be edited out later. Would it be better to just say this
SB> in the IANA section?

SB> PWE3 IANA needs to be a normative reference and needs to be
SB> called up in the IANA action section

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3