Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

[Warren Kumari <[e-mail]>]

On Mon, Mar 14, 2016 at 11:10 AM Tom Herbert <[e-mail]> wrote:

> On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari <[e-mail]> wrote:
> >
> >
> > On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert <[e-mail]> wrote:
> >>
> >> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter
> >> <[e-mail]> wrote:
> >> > On 14/03/2016 09:59, Tom Herbert wrote:
> >> > ...
> >> >> the point of using flow label is
> >> >> that it eliminates the need to parse extension headers in the first
> >> >> place for the ECMP use case. It would be nice if this benefit was and
> >> >> the need for flow label support were better enunciated in the draft.
> >> >
> >> > I'll be the least likely person on the planet to disagree with that,
> >> > but it is already part of the IPv6 standards (RFC6437 - see 2nd and
> 3rd
> >> > paragraphs of the Introduction) and has been in the IPv6 Node
> >> > Requirements
> >> > since 2011 (RFC434).
> >> >
> >> Brian,
> >>
> >> These are good descriptions flow label usage, but I don't see that
> >> they set requirements as to 1) whether end host must/should/may send
> >> non-zero flow labels with flow entropy 2) whether ECMP devices
> >> must/should/may use non-zero flow labels as input to their hash, or 3)
> >> if hosts use the flow label for EMCP must/should/may they parse any
> >> deeper to extract additional L4 entropy. RFC6438 comes close and
> >> answering #1, but that RFC is only applicable to tunnels.
> >>
> >> Pertaining to this draft, there is an observation that flow labels
> >> would obviate the need for middle boxes to parse the header chain,
> >
> >
> > I think I must have missed something somewhere / lost the plot -- which
> > draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops?
> > I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at
> all
> > -- if the *only* thing that the middlebox is doing is load-balancing /
> ECMP,
> > then this may be true, but in many cases "middleboxes" (a term which
> seems
> > about as vague as "thingies") are doing many other things, including
> > filtering, encapsulation, translation, monitoring / measurement,
> > "optimization", prioritization, etc.
> >
> Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses
> ECMP.


Nod.


> ECMP is a fundamental feature in switches,


Nod.

> we currently rely it
> on to get good load balancing across network fabrics.
>

Yah, nod, nod, fully agree.

I see where the disconnect is now -- to me, switches are not "middleboxes",
they fall into their own bucket ("switches" :-P).
I think we are in violent agreement, we are just using different terms.

To me, middleboxes are IP devices which are not designed to more than just
packet forwarding / filtering - but this is a vague description, and more
of a "I know it when I see it" (kind of like the entertaining (?)
discussions of the difference between a bridge and a switch, or a L3 switch
and a router).

RFC 3234 ("Middleboxes: Taxonomy and Issues") has a much better definition
than mine :-P
W



> > But, as I said, I suspect I've lost the plot somewhere along the line...
> > W
> >
> >>
> >> however the draft also states historically neither end nodes nor
> >> routers support. It seem like there should at least be a
> >> recommendation in "Future work"  section on how to attain widespread
> >> support flow label.
> >>
> >> Thanks,
> >> Tom
> >>
> >> >     Brian
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
>