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

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2006-05-31
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-05-29
09 Amy Vezza IESG state changed to Approved-announcement sent
2006-05-29
09 Amy Vezza IESG has approved the document
2006-05-29
09 Amy Vezza Closed "Approve" ballot
2006-05-29
09 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2006-05-26
09 (System) Removed from agenda for telechat - 2006-05-25
2006-05-25
09 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-05-25
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2006-05-25
09 Yoshiko Fong IANA Comments:

As described in the IANA Considerations section, we understand this document to have NO IANA Actions.
2006-05-25
09 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2006-05-25
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-05-25
09 Jari Arkko
[Ballot discuss]
> It is also
> recommended that PPP devices MUST NOT negotiate PPP MRUs larger than
> that of the AC MTU.

"Recommend …
[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
2006-05-25
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko by Jari Arkko
2006-05-25
09 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-05-25
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-05-25
09 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-05-24
09 Ross Callon [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Undefined by Ross Callon
2006-05-24
09 Ross Callon
[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 …
[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".
2006-05-24
09 Ross Callon [Ballot Position Update] New position, Undefined, has been recorded for Ross Callon by Ross Callon
2006-05-24
09 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2006-05-24
09 Ted Hardie
[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 …
[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.
2006-05-24
09 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2006-05-24
09 Russ Housley
[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 …
[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]/
2006-05-24
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2006-05-24
09 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt
2006-05-24
09 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-05-24
09 Yoshiko Fong IANA Comments:

As described in the IANA Considerations section, we understand this document to have NO
IANA Actions.
2006-05-22
09 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza
2006-05-22
09 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Undefined by Lars Eggert
2006-05-22
09 Lars Eggert
[Ballot comment]
Section 2., para. 2:

>    The following figure describes the reference models which are derived
>    from [ARCH] to support the …
[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.
2006-05-22
09 Lars Eggert [Ballot Position Update] New position, Undefined, has been recorded for Lars Eggert by Lars Eggert
2006-05-22
09 Magnus Westerlund
[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 …
[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.
2006-05-22
09 Magnus Westerlund
[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 …
[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."
2006-05-22
09 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-10
09 Mark Townsley Ballot has been issued by Mark Townsley
2006-05-10
09 Mark Townsley Placed on agenda for telechat - 2006-05-25 by Mark Townsley
2006-04-06
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-03-23
09 Amy Vezza Last call sent
2006-03-23
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-03-23
09 Mark Townsley Last Call was requested by Mark Townsley
2006-03-23
09 Mark Townsley State Changes to Last Call Requested from Publication Requested by Mark Townsley
2006-03-23
09 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2006-03-23
09 Mark Townsley Ballot has been issued by Mark Townsley
2006-03-23
09 Mark Townsley Created "Approve" ballot
2006-03-23
09 (System) Ballot writeup text was added
2006-03-23
09 (System) Last call text was added
2006-03-23
09 (System) Ballot approval text was added
2006-03-22
09 Dinara Suleymanova
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 …
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.
2006-03-22
09 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-02-13
08 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt
2006-01-05
07 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-07.txt
2005-12-28
06 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-06.txt
2005-05-04
05 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
2005-03-15
04 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-04.txt
2004-04-21
03 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt
2004-03-26
02 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt
2004-03-25
01 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-01.txt
2003-06-16
00 (System) New version available: draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt