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

From: Greg Mirsky <[email-masked]>
Date: Sun, 7 Nov 2021 12:00:51 -0800

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://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/>?

Regards,
Greg

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 8 Nov 2021 09:13:02 +0000

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]>
Sent: Sunday, November 7, 2021 9:01 PM
To: [email-masked]; [email-masked]; [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://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/>?

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Nov 2021 05:57:05 -0800

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]> wrote:

> 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.
>
> 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:
>
> - 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]>
> *Sent:* Sunday, November 7, 2021 9:01 PM
> *To:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* A question for draft-fz-spring-srv6-alt-mark
>
>
>
> Dear Authors et al.
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 8 Nov 2021 16:50:45 +0000

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, when the 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]>
Sent: Monday, November 8, 2021 2:57 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 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,

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.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Nov 2021 09:17:10 -0800

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]> 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, when the 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
>
>
>
>
>
> *Sent:* Monday, November 8, 2021 2:57 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,
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 8 Nov 2021 19:28:44 +0000

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

Sent: Monday, November 8, 2021 6:17 PM

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, when the 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,

Regards,
Greg

Regards,

Giuseppe

Dear Authors et al.

Regards,
Greg

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Nov 2021 02:51:07 +0000

Hi Greg,

“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.”

What’s the benefit of using HbH in this mode?
HbH EH has deployment issue in most of the existing network. I am happy to see now many people are working on this to solve the problem.
On the other hand, how about using the DoH behind RH, and use management plane to explicitly enable Alt-Mk on enabled nodes?
In this case, transit node will not process Alt-Mk with data plane semantic of DoH. Unless by the management plane force. I feel this is helpful for deployment.
What’s your thoughts?

Cheers,
Tianran

From: ipv6 [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, November 9, 2021 1:17 AM
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,

Regards,
Greg

Regards,

Giuseppe

Hi Giuseppe,

Regards,
Greg

Regards,

Giuseppe

Dear Authors et al.

Regards,
Greg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Nov 2021 10:30:58 -0500

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.

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.
> 
> *Sent:* Monday, November 8, 2021 6:17 PM
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> 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:
> 
> 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.
> 
>     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]>>
>     *To:* Giuseppe Fioccola <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     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,
> 
>     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.
> 
>     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:
> 
>     - 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]>>
>     *To:* [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Nov 2021 15:39:23 +0000

Assumption 2 is not correct. We assume there are nodes support srh but not hbh and doh.

Best,
Tianran

________________________________

Sent from WeLink
发件人： Joel M. Halpern<[email-masked]<mailto:[email-masked]>>
收件人： Giuseppe Fioccola<[email-masked]<mailto:[email-masked]>>
抄送： draft-fz-spring-srv6-alt-mark<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>;ipv6<[email-masked]<mailto:[email-masked]>>
主题： Re: A question for draft-fz-spring-srv6-alt-mark
时间： 2021-11-09 23:31:20

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Nov 2021 07:40:32 -0800

> 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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Nov 2021 07:56:23 -0800

Hi Tianran,
such a combination seems very strange to me. A vendor decides to
support the AltMarking in SRv6 (SRH TLV) but not in IPv6? Possible but,
IMHO, unlikely decision.

Regards,
Greg

On Tue, Nov 9, 2021 at 7:39 AM Tianran Zhou <[email-masked]> wrote:

> ------------------------------
>
> Sent from WeLink
> *发件人： *Joel M. Halpern<[email-masked]>
> *收件人： *Giuseppe Fioccola<[email-masked]>
> *抄送： *draft-fz-spring-srv6-alt-mark<[email-masked]
> >;spring<[email-masked]>;ipv6<[email-masked]>
> *主题： *Re: A question for draft-fz-spring-srv6-alt-mark
> *时间： *2021-11-09 23:31:20
>
> > <[email-masked] <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> >     Hi Greg,
> >
> >     <mailto:[email-masked] <[email-masked]>>>
> >     <mailto:[email-masked] <[email-masked]>
> >>
> >     <mailto:[email-masked]
> <[email-masked]>>; [email-masked]
> >     <mailto:[email-masked] <[email-masked]>>; [email-masked] <
> mailto:[email-masked] <[email-masked]>>
> >     <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> >     wrote:
> >
> >     Hi Greg,
> >
> >     <mailto:[email-masked] <[email-masked]>>>
> >     <mailto:[email-masked]
> <[email-masked]>>; [email-masked]
> >     <mailto:[email-masked] <[email-masked]>>; [email-masked] <
> mailto:[email-masked] <[email-masked]>>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Nov 2021 16:06:32 +0000

I am not saying alt mk, but generic case. I know major chip vendors can support srh but not support hbh nor doh.

That’s why hbh packets easily to be dropped. This is consensus in my opinion.

Sent from WeLink
发件人： Greg Mirsky<[email-masked]<mailto:[email-masked]>>
收件人： Tianran Zhou<[email-masked]<mailto:[email-masked]>>
抄送： Joel M. Halpern<[email-masked]<mailto:[email-masked]>>;Giuseppe Fioccola<[email-masked]<mailto:[email-masked]>>;draft-fz-spring-srv6-alt-mark<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>;ipv6<[email-masked]<mailto:[email-masked]>>
主题： Re: [spring] A question for draft-fz-spring-srv6-alt-mark
时间： 2021-11-09 23:57:14

Hi Tianran,
such a combination seems very strange to me. A vendor decides to support the AltMarking in SRv6 (SRH TLV) but not in IPv6? Possible but, IMHO, unlikely decision.

Regards,
Greg

On Tue, Nov 9, 2021 at 7:39 AM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Assumption 2 is not correct. We assume there are nodes support srh but not hbh and doh.

Best,
Tianran

Sent from WeLink

Yours,
Joel

On 11/8/2021 2:28 PM, Giuseppe Fioccola wrote:
> *From:* Greg Mirsky <[email-masked]<mailto:[email-masked]>>
> *To:* Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
> *Cc:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>
>     Hi Greg,
>
>     *From:* Greg Mirsky <[email-masked]<mailto:[email-masked]>
>     *To:* Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>
>     *Cc:* [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     wrote:
>
>     Hi Greg,
>
>     *From:* Greg Mirsky <[email-masked]<mailto:[email-masked]>
>     *To:* [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 10 Nov 2021 02:04:39 +0000

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:
> 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.

+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

> > Yes, with DOH + SRH, the end node of a segment should still conform 
> > to RFC8200, based on the discussion in 6MAN.
> >
> > 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
> >
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Nov 2021 21:38:13 -0500

(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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Nov 2021 19:02:05 -0800

> SRH TLVs.  And if they do, they clearly will not support a not yet

Yes, and we have no reason to believe that SRH TLVs are somehow more
amenable to hardware implementation than TLVs in Hop-by-Hop or
Destination options. They are essentially defined as the same
mechanism... well almost the same:  since SRH TLVs diverged from the
format of HbH and DestOps (specifically PADN does not have the same
type value in SRH) we can't use the same logic block to implement SRH
TLVs.

Tom

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 10 Nov 2021 03:40:49 +0000

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.

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:
> 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.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Nov 2021 10:32:27 -0800

> 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.

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.

Tom