First, there is a slight confusion in the way I formed the quesiton, but
I think it still applies.
The piece of this draft is section 9, which advertises the length of the
arg portion of the SID. But does not provide specific meanings for
specific values.
The example of an ARG in the network programming draft does provide part
of the explicit interpretation of the ARG. It says that it is a list of
k items, each of x bits, where each x bit blob identifies an OIF.
This leaves two gaps, and a more general question.
1) How does the receiver know the meanings of the OIF indices so that he
can correctly fill them in?
2) The NP draft says that k and x are defined on a per SID basis. But I
do not see anywhere in the isis draft to advertise the values of k and
x, only arg (which is k*x).
The more general question is, is there a requirement we can write down
about how receivers will be able to understand ARG fields in general?
One can argue that it would belong in the network programming draft; I
would prefer not to delay that with a significant technical addition.
There is a related question that I came across while trying to explain
this question.
END.T must be associated with a forwarding table. I presume this is
done by where one puts the END.T (however-many-subs) TLV. But I can not
find anything in this draft that says this. There is precisely one
reference to End.T in the draft.
Thank you,
Joel
On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
H Joel,
Can you reference the specific section in the IS-IS SRv6 draft you are
commenting on? I seem to remember this discussion but it was at least a month
back, if not more.
Thanks,
Acee
On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" <lsr-boun...@ietf.org on
behalf of j...@joelhalpern.com> wrote:
The announcement prompted me to look again and think about an
interaction between this and the network programming draft. To be
clear, I am NOT objecting to either this or the network programming
draft. I am just wondering what I am missing.
The NP draft, and the advertisement mechanism allows a router to
advertise the number of bits for the ARG portion of a SID.
Q1: The point presumably is to avoid needing to advertise each of the
individual values?
An example of this is, I think, and ARG for the table selection where
the ARG is the table number for the packet to be looked up in?
Q2: If so, how does the head end know what table number corresponds to
what meaning? If this requires a separate advertisement there seems
to be no savings. if this requires out-of-band knowledge then we seem
to have lost the benefit of advertising all of this in the routing
protocol.
I suspect I am simply missing a piece. can someone explain please?
Thank you,
Joel
On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
> Title : IS-IS Extension to Support Segment Routing
over IPv6 Dataplane
> Authors : Peter Psenak
> Clarence Filsfils
> Ahmed Bashandy
> Bruno Decraene
> Zhibo Hu
> Filename : draft-ietf-lsr-isis-srv6-extensions-10.txt
> Pages : 25
> Date : 2020-09-23
>
> Abstract:
> Segment Routing (SR) allows for a flexible definition of end-to-end
> paths by encoding paths as sequences of topological sub-paths, called
> "segments". Segment routing architecture can be implemented over an
> MPLS data plane as well as an IPv6 data plane. This draft describes
> the IS-IS extensions required to support Segment Routing over an IPv6
> data plane.
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
