On Thu, 15 Apr 2010 08:34:40 -0600 Shane Amante <[email protected]> wrote:
> 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 <[email protected]> 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. > You're right, I've been influenced by my past experience. In that (IPv4) scenario, dscp was set when traffic entered via the ISP transit links and that was for billing purposes. Traffic coming from customers had the dscp values left alone. As long resetting it on egress was an option operation, I think it would facilitate both points of view. (That dscp for billing idea was implemented before I started at that organisation. I didn't mind the idea of labelling packets to categorise them, however I didn't like using the dscp, as that has a specific QoS meaning. The flow label field seems to me to be a bit more general purpose, so I'd think the flow label would be the right field to use in that scenario) > 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. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
