Skip to main content

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;-)