Subject: [L2tpext] Re: [PWE3] WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 09 Jun 2004 13:50:52 +0200

OK, let me try again, I made the same mistake as you did regarding the FCS 
length. Andy, I stole the text describing the FCS Length parameter from you 
directly.

4. Signaling FCS Retention With L2TPv3-based Pseudowires

When using the signaling procedures in [7], the FCS Retention AVP, Attribute 
Type L2TP-TBA-1, is used.

  The Attribute Value field for this AVP has the following format:

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          FCS Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The FCS Length is a 2-octet unsigned integer.

The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) 
requests its peer to retain FCS for the L2TP session being established. If the 
receiving LCCE recognizes the AVP and complies with the FCS retention request, 
it MUST include an FCS Retention AVP as an acknowledgement in a corresponding 
ICRP or ICCN message. FCS Retention is always bidirectional, thus FCS is only 
retained if both LCCEs send an FCS Rentention AVP during session establishment.

The Attribute Value is 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 AVP 
allows the PEs to ensure that the FCS is only retained when it makes sense.

The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). 
This AVP MAY be hidden (the H bit MAY be 1 or 0).

For the IANA Considerations Section:

This specification requires one value within the L2TP "Control Message Attribute 
Value Pairs" section to be assigned by IANA as per [8]. The new AVP is encoded 
as L2TP-TBA-1 in this document, and should be referred to in the IANA L2TP 
parameters registry as "FCS Retention."

For the References Section:

  [7]   J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
        Protocol (Version 3)", work in progress,
        draft-ietf-l2tpext-l2tp-base-14.txt, June 2004.

  [8]   Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
        Assigned Numbers Authority (IANA) Considerations Update",
        RFC 3438, December 2002.

Thanks,

- Mark

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 09 Jun 2004 13:41:00 +0200

Andrew G. Malis wrote:

> The authors feel that this draft is ready to enter WG last call.

Looks like section 4 needs some attention first. It's pretty simple, here is 
some text:

The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) 
requests its peer to retain FCS for the L2TP session being established. If the 
receiving LCCE recognizes the AVP and complies with the FCS retention request, 
it MUST include an FCS Retention Indicator AVP as an acknowledgement in an ICRP 
or ICCN message. FCS Retention is always bidirectional, thus FCS is only 
retained if both LCCEs send an FCS Rentention AVP during session establishment.

The Length of this AVP is 6 (there is no Attribute Value field). The M bit for 
this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).

Thanks,

- Mark

> 
> 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
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 09 Jun 2004 08:22:53 -0400

Mark,

Thanks!  We'll consider this a last call comment :-) and edit it in 
following the close of last call (which I believe was this past Monday, 
actually).

Cheers,
Andy

---------

At 6/9/2004 01:50 PM +0200, W. Mark Townsley wrote:

>length. Andy, I stole the text describing the FCS Length parameter from 
>you directly.
>
>When using the signaling procedures in [7], the FCS Retention AVP, 
>Attribute Type L2TP-TBA-1, is used.
>
>The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE 
>(PE) requests its peer to retain FCS for the L2TP session being 
>established. If the receiving LCCE recognizes the AVP and complies with 
>the FCS retention request, it MUST include an FCS Retention AVP as an 
>acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is 
>always bidirectional, thus FCS is only retained if both LCCEs send an FCS 
>Rentention AVP during session establishment.
>
>The Attribute Value is 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 AVP allows the PEs to ensure 
>that the FCS is only retained when it makes sense.
>
>The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 
>(zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).
>
>This specification requires one value within the L2TP "Control Message 
>Attribute Value Pairs" section to be assigned by IANA as per [8]. The new 
>AVP is encoded as L2TP-TBA-1 in this document, and should be referred to 
>in the IANA L2TP parameters registry as "FCS Retention."
>