Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)

[t.petch <[e-mail]>]

----- Original Message -----
From: "Warren Kumari" <[e-mail]>
To: "Ronald Bonica" <[e-mail]>; "Brian Haberman"
<[e-mail]>; <[e-mail]>
Sent: Thursday, March 24, 2016 5:25 PM
> On Wed, Mar 23, 2016 at 9:01 PM Ronald Bonica <[e-mail]>
wrote:
>
> > Brian,
> >
> > Your question is not only appropriate, it is telling!
> >
> > Consider the following:
> >
> > - Today only ten HBH Options are defined
> > - Of these, Pad and PadN don't do very much
> > - Many of the others aren't widely deployed
> >
> > Many routing protocol designers avoid the Router Alert Option in
favor of
> > other mechanisms. For example, many RSVP-TE implementations avoid
the IPv4
> > router alert option. Alternatively, they address the RSVP packet to
the
> > next node in the path.  I suspect that they will do likewise when
then
> > implement RSVP-TE over IPv6. The designers of other protocols may
follow
> > suite.
> >
> > The WG is at an inflection point. Options are:
> >
> > a) continue down the path of RFC 7045 wrt HBH
> > b) continue down the path of the initial versions of
> > draft-ietf-6man-hbh-header-handling
> > c) deprecate the HBH Options Extension Header
> >
> > None of these are very appealing.
> >
> > If we continue down the path of RFC 7045, we break the semantics of
the
> > first two bits of the Option Type. If we are to do that, we should
probably
> > repurpose draft-ietf-6man-hbh-header-handling-01 to:
> >         - document the decision
> >         - deprecate the semantics of the first two bits of the
option type
> > (because we broke them)
> >         - explain how this deprecation limits the applicability of
HBH.
> > (i.e., HBH cannot support applications that absolutely require the
01/10/11
> > semantic)
> >         - figure out if we have broken any existing HBH options that
start
> > with 01/10/11
> >
> > If we continue down the path of the initial versions of
> > draft-ietf-6man-hbh-header-handling, we preserve the semantics of
the first
> > two bits of the option type. From a standardization point of view,
this is
> > as painful as continuing down the path of RFC 7045. It also makes
HBH
> > handling more computationally expensive. Lots of work, little
payoff.
> >
> > Deprecation may be painful for applications that rely on existing
HBH
> > Options. But given that there are only ten HBH Options and many of
them are
> > not widely deployed, we are probably better off experiencing the
pain now
> > than later.
> >
>
> This is probably not going to be popular, but I think that deprecating
them
> is the right thing to do - having something which is part of the spec,
but
> which we know doesn't work / isn't really implemented (and is
dangerous to
> enable / use ('tis a perfect dos)) seems like a bad thing.
>
> Lets just rip the bandaid off and get it over with.

I would support that.

The comment was made earlier this year that one factor in the uptake of
IPv6 not being as quick as would be desirable was the complexity of the
protocol so I am in general of pruning anything that can be, especially
when it is problematic.

Tom Petch

> >  Waiting for incoming,
>
> Likewise,
> W
>
>
> >
Ron
> >
> >
> > > -----Original Message-----
> > > From: ipv6 [mailto:[e-mail]] On Behalf Of Brian
Haberman
> > > Sent: Tuesday, March 22, 2016 1:50 PM
> > > To: [e-mail]
> > > Subject: Re: Review of draft-ietf-6man-hbh-header-handling-01
> > >
> > >  [SNIP]
> > >
> > > Provocative question...
> > >
> > > Have we reached a point where HBH options are completely obsolete?
If a
> > > router needs to process a signaling message (e.g., RSVP or
IGMP/MLD),
> > most
> > > implementations that I am aware of don't trigger that processing
based on
> > > the presence of a HBH option. For example, IGMP/MLD messages are
> > > identified by the protocol (or ICMPv6 codepoint).
> > >
> > > Which signaling protocol(s) would break if HBH went away?
> > >
> > > Brian
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>


------------------------------------------------------------------------
--------


> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>