Joel, Ketan,
On 28/09/2020 15:25, Ketan Talaulikar (ketant) wrote:
Hi Joel,
Please check inline below.
-----Original Message-----
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Joel M. Halpern
Sent: 25 September 2020 19:08
To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
Thanks Ketan. Let me paraphrase to confirm I understand, with some
suggestions. And repeat the last question which seems to have gotten lost.
It seems that you are saying that the arg field is defined for now so the
format is consistent, but is not used by any behavior defined in this draft.
[KT] The ISIS draft does not actually define any behavior - it only specifies
signaling of a subset of behaviors defined in net-pgm. You are right that the
behaviors that are listed as being signalled by ISIS in the current document do
not support an ARG.
ARG is part of the SID. The fact that it is not used currently by any
SID that is defined for ISIS, does not mean the ARG part of the SID does
not exists. We advertise the SID as 128 bits in ISIS, so we ARG is part
of it.
If so, should we say explicitly that ARG is (or MUST be) 0 for all the
behaviors defined in this draft?
[KT] I am not sure it is necessary. A future ISIS extension may introduce
support for signaling of a behavior that supports ARG.
draft-ietf-spring-srv6-network-programming only defines ARG for END.DT2M.
We can certainly say in ISIS draft that for the SIDs defined in it,
there are no ARGs.
Then separately the folks working on the END.DT2M behavior can write their own
draft one how to advertise that in is-is? Presumably with an additional
sub-TLV dealing with k and x?
[KT] End.DT2M is signaled in BGP and specified in BGP extensions. If a future
ISIS extension was to advertise a SID with a behavior supporting ARG, then it
would need to clarify its handling of the ARG.
Also, can you tell me how the association of an END.T behavior with a table is
understood from the advertisement as described in the draft?
[KT] Indeed, the End.T signaling does not carry the table context with it.
I would tend to remove the END.T from the ISIS draft. If we need it, we
could define it in a separate document.
thanks,
Peter
Thanks,
Ketan
Thank you,
Joel
On 9/25/2020 1:39 AM, Ketan Talaulikar (ketant) wrote:
Hi Joel,
Please check inline below.
-----Original Message-----
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Joel M. Halpern
Sent: 25 September 2020 03:18
To: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] I-D Action:
draft-ietf-lsr-isis-srv6-extensions-10.txt
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.
[KT] This is quite appropriate for this draft since it is only specifying a
generic SID structure and not associated with any specific behavior.
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.
[KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior
which includes support for ARG. That said, I am not quite sure about that text
in that section which talks about how the ARG bits are formed and what they
signify. I believe the ARG in this case is a locally assigned identifier that
maps to an ESI so that it can be used for ESI filtering - much the same as an
ESI label for split-horizon filtering. I see a comment from one of the ADs on
this and I expect that the authors will clarify.
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).
[KT] I hope the previous comment explains.
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.
[KT] I don't believe the handling of ARG is something that can be generalized.
It has to be something specific to the behavior that it is associated with.
Therefore, each behavior that supports an ARG needs to specify its handling.
The net-pgm draft is doing it for End.DT2M and future documents that introduce
other behaviors requiring ARG would be expected to the same.
Thanks,
Ketan
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
_______________________________________________
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
_______________________________________________
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
