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

[Carlos Pignataro <[e-mail]>]

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

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

   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
***CP: better to reference [FRAG] (since covered in Section 3.2).

   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/

-----

3. Section 4.1


   When the PE detect a status change in the attachment circuit status,

***CP:         ^detects

   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

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

-----

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

-----

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)

   [snip]

   When the PE detect a status change in the attachment circuit status,

***CP:         ^detects

   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/

-----

6. Section 5.

***CP: Missing TTL setting in the LSE?

-----

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


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
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

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