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

Luca,

Please find one follow-up inline.

Circa 8/16/2005 2:18 PM, Luca Martini said the following:
> 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.

PW Associated Channel Header (PW-ACH) as defined in MPLS CW.

> you mean ARCH ? in this case there is no requirements on the part of the
> ppp/hdlc to use the CW.

I meant that running an inband associated channel for OAM/VCCV might be
a 4th reason for desiring the use of the CW.

Thanks,

--Carlos.

> 
>>   [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
>>> pwe3@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>>   
>>
>>
>>  
>>
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3