> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Friday, May 07, 2010 9:29 PM > To: Brian E Carpenter > Cc: 6man > Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt] > > The more I think about "encouraging" locally defined use of > the flow label, the less I like it. > > The basic problem is that in the context we are discussing, > is for use by routers. > If you have locally defined flow label usage, then > 1) Any vendor selling to an operator has to somehow manage to > support their locally defined behavior.
This is not a problem to concern at all. Any vendor would support any useful features. That's the philosophy how the industry improves itself. The discussion should be whether the support for locally defined behavior is useful for operators. > 2) Operators MUST configure all their routers to properly > understand their flow label meaning. I am not agree on "MUST". There are two levels of it. On operator level, the locally defined behavior is optional. On the routers level, only routers that want to distinguish the packet according to locally defined flow label need to understand the flow label meaning; other routers can ignore flow label and do simple forwarding like before. > 2') Given that it can not be counted on, even the global > interpretation such as the use of non-zero flow-labels for > ECMP/LAG balancing would be to be off by default, since there > would be no default expect ability to match that use. Agree, the collision may happen. One of the possible approach is that FL domain could be hierarchical. Global FL domain can enforce certain behaviors that would be default for all FL domain (I guess this would be IETF standards). A sub FL domain needs to inherit behaviors from its parents FL domain as default. In flat level, B FL domain does not have to understand A FL domain and its egress routers may overwrite flow label from A. > 3) This is quite fragile. Given that there is no indication > in the packet of what meaning of flow-label was intended, > there is nothing that will alert an operator if (as seems > periodically inevitable some of the routers are attempting to > apply a different interpretation than the operator intends. Except for global FL domain, all FL domains are under control of operators. So are all routers. The egress routers of FL domains can overwrite flow labels. So operators can overwrite all flow label with different interpretations. > Basically, from a vendor's perspective, a multiplicity of > local interpretations of flow label is a serious impediment > to implementing any usage of flow label at all. A simple rule can be applied: handle what routers can understand and ignore others. > One could argue that as long as the routers are all from one > vendor, they will support the same local interpretation. I > hope we are not going there! There is nothing to do with single vendor. Vendors only provide the ability to enable operator to use/define flow label. Interoperation between different vendor is the reason we make standards here. Otherwise, private implementation from vendor can support almost everything. As one of the author, I personally prefer approach 2 since it encourage operators to use flow label. It enable operator to define the meaning or usage of flow label in their network scope as almost whatever they want. Best regards, Sheng > Hence, to be clear and specific, I support approach 1, and > oppose approach 2. > > Yours, > Joel > > > Brian E Carpenter wrote: > > Hi, > > > > This is revised again according to discussion on the list, and some > > off-list discussion with Shane Amante in particular. > > > > Firstly, since there seemed to be a feeling that a full > update of RFC > > 3697 is better than publishing a set of changes, this is now just > > informational, although written using normative language. > > The major next step would be a 3697bis draft. > > > > Secondly, it offers the WG a binary choice as the main decision: > > > > "There appear to be two viable approaches: > > 1. Definitively forbid locally defined use of the flow label. > > Strengthen RFC 3697 to say that hosts SHOULD set a > pseudo-random > > label value, which would clarify and limit its > possible uses. In > > particular, its use for load balancing and possibly > as a nonce > > would be encouraged. > > 2. Encourage locally defined use of the flow label. > This approach > > would make the flow label mutable and would exclude > any use case > > depending on end-to-end immutability. It would encourage > > applications of a pseudo-random flow label, such as load > > balancing, on a local basis, but it would exclude end-to-end > > applications such as [I-D.blake-ipv6-flow-label-nonce]." > > > > Please, can we focus on this choice rather than the fine details, > > initially? Also, please read the draft as a whole; looking at diffs > > would be quite confusing. > > > > Brian + Sheng > > > > -------- Original Message -------- > > Subject: I-D Action:draft-carpenter-6man-flow-update-03.txt > > Date: Thu, 6 May 2010 18:00:01 -0700 (PDT) > > From: internet-dra...@ietf.org > > Reply-To: internet-dra...@ietf.org > > To: i-d-annou...@ietf.org > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > Title : Update to the IPv6 flow label specification > > Author(s) : B. Carpenter, S. Jiang > > Filename : draft-carpenter-6man-flow-update-03.txt > > Pages : 11 > > Date : 2010-05-06 > > > > Various published proposals for use of the IPv6 flow label are > > incompatible with its existing specification in RFC 3697. This > > document proposes changes to the specification that permit > additional > > use cases. The concept of flow label domains is > introduced, with the > > label possibly being rewritten at domain boundaries. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-0 > > 3.txt > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
