Subject: [PWE3] AD Review of draft-ietf-pwe3-cw-03.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 11 Apr 2005 17:03:23 -0400

Please find comments inline.

Thanks,

- Mark

>                                                                         
> Network Working Group                                         S. Bryant 
> Internet Draft                                               G. Swallow 
> Expiration Date: September 2005                           Cisco Systems 
>                                                            D. McPherson 
>                                                          Arbor Networks 
>                                                                         
>                                                              March 2005 
>                                                                         
>                                                                         
>                 PWE3 Control Word for use over an MPLS PSN 
> 
>                         draft-ietf-pwe3-cw-03.txt 
> 
>   
>   
>     
> Status of this Memo  
> 
>    By submitting this Internet-Draft, we certify that any applicable 
>    patent or other IPR claims of which we are aware have been 
>    disclosed, or will be disclosed, and any of which we become aware 
>    will be disclosed, in accordance with RFC 3668. 
> 
>    Internet-Drafts are working documents of the Internet Engineering 
>    Task Force (IETF), its areas, and its working groups.  Note that 
>    other groups may also distribute working documents as        
>    Internet-Drafts. 
> 
>    Internet-Drafts are draft documents valid for a maximum of six 
>    months and may be updated, replaced, or obsoleted by other documents 
>    at any time.  It is inappropriate to use Internet-Drafts as 
>    reference material or to cite them other than as "work in progress". 
> 
>    The list of current Internet-Drafts can be accessed at 
>    http://www.ietf.org/1id-abstracts.html  
> 
>    The list of Internet-Draft Shadow Directories can be accessed at 
>    http://www.ietf.org/shadow.html 
> 
> Abstract  
>  
>    This document describes the preferred designs of the PWE3 MPLS 
>    Control Word, and the PW Associated Channel Header. The design of 
>    these fields is chosen so that an MPLS LSR performing MPLS payload 
>    inspection will not confuse a PWE3 payload with an IP payload. 
> 
> Conventions used in this document  
>      
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 1] 
> 
> 
> 
> 
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005 
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
>    document are to be interpreted as described in RFC 2119 [RFC2119]. 
> 
>  
> 1.   Introduction 
> 
>    The standard MPLS encapsulations have no explicit protocol 
>    identifier. In order for a pseudo wire (PW) [RFC3985] to operate 
>    correctly over an MPLS packet switched network (PSN) that performs 
>    MPLS payload inspection, a PW packet must not appear to the LSR as 
>    if it were an IP packet [BCP]. An example of an LSR that performs 
>    MPLS payload inspection is one that is performing equal-cost 
>    multiple-path load-balancing (ECMP) [RFC2992]. If ECMP were 
>    performed on PWE3 packets, the packets in the PW may not all follow 
>    the same path through the PSN. This may result in misordered packet 
>    delivery to the egress PE. The inability to ensure that all packets 
>    belonging to a PW follow the same path may also prevent the PW OAM 
>    [VCCV] mechanism from correctly monitoring the PW.  
> 
>    This draft specifies how a PW header distinguishes a PW payload from 
>    an IP payload carried over an MPLS PSN. 
> 
> 2.   PWE3 Packet Identification 
> 
>    All IP packets [RFC791][RFC1883] start with a version number that is 
>    checked by LSRs performing MPLS payload inspection. To prevent the 
>    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 
>    to carry normal IP payloads. 

Why not specify a MUST NOT here?

> 
>    This document defines a PW header and two general formats of that 
>    header. These two formats are the PW MPLS Control Word (PWMCW) used 
>    for data passing across the PW, and a PW Associated Channel Header 
>    (PW-ACH) that can be used for functions such as OAM. 
> 
>    If the first nibble of a PWE3 packet carried over an MPLS PSN has a 
>    value of 0, it starts with a PWMCW. If the first nibble of a packet 
>    carried over an MPLS PSN has a value of 1, it starts with a PW-ACH. 
>    The use of any other first nibble value for a PWE3 packet carried 
>    over an MPLS PSN is deprecated. 
> 
>    A PW carried over an MPLS PSN that uses the contents of the MPLS 
>    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. 
> 
> 
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 2] 
> 
> 
> 
> 
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005 
> 
> 3.   Generic PW MPLS Control Word 
> 
>    The Generic PW MPLS Control Word is shown in Figure 1.  
> 
>  
>     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 0|          Specified by PW Encapsulation                | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     
>          Figure 1: Generic PW MPLS Control Word 
>  
>  
>    The PW set-up protocol or configuration mechanism determines whether 
>    a PW uses a PW MPLS Control Word (PWMCW). Bits 0..3 differ from the 
>    first four bits of an IP packet [BCP] and hence provide the 
>    necessary MPLS payload discrimination. 
> 
>    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:  

Is this a capital RECOMMENDED or SHOULD?

> 
>  
>     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 0| Flags |FRG|  Length   | Sequence Number               | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
>         Figure 2: PW Preferred MPLS Control Word 
> 
>    The meaning of the fields of the PW Preferred MPLS Control Word 
>    (Figure 2) are as follows: 
> 
>    Flags (bits 4 to 7): 
> 
>           These bits are available for per-payload signalling.  Their 

s/ll/l

>           definition is encapsulation specific as defined in 
>           [pointer?]. 

"pointer?" needs to be defined.

> 
>    FRG (bits 8 and 9): 
> 
>           These bits are used when fragmenting a PW payload. Their use 
>           is described in [FRAG] which is currently a work in progress. 

Simply refer to [FRAG] here as if this reference was solid so as not to burden 
the RFC Editor with catching this sentence.

>           When the PW is of a type that will never need payload 
>           fragmentation, these bits may be used as general purpose 
>           flags. 
> 
>    Length (bits 10 to 15): 
> 
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 3] 
> 
> 
> 
> 
> 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. 

What is meant by "if required" - To me, this either MUST be trimmed or not (no 
need to suggest an implementation loophole if none should exist).

> 
>    Sequence number (Bit 16 to 31): 
> 
>           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 

s/syncronise/synchronize

That's two I caught, there must be more. Please run the doc through a spell checker.

>           number with the received sequence number is implementation 
>           dependent. 
> 
> 4.   PW Associated Channel 
> 
>    For some features of PWs, such as OAM, an associated channel is 
>    required. An associated channel is a channel that is multiplexed 
>    over the PW so that it follows exactly the same path through the PSN 
>    as the PW. Note that the use of the term "channel" is not a "PW 
>    channel type" as used in subsection 5.1.2 of [RFC3985] 
> 
>    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  
> 
>    The meaning of the fields in the PW Associated Channel Header 
>    (Figure 3) are as follows: 
> 
>    FmtID:  
> 
>           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.  
> 
>    Reserved: 
> 
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 4] 
> 
> 
> 
> 
> 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 

The first bits being 0x01 also differ this payload from being a PW payload.

>    discrimination.  

The last sentence here could use a little more qualification, e.g., 
"...necessary MPLS payload discrimination for ECMP and other methods which 
require MPLS payload inspection..." or some such.

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

Need to define REFERENCE (RFC3931).

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

What about FMT IDs?

> 
> 6.   Security Considerations 
> 
>    An application using PW Associated Channel to provide an OAM [VCCV] 

Please provide the [VCCV] reference earlier in this document, the first time OAM 
is mentioned (and not necessarily here).

>    or other message channel MUST be aware that this can potentially be 
>    misused. Any application using the Associated Channel must therefore 
>    fully consider the resultant security issues, and provide mechanisms 
>    to prevent an attacker from using this as a mechanism to disrupt the 
>    operation of the PW or the PE, and to stop this channel from being 
>    used as a conduit to deliver packets elsewhere. 
> 
>    If a PW has been configured to operate without a CW, the PW 
>    Associated Channel Type mechanism described in the document MUST NOT 
>    be used. This is to prevent user payloads being fabricated in such a 
>    way that they mimic the PW Associated Channel Header, and thereby 
>    provide a method of attacking the application that is using the 
>    Associated Channel. 
> 
>     
> 
> 7.   Acknowledgements 
> 
>    The authors wish to thank David Allan, Luca Martini, Thomas Nadeau 
>    and Mark Townsley for their input to this work. 
> 
> 8.   Intellectual Property Statement 
> 
>  
>    The IETF takes no position regarding the validity or scope of any   
>    Intellectual Property Rights or other rights that might be claimed 
> 
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 5] 
> 
> 
> 
> 
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005 
> 
>    to pertain to the implementation or use of the technology described 
>    in this document or the extent to which any license under such 
>    rights might or might not be available; nor does it represent that 
>    it has made any independent effort to identify any such rights.  
>    Information on the procedures with respect to rights in RFC 
>    documents can be found in BCP 78 and BCP 79. 
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any 
>    assurances of licenses to be made available, or the result of an   
>    attempt made to obtain a general license or permission for the use 
>    of such proprietary rights by implementers or users of this 
>    specification can be obtained from the IETF on-line IPR repository 
>    at http://www.ietf.org/ipr. 
> 
>    The IETF invites any interested party to bring to its attention any 
>    copyrights, patents or patent applications, or other proprietary 
>    rights that may cover technology that may be required to implement 
>    this standard.  Please address the information to the IETF at ietf-
>    [email-masked]. 
> 
>  
> 9.    Full copyright statement 
> 
>    Copyright (C) The Internet Society (2004). This document is subject 
>    to the rights, licenses and restrictions contained in BCP 78, and 
>    except as set forth therein, the authors retain all their rights. 
> 
>    This document and the information contained herein are provided on 
>    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
>    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
>    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
>    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
> 
>     
> 
> 10.    Normative References 
> 
>    Internet-drafts are works in progress available from   
>    http://www.ietf.org/internet-drafts/ 
> 
>    [RFC791]   RFC-791: DARPA Internet Program, Protocol 
>                Specification, ISI, September 1981. 
> 
>    [RFC1883]  RFC-1883: Internet Protocol, Version 6 (IPv6), S. 
>                Deering, et al, December 1995 
> 
>     
> 
> 
> 
> 
> 
> 
>  
> Bryant et al            Expires September 2005               [Page 6] 
> 
> 
> 
> 
> INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Mar 2005 
> 
>     
> 
> 11.    Informative References 
> 
>  
>    Internet-drafts are works in progress available from   
>    <http://www.ietf.org/internet-drafts/> 
> 
>    [BCP]     Swallow, G. et al, "Avoiding Equal Cost Multipath 
>               Treatment in MPLS Networks", Internet Draft         
>               <draft-ietf-mpls-ecmp-bcp-00.txt>, September 2004, 
>               Work in Progress. 
> 
>    [FRAG]    Malis, A., Townsley, M., "PWE3 Fragmentation and 
>               Reassembly", Internet Draft, <draft-ietf-pwe3-
>               fragmentation-08.txt>, February 2005, Work in 
>               Progress. 
> 
>    [IANA]    Martini, L., Townsley M., "IANA Allocations for 
>               pseudo Wire Edge to Edge Emulation (PWE3) ", 
>               Internet Draft, <draft-ietf-pwe3-iana-allocation-
>               07.txt>, October 2004, Work in Progress. 
>                
>    [RFC2434] RFC-2434: Guidelines for Writing an IANA 
>               Considerations Section in RFCs, Narten, T., 
>               Alvestrand, H., October 1998 
>                
>    [RFC2992] RFC-2992:  Analysis of an Equal-Cost Multi-Path 
>               Algorithm, C. Hopps, November 2000 
>    [RFC3985] RFC-3985: PWE3 Architecture, Bryant, S. ed., Pate, 
>               P. ed. , To be published.  
>    [VCCV]    Nadeau, T., Aggarwal, T., "Pseudo Wire (PW) Virtual 
>               Circuit Connection Verification (VCCV)", Internet 
>               Draft, <draft-ietf-pwe3-vccv-04.txt>, Feb. 2005, 
>               Work in Progress. 

Line spacing above.

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

---

From: Luca Martini <[email-masked]>
Date: Wed, 13 Apr 2005 12:47:57 -0600

some comments inline.
Tks
Luca

W. Mark Townsley wrote:

>> Network Working Group                                         S. 
>> Bryant Internet Draft                                               
>> G. Swallow Expiration Date: September 2005                           
>> Cisco Systems 
>>                                                            D. 
>> McPherson                                                          
>> Arbor Networks 
>>                                                                         
>>                                                              March 
>> 2005 
>>                                                                         
>>                                                                         
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>> NOT",    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
>> in this    document are to be interpreted as described in RFC 2119 
>> [RFC2119].
>>  
>> 1.   Introduction
>>    the same path through the PSN. This may result in misordered 
>> packet    delivery to the egress PE. The inability to ensure that all 
>> packets    belonging to a PW follow the same path may also prevent 
>> the PW OAM    [VCCV] mechanism from correctly monitoring the PW. 
>>    This draft specifies how a PW header distinguishes a PW payload 
>> from    an IP payload carried over an MPLS PSN.
>>    All IP packets [RFC791][RFC1883] start with a version number that 
>> is    checked by LSRs performing MPLS payload inspection. To prevent 
>> the    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    to carry normal IP payloads. 
>
>
Some of the TDM PWs might start with a 4, as they do not have a 
conformant CW.

>>    header. These two formats are the PW MPLS Control Word (PWMCW) 
>> used    for data passing across the PW, and a PW Associated Channel 
>> Header    (PW-ACH) that can be used for functions such as OAM.
>>    If the first nibble of a PWE3 packet carried over an MPLS PSN has 
>> a    value of 0, it starts with a PWMCW. If the first nibble of a 
>> packet    carried over an MPLS PSN has a value of 1, it starts with a 
>> PW-ACH.    The use of any other first nibble value for a PWE3 packet 
>> carried    over an MPLS PSN is deprecated.
>>    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.
>>
>>
>>
>>
>>
>>  
>>    The PW set-up protocol or configuration mechanism determines 
>> whether    a PW uses a PW MPLS Control Word (PWMCW). Bits 0..3 differ 
>> from the    first four bits of an IP packet [BCP] and hence provide 
>> the    necessary MPLS payload discrimination.
>>    Word format as illustrated in Figure 1 above. It is however 
>> strongly    recommended that it also follows the following format:  
>
>
yes i think it needs a capital RECOMMENDED.

> "pointer?" needs to be defined.
omission - this needs to be removed ....

>>
>>    FRG (bits 8 and 9):
>>           These bits are used when fragmenting a PW payload. Their 
>> use           is described in [FRAG] which is currently a work in 
>> progress. 
>
>
> Simply refer to [FRAG] here as if this reference was solid so as not 
> to burden the RFC Editor with catching this sentence.
>
>>           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. 
> What is meant by "if required" - To me, this either MUST be trimmed or 
> not (no need to suggest an implementation loophole if none should exist).
>
no, it means that the payload might already be the correct length , 
hence it might not need to be trimmed....
Not all short packet have to be padded , some media do not require 
padding ....

>>           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 
>
>
> s/syncronise/synchronize
>
>>    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    
>>    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 
>
>
> "...necessary MPLS payload discrimination for ECMP and other methods 
> which require MPLS payload inspection..." or some such.
>
>>
r

> Please provide the [VCCV] reference earlier in this document, the 
> first time OAM is mentioned (and not necessarily here).
>
>>    or other message channel MUST be aware that this can potentially 
>> be    misused. Any application using the Associated Channel must 
>> therefore    fully consider the resultant security issues, and 
>> provide mechanisms    to prevent an attacker from using this as a 
>> mechanism to disrupt the    operation of the PW or the PE, and to 
>> stop this channel from being    used as a conduit to deliver packets 
>> elsewhere.
>>    be used. This is to prevent user payloads being fabricated in such 
>> a    way that they mimic the PW Associated Channel Header, and 
>> thereby    provide a method of attacking the application that is 
>> using the    Associated Channel.
>>    
>> 7.   Acknowledgements
>>    The IETF takes no position regarding the validity or scope of 
>> any      Intellectual Property Rights or other rights that might be 
>> claimed
>>
>>
>>
>>
>>  
>>    to pertain to the implementation or use of the technology 
>> described    in this document or the extent to which any license 
>> under such    rights might or might not be available; nor does it 
>> represent that    it has made any independent effort to identify any 
>> such rights.     Information on the procedures with respect to rights 
>> in RFC    documents can be found in BCP 78 and BCP 79.
>>    The IETF invites any interested party to bring to its attention 
>> any    copyrights, patents or patent applications, or other 
>> proprietary    rights that may cover technology that may be required 
>> to implement    this standard.  Please address the information to the 
>> IETF at ietf-
>>    [email-masked].
>>  
>>    Copyright (C) The Internet Society (2004). This document is 
>> subject    to the rights, licenses and restrictions contained in BCP 
>> 78, and    except as set forth therein, the authors retain all their 
>> rights.
>>    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
>> OR    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 
>> OF    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
>> IMPLIED    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>    
>> 10.    Normative References
>> Considerations Section in RFCs, Narten, T.,               Alvestrand, 
>> H., October 1998                   [RFC2992] RFC-2992:  Analysis of 
>> an Equal-Cost Multi-Path               Algorithm, C. Hopps, November 
>> 2000    [RFC3985] RFC-3985: PWE3 Architecture, Bryant, S. ed., Pate, 
>>               P. ed. , To be published.     [VCCV]    Nadeau, T., 
>> Aggarwal, T., "Pseudo Wire (PW) Virtual               Circuit 
>> Connection Verification (VCCV)", Internet               Draft, 
>> <draft-ietf-pwe3-vccv-04.txt>, Feb. 2005,               Work in 
>> Progress. 
>
>
> Line spacing above.
>
>
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 13 Apr 2005 16:28:05 -0400

Apologies for the CR/LF problem in the earlier email. I think that it should be 
fixed in this one.

I have reinserted Luca and I's comments inline marked with "Luca>" and "Mark>". 
Luca, I have a few additional comments/responses inline after yours.

Thanks,

- Mark

 >    to carry normal IP payloads.

Mark> Why not specify a MUST NOT here?

Luca> Some of the TDM PWs might start with a 4, as they do not have a
Luca> conformant CW.

So they are non-conformant and it should be duly noted. I don't think that just 
because the TDM specs happen to already be in violation we should relax the 
requirement for all. If the correct recommendation is that 4 and 6 can break 
ECMP, then go ahead and make it a MUST NOT here, and let the non-comformant PWs 
state in their doc that they are non-conformant and could possibly cause 
problems with ECMP. Otherwise, I think the issue may get lost.

I don't want to rathole on this. So, if it has already been hashed out in the WG 
extensively, I'll take a call from the chairs on this. But, it seems to me that 
since this is a basic construct for a lot of other documents, the fundamentals 
should be defined correctly.

 >    The Generic PW MPLS Control Word is shown in Figure 1.

Mark> Is this a capital RECOMMENDED or SHOULD?

Luca> yes i think it needs a capital RECOMMENDED.

Mark> "pointer?" needs to be defined.

Luca> omission - this needs to be removed ....

 >           If a non-zero length field is received, the PW payload MUST

Mark> What is meant by "if required" - To me, this either MUST be trimmed or
Mark> not (no need to suggest an implementation loophole if none should exist).
Mark>

Luca> no, it means that the payload might already be the correct length ,
Luca> hence it might not need to be trimmed....
Luca> Not all short packet have to be padded , some media do not require
Luca> padding ....

So, just to be sure, we are stating that the payload length field MUST be set 
for < 64 byte payloads regardless of media type, but there is an "if required" 
on the trimming when receiving a non-zero length as some media types do not need 
the length field.

Yes, I understand the issue here is ethernet, I'm not debating when it is 
necessary or not. I simply find it odd that we have an exception clause on the 
trimming, but not on the setting of the field.

Also, I think it might be helpful for interoperability to point out ethernet as 
an example of when this field would be used. This shouldn't take more than a 
sentence or two and perhaps a reference.

 >           number with the received sequence number is implementation

Mark> s/syncronise/synchronize

Mark> That's two I caught, there must be more. Please run the doc through a
Mark> spell checker.

 >    identified by the following header:

Mark> The first bits being 0x01 also differ this payload from being a PW
Mark> payload.

My point here was simply that 0x01 does more than just differ this packet from 
being a non-IP packet. It also makes it differ from being a PWE3 data packet.

 >    this associated channel, and is therefore out of the scope of this

Mark> Need to define REFERENCE (RFC3931).

 >    using the "IETF Consensus" policy defined in [RFC2434].

Mark> What about FMT IDs?

Luca> r

Looks like part of your response got cut off here.

 >               Draft, <draft-ietf-pwe3-vccv-04.txt>, Feb. 2005,

Mark> Line spacing above.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Apr 2005 22:55:46 +0100

Firstly I am sorry that I am so late in responding to this thread.
I was traveling last week.

I will attempt to persuade my copy of word to use an American
dictionary. The two spelling that Mark picked up were, believe,
both proper English spellings. I will also address the references
and other typos.

> Luca> Some of the TDM PWs might start with a 4, as they do not have a

Given the SONET proposal to use a the standard CW, I think that the use
of MUST NOT would be appropriate.

> Luca> yes i think it needs a capital RECOMMENDED.

Again, given the SONET change, I think that we can make this a SHOULD

> Luca> omission - this needs to be removed ....

Will do.

> So, just to be sure, we are stating that the payload length field MUST 
> be set for < 64 byte payloads regardless of media type, but there is an 
> "if required" on the trimming when receiving a non-zero length as some 
> media types do not need the length field.
> 
> Yes, I understand the issue here is ethernet, I'm not debating when it 
> is necessary or not. I simply find it odd that we have an exception 
> clause on the trimming, but not on the setting of the field.
> 
> Also, I think it might be helpful for interoperability to point out 
> ethernet as an example of when this field would be used. This shouldn't 
> take more than a sentence or two and perhaps a reference.

How about:

When the PSN path between the PEs includes an Ethernet, the PW packet
arriving at the CE-bound PE may include padding appended by the Ethernet
data link layer. The CE-bound PE uses the length field to determined
the size of the padding 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.

> Mark> That's two I caught, there must be more. Please run the doc through a

See other mail in response to Ron's proposal

>  >    an IP packet [BCP]. This provides the necessary MPLS payload discrimination.
> 
> My point here was simply that 0x01 does more than just differ this 
> packet from being a non-IP packet. It also makes it differ from being a 
> PWE3 data packet.
> 

How about

Bits 0..3 MUST be 0x01. This allows the packet the packet to be distinguished
from an IP packet [BCP] and from a PWE3 data packet.

> Mark> Need to define REFERENCE (RFC3931).

Will do.

> Mark> What about FMT IDs?

Propose to add:
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].

Also propose to change

FmtID:

           Format ID for the remaining 3 octets of the header......
                  ^^
to
           Format identifier for the remaining 3 octets of the header.....
                  ^^^^^^^^^^

to allow the for better consistency between the text and the
registry.

> Mark> Line spacing above.

Yes. Also need to add the RFC 3931 to references.

Stewart

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 20 Apr 2005 03:42:28 -0400

Stewart Bryant wrote:

> both proper English spellings. 

Apologies, my brain was programmed with an American bias beginning at a very 
early age. If the document consistently uses correct English spellings, I'm 
happy if the RFC Editor is happy.

Thanks,

- Mark

 > I will also address the references
> and other typos.
> 
>> strongly
>> be set for < 64 byte payloads regardless of media type, but there is 
>> an "if required" on the trimming when receiving a non-zero length as 
>> some media types do not need the length field.
>>
>> ethernet as an example of when this field would be used. This 
>> shouldn't take more than a sentence or two and perhaps a reference.
> 
> 
> 
> How about:
> 
>> packet from being a non-IP packet. It also makes it differ from being 
>> a PWE3 data packet.
>>
> 
> How about
>

---

From: Luca Martini <[email-masked]>
Date: Wed, 20 Apr 2005 11:29:52 -0600

Stewart Bryant wrote:

Snip ....

>> So, just to be sure, we are stating that the payload length field 
>> MUST be set for < 64 byte payloads regardless of media type, but 
>> there is an "if required" on the trimming when receiving a non-zero 
>> length as some media types do not need the length field.
>>
>> Yes, I understand the issue here is ethernet, I'm not debating when 
>> it is necessary or not. I simply find it odd that we have an 
>> exception clause on the trimming, but not on the setting of the field.
>>

CEE-bound PE -> need to change to something like "packet received on the 
PW from the PSN"
Snip...

>> Mark> Need to define REFERENCE (RFC3931).
can you please change to "bit 0 to bit 3 MUST be set to 0001 "

---

From: Luca Martini <[email-masked]>
Date: Wed, 13 Apr 2005 16:01:46 -0600

W. Mark Townsley wrote:

>
> Apologies for the CR/LF problem in the earlier email. I think that it 
> should be fixed in this one.
>
> I have reinserted Luca and I's comments inline marked with "Luca>" and 
> "Mark>". Luca, I have a few additional comments/responses inline after 
> yours.
>
> Thanks,
>
> - Mark
>
> >
> So they are non-conformant and it should be duly noted. I don't think 
> that just because the TDM specs happen to already be in violation we 
> should relax the requirement for all. If the correct recommendation is 
> that 4 and 6 can break ECMP, then go ahead and make it a MUST NOT 
> here, and let the non-comformant PWs state in their doc that they are 
> non-conformant and could possibly cause problems with ECMP. Otherwise, 
> I think the issue may get lost.
>
I agree.

> I don't want to rathole on this. So, if it has already been hashed out 
> in the WG extensively, I'll take a call from the chairs on this. But, 
> it seems to me that since this is a basic construct for a lot of other 
> documents, the fundamentals should be defined correctly.
>
> >
ok, we can expand it to explicitly state that trimming is required if 
the actual received packet length exceeds the value in the length files.

> Mark> What about FMT IDs?
yes- the fmt id=0  is the format described in this draft. So a new draft 
would be required to define a new format and a new fmt id.
we can either remove it and make it reserved - must be 0 ( my preference )
or create another IANA registry for it .

Luca