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. 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. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
