Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks
RFC 4618
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
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 steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Ross Callon; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
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.