Subject: RE: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 22 May 2004 15:33:37 -0400

Sasha,

>Andy and all,
>A brief pre-LC comment on the draft in question:
>
>In its present form the draft only indicates whether the FCS is
>retained or not  as the corresponding Interface Parameter does
>not carry any value,just ID.
>
>This is OK when dealing with Ethernet and ATM AAL5 PWs.
>
>However, if you want to retain FCS in HDLC or FR PWs, FCS retention
>only makes sense if the two ACs use the same FCS size (2 or 4 bytes).
>If the sizes are different, FCS retenation cannot function.
>However, the draft does not allow signaling of the expected FCS
>size and hence does not prevent successful setup of non-operational PWs.

Thanks - you're absolutely correct. For the post-LC revision, I'll replace 
section 3 with the following:

3. Signaling FCS Retention With MPLS-based Pseudowires

When using the signaling procedures in [4], there is a Virtual Circuit FEC 
element parameter ID used to signal the desire to retain the FCS when 
advertising a VC label:

    Parameter   ID Length    Description
         0x0A           4    FCS Retention Indicator

The presence of this parameter ID in the VC FEC element indicates that the 
egress PE requests the ingress PE to retain the FCS for the VC label being 
advertised.  It does not obligate the ingress PE to retain the FCS; it is 
simply an indication that the ingress PE MAY retain the FCS.  The sender 
MUST NOT retain the FCS if this parameter ID is not present in the VC FEC 
element.

The parameter includes a 16-bit FCS length field, which indicates the 
length of the original FCS being retained.  For Ethernet and ATM AAL5 
pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame 
Relay pseudowires, this length will be set to either 2 or 4. Since the FCS 
length on these interfaces is a local setting, retaining the FCS only makes 
sense if the FCS length is identical on both ends of the 
pseudowire.  Including the FCS length in this parameter allows the PEs to 
ensure that the FCS is only retained when it makes sense.

Since unknown parameter IDs are silently ignored [4], backwards 
compatibility with systems that do not implement this document is provided 
by requiring that the FCS is retained ONLY if the FCS Retention Indicator 
with an identical setting for the FCS length has been included in the 
advertisements for both directions on a pseudowire.

If the ingress PE recognizes the FCS Retention Indicator parameter ID, but 
does not wish to retain the FCS with the indicated length, it need only 
issue its own label mapping message for the opposite direction without 
including the FCS Retention Indicator.  This will prevent FCS retention in 
either direction.

If PWE3 signaling [4] is not in use for a pseudowire, then whether or not 
the FCS is to be retained MUST be identically provisioned in both PEs at 
the pseudowire endpoints.  If there is no provisioning support for this 
option, the default behavior is to remove the FCS.

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 May 2004 10:44:51 +0100

Sasha

Good point.

Stewart

Sasha Vainshtein wrote:

> Hopefully this comment will be helpful.
>  
> -----Original Message-----
> From: Andrew G. Malis
> To: PWE3 (IETF)
> Sent: 5/20/2004 11:21 PM
> Subject: [PWE3] WG last call requested for
> draft-ietf-pwe3-fcs-retention-01.txt
> 
> The authors feel that this draft is ready to enter WG last call.
> 
> Thanks,
> Andy
> 
> ------- Begin of Forwarded Message -------
> To: [email-masked]
> Cc: [email-masked]
> From: [email-masked]
> Subject: I-D ACTION:draft-ietf-pwe3-fcs-retention-01.txt
> Date: Thu, 20 May 2004 16:02:00 -0400
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Pseudo Wire Emulation Edge to Edge
> Working 
> Group of the IETF.
> 
> 	Title		: PWE3 Frame Check Sequence Retention
> 	Author(s)	: A. Malis, et al.
> 	Filename	: draft-ietf-pwe3-fcs-retention-01.txt
> 	Pages		: 6
> 	Date		: 2004-5-20
> 	
> This document defines a mechanism for preserving frame FCS through
> Ethernet, Frame Relay, and HDLC pseudowires.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the 
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pwe3-fcs-retention-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt
> 
> <ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt
> 
> 
> ------- End of Forwarded Message ------- 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 May 2004 06:45:12 -0400

Stewart,

Did you see the reply I sent on the list about this on Saturday?

Cheers,
Andy

At 5/24/2004 10:44 AM +0100, Stewart Bryant wrote:
>>In its present form the draft only indicates whether the FCS is retained 
>>or not  as the corresponding Interface Parameter does not carry any 
>>value,just ID.
>>However, if you want to retain FCS in HDLC or FR PWs, FCS retention only 
>>makes sense if the two ACs use the same FCS size (2 or 4 bytes). If the 
>>sizes are different, FCS retenation cannot function. However, the draft 
>>does not allow signaling of the expected FCS size and hence does not 
>>prevent successful setup of non-operational PWs.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 May 2004 12:17:46 +0100

> Did you see the reply I sent on the list about this on Saturday?

Just found it.

- Stewart

>>> retained or not  as the corresponding Interface Parameter does not 
>>> carry any value,just ID.
>>> If the sizes are different, FCS retenation cannot function. However, 
>>> the draft does not allow signaling of the expected FCS size and hence 
>>> does not prevent successful setup of non-operational PWs.