A fair and relevant point. Thank you fro clarifying what problem is
being solved and how the solution addresses it.
Yours,
Joel
On 4/9/2024 2:33 AM, Francois Clad wrote:
Hi Joel,
One small clarification.
Knowledge of the SRv6 SID block (either by configuration or using the
new SRv6 block specified in draft-ietf-6man-sids as a default) is
sufficient for an “observer node” to identify SRv6 traffic and
potentially skip verifying the checksum.
An SRv6 and C-SID aware “observer node” is indeed likely to require
additional information to determine the ultimate destination address
of such traffic, although how it will obtain that information may
depend on its implementation.
Thanks,
Francois
On 9 Apr 2024 at 00:34:43, Joel Halpern <j...@joelhalpern.com> wrote:
Note as an observer of this discussion:
If we consider that the need for configuration of observer nodes is
an issue, I am pretty sure we need to remember that it is not just
the SID block that needs to be known. The compressed SID length and
flavor also need to be known.
Yours,
Joel
On 4/8/2024 2:36 PM, Robert Raszuk wrote:
Hi Ketan,
a) SR Source Node: the node originating the packet - it may have
an SRH or may skip it (section 4.1)
b) Transit Node: node doing IPv6 forwarding
c) (Ultimate) Destination Node (from RFC8200): the final node to
which the packet is destined
All you said seems true valid, but the above three node categories
do miss a fourth one - randomly plugged sniffer, or any other way to
selectively capture subset of packets for troubleshooting.
I do think this is a bit of an obstacle to require that before such
an analyzer is connected to process live or offline traffic captures
it needs to be configured with given's network's SRv6 dedicated
locator(s) and/or SID blocks.
We clearly do not have such a requirement today for any other
transport protocol.
Maybe this is a good topic for SRv6OPS WG ? I said maybe as there
clearly seems to be a group of folks who say do not care about SRv6
or CSIDs and would like to continue using same operational tools for
troubleshooting bare IPv6 protocol. Well in the network where both
are running in parallel lacking a clear demux flag seems to make it
a bit of a challenge ... especially if any endpoints talking native
SRv6 with uSIDs would also talk native IPv6.
Can you kindly share your perspective on this ?
Cheers,
Robert
The CSID document in section 6.5 does not change or update the
text in RFC8200 sec 8.1. It is simply stating what the "final
destination" is going to be when CSID is used because RFC8200
does not talk about RHs in sec 8.1. RFC8754 covered this aspect
by specifying that the last segment is the "final destination"
but this needs to be specified when using C-SID (with or without
SRH) and for all C-SID flavors/behaviors.
I find the current text in section 6.5 to be necessary and
sufficient for implementations that claim (or need to) support
SR Source Node behavior for C-SIDs.
The CSID document does not change any behavior at the Transit
Node or for the (Ultimate) Destination Node. Therefore, the
discussion of Transit Nodes is outside the scope of this
document - just as it was outside the scope for RFC8754.
Now, if some "Special Transit Node" wants to go beyond RFC8200
and do things like upper layer checksum validation enroute then
they can refer to the same text in section 6.5 to first
understand CSID processing and to do what is necessary for their
packet processing enroute. This requires such "Special Transit
Nodes" to be aware of first SRv6 and now C-SID - this is the
same for any new packet encoding technology.
It seems like we are putting the cart before the horse when
raising concerns about existing implementations that are not
SRv6 and C-SID aware of not being able to do their processing.
Let us publish the C-SID document so implementers of those
"Special Transit Nodes" (also being referred to as middleboxes
on some threads) have a reference to upgrade for C-SID support.
Finally, I’ve not heard of issues related to these "Special
Transit Nodes" from operators that have deployed SRv6. That may
be a good discussion to have (again outside the scope of this
document and perhaps in srv6ops?) - so operators who have SRv6
deployment experience can share their learnings and best practices.
Thanks,
Ketan
On Thu, Mar 28, 2024 at 5:34 PM Alvaro Retana
<aretana.i...@gmail.com> wrote:
Section 6.5 of draft-ietf-spring-srv6-srh-compression
describes the
behavior when an originating node inside an SRv6 domain
creates a
packet with a C-SID as the final destination. This
description differs
from the text in Section 8.1 of RFC8200.
We plan to send the draft to the 6man WG for review and
explicitly
highlight this difference.
Please comment on the text in Section 6.5. Does anything
need to be
added, deleted, changed, or clarified?
We want to ask for feedback soon; please send comments on
this topic
by April 5th.
Thanks!
Alvaro.
-- for spring-chairs
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
