Skip to main content

Avoiding Equal Cost Multipath Treatment in MPLS Networks
RFC 4928

Yes

(Alex Zinin)
(Ross Callon)
(Sam Hartman)

No Objection

(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Magnus Westerlund)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)

Abstain


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

(Alex Zinin; former steering group member) Yes

Yes ()

                            

(Ross Callon; former steering group member) (was No Objection, Discuss) Yes

Yes ()

                            

(Sam Hartman; former steering group member) Yes

Yes ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection (2005-12-01)
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.

(Bert Wijnen; former steering group member) No Objection

No Objection (2005-12-01)
I share concerns raised by Allison, Margaret and Bill.

(Bill Fenner; former steering group member) No Objection

No Objection (2005-12-01)
[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"

(Brian Carpenter; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2007-03-08)
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?

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) (was Discuss) No Objection

No Objection (2007-02-01)
>      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

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) Abstain

Abstain (2005-11-30)
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.

(Ted Hardie; former steering group member) Abstain

Abstain (2005-11-28)
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.