Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks
RFC 4618

[Ballot discuss]
> It is also
> recommended that PPP devices MUST NOT negotiate PPP MRUs larger than
> that of the AC MTU.

"Recommend that ... MUST NOT ..."? Perhaps you meant "... recommended
that .... do not ...".

But there's also a more fundamental issue with this requirement: if I
have understood the architecture correctly, the PPP endpoints are
not in the same device which terminates the PW. As a result, the
PPP endpoints can be legacy devices with no knowledge of this
arrangement. Suggest changing the requirement to:

  It is also RECOMMENDED that the PPP devices be configured to not
  negotiate PPP MRUs larger that of the AC MTU.


Comment: Nits:

s/asummmed/assumed/g

Missing Reference: [Q922] is mentioned on line 193, but not defined

Missing Reference: [Q933] is mentioned on line 194, but not defined

[Ballot comment]
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".

[Ballot comment]
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.

[Ballot comment]
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]/

[Ballot comment]
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.

[Ballot discuss]
Section 4.1:
"The next 2 bits are reserved for future use, and MUST be ignored."

In my opinion a mandatory to set pattern should be defined. Otherwise it will be required to use out of band to negotiate use of this field. To not necessarily require that I propose the following change:

"The next 2 bits are reserved for future use, and MUST be set to 0 on transmission and MUST be ignored on reception."

8. IANA Considerations

  This document has no IANA Actions.

This document does not define any IANA actions due to that RFC-ietf-pwe3-iana-allocation-15.txt has made the necessary registrations for this document if I understand things correctly. I would propose a informative reference that this registration has occured.

[Ballot discuss]
Section 4.1:
"The next 2 bits are reserved for future use, and MUST be ignored."

In my opinion a mandatory to set pattern should be defined. Otherwise it will be required to use out of band to negotiate use of this field. To not necessarily require that I propose the following change:

"The next 2 bits are reserved for future use, and MUST be set to 0 on transmission and MUST be ignored on reception."

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

This document has been fully reviewed by the PWE3 WG.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

We have no concerns.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

We have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is firm consensus for the design described in this document.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director.

No

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes

1.h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

Yes, it is correctly split into normative and informative references.
All normative references are either RFCs, or in the RFC-Editor
queue.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

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.

This enables service providers to offer "emulated" HDLC, or PPP
link services over existing MPLS networks. This document specifies
the encapsulation of PPP/HDLC Packet Data Units (PDUs) within
a PW.

* Working Group Summary

This work has been thoroughly analysed by the working group
and there is consensus for the design.
* Protocol Quality

There are many implementations of this protocol, and it is
in operational service.