Subject: Re: A comment on the signaling part of draft-ietf-pwe3-fcs-retention- 00.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Nov 2003 10:52:58 -0500

Sasha,

Thanks for your comments.  Replies inline.

>IMHO, there is a couple of (minor) problems with the proposed
>signaling of FCS retention in draft-ietf-pwe3-fcs-retention-00.txt.
>
>1. PEs only signal that they agree to receive retained FCS as the proposed
>    interface attribute does not have any value, just an ID. This is OK with
>    Ethernet, but the draft also discusses FR (port mode), HDLC and PPP -
>    and, AFAIK, these may use 16-bit or 32-bit FCS (even if 32-bit FCS is 
> rare).
>    Surely retaining a 16-bit FCS value coming from the AC at one end of 
> the PW
>    will not be of much use at the other end if the corresponding AC uses
>    32-bit FCS!
>
>    This problem is easy to fix by adding VALUE to the proposed attribute.
>    This value would specify the FCS type used by the AC in question (e.g.,
>    Ethernet, 16-bit HDLC, 32-bit HDLC), and limiting applicability of 
> retention
>    to the case when the two ACs use the same kind of FCS. (The size of 
> the attribute
>    should be increased accordingly to account for this value).

Thanks - that's a really good suggestion.  We'll include that in the next 
revision.

>2. It would also be nice to specify that a PE includes the FCS retention
>attribute if it is capable of both receiving (as in the text) and SENDING 
>retained
>FCS.
>
>    This would prevent bizarre situations where both PEs have agreed to 
> RECEIVE
>    retained FCS (and hence presumably expect FCS in the PW packets) without
>    one (and possibly both) really SENDING it.

That's also a good clarification to make explicit.

>    Of course, the signaling could be also enhanced to allow independent 
> FCS retention
>    in each direction of the PW, but this hardly seems justified.

Yeah, and it's also much harder to keep backwards compatibility, so we'll 
keep the current requirement of using it in both directions, or neither.

Thanks again,
Andy