Avoiding Equal Cost Multipath Treatment in MPLS Networks
RFC 4928

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

(Ross Callon) (was No Objection, Discuss) Yes

(Sam Hartman) Yes

(Alex Zinin) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2007-03-08)
No email
send info
I wonder if the document should have a clearer statement
of its limitations. Is this truly best (Bcp) that we can achieve
in this space?

(Brian Carpenter) No Objection

(Margaret Cullen) (was Discuss) No Objection

(Bill Fenner) No Objection

Comment (2005-12-01 for -)
No email
send info
[Ted: The nibble searching is described as background to why the solution is necessary; the define-your-payload-to-not-look-like-IP is the proposed solution in the BCP.  The BCP isn't about how routers should do ECMP, it's about how people defining new MPLS applications should structure their packets if they want to avoid accidentally triggering this known behavior.]

I basically agree with the combination of Mark and Margaret's comments:
- I wondered why not 2 or 3 if 0 or 1 was ok.  (If there's a real reason, that's fine - say so)
- I'd like to see "applications SHOULD use first nybble 0, 1, 2 or 3 if they want to avoid ECMP" and I wish there was somewhere appropriate to say "routers MUST NOT perform ECMP on packets with first nybble 0, 1, 2 or 3"

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Allison Mankin) No Objection

Comment (2005-12-01 for -)
No email
send info
No further objection, but we should consider putting on an IESG note like:

"the wg knows this pragmatic practice, brittle in the sense
used in RFC 3424, 4.3, and not future-proof.

It's not a condescending note, and I think it's the status.

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) (was Discuss) No Objection

Comment (2007-02-01)
No email
send info
>      This document describes the Equal Cost Multipath (ECMP) behavior
>      of currently deployed MPLS networks and makes best practice
>      recommendations for anyone defining an application to run over an
>      MPLS network and wishes to avoid such treatment.
>

Avoid what treatment? I know what you mean, but that's because I am familar with the document. How about just replacing "and wishes to avoid such treatment" with "where ECMP may be deployed."

>  within a network core, the hashing in based mainly or exclusively on
>
s/in/is

Magnus Westerlund No Objection

(Bert Wijnen) No Objection

Comment (2005-12-01 for -)
No email
send info
I share concerns raised by Allison, Margaret and Bill.

(Ted Hardie) Abstain

Comment (2005-11-28 for -)
No email
send info
I don't think it would be appropriate to DISCUSS this, since I can see no way in which this could be changed to clear the objection.  But I personally believe this is a stunningly bad idea.  Attempting
to get around current operational behavior by creating this application label simply pushes the
problem down one more label in the stack.  The nibble-seeking behavior certainly makes it
look like those desiring to perform ECMP are willing to do packet inspection--why do we believe
adding a label will not simply cause this nibbling be done further down?  And as operational
behavior changes, this mechanism will be nothing but cruft.

(David Kessens) Abstain

Comment (2005-11-30 for -)
No email
send info
This document does not address any problem or issue that has anything to do with the Internet.

From the IETF Mission statement (RFC3935):

"The goal of the IETF is to make the Internet work better.
   
 The mission of the IETF is to produce high quality, relevant
 technical and engineering documents that influence the way people
 design, use, and manage the Internet in such a way as to make the
 Internet work better.  These documents include protocol standards,
 best current practices, and informational documents of various kinds."

I don't see anything in this document that will make the Internet work better.