Subject: RE: [PWE3] AD Review of draft-ietf-pwe3-cw-03.txt

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 14 Apr 2005 10:05:45 +0200

Mark and all,
Please see some comments inline below.
I have snipped the portions of the text that are not relevant for these
comments.

Regards,
                                  Sasha Vainshtein
email:                         [email-masked] <mailto:[email-masked]> 
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2005 10:28 PM
> To: Luca Martini
> Cc: Stewart Bryant; PWE3 WG (E-mail); Danny McPherson
> Subject: Re: [PWE3] AD Review of draft-ietf-pwe3-cw-03.txt
> 
... snipped 
>  > 2.   PWE3 Packet Identification
>  >
>  >    All IP packets [RFC791][RFC1883] start with a version 
>  >    number that is
>  >    checked by LSRs performing MPLS payload inspection. To 
>  >    prevent the
>  >    incorrect processing of packets carried within a PW, PW packets
>  >    carried over an MPLS PSN SHOULD NOT start with the 
>  >    value 4 (IPv4) or the value 6 (IPv6) in the first nibble [BCP], 
>  >    as those are assumed to carry normal IP payloads.
> 
> Mark> Why not specify a MUST NOT here?
> 
> Luca> Some of the TDM PWs might start with a 4, as they do not have a
> Luca> conformant CW.
> So they are non-conformant and it should be duly noted. I 
> don't think that just because the TDM specs happen to already 
> be in violation we should relax the requirement for all. 
>
[Sasha]AFAIK the only PW that still uses a non-comformant CW
[Sasha]is CEP (draft-ietf-pwe3-sonet-10.txt), and this document
[Sasha]both states the problem and describes a solution.
[Sasha](Low-rate) TDM PW encapsulations described in the SAToP
[Sasha](draft-ietf-pwe3-satop-01.txt), CESoPSN 
[Sasha](draft-ietf-pwe3-cesopsn-02.txt) and TDMoIP 
(draft-ietf-pwe3-tdmoip-03.txt) docs all use a conformant CW. 
[Sasha]Hence I would say that TDM PWs are NOT in violation and
[Sasha]should not be cited as the reason to relax a requirement
[Sasha]if such is deemed necessary.
... snipped
>  > 3.   Generic PW MPLS Control Word
>  >
>  >    Length (bits 10 to 15):
>  >           The value of the length field, if non-zero, can 
>  >           be used to
>  >           remove any padding added by the PSN. If the entire packet
>  >           length is less than 64 bytes, the length field 
>  >           MUST be set to
>  >           the length of the PW payload plus the length of 
>  >           the control word. Otherwise it MUST be set to zero.
>  >
>  >           If a non-zero length field is received, the PW 
>  >           payload MUST be trimmed if required.
> 
> Mark> What is meant by "if required" - To me, this either 
> MUST be trimmed or
> Mark> not (no need to suggest an implementation loophole if 
> none should exist).
> Mark>
> 
> Luca> no, it means that the payload might already be the 
> correct length ,
> Luca> hence it might not need to be trimmed....
> Luca> Not all short packet have to be padded , some media do 
> not require
> Luca> padding ....
> 
> So, just to be sure, we are stating that the payload length 
> field MUST be set 
> for < 64 byte payloads regardless of media type, but there is 
> an "if required" 
> on the trimming when receiving a non-zero length as some 
> media types do not need 
> the length field.
>
[Sasha] I have commented on this subject already.

[Sasha]Neither this draft nor any service-specific
[Sasha]draft explains how to treat the following situations
[Sasha](LEN_CW is the value of the Length field and LEN_L2
[Sasha]is the length of the MPLS payload derived from the Layer 2
[Sasha]lentgh after stripping the Layer 2 header and the label stack,
[Sasha]MAX_PAD = 46 is the max. padding that can be added by Ethernet):
[Sasha]
[Sasha](1) (LEN_CW == 0) && (LEN_L2 < 64)       
[Sasha](2) (LEN_CW > 0) && (LEN_L2 < LEN_CW)
[Sasha](3) (LEN_CW > 0) && (LEN_L2 > LEN_CW + MAX_PAD) 
[Sasha]
[Sasha]To me all the cases above look like malformed packets to be
[Sasha] silently discarded...
[Sasha]Note that in these terms  "trimming is not
[Sasha]required" means that (LEN_CW > 0) && (LEN_L2 == LEN_CW).
[Sasha]I'd also say that "trimming is required" means

[Sasha](LEN_CW > 0) && (LEN_L2 > LEN_CW) && (LEN_L2 <= LEN_CW + MAX_PAD)

[Sasha]Maybe it is worth explicitly specifying these rules?
>
> Yes, I understand the issue here is ethernet, I'm not 
> debating when it is 
> necessary or not. I simply find it odd that we have an 
> exception clause on the 
> trimming, but not on the setting of the field.
> 
> Also, I think it might be helpful for interoperability to 
> point out ethernet as 
> an example of when this field would be used. This shouldn't 
> take more than a 
> sentence or two and perhaps a reference.
>
[Sasha] IMO it is also worth noting that any hypothetical media
that pads L2 frames to sizes exceeding 64 would not be suitable
for carrying MPLS PWs oaver it. 
... snipped to the end ...

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 14 Apr 2005 10:08:08 -0400

Thanks Sasha... Responses inline..

> [Sasha]if such is deemed necessary.

Then in your mind we can use a MUST NOT here in the CW spec?

> [Sasha] silently discarded...

I'm not sure the document needs to specify all possible error conditions. It 
would certainly be nice, but I'm not sure it is 100% necessary.

> [Sasha]Maybe it is worth explicitly specifying these rules?

Perhaps so. My concern was a bit less comprehensive, but you make a good point. 
I'll wait to hear other opinions if there are any...

> for carrying MPLS PWs oaver it. 

Yes, I agree.

- Mark