Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

From: Tianran Zhou <[email-masked]>
Date: Tue, 16 Nov 2021 01:02:58 +0000

Hi Ron,
Please see my reply in line.

Thanks,
Tianran

-----邮件原件-----
发件人: Ron Bonica [mailto:[email-masked]] 
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

The SRH TLV for Alternate Marking isn't needed because its meaning is identical to the AltMark Option when it appears in a Destination Options Header that precedes the SRH. 

Arguments regarding the HBH are orthogonal to this issue. The HBH is processed at every node along a packet's deliver path, while the Destination Options header that precedes the SRH is processed " by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header.

ZTR> This is clear to me. But this is not my point to propose the SRH TLV method.

Arguments regarding whether a complete IPv6 implementation must support the Destination Options header have already been settled by RFC 8200.

ZTR> I am sorry, I do not understand what do you mean hear. Could you please give more hint?

Arguments about whether it is easier to parse two smaller extension headers or one larger extension headers are not appropriate in the IETF, because they are platform dependent.

ZTR> My point is not about parsing two smaller EH vs. one larger EH. My point is the deployment when a network that support SRH but not support other EHs.

                                                                                                                  Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]

Hi Tom,

Firstly, the proposed solution follows the same logic as RFC8200, as in your text. So I do not see any problem. We just find another away to "ignore the options".
" RFC8200 relaxed the requirement for all nodes to process HBH options and acknowledged that this is reality. From an application perspective, if the TLVs can't be processed in a "fast path" it is best to ignore the options."

Secondly, I agree with the complexity of processing TLV. But we have already implemented the function with line rate. So the "core problem" from my perspective is how to deploy it.

We are always on the way to performance optimization. I've read your draft, and your solution is very interesting.

Best,
Tianran

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

On Wed, Nov 10, 2021 at 10:48 PM Tianran Zhou <[email-masked]> wrote:
>
> Hi Tom,
>
> Please see my reply below.
>
> Best,
> Tianran
>
> -----邮件原件-----
> 发件人: Tom Herbert [mailto:[email-masked]]
> 发送时间: 2021年11月11日 2:32
> 收件人: Tianran Zhou <[email-masked]>
> 抄送: Joel M. Halpern <[email-masked]>; 
> [email-masked]; [email-masked]; [email-masked]
> 主题: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
>
> On Tue, Nov 9, 2021 at 7:41 PM Tianran Zhou <[email-masked]> wrote:
> >
> > Hi Joel,
> >
> > I do not need to assume a device that support SRH will support this new TLV.
> > We only assume the device that do not support this new TLV can ignore and bypass the packet, not to drop.
> > I see text from RFC8754 section 2.1.
> > " all TLVs are ignored unless local configuration indicates otherwise "
> > " Thus, TLV and HMAC support  is optional for any implementation "
> > " Type Length Value (TLV) entries contain OPTIONAL information that may
> >    be used by the node identified in the Destination Address (DA) of the
> >    packet. "
> > " The Length field of the TLV is used to skip the TLV while inspecting
> >    the SRH in case the node doesn't support or recognize the Type. "
> >
> > My understanding on SRH can support my assumption.
>
> Tianran,
>
> RFC8200 allows intermediate nodes to ignore TLVs in HBH options, and I did propose allowing intermediate destinations to ignore destination options before the routing header in draft-herbert-ipv6-update-opts.
>
> ZTR> It is true, but this is another story. RFC8200 is new, while RFC2460 has been widely deployed. The industry need time to evolve. I talked about the reality. The new proposal is motivated by the real deployment.
>
> But allowing nodes to ignore TLVs only mitigates the problems of packet loss in the presence of TLVs; the obvious purpose of defining a new TLV is that it _will_ be processed, lest the host sender is just wasting cycles and bandwidth sending bits no one looks at. If all implementations of SRH ignore TLVs then defining the TLV is pointless (AFAIK only Linux and maybe VPP software implementations support SRH TLVs). For the purposes of actually processing a TLV, like alt mark, I still don't see any advantage to putting this in SRH as opposed to Destination options or HBH options.
>
> ZTR> We consider the incremental deployment case, or the deployment with multi-vendors. That means the supportive node could process SRH TLV well, while the non-supportive node could still transit. This is still valuable for operators to narrow down the scope when packet loss happens. This could also encourage the new tech development and deployment. I see this is very useful.

Tianran,

I think you're dancing around the core problem. Hardware implementations didn't support Hop-by-Hop options because they contain TLVs which are considered to be hard to process in a high performance datapath hardware pipeline. RFC2460 did mandate that all intermediate nodes need to process the HBH options which left hardware vendors with three choices: 1) process them in a software slow path and adhere to
RFC2460 2) ignore them altogether and violate RFC2460 3) drop the packet which technically adheres to RFC2460, but obviously kills any utility of feature. RFC8200 relaxed the requirement for all nodes to process HBH options and acknowledged that this is reality. From an application perspective, if the TLVs can't be processed in a "fast path" it is best to ignore the options.

So the underlying problem is in fact the complexity of processing TLVs in hardware datapath. Just replicating the same TLV mechanism in more protocols like SRH does nothing to help solve the problem. Until this is solved I don't believe we'll ever see TLVs being productively used in L3 (I suppose this might the anticipated industry evolution to which you referred). On the other hand if the problem is solved and a deployable an economical solution is presented that hardware vendors would adopt, then the problem would be solved for a whole class of use case (i.e. the same basic TLV construct is used in HBH, DestOpts, SRH, TCP options, IP options, UDP options, etc.).

If you're interested, I will be outlining the solution to this problem that we're working on in IPv6/v6ops meeting tomorrow.

Tom

>
> Tom
>
> >
> > Best,
> > Tianran
> >
> > -----Original Message-----
> > From: spring [mailto:[email-masked]] On Behalf Of Joel M.
> > Halpern
> > Sent: Wednesday, November 10, 2021 10:38 AM
> > To: Tianran Zhou <[email-masked]>
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
> >
> > (Again, speaking as  participant.)
> > You seem to be assuming that devices (hard or soft) that support SRH will support this new TLV.  It is not obvious that they will support any SRH TLVs.  And if they do, they clearly will not support a not yet defined TLV.
> >
> > Yours,
> > Joel
> >
> > On 11/9/2021 9:04 PM, Tianran Zhou wrote:
> > > Hi Tom,
> > >
> > > All you arguments are correct.
> > > If a network is built all by supportive devices (support HbH, DoH), there is no doubt that 6man-alt-mk is a sound solution.
> > >
> > > However, existing network may consist many non-supportive devices.
> > > These devices may 1. support SRH, but not HbH and DoH. This is the current situation about most chip vendors.
> > > 2. some vendors may not want to support HbH and DoH in near future.
> > >
> > > Then, how to deploy alt-mk in these network?
> > > The way is to bypass those non-supportive nodes without packet drop.
> > >
> > > This is why SRH TLV based spring-srv6-alt-mark is proposed.
> > >
> > > Best,
> > > Tianran
> > >
> > > -----Original Message-----
> > > From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
> > > Sent: Tuesday, November 9, 2021 11:41 PM
> > > To: Joel M. Halpern <[email-masked]>
> > > Cc: [email-masked]; [email-masked]; 
> > > [email-masked]
> > > Subject: Re: A question for draft-fz-spring-srv6-alt-mark
> > >
> > > On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern <[email-masked]> wrote:
> > >>
> > >> Let me try phrasing the question about the SRH TLV in a different way.
> > >> And this is as a participant, not as co-chair.
> > >> Assumptions as I understand them:
> > >>
> > >> 1) The 6man draft requires support of both the HbH and DoH cases
> > >> 2) Any node supporting the SRH altMarking can be assumed to also 
> > >> support the 6man altMark
> > >>
> > >> If assumption 2 is accurate, then it seems to me that adding the 
> > >> SRH TLV adds complexity to save a few bits without adding any capability.
> > >> This strikes me as a bad trade.
> > >
> > > +1
> > >
> > > Also, destination and hop-by-hop options have the advantage that they work with any other extension header or protocol. SRH TLVs only work in the narrow use case of SRv6 and don't help router headers that might be defined.
> > >
> > > Tom
> > >
> > >>
> > >> Yours,
> > >> Joel
> > >>
> > >> On 11/8/2021 2:28 PM, Giuseppe Fioccola wrote:
> > >>> Hi Greg,
> > >>>
> > >>> Yes, with DOH + SRH, the end node of a segment should still 
> > >>> conform to RFC8200, based on the discussion in 6MAN.
> > >>>
> > >>> The proposal to use HBH is also mentioned in draft-ietf-6man-ipv6-alt-mark.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Giuseppe
> > >>>
> > >>> *From:* Greg Mirsky <[email-masked]>
> > >>> *Sent:* Monday, November 8, 2021 6:17 PM
> > >>> *To:* Giuseppe Fioccola <[email-masked]>
> > >>> *Cc:* [email-masked]; [email-masked]; 
> > >>> [email-masked]
> > >>> *Subject:* Re: A question for draft-fz-spring-srv6-alt-mark
> > >>>
> > >>> Hi Giuseppe,
> > >>>
> > >>> thank you for the clarification.
> > >>>
> > >>> I was considering the DOH+SDH but am not sure if the end node of 
> > >>> a segment conforms to the note attributed to DOH in RFC 8200:
> > >>>
> > >>>      note 3: for options to be processed only by the final destination of
> > >>>      the packet.
> > >>>
> > >>> I recall the discussion in 6man WG but not the final conclusion of it.
> > >>>
> > >>> My proposal to use HbH EH included the use of the management 
> > >>> plane to explicitly enable AltMarking only on segment end-points 
> > >>> and keep it disabled on transit nodes.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Greg
> > >>>
> > >>> On Mon, Nov 8, 2021 at 8:50 AM Giuseppe Fioccola 
> > >>> <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>
> > >>>      Hi Greg,
> > >>>
> > >>>      The use of HbH EH does not fit well in the case of SRH. Indeed, with
> > >>>      the AltMark HbH Option, it is possible to monitor every router on
> > >>>      the path with feature enabled, so it potentially allows the
> > >>>      measurement to every nodes in the path and not only to the nodes
> > >>>      that are identities in the SR path.
> > >>>
> > >>>      While, with the Destination Option preceding a Routing Header, it is
> > >>>      possible to apply the measurement to every destination node in the
> > >>>      route list. This means that, whenthe AltMark Destination Option
> > >>>      precedes the SRH, it allows the measurement for all the nodes that
> > >>>      are identities in the SR path.
> > >>>
> > >>>      The solution with SRH TLV is equivalent to DOH + SRH, but it can be
> > >>>      an optimized solution for SRH since it leverages the SRH TLV
> > >>>      capability, without adding an additional EH that can be a problem in
> > >>>      some cases.
> > >>>
> > >>>      Regards,
> > >>>
> > >>>      Giuseppe
> > >>>
> > >>>      *From:* Greg Mirsky <[email-masked]
> > >>>      <mailto:[email-masked]>>
> > >>>      *Sent:* Monday, November 8, 2021 2:57 PM
> > >>>      *To:* Giuseppe Fioccola <[email-masked]
> > >>>      <mailto:[email-masked]>>
> > >>>      *Cc:* [email-masked]
> > >>>      <mailto:[email-masked]>; [email-masked]
> > >>>      <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > >>>      *Subject:* Re: A question for draft-fz-spring-srv6-alt-mark
> > >>>
> > >>>      Hi Giuseppe,
> > >>>
> > >>>      thank you for the detailed explanation of what the authors consider
> > >>>      as the problem. In the presentation, you've mentioned that the new
> > >>>      AltMark SRH TLV allows for better control of which nodes along an SR
> > >>>      Policy participate in the measurement. I imagine that the HbH IPv6
> > >>>      extension header that includes the AltMark TLV can be used to
> > >>>      achieve the same result if only SR nodes are enabled for the AltMark
> > >>>      processing. What do you think of using the HbH EH? Am I missing
> > >>>      something?
> > >>>
> > >>>      Regards,
> > >>>
> > >>>      Greg
> > >>>
> > >>>      On Mon, Nov 8, 2021 at 1:13 AM Giuseppe Fioccola
> > >>>      <[email-masked] <mailto:[email-masked]>>
> > >>>      wrote:
> > >>>
> > >>>      Hi Greg,
> > >>>
> > >>>      Thank you for your comment.
> > >>>
> > >>>      It is very good to have your support on this draft.
> > >>>
> > >>>      draft-ietf-6man-ipv6-alt-mark defines the AltMark DOH. In case of
> > >>>      SRH, DOH + SRH can be used to implement the measurement for every
> > >>>      node that is an identity in the SR path.
> > >>>
> > >>>      But, the approach with DOH + SRH requires two extension headers and
> > >>>      this can have operational implications.
> > >>>
> > >>>      The goal of this draft is to find an optimized solution that best
> > >>>      suits for SRH. Therefore we propose to use the SRH TLV. If accepted,
> > >>>      this document would update draft-ietf-6man-ipv6-alt-mark only for SRv6:
> > >>>
> > >>>      - in case of SRH there would be a single way to apply AltMark
> > >>>      through SRH TLV,
> > >>>
> > >>>      - while for all the other cases with IPv6 data plane the use of the
> > >>>      HbH and DOH is the only choice to carry AltMark data fields.
> > >>>
> > >>>      Regards,
> > >>>
> > >>>      Giuseppe
> > >>>
> > >>>      *From:* Greg Mirsky <[email-masked]
> > >>>      <mailto:[email-masked]>>
> > >>>      *Sent:* Sunday, November 7, 2021 9:01 PM
> > >>>      *To:* [email-masked]
> > >>>      <mailto:[email-masked]>; [email-masked]
> > >>>      <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > >>>      *Subject:* A question for draft-fz-spring-srv6-alt-mark
> > >>>
> > >>>      Dear Authors et al.
> > >>>
> > >>>      thank you for this document. I am supporting and following the work
> > >>>      on the Alternate Marking method in various IETF WGs. What do you see
> > >>>      as the benefits of defining a new SRH TLV for the Alternate Marking
> > >>>      method compared to solutions defined for IPv6 in
> > >>>      draft-ietf-6man-ipv6-alt-mark
> > >>>      <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7mPTLWcpo221rpmep31F9$ >?
> > >>>
> > >>>      Regards,
> > >>>
> > >>>      Greg
> > >>>
> > >>>
> > >>> ----------------------------------------------------------------
> > >>> --
> > >>> -- IETF IPv6 working group mailing list [email-masked] 
> > >>> Administrative
> > >>> Requests: 
> > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > >>> o/ipv6__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_c
> > >>> hK7mPTLWcpo221rprIfvSmZ$
> > >>> ----------------------------------------------------------------
> > >>> --
> > >>> --
> > >>>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> - IETF IPv6 working group mailing list [email-masked] 
> > >> Administrative
> > >> Requests: 
> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo
> > >> /ipv6__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK
> > >> 7mPTLWcpo221rprIfvSmZ$
> > >> -----------------------------------------------------------------
> > >> --
> > >> -
> > >
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [email-masked] 
> > > Administrative
> > > Requests: 
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > ipv6__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7m
> > > PTLWcpo221rprIfvSmZ$
> > > ------------------------------------------------------------------
> > > --
> > >
> >
> > _______________________________________________
> > spring mailing list
> > [email-masked]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> > ring__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7mPT
> > LWcpo221rpu4mP70S$
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list [email-masked] Administrative
> > Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7mPTLW
> > cpo221rprIfvSmZ$
> > --------------------------------------------------------------------
_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7mPTLWcpo221rpu4mP70S$

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Nov 2021 19:48:01 -0800

Hi Tianran,
as I imagine it, the deployment of SRH in a production network, i.e., a
network with legacy nodes, will require upgrading SW and firmware. If that
is the case, the decision of supporting in the upgrades only the SRH but
not other IPv6 EHs, e.g., Destination and HbH, seems unreasonable to me and
does not rise to the level that justifies the duplication of ways to
support the Alternate Marking method in IPv6 networks.

Regards,
Greg

On Mon, Nov 15, 2021 at 5:03 PM Tianran Zhou <[email-masked]> wrote:

> The SRH TLV for Alternate Marking isn't needed because its meaning is
> identical to the AltMark Option when it appears in a Destination Options
> Header that precedes the SRH.
>
> Arguments regarding the HBH are orthogonal to this issue. The HBH is
> processed at every node along a packet's deliver path, while the
> Destination Options header that precedes the SRH is processed " by the
> first destination that appears in the IPv6 Destination Address field plus
> subsequent destinations listed in the Routing header.
>
> Arguments regarding whether a complete IPv6 implementation must support
> the Destination Options header have already been settled by RFC 8200.
>
> Arguments about whether it is easier to parse two smaller extension
> headers or one larger extension headers are not appropriate in the IETF,
> because they are platform dependent.
>
> ZTR> My point is not about parsing two smaller EH vs. one larger EH. My
> point is the deployment when a network that support SRH but not support
> other EHs.
>
>
>
>                                         Ron
>
>
>
>
>
>
>
> Firstly, the proposed solution follows the same logic as RFC8200, as in
> your text. So I do not see any problem. We just find another away to
> "ignore the options".
> " RFC8200 relaxed the requirement for all nodes to process HBH options and
> acknowledged that this is reality. From an application perspective, if the
> TLVs can't be processed in a "fast path" it is best to ignore the options."
>
> Secondly, I agree with the complexity of processing TLV. But we have
> already implemented the function with line rate. So the "core problem" from
> my perspective is how to deploy it.
>
> We are always on the way to performance optimization. I've read your
> draft, and your solution is very interesting.
>
> Best,
> Tianran
>
> Cc: Joel M. Halpern <[email-masked]>;
> > RFC8200 allows intermediate nodes to ignore TLVs in HBH options, and I
> did propose allowing intermediate destinations to ignore destination
> options before the routing header in draft-herbert-ipv6-update-opts.
> >
> > ZTR> It is true, but this is another story. RFC8200 is new, while
> RFC2460 has been widely deployed. The industry need time to evolve. I
> talked about the reality. The new proposal is motivated by the real
> deployment.
> >
> > But allowing nodes to ignore TLVs only mitigates the problems of packet
> loss in the presence of TLVs; the obvious purpose of defining a new TLV is
> that it _will_ be processed, lest the host sender is just wasting cycles
> and bandwidth sending bits no one looks at. If all implementations of SRH
> ignore TLVs then defining the TLV is pointless (AFAIK only Linux and maybe
> VPP software implementations support SRH TLVs). For the purposes of
> actually processing a TLV, like alt mark, I still don't see any advantage
> to putting this in SRH as opposed to Destination options or HBH options.
> >
> > ZTR> We consider the incremental deployment case, or the deployment with
> multi-vendors. That means the supportive node could process SRH TLV well,
> while the non-supportive node could still transit. This is still valuable
> for operators to narrow down the scope when packet loss happens. This could
> also encourage the new tech development and deployment. I see this is very
> useful.
>
> Tianran,
>
> I think you're dancing around the core problem. Hardware implementations
> didn't support Hop-by-Hop options because they contain TLVs which are
> considered to be hard to process in a high performance datapath hardware
> pipeline. RFC2460 did mandate that all intermediate nodes need to process
> the HBH options which left hardware vendors with three choices: 1) process
> them in a software slow path and adhere to
> RFC2460 2) ignore them altogether and violate RFC2460 3) drop the packet
> which technically adheres to RFC2460, but obviously kills any utility of
> feature. RFC8200 relaxed the requirement for all nodes to process HBH
> options and acknowledged that this is reality. From an application
> perspective, if the TLVs can't be processed in a "fast path" it is best to
> ignore the options.
>
> So the underlying problem is in fact the complexity of processing TLVs in
> hardware datapath. Just replicating the same TLV mechanism in more
> protocols like SRH does nothing to help solve the problem. Until this is
> solved I don't believe we'll ever see TLVs being productively used in L3 (I
> suppose this might the anticipated industry evolution to which you
> referred). On the other hand if the problem is solved and a deployable an
> economical solution is presented that hardware vendors would adopt, then
> the problem would be solved for a whole class of use case (i.e. the same
> basic TLV construct is used in HBH, DestOpts, SRH, TCP options, IP options,
> UDP options, etc.).
>
> If you're interested, I will be outlining the solution to this problem
> that we're working on in IPv6/v6ops meeting tomorrow.
>
> Tom
>
> >
> > Tom
> >
> > >
> > > Best,
> > > Tianran
> > >
> > > You seem to be assuming that devices (hard or soft) that support SRH
> will support this new TLV.  It is not obvious that they will support any
> SRH TLVs.  And if they do, they clearly will not support a not yet defined
> TLV.
> > >
> > > Yours,
> > > Joel
> > >
> > > > If a network is built all by supportive devices (support HbH, DoH),
> there is no doubt that 6man-alt-mk is a sound solution.
> > > >
> > > > These devices may 1. support SRH, but not HbH and DoH. This is the
> current situation about most chip vendors.
> > > > Also, destination and hop-by-hop options have the advantage that
> they work with any other extension header or protocol. SRH TLVs only work
> in the narrow use case of SRv6 and don't help router headers that might be
> defined.
> > > >
> > > > Tom
> > > >
> > > >>
> > > >> Yours,
> > > >> Joel
> > > >>
> > > >>>      <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]
> >
> > > >>>      <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]
> >
> > > >>>      <
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/__;!!NEt6yMaO-gk!Rer99s0DO7Ys6kR2kNbYfO5WFUh7DlH4ouzWfIp_chK7mPTLWcpo221rpmep31F9$
> >?
> > > >>>
> > > >>>      Regards,
> > > >>>
> > > >>>      Greg
> > > >>>
> > > >>>
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 Nov 2021 16:59:44 +0000

Tianran,

Should the IETF standardize two methods of encoding the same information because some networks have not deployed the older method? (yes/no)

Should the IETF standardize two methods of encoding the same information because some hardware platforms have never implemented the older method? (yes / no)

If the answer to either question is "yes", please explain why?

If the answer to both questions is "no", please explain why the SRH TLV for Alternate Marking is needed.

                                                                                                     Ron

-----Original Message-----
From: Tianran Zhou <[email-masked]> 
Sent: Monday, November 15, 2021 8:03 PM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Ron,

Thanks,
Tianran

-----邮件原件-----
发件人: Ron Bonica [mailto:[email-masked]]
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

                                                                                                                  Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Tom,

Best,
Tianran

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

Tom

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 17 Nov 2021 02:08:28 +0000

Hi Ron,

Your both questions are too generic. I cannot answer, I do not want to boil the ocean.
In addition, the SRH TLV proposal is not relevant to both of your questions.
The proposal is for a specific scenario. 
This document would update the AltMark application only for SRv6. This means that: 
• in case of SRv6, AltMark can be applied through SRH TLV,
• for all the other cases with IPv6 data plane, the use of the HbH and DOH is the only choice to carry AltMark data fields.

Follow your thoughts, maybe there is no need for HbH and DoH two EHs.
With HbH, we can configure each intermediate node not to process the further options, then only destination node process. This is the same function as in DoH.
With DoH, we can configure each intermediate node to process the DoH by force, then every node along the path can process. This is the same function as in HbH.

Regards,
Tianran 

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2021 1:00 AM
To: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

                                                                                                     Ron

-----Original Message-----
From: Tianran Zhou <[email-masked]>
Sent: Monday, November 15, 2021 8:03 PM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Ron,

Thanks,
Tianran

-----邮件原件-----
发件人: Ron Bonica [mailto:[email-masked]]
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

                                                                                                                  Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Tom,

Best,
Tianran

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

Tom

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 17 Nov 2021 07:37:57 +0000

Hi Greg,

In real word, upgrade all devices is hard, especially for multi-vendors. And there are devices not able to update the fast path.  
Supporting only SRH but not other IPv6 EHs is normal. 

Best,
Tianran

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2021 11:48 AM
To: Tianran Zhou <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Tianran,
as I imagine it, the deployment of SRH in a production network, i.e., a network with legacy nodes, will require upgrading SW and firmware. If that is the case, the decision of supporting in the upgrades only the SRH but not other IPv6 EHs, e.g., Destination and HbH, seems unreasonable to me and does not rise to the level that justifies the duplication of ways to support the Alternate Marking method in IPv6 networks.

Regards,
Greg

On Mon, Nov 15, 2021 at 5:03 PM Tianran Zhou <[email-masked]> wrote:

> identical to the AltMark Option when it appears in a Destination 
> Options Header that precedes the SRH.
>
> first destination that appears in the IPv6 Destination Address field 
> plus subsequent destinations listed in the Routing header.
>
> ZTR> This is clear to me. But this is not my point to propose the SRH 
> ZTR> TLV
> method.
>
> Arguments regarding whether a complete IPv6 implementation must 
> support the Destination Options header have already been settled by RFC 8200.
>
> headers or one larger extension headers are not appropriate in the 
> IETF, because they are platform dependent.
>
> ZTR> My point is not about parsing two smaller EH vs. one larger EH. 
> ZTR> My
> point is the deployment when a network that support SRH but not 
> support other EHs.
>
>
>
>                                         Ron
>
>
>
>
>
>
>
> Firstly, the proposed solution follows the same logic as RFC8200, as 
> in your text. So I do not see any problem. We just find another away 
> to "ignore the options".
> " RFC8200 relaxed the requirement for all nodes to process HBH options 
> and acknowledged that this is reality. From an application 
> perspective, if the TLVs can't be processed in a "fast path" it is best to ignore the options."
>
> already implemented the function with line rate. So the "core problem" 
> from my perspective is how to deploy it.
>
> > > I do not need to assume a device that support SRH will support 
> > > this
> new TLV.
> > > We only assume the device that do not support this new TLV can 
> > > ignore
> and bypass the packet, not to drop.
> > >    be used by the node identified in the Destination Address (DA) 
> > > of
> the
> > >    packet. "
> loss in the presence of TLVs; the obvious purpose of defining a new 
> TLV is that it _will_ be processed, lest the host sender is just 
> wasting cycles and bandwidth sending bits no one looks at. If all 
> implementations of SRH ignore TLVs then defining the TLV is pointless 
> (AFAIK only Linux and maybe VPP software implementations support SRH 
> TLVs). For the purposes of actually processing a TLV, like alt mark, I 
> still don't see any advantage to putting this in SRH as opposed to Destination options or HBH options.
> >
> > ZTR> We consider the incremental deployment case, or the deployment 
> > ZTR> with
> multi-vendors. That means the supportive node could process SRH TLV 
> well, while the non-supportive node could still transit. This is still 
> valuable for operators to narrow down the scope when packet loss 
> happens. This could also encourage the new tech development and 
> deployment. I see this is very useful.
>
> Tianran,
>
> I think you're dancing around the core problem. Hardware 
> implementations didn't support Hop-by-Hop options because they contain 
> TLVs which are considered to be hard to process in a high performance 
> datapath hardware pipeline. RFC2460 did mandate that all intermediate 
> nodes need to process the HBH options which left hardware vendors with 
> three choices: 1) process them in a software slow path and adhere to
> RFC2460 2) ignore them altogether and violate RFC2460 3) drop the 
> packet which technically adheres to RFC2460, but obviously kills any 
> utility of feature. RFC8200 relaxed the requirement for all nodes to 
> process HBH options and acknowledged that this is reality. From an 
> application perspective, if the TLVs can't be processed in a "fast 
> path" it is best to ignore the options.
>
> So the underlying problem is in fact the complexity of processing TLVs 
> in hardware datapath. Just replicating the same TLV mechanism in more 
> protocols like SRH does nothing to help solve the problem. Until this 
> is solved I don't believe we'll ever see TLVs being productively used 
> in L3 (I suppose this might the anticipated industry evolution to 
> which you referred). On the other hand if the problem is solved and a 
> deployable an economical solution is presented that hardware vendors 
> would adopt, then the problem would be solved for a whole class of use 
> case (i.e. the same basic TLV construct is used in HBH, DestOpts, SRH, 
> TCP options, IP options, UDP options, etc.).
>
> > > (Again, speaking as  participant.) You seem to be assuming that 
> > > devices (hard or soft) that support SRH
> will support this new TLV.  It is not obvious that they will support 
> any SRH TLVs.  And if they do, they clearly will not support a not yet 
> defined TLV.
> > >
> > > Yours,
> > > Joel
> > >
> > > > The way is to bypass those non-supportive nodes without packet drop

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 Nov 2021 07:00:44 -0800

Tianran,

I do not know what "normal" means in this context, please quantify.

If you're saying that supporting SRH and not other EHs is protocol
conformant with RFC8200  then I might argue it's not (although
considering that SRH already breaks at least one other in AH, I
suppose the argument is academic). If you're saying that SRH is
already widely deployed in the relatively short time RFC8754 has been
published, then, considering that supporting SRH requires hardware
change, that would apparently contradict the statement that upgrade of
devices is hard. If you're saying that vendors are choosing to support
SRH and not other EHs then please define what it means to support and
EH. If a vendor supports SRH but not SRH TLVs, which AFAIK is common
for hardware implementations, then is that really supporting SRH? As
previously discussed if TLVs aren't supported then defining a TLV is
pointless.

I believe the crux of your argument comes down to the fact, or
preception, that the TLVs in Hop-by-Hop Options before the header and
Destination Options before the routing header MUST be processed where
as RFC8754 explicitly allows SRH TLVs to be ignored. RFC8200 relaxed
the requirement on Hop-by-Hop options being processed at every node.
RFC8200 was published in 2017, so an obvious question is what has been
the impact, are vendors ignoring HBH options them instead of dropping?
I asked that question in 6man last week and the answer seems to be
that the impact is not known yet (because it takes several years to
reach sufficient deployment levels of a new protocol because upgrade
of devices is hard). For Destination Options they would be required to
be processed by every intermediate destination, but that could be
adapted to allow them to be ignored.

IMO, if vendors are able to support a new EH protocol as complex as
SRH, and especially if they're going to add SRH TLV support, then
there's no reason why they can't support other EHs like Hop-by-Hop
options or at least ignore them.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 17 Nov 2021 16:14:55 +0000

Tianran,

I will state the case a little more bluntly. You need a method of invoking AltMark behavior:

- at each hop along a packet's deliver path
- at segment endpoints only
- at the ultimate destination node only

You have already defined the AltMark Option that can be included in:

- A Hop-by-hop extension header (processed at each hop along a packet's delivery path)
- A Destination Options header that precedes a routing header (processed at segment endpoints only)
- A Destination Options header that follows a routing header ( processed at the ultimate destination only)

You don't need anything else. 

                                                          Ron

-----Original Message-----
From: Tianran Zhou <[email-masked]> 
Sent: Tuesday, November 16, 2021 9:08 PM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Ron,

• in case of SRv6, AltMark can be applied through SRH TLV, • for all the other cases with IPv6 data plane, the use of the HbH and DOH is the only choice to carry AltMark data fields.

Regards,
Tianran

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: Wednesday, November 17, 2021 1:00 AM
To: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

                                                                                                     Ron

-----Original Message-----
From: Tianran Zhou <[email-masked]>
Sent: Monday, November 15, 2021 8:03 PM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Ron,

Thanks,
Tianran

-----邮件原件-----
发件人: Ron Bonica [mailto:[email-masked]]
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou <[email-masked]>; Tom Herbert <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

                                                                                                                  Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Hi Tom,

Best,
Tianran

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

Tom