Skip to main content

Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks
draft-ietf-pwe3-hdlc-ppp-encap-mpls-09

Yes

(Mark Townsley)

No Objection

(Bill Fenner)
(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)

Note: This ballot was opened for revision 09 and is now closed.

Lars Eggert
No Objection
Comment (2006-05-22) Unknown
Section 2., para. 2:

>    The following figure describes the reference models which are derived
>    from [ARCH] to support the HDLC/PPP PW emulated services. The reader
>    is also asummmed to be familiar with the content of the [ARCH]
>    Document.

        Then [ARCH] should be normative.

Section 3., para. 2:

>    The applicability statements in [FRAME] also apply to the Frame Relay
>    port mode PW described in this document.

        Then [FRAME] should probably be normative.

Section 3., para. 5:

>      - A Frame Relay Port mode PW, or HDLC PW, does not process any
>        packet relay status messages or alarms as described in [Q922]
>        [Q933]

        [Q922] and [Q933] are not referenced.

Section 4.1., para. 12:

>    The next 2 bits are reserved for future use, and MUST be ignored.

        See Magnus' DISCUSS on this.

Section 4.1., para. 13:

>    The next 16 bits provide a sequence number that can be used to
>    guarantee ordered packet delivery. The processing of the sequence
>    number field is OPTIONAL.

        What if more packets can be in flight (long, fat pipe)?
        "Processing" is vague, what does it involve? Cite [CW].

>    The sequence number space is a 16 bit, unsigned circular space. The
>    sequence number value 0 is used to indicate an unsequenced packet.

        If it is circular, it wraps to zero. I think [CW] says that zero
        needs to be skipped for this reason - reference?

Section 4.1.1., para. 1:

>    The procedures described in section 4 of [CW] MUST be followed to
>    process the sequence number field.

        Odd to have this sentence in its own section. Previous paragraphs
        should have already referred to [CW] for details of sequence number
        processing.

Section 4.2., para. 1:

>    The network MUST be configured with an MTU that is sufficient to
>    transport the largest encapsulation packets. 

        Not sure if we can have RFC2119 text about a configuration requirement
        on the underlying network.

Section 7., para. 1:

>    As explained in [ARCH], the PSN carrying the PW may be subject to
>    congestion, with congestion characteristics depending on PSN type,
>    network architecture, configuration, and loading. During congestion
>    the PSN may exhibit packet loss that will impact the service carried
>    by the PPP/HLDC PW.  In addition, since PPP/HDLC PWs carry an
>    unspecified type of services across the PSN, they cannot behave in a
>    TCP-friendly manner prescribed by [RFC2914]. In the presence of
>    services that reduce transmission rate, PPP/HDLC PWs will thus
>    consume more than their fair share and SHOULD be halted.

        In addition, if a PW carries multiple TCP-friendly connections,
        the aggregate may still not necessarily be TCP-friendly.
Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection (2006-05-24) Unknown
I agree with the first part of Magnus' comment. However, since he
already has a "discuss" on this, and it seems like a simple matter
to resolve using an RFC editor's note (assuming that the authors do
not object), I figured that I could register a "no objection".
Russ Housley Former IESG member
No Objection
No Objection (2006-05-24) Unknown
  In many places: s/port to port transport/port-to-port transport/

  A space needs to be inserted at the beginning of Figure 5b to align
  the arrow at the top of the figure.

  Section 9: s/in [ARCH][CONTROL]/in [ARCH] and [CONTROL]/
Ted Hardie Former IESG member
No Objection
No Objection (2006-05-24) Unknown
The technical summary appears to be missing a verb:

 This draft describes how a Point to Point Protocol (PPP), or High-
 Level Data Link Control (HDLC) Protocol Data Units over an 
 MPLS network without terminating the PPP/HDLC protocol.