Hi Mark, On Apr 15, 2010, at 04:36 MDT, Mark Smith wrote: > Hi Brian, Shane, > > On Thu, 15 Apr 2010 15:52:15 +1200 > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> >> Regards >> Brian Carpenter >> >> >> >> >> On 2010-04-15 14:10, Shane Amante wrote: >>> Brian, Mark, >>> >>> Brian: FWIW, I like the direction of this version of draft >>> much better than previous versions; however, I agree with >>> Remi that the current version is a bit confusing at the >>> moment and could likely be rewritten to be more simple and >>> just obsolete RFC 3967. In addition, I'm still a bit unclear >>> and, therefore, uncomfortable on the proposal with respect to >>> flow-labels within an "administratively defined domain". In >>> particular, if one administrative domain has set their own >>> "locally defined" flow-label, I think the draft could benefit >>> from a stronger emphasis that the flow-label MUST or, at >>> least, SHOULD be reset to 0 upon /leaving/ that domain, >>> otherwise the next domain may (or, will?) misinterpret the >>> meaning of the incoming "locally-defined" flow-label. The >> >> I'm personally quite attracted by this. It does further damage >> to the sacred principle that the flow label is immutable, >> but maybe that is the inevitable result anyway. >> > > I think the way the dscp is handled provides a good example. If your > network is QoS enabled, then you reset the dscp value upon ingress > because you can't trust it, otherwise you completely ignore the value of > it as it traverses your network. I think the same model can be applied > to flow labels.
I believe we're in agreement on the above point. > For an ISP, if it considered it's network to be a separate flow domain > from that of it's customers' networks (and my position is that I > would, for both business and residential customers), then every egress > interface towards a customer would have to be resetting the flow label. > ISPs with many PPPoE/PPP customers have as many virtual egress > interfaces as they do customers. I think a lot of those customers > wouldn't implement a flow domain, so having every virtual interface > reset the flow label back to 0 on packet egress would be a relatively > high price for the value it provides to only a small number of > customers. I acknowledge the operational burden of resetting the flow-label on egress; however, the same challenge exists on ingress, as well. IOW, if you don't trust the flow-label setting coming from another "administratively defined domain" (ADD), then you'll always need to have to reset (and/or set) it on ingress before it transits your ADD ... wh/ would translate into roughly the same problem. Regardless, the way the draft is written now it still seems a bit ambiguous (at best) as to whether the next, downstream "administratively defined domain" (ADD) is supposed to accept "as-is" the incoming, perhaps locally-defined in another ADD, flow-label or not. Most importantly consideration should be given to what the operational implications will be if that were the case. IOW, it could result in very poor load-balancing if the incoming locally-defined flow-label does not correspond to, say, a 5-tuple "microflow" and, instead, means something else entirely (e.g.: a "nonce" as per one of the many proposals to recast/re-use/abuse the flow-label). The reason I offered the proposed text was to make it abundantly clear that there should be no assumptions made about the flow-label once it leaves one "administratively defined domain", since one ADD can't tell if it's locally-defined or not. In summary, I think the text could stand to be made more clear that a flow-label needs to be reset /either/ on egress from or ingress to an ADD[1]. I think, in practice, you're likely correct that most operators would probably (re)set it only on ingress (similar to IP DSCP or IPv6 TC), since that's a common operation. Lastly, FWIW, I'd personally rather not carve out a bit in the flow-label (as was discussed in previous revisions of this draft), for "locally-defined" flow-labels since the same operational problem exists. Only in that case, as a packet enters my ADD I won't be able to do anything with it. This means I need to have even more complex logic in routers to ignore those flow-labels with that bit set and then attempt to look for Layer-4 Transport header info at every hop for load-balancing calculations. -shane [1] I should note that if one or more "consenting" ADD's want to exchange a locally defined flow-label between them, then that's their right, i.e.: your network(s), your rules. However, I would typically expect this to be an exception, not the rule, given the implications a misunderstanding or misinterpretation a "locally-defined" flow-label might have. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
