(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:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, November 9, 2021 11:41 PM
To: Joel M. Halpern <j...@joelhalpern.com>
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: A question for draft-fz-spring-srv6-alt-mark
On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern <j...@joelhalpern.com> 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 <gregimir...@gmail.com>
*Sent:* Monday, November 8, 2021 6:17 PM
*To:* Giuseppe Fioccola <giuseppe.fiocc...@huawei.com>
*Cc:* draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org;
i...@ietf.org
*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
<giuseppe.fiocc...@huawei.com <mailto:giuseppe.fiocc...@huawei.com>> 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 <gregimir...@gmail.com
<mailto:gregimir...@gmail.com>>
*Sent:* Monday, November 8, 2021 2:57 PM
*To:* Giuseppe Fioccola <giuseppe.fiocc...@huawei.com
<mailto:giuseppe.fiocc...@huawei.com>>
*Cc:* draft-fz-spring-srv6-alt-m...@ietf.org
<mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; spring@ietf.org
<mailto:spring@ietf.org>; i...@ietf.org <mailto:i...@ietf.org>
*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
<giuseppe.fiocc...@huawei.com <mailto:giuseppe.fiocc...@huawei.com>>
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 <gregimir...@gmail.com
<mailto:gregimir...@gmail.com>>
*Sent:* Sunday, November 7, 2021 9:01 PM
*To:* draft-fz-spring-srv6-alt-m...@ietf.org
<mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; spring@ietf.org
<mailto:spring@ietf.org>; i...@ietf.org <mailto:i...@ietf.org>
*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
--------------------------------------------------------------------
IETF IPv6 working group mailing list i...@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
