Subject: AD review of draft-ietf-pwe3-cw-01.txt - comment 5

From: Stewart Bryant <[email-masked]>
Date: Fri, 18 Feb 2005 19:10:18 +0000

> If the MPLS payload is between 46 bytes and 63 bytes the
 > implementation MAY either set to the length of the MPLS
 > payload, or it MAY set it to 0.
 > Note to the reader: In the definition above, both the MUSTs
 > are needed to make the mechanism work, the MAY provides
 > backwards compatibility with deployed systems.
 >
 > Is this really what is needed? Seems like the spec should be
 > saying. The sender MUST or SHOULD set it to (pick one or the other),
 > but (and this is what is critical) on receipt should be prepared to
 > handle _either_ value. That is what gives you interoperability.
 >
 > Or, if you want new implementation to work with old, than say the
 > SHOULD (or MAY) also support sending a 0, but that this should be
 > configurable??? Or something. Kind of depends on what you are trying
 > to acheive. Is it interoperability with implementations that send a 0?
 > Or those that expect 0 on receipt and don't handle the "correct"
 > value?

The issue is with the 46-63 case.

Looking at the encap drafts they all say (unless I have missed one)
set length to length at or below 63, otherwise set to 0.

I propose that we change the text from:

"The length field is used to determine the size of a PW payload that might have 
been padded to the minimum Ethernet MAC frame size during its transit across the 
PSN. If the MPLS payload (defined as the PW-CW + the PW payload + any additional 
PW headers) is less than 46 bytes, the length MUST be set to the length of the 
MPLS payload.  If the MPLS payload is between 46 bytes and 63 bytes the 
implementation MAY either set to the length of the MPLS payload, or it MAY set 
it to 0.  If the length of the MPLS payload is greater than 63 bytes the length 
MUST be set to 0.

"Note to the reader: In the definition above, both the MUSTs are needed to make 
the mechanism work, the MAY provides backwards compatibility with deployed systems."

To

"The length field is used to determine the size of a PW payload that might have 
been padded to the minimum Ethernet MAC frame size during its transit across the 
PSN. If the MPLS payload (defined as the PW-CW + the PW payload + any additional 
PW headers) is less than 63 bytes, the length MUST be set to the length of the 
MPLS payload.  Otherwise the length MUST be set to 0."

If this revised text breaks any existing implementation, then we will add
the 46 to 63 byte case back in as a MAY send, MUST receive, otherwise we are
better simplifying the text by deleting this case.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 18 Feb 2005 19:14:48 +0000

That should of course be :

"is less than 64 bytes, the length MUST be set to the length
of the MPLS payload"

Stewart

Stewart Bryant wrote:

> "The length field is used to determine the size of a PW payload that 
> might have been padded to the minimum Ethernet MAC frame size during its 
> transit across the PSN. If the MPLS payload (defined as the PW-CW + the 
> PW payload + any additional PW headers) is less than 46 bytes, the 
> length MUST be set to the length of the MPLS payload.  If the MPLS 
> payload is between 46 bytes and 63 bytes the implementation MAY either 
> set to the length of the MPLS payload, or it MAY set it to 0.  If the 
> length of the MPLS payload is greater than 63 bytes the length MUST be 
> set to 0.
> 
> "Note to the reader: In the definition above, both the MUSTs are needed 
> to make the mechanism work, the MAY provides backwards compatibility 
> with deployed systems."
> 
> To
> 
> "The length field is used to determine the size of a PW payload that 
> might have been padded to the minimum Ethernet MAC frame size during its 
> transit across the PSN. If the MPLS payload (defined as the PW-CW + the 
> PW payload + any additional PW headers) is less than 63 bytes, the 
> length MUST be set to the length of the MPLS payload.  Otherwise the 
> length MUST be set to 0."
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 18 Feb 2005 19:34:22 +0000

"IANA considerations for all these documents need to be synced up, as
there are redundencies"

I propose that we change the IANA section to:

"5. IANA considerations
The initial values of PW Associated Channel Type and the procedure for the 
allocation of new values is defined in [IANA]."

This then puts the discussion of all the registry issues in one
place. Registry issues are still an outstanding matter that
we need to resolve.

Stewart

---

From: Luca Martini <[email-masked]>
Date: Fri, 18 Feb 2005 17:03:53 -0700

Actually I propose that we make all allocations by IETF consensus only 
in this area.
It is simple , and in line with things that go in the data path like IP 
version numbers and such ....

Luca

Stewart Bryant wrote:

> The initial values of PW Associated Channel Type and the procedure for 
> the allocation of new values is defined in [IANA]."
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 19 Feb 2005 00:20:15 +0000

> version numbers and such ....

Sure, but where should we say that - in IANA or in CW?

Stewart

---

From: Luca Martini <[email-masked]>
Date: Fri, 18 Feb 2005 18:45:01 -0700

Note that all the encapsulation drafts seem to say if less then 64 bytes 
, then set the length field to the correct length.
So if you make this change you are in agreement with all the 
encapsulation drafts ....
Luca

Stewart Bryant wrote:

> might have been padded to the minimum Ethernet MAC frame size during 
> its transit across the PSN. If the MPLS payload (defined as the PW-CW 
> + the PW payload + any additional PW headers) is less than 46 bytes, 
> the length MUST be set to the length of the MPLS payload.  If the MPLS 
> "Note to the reader: In the definition above, both the MUSTs are 
> needed to make the mechanism work, the MAY provides backwards 
> compatibility with deployed systems."
>
> To
>
> might have been padded to the minimum Ethernet MAC frame size during 
> its transit across the PSN. If the MPLS payload (defined as the PW-CW 
> + the PW payload + any additional PW headers) is less than 63 bytes, 
> the length MUST be set to the length of the MPLS payload.  Otherwise 
> the length MUST be set to 0."
>

---

From: Luca Martini <[email-masked]>
Date: Sat, 19 Feb 2005 10:22:10 -0700

Stewart Bryant wrote:

>
>
> Luca Martini wrote:
>
>> Actually I propose that we make all allocations by IETF consensus 
>> only in this area.
>> It is simple , and in line with things that go in the data path like 
>> IP version numbers and such ....
>
>
Since it was not in IANA already , might as well put it in CW , then we 
avoid a dependency on IANA , what has not yet been last called ....
Luca

>>> The initial values of PW Associated Channel Type and the procedure 
>>> for the allocation of new values is defined in [IANA]."
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 19 Feb 2005 20:24:02 +0000

> avoid a dependency on IANA , what has not yet been last called ....

OK the IANA section now reads:

5. IANA considerations
IANA needs to set up a registry of "Pseudowire Associated Channel Types". These 
are 16-bit values. Registry entries are assigned by using the "IETF Consensus" 
policy defined in [RFC2434].