Re: [PWE3] draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt last call

[Luca Martini <[e-mail]>]

Carlos,


Comments in line below.

Thanks.
Luca

Carlos Pignataro wrote:

>***Please find comments on draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
>marked `***CP':
>
>
>-----
>
>1. Section 3.1:
>
>   There are three requirements that may need to be satisfied when
>   transporting layer 2 protocols over an MPLS backbone:
>
>***CP: Is a PW-ACH a 4th requirement to use CW?
>
>  
>
PW-ACH ? Not sure what this is.
you mean ARCH ? in this case there is no requirements on the part of the 
ppp/hdlc to use the CW.

>   [snip]
>
>   In the above diagram the first 4 bits are set to 0 in indicate PW
>   data [ARCH].
>
>***CP: Maybe the above reference should be to the CW draft.
>
>  
>
indeed. changed.

>   The next 4 bits provide space for carrying protocol specific flags.
>   These are not used for HDLC/PPP and they They MUST be set to 0 when
>   transmitting, and MUST be ignored upon receipt.
>
>***CP: Bits 8 and 9 are missing in this description. A "The next 2
>***CP: bits..." is missing, to say either "Reserved" as in Figure 2 or
>  
>
yes - fixed,

>***CP: better to reference [FRAG] (since covered in Section 3.2).
>
>  
>
no - I would like to avoid a normative reference to FRAG.

>   The next 6 bits provide a length field, which is used as follows: If
>   the packet's length (defined as the length of the layer 2 payload
>
>-----
>
>2. Section 3.2
>
>***CP: s/exeeed/exceed/
>
>  
>
ok.

>-----
>
>3. Section 4.1
>
>
>   When the PE detect a status change in the attachment circuit status,
>
>***CP:         ^detects
>
>  
>
ok.

>   such as an attachment circuit physical link failure, or the AC is
>
>   [snip]
>
>   The HDLC mode is suitable for port to port transport of Frame Relay
>   UNI or NNI traffic. It must be noted, however, that this mode is
>   transparent to the FECN, BECN and DE bits. Since all packets are
>
>***CP: I wonder if the above para should be moved to Section 4.2
>
>  
>
it is almost repeated in section 4.2, I think it's fine as is .

>   [snip]
>
>   The PW of type 0x0006 "HDLC" will be used to transport HDLC frames
>   while PW of type 0x0007 "PPP" will be used to transport PPP frames.
>
>***CP: `PW of type 0x0007 "PPP"...' should probably go into Section 4.3.
>***CP: Or all the PW Types (including FR Port mode currently in Section
>***CP: 4.2) together.
>
>  
>
ok fixed.

>-----
>
>4. Section 4.2
>
>   between a FR device and a PE is either a FR UNI or NNI. The set of n
>   FR VCs between the two FR ports P1 and P2 which are controlled by the
>   same signaling channel using DLCI=0, are mapped into one PW. Hence
>
>***CP: It seems to me that "are controlled" could be more descriptive.
>***CP: It could also make explicit that the PVC status management
>***CP: procedures per Q.933 Annex A happen between CEs. This would be
>***CP: inline with the second to last sentence of Section 4.3
>
>  
>
ok.

>-----
>
>5. Section 4.3
>
>   PPP mode provides point to point transport of PPP encapsulated
>   traffic, as specified in [PPP]. The PPP PDU is transported in its
>   entirety, including the protocol field (whether compressed using PFC
>
>***CP: Protocol Field Compression not defined (only the acronym)
>
>  
>
ok.

>   [snip]
>
>   When the PE detect a status change in the attachment circuit status,
>
>***CP:         ^detects
>
>  
>
ok

>   such as an attachment circuit physical link failure, or the AC is
>   administratively disabled, the PE MUST send the appropriate PW status
>   notification message that corresponds to the HDLC AC status. It
>
>***CP: s/HDLC/PPP/
>
>  
>
ok

>-----
>
>6. Section 5.
>
>***CP: Missing TTL setting in the LSE?
>
>-----
>
>  
>
a particular TTL setting  is a matter of local policy ... not defined here.

>7. General:
>
>***CP: The Title, Abstract, Introduction and Section 3.1 only center
>***CP: around and explicitly cite HDLC and PPP (search for `PPP/HDLC')
>***CP: and do not mention "FR Port Mode" (added later).
>
>
>  
>
Yes. This is on purpose. F/R port mode is just a special terminology for 
an HDLC PW.
I'm not sure we need to mention this in the abstract. There should be a 
pointer to this draft from the frame-relay draft. That is , in my mind, 
sufficient for somebody to find frame-relay port mode ...



>Thanks !
>
>--Carlos.
>
>Circa 5/31/2005 11:36 AM, Stewart Bryant said the following:
>  
>
>>This is the start of last call for
>>
>>draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
>>
>>Last call will close on 20 June 2005
>>
>>- Stewart
>>
>>_______________________________________________
>>pwe3 mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>    
>>
>
>  
>

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