[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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







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