Subject: [L2tpext] Re: [PWE3] draft-ietf-pwe3-cw-04.txt

From: Scott Wainner <[email-masked]>
Date: Tue, 07 Jun 2005 14:31:25 -0400

Recommend two more changes:

ITEM1
=====
Last note in Section 4 text should be moved to the end of Section 3:

  Note that L2TPv3 [RFC3931] has its own mechanisms for providing this 
  associated channel, and is therefore out of the scope of this 
  document. 

ITEM2
=====

Following the text in Section 4:

When MPLS is used as the PSN, the PW Associated Channel is 
  identified by the following header:  

  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  |0 0 0 1| FmtID |   Reserved    |         Channel Type          | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

      Figure 3: PW Associated Channel Header

Add the text:

When IP is used as the PSN and L2TPv3 is used as the sesssion
  management control plane, the PW Associated Channel is 
  identified by the following header:  

  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  |1 0 0 0| FmtID |   Reserved    |         Channel Type          | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

      Figure 4: PW Associated Channel Header

Scott Wainner

PS> The first bit in the L2-Specific Sublayer of L2TPv3 was reserved as the V-bit
for VCCV.  The PW-ACH incorporates the functions of the VCCV.

Stewart Bryant wrote:

>
> I have just emailed draft-ietf-pwe3-cw-04.txt to [email-masked]
>
> I have run a diff and edited out the minor (English/typos)
> editorial changes.
>
> The following are the technical diffs.
>
> Provided there is consensus for these changes, I will send the
> draft back to Mark on June 10th.
>
> - Stewart
>
>
> ***** draft-ietf-pwe3-cw-03.txt
>    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
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>    incorrect processing of packets carried within a PW, PW packets
>    carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or
>    the value 6 (IPv6) in the first nibble [BCP], as those are assumed
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>    payload to select the ECMP path SHOULD employ the PW MPLS Control
>    Word described in Section 3 for data, and the PW Associated Channel
>    Header described in Section 4 for channel associated traffic. These
>    Control Words MUST immediately follow the bottom of the MPLS label
>    stack.
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>    payload to select the ECMP path SHOULD employ the PW MPLS Control
>    Word described in Section 3 for data, or the PW Associated Channel
>    Header described in Section 4 for channel associated traffic. The
>    PWE3 Control Word or the PW Associated Channel Header MUST
>    immediately follow the bottom of the MPLS label stack.
>
> *****
>
>
> ***** draft-ietf-pwe3-cw-03.txt
>    When a PWMCW is used, it MUST adhere to the Generic MPLS Control
>    Word format as illustrated in Figure 1 above. It is however strongly
>    recommended that it also follows the following format:
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>    When a PWMCW is used, it MUST adhere to the Generic MPLS Control
>    Word format as illustrated in Figure 1 above. It SHOULD also follow
>    the following format:
>
> *****
>
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>           These bits are available for per-payload signalling.  Their
>           definition is encapsulation specific as defined in
>           [pointer?].
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>           These bits are available for per-payload signaling.
>
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>           When the PSN path between the PEs includes an Ethernet, the
>           PW packet arriving at the CE-bound PE from the PSN may
>
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005
>
>           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.
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005
>
>           include padding appended by the Ethernet data link layer. The
>           CE-bound PE uses the length field to determine the size of
>           the padding added by the PSN, and hence extract the PW
>           payload from the PW packet.
>
>           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.
>
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>           If the sequence number is not used, it is set to zero by the
>           sender and ignored by the receiver.  Otherwise it specifies
>           the sequence number of a packet.  A circular list of sequence
>           numbers is used.  A sequence number takes a value from 1 to
>           65535 (2**16-1). The sequence number window size for packet
>           acceptance is dependent on the parameters of both the PW and
>           the MPLS PSN, and SHOULD be configurable. The mechanism used
>           by the decapsulating PE to syncronise the expected sequence
>           number with the received sequence number is implementation
>           dependent.
>
> 4.   PW Associated Channel
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>           The sequence number implements the sequencing function
>           [RFC3985]. The definition of this field is PW specific.
>
>   PW Associated Channel
>
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>           Format ID for the remaining 3 octets of the header. A FmtID
>           of 0 indicates that the 3 octets are as shown in Figure 3.
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>           This is the Format Identifier for the remaining 3 octets of
>           the header. A Format Identifier value of 0 indicates that the
>           3 octets are as shown in Figure 3.
>
> *****
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>           MUST be sent as 0, and ignored on reception.
>
>    Channel Type:
>
>           The PW Associated Channel Type is defined in the IANA PW
>           Associated Channel Type registry [IANA].
>
> *****
>
>
> ***** draft-ietf-pwe3-cw-03.txt
>
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005
>
>           Must be sent as 0, and ignored on reception.
>
>    Channel Type:
>
>           The PW Associated Channel Type is defined in the IANA PW
>           Associated Channel Type registry [IANA].
>
>    Bits 0..3 MUST be 0x01, and hence differ from the first four bits of
>    an IP packet [BCP]. This provides the necessary MPLS payload
>    discrimination.
>
>    Note that L2TPv3 [REFERENCE] has its own mechanisms for providing
>    this associated channel, and is therefore out of the scope of this
>    document.
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005
>
>    Bits 0..3 MUST be 0001. This allows the packet the packet to be
>    distinguished from an IP packet [BCP] and from a PWE3 data packet.
>
>    Note that L2TPv3 [RFC3931] has its own mechanisms for providing this
>    associated channel, and is therefore out of the scope of this
>    document.
> *****
>
>
>
> ***** draft-ietf-pwe3-cw-03.txt
>
>
> ***** DRAFT-IETF-PWE3-CW-04.TXT
>
>    IANA also needs to set up a registry of "Pseudowire Format
>    Identifiers". These are 4-bit values. Registry entries are assigned
>    by using the "IETF Consensus" policy defined in [RFC2434].
>
> *****
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

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