Avoiding Equal Cost Multipath Treatment in MPLS Networks
draft-ietf-mpls-ecmp-bcp-03
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 IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
(was No Objection, Discuss)
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2005-12-01)
Unknown
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 IESG member
No Objection
No Objection
(2005-12-01)
Unknown
I share concerns raised by Allison, Margaret and Bill.
Bill Fenner Former IESG member
No Objection
No Objection
(2005-12-01)
Unknown
[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 IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2007-03-08)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
(was Discuss)
No Objection
No Objection
(2007-02-01)
Unknown
> 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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
Abstain
Abstain
(2005-11-30)
Unknown
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 IESG member
Abstain
Abstain
(2005-11-28)
Unknown
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.