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

[Tianran Zhou <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, November 16, 2021 11:48 AM
To: Tianran Zhou <[e-mail]>
Cc: Ron Bonica <[e-mail]>; Tom Herbert <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> wrote:

> Hi Ron,
> Please see my reply in line.
>
> Thanks,
> Tianran
>
> -----邮件原件-----
> 发件人: Ron Bonica [mailto:[e-mail]]
> 发送时间: 2021年11月16日 6:20
> 收件人: Tianran Zhou <[e-mail]>; Tom Herbert < 
> [e-mail]>
> 抄送: [e-mail]; [e-mail]; 
> [e-mail]
> 主题: 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 
> ZTR> 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. 
> ZTR> 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 <[e-mail]> On Behalf Of Tianran Zhou
> Sent: Friday, November 12, 2021 3:56 AM
> To: Tom Herbert <[e-mail]>
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> 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:[e-mail]]
> Sent: Friday, November 12, 2021 1:05 AM
> To: Tianran Zhou <[e-mail]>
> Cc: Joel M. Halpern <[e-mail]>; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
>
> On Wed, Nov 10, 2021 at 10:48 PM Tianran Zhou <[e-mail]>
> wrote:
> >
> > Hi Tom,
> >
> > Please see my reply below.
> >
> > Best,
> > Tianran
> >
> > -----邮件原件-----
> > 发件人: Tom Herbert [mailto:[e-mail]]
> > 发送时间: 2021年11月11日 2:32
> > 收件人: Tianran Zhou <[e-mail]>
> > 抄送: Joel M. Halpern <[e-mail]>; 
> > [e-mail]; [e-mail]; 
> > [e-mail]
> > 主题: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
> >
> > On Tue, Nov 9, 2021 at 7:41 PM Tianran Zhou <[e-mail]>
> 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 
> > 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.).
>
> 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:[e-mail]] On Behalf Of Joel M.
> > > Halpern
> > > Sent: Wednesday, November 10, 2021 10:38 AM
> > > To: Tianran Zhou <[e-mail]>
> > > Cc: [e-mail]; [e-mail]; 
> > > [e-mail]
> > > 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