RE: Comments on raft-fz-6man-ipv6-alt-mark-01

Hi Tom and Ole,

Thanks for your comments.
Yes, your proposal is a very good guidance for users to choose the mode how to take the alt-mark field.
We will revise to show these considerations.
But I think this is for the idea cases.
We would also like to show some "abnormal" usage for legacy network. :-)
That is to say, using SRH and DO for the hop by hop usage. I see the similar usage in RFC7837.
What's your thoughts?

BR,
Tianran

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ole Troan
> Sent: Saturday, November 02, 2019 2:16 AM
> To: Tom Herbert <tom@herbertland.com>
> Cc: 6man <ipv6@ietf.org>
> Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
> 
> 
> 
> > On 1 Nov 2019, at 18:57, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Fri, Nov 1, 2019 at 10:46 AM Ole Troan <otroan@employees.org> wrote:
> >>
> >> DestOpt => measurement only  by node in DA HBH => every router on the
> >> path with feature enabled SRH TLV => every node along the SR path
> >> DestOpt + SRH => every node along the SR path
> >>
> > Ole,
> >
> > So the last two have identical effects, hence we've introduced the
> > complexity or redundant protocol mechanisms.
> 
> Yes, that should guide us in making choices here.
> 
> Ole
> 
> 
> >
> > Tom
> >
> >> Cheers
> >> Ole
> >>
> >>>> On 1 Nov 2019, at 18:33, Tom Herbert <tom@herbertland.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>>> From the draft: "Regarding Hop-By-Hop Options Header, if we
> >>>> consider
> >>> its real deployment, it is sometimes dropped by legacy devices and
> >>> not so used by intermediate nodes.  Destination Options Header is
> >>> preferred."
> >>>
> >>> I don't think this is helpful guidance. First of all, it's not just
> >>> Hop-by-Hop options that can be dropped, it's pretty much packets
> >>> with any extension heades or atypical protocols that might be
> >>> dropped by legacy devices-- including packets with Destination
> >>> Options or Routing Headers. Neither does it make sense that
> >>> Destination Options Header is preferred, as correctly stated in the
> >>> previous paragraph DO and HBH address difference use cases (i.e. DO
> >>> is end to end, and HBH is per hop). Saying that DO is preferred is
> >>> equivalent to saying that end-to-end performance measurements are
> >>> preferred which I doubt is the intent. IMO, this whole paragraph
> >>> could be removed without loss of content.
> >>>
> >>> "SRH TLV can also be a good choice from this point of view.  The
> >>> intermediated nodes that are not in the SID list can consider the
> >>> SRH as a green field, they cannot support and bypass or support and
> >>> dig into the SRH TLV."
> >>>
> >>> I disagree with the conclusion that SRH TLV is a good choice. The
> >>> implicit assumption in this paragraph is that somehow SRH EH is less
> >>> likely to be dropped by intermediate nodes than other EH like DO and
> >>> HBH. I don't think there's any data to support that. Additionally,
> >>> it's not clear what use case an SRH TLV addresses that can't already
> >>> be addressed by Destination or HBH options.
> >>>
> >>> Tom
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------