MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-09
Yes
(Adrian Farrel)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
Note: This ballot was opened for revision 08 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -08)
Unknown
Sean Turner Former IESG member
Yes
Yes
(2014-02-20 for -08)
Unknown
Liked this one.
Stewart Bryant Former IESG member
Yes
Yes
(2014-02-18 for -08)
Unknown
This is a well written document. However I do have some comments that I would ask the authors to consider: In 2.1.7. MPLS Fast Reroute (FRR), there should be some discussion of RFC5286, and possibly RFC5714 and draft-ietf-rtgwg-remote-lfa since they are all deployed in MPLS networks. ===== 1. Introduction and Document Scope The initial purpose of this document was to address concerns raised on the MPLS WG mailing list about shortcomings in implementations of MPLS forwarding. SB> "The initial purpose" implies a later purpose, but that is not clear. ===== SB> It would be useful to warn the reader of the issues with non-IETF definitions of MPLS. For example the G8110 the definition of MPLS led to incorrect assumptions which were noted in RFC5704 ==== 2.1.3. Time Synchronization "PTP and NTP timestamp formats differ slightly. " SB> The difference is surely fundamental! ==== PW services which are not timing critical bit streams in nature are cell oriented or frame oriented. SB> Actually some ATM cell streams are also timing critical ==== 2.3. Packet Rates Internet service providers and content providers at one time specified full rate forwarding with 40 byte payload packets as a requirement. Today, this requirement often can be waived if the provider can be convinced that when long sequence of short packets occur no packets will be dropped. SB> Doesn't this then feed the buffer bloat problem? ==== Appendix A. Organization of References Section This would be more useful as section 8.0 ==== You might want to give a heads up to the work on SPRING which will further inflate the label stack. ==== It might be useful to add some text on IPFIX in particular IEs 46,47, 70..79, 90, 91, 140, 194
Barry Leiba Former IESG member
No Objection
No Objection
(2014-02-17 for -08)
Unknown
-- Section 1.2 -- This document is informational. The upper case [RFC2119] key words are not used in this document, except in the following cases. In fact, there's quite a lot of 2119 language in here, and this makes it sound like there isn't. I suggest re-wording this: NEW This document is informational. The upper case [RFC2119] key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document in the following cases. END
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -08)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -08)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -08)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-02-18 for -08)
Unknown
This document is a real treasure. Thank you for producing it.
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-19 for -08)
Unknown
Excellent document, thanks. 2.4.5.2, last para: "This document makes the following recommendations." Is some text here a cut'n'paste error? 2.6.1, I don't get "Only where hardware can identify a signature and the portion of packet covered by the signature is cryptographic authentication highly beneficial in protecting against DoS attacks." What is that meant to mean? I'm guessing signature there does not mean digital signature. 2.6.1, To be honest this section reads like there's not that much known about DoS mitigation at this layer, (or that someone's not saying:-) Either would be surprising. Is there not more to be said? (Honest question, I don't know how DoS-mitigation is done down here;-)