MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-09

Note: This ballot was opened for revision 08 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes ( for -08)
No email
send info

(Sean Turner; former steering group member) Yes

Yes (2014-02-20 for -08)
No email
send info
Liked this one.

(Stewart Bryant; former steering group member) Yes

Yes (2014-02-18 for -08)
No email
send info
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 steering group member) No Objection

No Objection (2014-02-17 for -08)
No email
send info
-- 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 steering group member) No Objection

No Objection ( for -08)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection (2014-02-18 for -08)
No email
send info
This document is a real treasure. Thank you for producing it.

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-02-19 for -08)
No email
send info
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;-)