Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

From: Chris Bowers <[email-masked]>
Date: Wed, 1 Apr 2020 14:58:40 -0500

Peter,

There seem to be two disconnects in this discussion.

1) The response below implies that the encodings in
draft-ietf-lsr-isis-srv6-extensions are supposed represent the case where
the locators are allocated from several different IPv6 address blocks (for
example, blocks S1/s1 through Sn/sn). However,
draft-ietf-spring-srv6-network-programming and
draft-ietf-6man-segment-routing-header only discuss the case where the
locators are allocated from a single block (S/s).  If an implementation is
expected to properly encode the case where locators are allocated from
several different IPv6 address blocks, then I think that case should be
explicitly described in these documents.

2)   The response below says "To be able to find out where the func and arg
are located, you need to know the LOC length, e.g. Block and Node length."
However, the SRv6 SID Structure Sub-Sub-TLV is carried within the SRv6 End
SID, SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs, which are carried
within the SRv6 Locator TLV.  The  SRv6 Locator TLV has a Loc-Size field.
Why would the value of the LOC length computed as the sum of the Block and
Node length ever be different from the value in the Loc-Size field?

Chris

On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak <[email-masked]> wrote:

> Chris,
>
> please see inline:
>
>
> On 23/03/2020 17:39, Chris Bowers wrote:
> > Peter,
> >
> > The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
> >
> > 1) As discussed in item#3 below, it is not clear that flooding LB
> > Length, LN Length, Fun. Length, and Arg. Length to all ISIS speakers is
> > really the right approach.  However, if the WG determines that it is the
> > right approach, the current encodings of this information in the
> > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As discussed
> > earlier in this thread, a network operator may choose to not allocate
> > all locators from a single block, so LB Length and LN Length may not be
> > well-defined.
>
> I'm not sure what do you mean by not "well defined". For every SID you
> need to know the LOC (B+N) part. If you guarantee that it is the same on
> all nodes, you know it from the local config, otherwise, you advertise
> it with a SID.
>
> > The current encoding of the SRv6 SID Structure
> > Sub-Sub-TLV makes it difficult to represent this situation.  The simple
> > thing to do for nodes that don't have a well-defined value of LB Length
> > and LN Length would be to not advertise a value for LB Length and LN
> > Length.  However, since the currently proposed SRv6 SID Structure
> > Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg. Length
> > into a single sub-sub-TLV, if a node wants to advertise values for Fun.
> > Length and Arg. Length, it also has to advertise values for LB Length
> > and LN Length.  It seems like a better approach would be to have
> > different sub-sub-TLVs, one for  LB Length and LN Length, and a separate
> > one for Fun. Length and Arg. Length to be able to better represent this
> > situation.
>
>
> I'm afraid you are missing an important point.
>
> SRv6 SID is defined as LOC:FUNCT:ARG, where LOC is represented as B:N.
> To be able to find out where the func and arg are located, you need to
> know the LOC length, e.g. Block and Node length. Advertising just Func
> and Arg length does not help.
>
>
> >
> > 2) Now consider the situation where a network operator chooses to
> > allocate all locators from a single block, so that LB Length and LN
> > Length are well-defined across the network.  A given node should
> > presumably advertise its own understanding of LB Length and LN Length.
> > A given node's understanding of LB Length and LN Length is a property of
> > the node.  It is not a property of a given End SID.  The currently
> > proposed SRv6 SID Structure Sub-Sub-TLV however is carried within each
> > End SID Sub-TLV.  With the currently proposed encoding, presumably an
> > implementation is expected to send the exact same values of LB Length
> > and LN Length for all of the End SIDs that it advertises.  Not only is
> > this inefficient, but it creates the need for logic to decide what to do
> > when different End SIDs advertised by the same node carry different
> > values of LB Length and LN Length in their sub-sub-TLVs.  It seems like
> > a better approach would be for a given node to advertise its
> > understanding of the value of LB Length and LN Length in a sub-TLV of
> > the Router Capability TLV.
>
> When we design the encoding, we have to define it such, that it supports
> all possible use cases. We can not design the encoding that works for
> single use case (allocate all locators from a single block) and does not
> work for others - different block from different node, multiple blocks
> on a single node (e.g. border node), which are all valid.
>
> >
> > 3) At this point, the only use case that has been proposed for flooding
> > the LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS
> > speakers is to make it more convenient for BGP-LS to get those values to
> > an external controller as part of a topology feed from any ISIS node.
> > No use case has been proposed for ISIS speakers themselves to make use
> > of the information.  It seems like a more scalable approach would be to
> > use BGP-LS sessions to collect the information from the subset of nodes
> > that actually produce the relevant information.  So far there are no End
> > SIDs defined that are advertised in ISIS that have a non-zero Arg.
> > Length.  If an End SID with non-zero Arg. Length were to be proposed in
> > the future as needing to be flooded to all ISIS nodes, it seems likely
> > that the new End SID would also be advertised using the BGP IP/VPN/EVPN
> > control plane.   So it seems like a viable alternative for this
> > hypothetical future End SID would be to have the subset of nodes that
> > have non-zero Arg. Length values communicate to an external controller
> > via  BGP sessions. I think the WG needs a more detailed discussion of a
> > concrete use case in order to determine whether flooding LB Length, LN
> > Length, Fun. Length, and Arg. Length to all ISIS speakers is really the
> > right approach.
>
> there are networks, where BGP is not deployed on all nodes, only on a
> few nodes that re-distribute the information to BGP-LS. In such case we
> need the IGP to distribute this data.
>
> Argument that "it seems likely that the new End SID would also be
> advertised using the BGP IP/VPN/EVPN" is a wishful thinking that we can
> not based our encoding on.
>
>
> >
> > Given the lack of a compelling use case for flooding LB Length, LN
> > Length, Fun. Length, and Arg. Length to all ISIS speakers and the
> > problems with the currently proposed encodings for doing that, I think
> > that the SRv6 SID Structure Sub-Sub-TLV should be removed from
> > draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB Length,
> > LN Length, Fun. Length, and Arg. Length to all ISIS speakers can be
> > defined in a future document.
>
> The security use case has already been pointed out earlier in this thread:
>
>
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
>
> Given the arguments I mentioned above, I respectfully disagree with the
> removal of the SID Structure Sub-Sub-TLV from the ISIS SRv6 draft.
>
> thanks,
> Peter
>
>
> >
> > Thanks,
> > Chris
> >
> > On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     Hi Chris,
> >
> >     On 12/03/2020 15:58, Chris Bowers wrote:
> >      > Peter,
> >      >
> >      > I think that the SRv6 SID Structure Sub-Sub-TLV should be removed
> >     from
> >      > draft-ietf-lsr-isis-srv6-extensions.  I think that we should
> >     leave the
> >      > ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV,
> >     End.X SID
> >      > Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those
> >     sub-TLVs.
> >      >
> >      > I don't think that the current text describing the SRv6 SID
> >     Structure
> >      > Sub-Sub-TLV would result in interoperable implementations.  Based
> >     on the
> >
> >     SRv6 base spec defines SID B, L, A, F.
> >
> >     SRv6 protocol specs are advertising these values with the SRv6 SID,
> >     they
> >     don't use them. The usage is outside of the scope of the protocol
> >     drafts. What exactly is the problem?
> >
> >     thanks,
> >     Peter
> >
> >
> >      > discussion with Ketan below, it appears that use cases for ISIS
> >     speakers
> >      > receiving advertised values of LB Length, LN Length, Fun. Length,
> >     and
> >      > Arg. Length are not currently well-defined.    So I think it
> >     makes sense
> >      > to defer the definition of the SRv6 SID Structure Sub-Sub-TLV to a
> >      > future document.
> >      >
> >      > Thanks,
> >      > Chris
> >      >
> >      > On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant)
> >      > <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >      >
> >      >     Hi Chris,____
> >      >
> >      >     __ __
> >      >
> >      >     Dropping the draft-ietf-spring-srv6-network-programming
> authors
> >      >     since we are now back to discussing the ISIS extensions.____
> >      >
> >      >     __ __
> >      >
> >      >     Please check inline below.____
> >      >
> >      >     __ __
> >      >
> >      >     *From:*Chris Bowers <[email-masked]
> >     <mailto:[email-masked]>
> >      >     <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >      >     *Sent:* 05 March 2020 21:53
> >      >     *To:* Ketan Talaulikar (ketant) <[email-masked]
> >     <mailto:[email-masked]>
> >      >     <mailto:[email-masked] <mailto:[email-masked]>>>
> >      >     *Cc:* Ketan Talaulikar (ketant) <[email-masked]
> >     <mailto:[email-masked]>
> >      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>;
> >      >     SPRING WG List <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>;
> >      >     draft-ietf-spring-srv6-network-programming
> >      >     <[email-masked]
> >     <mailto:[email-masked]>
> >      >     <mailto:[email-masked]
> >     <mailto:[email-masked]>>>;
> Peter
> >      >     Psenak (ppsenak) <[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>>;
> >      >     Bruno Decraene <[email-masked]
> >     <mailto:[email-masked]>
> >      >     <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >      >     *Subject:* Re: [Lsr] clarification of locator block and
> >     locator node
> >      >     in draft-ietf-spring-srv6-network-programming and
> >      >     draft-ietf-lsr-isis-srv6-extensions____
> >      >
> >      >     __ __
> >      >
> >      >     Ketan,____
> >      >
> >      >     __ __
> >      >
> >      >     See inline [CB].____
> >      >
> >      >     __ __
> >      >
> >      >     On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant)
> >      >     <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
> >      >
> >      >         Hi Chris,____
> >      >
> >      >         ____
> >      >
> >      >         You are right in that there is no assumption that all SRv6
> >      >         locators in a domain are allocated from the same block.
> >      >         Therefore knowing the blocks used in the domain is
> >     useful.____
> >      >
> >      >     ____
> >      >
> >      >     [CB] Since you refer to "blocks" (plural) in this sentence,
> >     are you
> >      >     saying that in the scenario where all SRv6 locators in a
> >     domain are
> >      >     not allocated from the same block, you would expect different
> >      >     routers in the same domain to advertise different values of B
> >     and N?
> >      >     ____
> >      >
> >      >     */[KT] While personally I believe it would not be the usual
> >     case, it
> >      >     is left to the operator.____/*
> >      >
> >      >     */__ __/*
> >      >
> >      >     For example, assume we have a network where all SRv6 locators
> >     in a
> >      >     domain are not allocated from the same block.  Router A
> >     advertises
> >      >     an SRv6 Locator TLV with locator = 2000::/64, and an SRv6 End
> SID
> >      >     sub-TLV with some endpoint behavior. Router B advertises an
> SRv6
> >      >     Locator TLV with locator = 3000::/64, and an SRv6 End SID
> sub-TLV
> >      >     with some endpoint behavior. What should routers A and B
> >     advertise
> >      >     as the values of B and N in their SRv6 SID Structure
> >     Sub-Sub-TLVs ?____
> >      >
> >      >     */[KT] It is difficult for me to figure out what the block
> >     and node
> >      >     parts are with such an addressing./*____
> >      >
> >      >     ____
> >      >
> >      >         ____
> >      >
> >      >         The IGP drafts covers the advertisement of the B and N
> >     parts of
> >      >         the locally configured locator on the node via IGPs. On
> the
> >      >         receiver side, the IGP may not really do much with this
> >      >         information, however it enables propagation of this
> >     information
> >      >         from all nodes in the network to be advertised out via
> BGP-LS
> >      >         (or other mechanisms) as part of the topology feed. Once
> >     this is
> >      >         part of the topology feed, it enables use-cases on
> >     controllers
> >      >         to perform network wide validation of the SRv6 SID block
> >      >         provisioning and can also help in automation of the
> security
> >      >         aspects described in
> >      >
> >
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5____
> >      >
> >      >         ____
> >      >
> >      >     [CB] If an ISIS speaker is not expected to do anything with B
> >     and N,
> >      >     then I think the text in draft-ietf-lsr-isis-srv6-extensions
> >     needs
> >      >     to clarify this.  I have a similar observation about Fun.
> >     Length and
> >      >     Arg. Length in the SRv6 SID Structure Sub-Sub-TLV .  As far
> >     as I can
> >      >     tell, none of the endpoint behaviors that are currently
> >     specified to
> >      >     be carried in ISIS End, End.X, and LAN End.X SIDs sub-TLVs
> >     uses an
> >      >     Argument, so there is never a case where an SRv6 SID Structure
> >      >     Sub-Sub-TLV should have a non-zero value for Arg. Length. What
> >      >     should an ISIS speaker do if it receives a non-zero value of
> the
> >      >     Arg. Length for an endpoint behavior that doesn't use an
> >     argument?
> >      >     Are there any use cases envisioned where an ISIS speaker
> needs to
> >      >     know the Arg. Length ? ____
> >      >
> >      >     */[KT] The behaviors currently listed in the draft do not
> have an
> >      >     argument nor is the use of B and N required for them. We
> cannot
> >      >     preclude a future use-case or extension where such behaviors
> >      >     introduced are also applicable to ISIS. So IMHO ruling such
> >     aspects
> >      >     out might not be the right thing to do from a protocol
> >     extensibility
> >      >     perspective.____/*
> >      >
> >      >     */__ __/*
> >      >
> >      >     */Thanks,____/*
> >      >
> >      >     */Ketan/*____
> >      >
> >      >     __ __
> >      >
> >      >         Thanks,____
> >      >
> >      >         Ketan____
> >      >
> >      >         ____
> >      >
> >      >         *From:*Chris Bowers <[email-masked]
> >     <mailto:[email-masked]>
> >      >         <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >      >         *Sent:* 02 March 2020 23:39
> >      >         *To:* Ketan Talaulikar (ketant) <[email-masked]
> >     <mailto:[email-masked]>
> >      >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >      >         *Cc:* Ketan Talaulikar (ketant)
> >      >         <ketant=[email-masked]
> >     <mailto:[email-masked]>
> >      >         <mailto:[email-masked]
> >     <mailto:[email-masked]>>>; [email-masked]
> >     <mailto:[email-masked]>
> >      >         <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG
> >     List <[email-masked] <mailto:[email-masked]>
> >      >         <mailto:[email-masked] <mailto:[email-masked]>>>;
> >      >         draft-ietf-spring-srv6-network-programming
> >      >         <[email-masked]
> >     <mailto:[email-masked]>
> >      >
> >       <mailto:[email-masked]
> >     <mailto:[email-masked]>>>;
> >      >         Peter Psenak (ppsenak) <[email-masked]
> >     <mailto:[email-masked]>
> >      >         <mailto:[email-masked] <mailto:[email-masked]>>>;
> >     Bruno Decraene
> >      >         <[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >      >         *Subject:* Re: [Lsr] clarification of locator block and
> >     locator
> >      >         node in draft-ietf-spring-srv6-network-programming and
> >      >         draft-ietf-lsr-isis-srv6-extensions____
> >      >
> >      >         ____
> >      >
> >      >         Ketan,____
> >      >
> >      >         ____
> >      >
> >      >         Based on current documents, allocating all SRv6 locators
> >     used in
> >      >         a domain from a single block is optional.____
> >      >
> >      >         ____
> >      >
> >      >         However, assuming for the moment that a network operator
> has
> >      >         chosen to allocate all SRv6 locators used in a domain
> from a
> >      >         single block, so that there is a well-defined value of B
> >     and N
> >      >         across a domain, what is the use of having a router
> advertise
> >      >         its own understanding of these two values?  And what is a
> >      >         receiver supposed to do with this information?____
> >      >
> >      >         ____
> >      >
> >      >         Thanks,____
> >      >
> >      >         Chris____
> >      >
> >      >         ____
> >      >
> >      >         On Fri, Feb 28, 2020 at 8:23 AM
> >     <[email-masked] <mailto:[email-masked]>
> >      >         <mailto:[email-masked]
> >     <mailto:[email-masked]>>> wrote:____
> >      >
> >      >             Hi Ketan,____
> >      >
> >      >             ____
> >      >
> >      >             Thanks fort the follow up.____
> >      >
> >      >             Clarification inline [Bruno]____
> >      >
> >      >             ____
> >      >
> >      >             *From**:*Ketan Talaulikar (ketant)
> >     [mailto:[email-masked] <mailto:[email-masked]>
> >      >             <mailto:[email-masked] <mailto:[email-masked]>>]
> >      >             *Sent:* Friday, February 28, 2020 11:11 AM
> >      >             *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar
> (ketant);
> >      >             Chris Bowers
> >      >             *Cc:* [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List;
> >      >             draft-ietf-spring-srv6-network-programming; Peter
> Psenak
> >      >             (ppsenak)
> >      >             *Subject:* RE: [Lsr] clarification of locator block
> and
> >      >             locator node in
> >     draft-ietf-spring-srv6-network-programming
> >      >             and draft-ietf-lsr-isis-srv6-extensions____
> >      >
> >      >             ____
> >      >
> >      >             Hi Bruno,____
> >      >
> >      >             ____
> >      >
> >      >             I believe the description and usage of Locator is
> >     very well
> >      >             described and covered in the net-pgm draft as also the
> >      >             corresponding IGP extensions. Is the question is more
> >     about
> >      >             the “block” part of it (what is not in the block part
> >     is in
> >      >             the node part as per the text in the net-pgm
> draft)?____
> >      >
> >      >             ____
> >      >
> >      >             The “block” is again not a new thing. Please check the
> >      >             following:____
> >      >
> >      >             Under
> >      >
> >
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
> >      >             … look for “block”____
> >      >
> >      > https://tools.ietf.org/html/rfc8402#section-2 … look under
> >      >             SRGB for SRv6____
> >      >
> >      >             ____
> >      >
> >      >             [Bruno]____
> >      >
> >      >             To clarify, my question was not specific to “block”
> but
> >      >             related to the usage, by the receiver, of the
> following
> >      >             piece of information:____
> >      >
> >      >             ____
> >      >
> >      >                    LB Length: SRv6 SID Locator Block length____
> >      >
> >      >                    LN Length: SRv6 SID Locator Node length____
> >      >
> >      >                    Fun. Length: SRv6 SID Function length____
> >      >
> >      >                    Arg. Length: SRv6 SID Arguments length____
> >      >
> >      >             ____
> >      >
> >      >             ____
> >      >
> >      >             So perhaps I don’t get Chris’s point and would wait
> >     for him
> >      >             to clarify.____
> >      >
> >      >             [Bruno] I’ll leave this to Chris.____
> >      >
> >      >             ____
> >      >
> >      >             Thanks,____
> >      >
> >      >             Ketan____
> >      >
> >      >             ____
> >      >
> >      >             *From:*Lsr <[email-masked]
> >     <mailto:[email-masked]>
> >      >             <mailto:[email-masked]
> >     <mailto:[email-masked]>>> *On Behalf Of
> >      >             [email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>
> >      >             *Sent:* 28 February 2020 14:34
> >      >             *To:* Ketan Talaulikar (ketant)
> >      >             <ketant=[email-masked]
> >     <mailto:[email-masked]>
> >      >             <mailto:[email-masked]
> >     <mailto:[email-masked]>>>; Chris Bowers
> >      >             <[email-masked]
> >     <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >      >             *Cc:* [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List
> >      >             <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>;
> >      >             draft-ietf-spring-srv6-network-programming
> >      >             <[email-masked]
> >     <mailto:[email-masked]>
> >      >
> >       <mailto:[email-masked]
> >     <mailto:[email-masked]>>>;
> >      >             Peter Psenak (ppsenak) <[email-masked]
> >     <mailto:[email-masked]>
> >      >             <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >      >             *Subject:* Re: [Lsr] clarification of locator block
> and
> >      >             locator node in
> >     draft-ietf-spring-srv6-network-programming
> >      >             and draft-ietf-lsr-isis-srv6-extensions____
> >      >
> >      >             ____
> >      >
> >      >             Hi Ketan,____
> >      >
> >      >             ____
> >      >
> >      >             ____
> >      >
> >      >             ____
> >      >
> >      >             *From:*Lsr [mailto:[email-masked]
> >     <mailto:[email-masked]>] *On Behalf Of
> >      >             *Ketan Talaulikar (ketant)
> >      >             *Sent:* Friday, February 28, 2020 6:30 AM____
> >      >
> >      >             ____
> >      >
> >      >             Hi Chris,____
> >      >
> >      >             ____
> >      >
> >      >             I agree with Peter and I would suggest to drop LSR
> since
> >      >             this is not a protocol specific thing.____
> >      >
> >      >             ____
> >      >
> >      >             I believe the text in
> >      >             draft-ietf-spring-srv6-network-programming clears
> >     says what
> >      >             locator block and locator node are. What more details
> >     do you
> >      >             think are required?____
> >      >
> >      >             ____
> >      >
> >      >             [Bruno] Speaking as an individual, the draft could
> >     possibly
> >      >             clarify the usage of these information/fields by the
> >      >             receiver. Possibly using the same name/term (e.g.
> >     SRv6 SID
> >      >             Locator Block length) to ease the references between
> both
> >      >             drafts.____
> >      >
> >      >             ____
> >      >
> >      >             Thanks,____
> >      >
> >      >             --Bruno____
> >      >
> >      >             ____
> >      >
> >      >             Thanks,____
> >      >
> >      >             Ketan____
> >      >
> >      >             ____
> >      >
> >      >             *From:*Lsr <[email-masked]
> >     <mailto:[email-masked]>
> >      >             <mailto:[email-masked]
> >     <mailto:[email-masked]>>> *On Behalf Of *Chris Bowers
> >      >             *Sent:* 27 February 2020 22:46
> >      >             *To:* [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List
> >      >             <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>
> >      >             *Cc:* Peter Psenak (ppsenak) <[email-masked]
> >     <mailto:[email-masked]>
> >      >             <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >      >             *Subject:* [Lsr] clarification of locator block and
> >     locator
> >      >             node in draft-ietf-spring-srv6-network-programming and
> >      >             draft-ietf-lsr-isis-srv6-extensions____
> >      >
> >      >             ____
> >      >
> >      >             SPRING and LSR WGs,____
> >      >
> >      >             ____
> >      >
> >      >             I think that we need a much more detailed description
> >     of the
> >      >             locator block and locator node in either
> >      >             draft-ietf-spring-srv6-network-programming or
> >      >             draft-ietf-lsr-isis-srv6-extensions.  See original
> email
> >      >             below.____
> >      >
> >      >             ____
> >      >
> >      >             Thanks,____
> >      >
> >      >             Chris____
> >      >
> >      >             ____
> >      >
> >      >             On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak
> >      >             <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
> >      >
> >      >                 Hi Chris,
> >      >
> >      >                 On 27/02/2020 17:54, Chris Bowers wrote:
> >      >                  > LSR WG,
> >      >                  >
> >      >                  > Section 9 of
> >     draft-ietf-lsr-isis-srv6-extensions-05
> >      >                 defines the  SRv6
> >      >                  > SID Structure Sub-Sub-TLV. In particular, it
> >     defines
> >      >                 encoding for the
> >      >                  > locator block length and the locator node
> length.
> >      >                 The text refers to
> >      >                  > [I-D.ietf-spring-srv6-network-programming] for
> the
> >      >                 definition of these
> >      >                  > concepts.
> >      >                  >
> >      >                  > As far as I can tell, the only reference to
> >     locator
> >      >                 block and locator
> >      >                  > node in
> >     draft-ietf-spring-srv6-network-programming-10
> >      >                 is section 3.1
> >      >                  > which has the following text:
> >      >                  >
> >      >                  >     A locator may be represented as B:N where
> B is
> >      >                 the SRv6 SID block
> >      >                  >     (IPv6 subnet allocated for SRv6 SIDs by the
> >      >                 operator) and N is the
> >      >                  >     identifier of the parent node
> >     instantiating the
> >      >                 SID...
> >      >                  >
> >      >                  > I think that we need a much more detailed
> >     description
> >      >                 of the locator
> >      >                  > block and locator node.
> >      >
> >      >                 sure, but that would be in the
> >      >                 draft-ietf-spring-srv6-network-programming-10,
> not in
> >      >                 draft-ietf-lsr-isis-srv6-extensions, as these are
> >     not a
> >      >                 protocol
> >      >                 specific constructs.
> >      >
> >      >                 thanks,
> >      >                 Peter
> >      >
> >      >                  >
> >      >                  > Thanks,
> >      >                  >
> >      >                  > Chris
> >      >                  > ____
> >      >
> >      >
> >
>  _____________________________________________________________________________________________________________________________
> >      >
> >      >             ____
> >      >
> >      >             Ce message et ses pieces jointes peuvent contenir des
> >      >             informations confidentielles ou privilegiees et ne
> >     doivent donc____
> >      >
> >      >             pas etre diffuses, exploites ou copies sans
> >     autorisation. Si
> >      >             vous avez recu ce message par erreur, veuillez le
> >     signaler____
> >      >
> >      >             a l'expediteur et le detruire ainsi que les pieces
> >     jointes.
> >      >             Les messages electroniques etant susceptibles
> >     d'alteration,____
> >      >
> >      >             Orange decline toute responsabilite si ce message a
> ete
> >      >             altere, deforme ou falsifie. Merci.____
> >      >
> >      >             ____
> >      >
> >      >             This message and its attachments may contain
> >     confidential or
> >      >             privileged information that may be protected by
> law;____
> >      >
> >      >             they should not be distributed, used or copied without
> >      >             authorisation.____
> >      >
> >      >             If you have received this email in error, please
> >     notify the
> >      >             sender and delete this message and its
> attachments.____
> >      >
> >      >             As emails may be altered, Orange is not liable for
> >     messages
> >      >             that have been modified, changed or falsified.____
> >      >
> >      >             Thank you.____
> >      >
> >      >
> >
>  _____________________________________________________________________________________________________________________________
> >      >
> >      >             ____
> >      >
> >      >             Ce message et ses pieces jointes peuvent contenir des
> >      >             informations confidentielles ou privilegiees et ne
> >     doivent donc____
> >      >
> >      >             pas etre diffuses, exploites ou copies sans
> >     autorisation. Si
> >      >             vous avez recu ce message par erreur, veuillez le
> >     signaler____
> >      >
> >      >             a l'expediteur et le detruire ainsi que les pieces
> >     jointes.
> >      >             Les messages electroniques etant susceptibles
> >     d'alteration,____
> >      >
> >      >             Orange decline toute responsabilite si ce message a
> ete
> >      >             altere, deforme ou falsifie. Merci.____
> >      >
> >      >             ____
> >      >
> >      >             This message and its attachments may contain
> >     confidential or
> >      >             privileged information that may be protected by
> law;____
> >      >
> >      >             they should not be distributed, used or copied without
> >      >             authorisation.____
> >      >
> >      >             If you have received this email in error, please
> >     notify the
> >      >             sender and delete this message and its
> attachments.____
> >      >
> >      >             As emails may be altered, Orange is not liable for
> >     messages
> >      >             that have been modified, changed or falsified.____
> >      >
> >      >             Thank you.____
> >      >
> >
>
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 6 Apr 2020 13:03:09 +0200

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> draft-ietf-lsr-isis-srv6-extensions are supposed represent the case 
> where the locators are allocated from several different IPv6 address 
> blocks (for example, blocks S1/s1 through Sn/sn). However, 
> locators are allocated from a single block (S/s).  If an implementation 
> is expected to properly encode the case where locators are allocated 
> from several different IPv6 address blocks, then I think that case 
> should be explicitly described in these documents.

There is no statement in draft-ietf-spring-srv6-network-programming that 
the block is unique. As an example, Iliad authorized me to indicate that 
their SRv6 deployment involves several blocks.

> 
> 2)   The response below says "To be able to find out where the func and 
> arg are located, you need to know the LOC length, e.g. Block and Node 
> length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried within 
> the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs, 
> which are carried within the SRv6 Locator TLV.  

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are 
advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in 
SRv6 Locator TLV.

thanks,
Peter

> The  SRv6 Locator TLV 
> has a Loc-Size field.  Why would the value of the LOC length computed as 
> the sum of the Block and Node length ever be different from the value in 
> the Loc-Size field?
> 
> Chris
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak <[email-masked] 
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Chris,
>      >
>      >      > Peter,
>      >      >
>      >      > I think that the SRv6 SID Structure Sub-Sub-TLV should be
>     removed
>      >     from
>      >      > draft-ietf-lsr-isis-srv6-extensions.  I think that we should
>      >     leave the
>      >      > ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV,
>      >     End.X SID
>      >      > Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those
>      >     sub-TLVs.
>      >      >
>      >      > I don't think that the current text describing the SRv6 SID
>      >     Structure
>      >      > Sub-Sub-TLV would result in interoperable
>     implementations.  Based
>      >     on the
>      >
>      >      > discussion with Ketan below, it appears that use cases for
>     ISIS
>      >     speakers
>      >      > receiving advertised values of LB Length, LN Length, Fun.
>     Length,
>      >     and
>      >      > Arg. Length are not currently well-defined.    So I think it
>      >     makes sense
>      >      > to defer the definition of the SRv6 SID Structure
>     Sub-Sub-TLV to a
>      >      > future document.
>      >      >
>      >      > Thanks,
>      >      > Chris
>      >      >
>      >      > On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant)
>      >      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi Chris,____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Dropping the
>     draft-ietf-spring-srv6-network-programming authors
>      >      >     since we are now back to discussing the ISIS
>     extensions.____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Please check inline below.____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     *From:*Chris Bowers <[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >     *Sent:* 05 March 2020 21:53
>      >      >     *To:* Ketan Talaulikar (ketant) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >     *Cc:* Ketan Talaulikar (ketant) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>      >      >     SPRING WG List <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      >     draft-ietf-spring-srv6-network-programming
>      >      >     <[email-masked]
>     <mailto:[email-masked]>>
>      >      >   
>     <mailto:[email-masked]>>>>; Peter
>      >      >     Psenak (ppsenak) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      >     Bruno Decraene <[email-masked]
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >     *Subject:* Re: [Lsr] clarification of locator block and
>      >     locator node
>      >      >     in draft-ietf-spring-srv6-network-programming and
>      >      >     draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     Ketan,____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     See inline [CB].____
>      >      >
>      >      >     __ __
>      >      >
>      >      >     On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant)
>      >      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____
>      >      >
>      >      >         Hi Chris,____
>      >      >
>      >      >         ____
>      >      >
>      >      >         You are right in that there is no assumption that
>     all SRv6
>      >      >         locators in a domain are allocated from the same
>     block.
>      >      >         Therefore knowing the blocks used in the domain is
>      >     useful.____
>      >      >
>      >      >     ____
>      >      >
>      >      >     [CB] Since you refer to "blocks" (plural) in this
>     sentence,
>      >     are you
>      >      >     saying that in the scenario where all SRv6 locators in a
>      >     domain are
>      >      >     not allocated from the same block, you would expect
>     different
>      >      >     routers in the same domain to advertise different
>     values of B
>      >     and N?
>      >      >     ____
>      >      >
>      >      >     */[KT] While personally I believe it would not be the
>     usual
>      >     case, it
>      >      >     is left to the operator.____/*
>      >      >
>      >      >     */__ __/*
>      >      >
>      >      >     For example, assume we have a network where all SRv6
>     locators
>      >     in a
>      >      >     domain are not allocated from the same block.  Router A
>      >     advertises
>      >      >     an SRv6 Locator TLV with locator = 2000::/64, and an
>     SRv6 End SID
>      >      >     sub-TLV with some endpoint behavior. Router B
>     advertises an SRv6
>      >      >     Locator TLV with locator = 3000::/64, and an SRv6 End
>     SID sub-TLV
>      >      >     with some endpoint behavior. What should routers A and B
>      >     advertise
>      >      >     as the values of B and N in their SRv6 SID Structure
>      >     Sub-Sub-TLVs ?____
>      >      >
>      >      >     */[KT] It is difficult for me to figure out what the block
>      >     and node
>      >      >     parts are with such an addressing./*____
>      >      >
>      >      >     ____
>      >      >
>      >      >         ____
>      >      >
>      >      >         The IGP drafts covers the advertisement of the B and N
>      >     parts of
>      >      >         the locally configured locator on the node via
>     IGPs. On the
>      >      >         receiver side, the IGP may not really do much with
>     this
>      >      >         information, however it enables propagation of this
>      >     information
>      >      >         from all nodes in the network to be advertised out
>     via BGP-LS
>      >      >         (or other mechanisms) as part of the topology
>     feed. Once
>      >     this is
>      >      >         part of the topology feed, it enables use-cases on
>      >     controllers
>      >      >         to perform network wide validation of the SRv6 SID
>     block
>      >      >         provisioning and can also help in automation of
>     the security
>      >      >         aspects described in
>      >      >
>      >
>      >      >
>      >      >         ____
>      >      >
>      >      >     [CB] If an ISIS speaker is not expected to do anything
>     with B
>      >     and N,
>      >      >     then I think the text in
>     draft-ietf-lsr-isis-srv6-extensions
>      >     needs
>      >      >     to clarify this.  I have a similar observation about Fun.
>      >     Length and
>      >      >     Arg. Length in the SRv6 SID Structure Sub-Sub-TLV . 
>     As far
>      >     as I can
>      >      >     tell, none of the endpoint behaviors that are currently
>      >     specified to
>      >      >     be carried in ISIS End, End.X, and LAN End.X SIDs sub-TLVs
>      >     uses an
>      >      >     Argument, so there is never a case where an SRv6 SID
>     Structure
>      >      >     Sub-Sub-TLV should have a non-zero value for Arg.
>     Length. What
>      >      >     should an ISIS speaker do if it receives a non-zero
>     value of the
>      >      >     Arg. Length for an endpoint behavior that doesn't use an
>      >     argument?
>      >      >     Are there any use cases envisioned where an ISIS
>     speaker needs to
>      >      >     know the Arg. Length ? ____
>      >      >
>      >      >     */[KT] The behaviors currently listed in the draft do
>     not have an
>      >      >     argument nor is the use of B and N required for them.
>     We cannot
>      >      >     preclude a future use-case or extension where such
>     behaviors
>      >      >     introduced are also applicable to ISIS. So IMHO ruling
>     such
>      >     aspects
>      >      >     out might not be the right thing to do from a protocol
>      >     extensibility
>      >      >     perspective.____/*
>      >      >
>      >      >     */__ __/*
>      >      >
>      >      >     */Thanks,____/*
>      >      >
>      >      >     */Ketan/*____
>      >      >
>      >      >     __ __
>      >      >
>      >      >         Thanks,____
>      >      >
>      >      >         Ketan____
>      >      >
>      >      >         ____
>      >      >
>      >      >         *From:*Chris Bowers <[email-masked]
>     <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >         *Sent:* 02 March 2020 23:39
>      >      >         *To:* Ketan Talaulikar (ketant) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >         *Cc:* Ketan Talaulikar (ketant)
>      >      >         <ketant=[email-masked]
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>; [email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      >         draft-ietf-spring-srv6-network-programming
>      >      >       
>     <mailto:[email-masked]>>
>      >      >
>     <mailto:[email-masked]>>>>;
>      >      >         Peter Psenak (ppsenak) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>>;
>      >     Bruno Decraene
>      >      >         <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>
>      >      >         *Subject:* Re: [Lsr] clarification of locator
>     block and
>      >     locator
>      >      >         node in draft-ietf-spring-srv6-network-programming and
>      >      >         draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Ketan,____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Based on current documents, allocating all SRv6
>     locators
>      >     used in
>      >      >         a domain from a single block is optional.____
>      >      >
>      >      >         ____
>      >      >
>      >      >         However, assuming for the moment that a network
>     operator has
>      >      >         chosen to allocate all SRv6 locators used in a
>     domain from a
>      >      >         single block, so that there is a well-defined
>     value of B
>      >     and N
>      >      >         across a domain, what is the use of having a
>     router advertise
>      >      >         its own understanding of these two values?  And
>     what is a
>      >      >         receiver supposed to do with this information?____
>      >      >
>      >      >         ____
>      >      >
>      >      >         Thanks,____
>      >      >
>      >      >         Chris____
>      >      >
>      >      >         ____
>      >      >
>      >      >         On Fri, Feb 28, 2020 at 8:23 AM
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:____
>      >      >
>      >      >             Hi Ketan,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks fort the follow up.____
>      >      >
>      >      >             Clarification inline [Bruno]____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From**:*Ketan Talaulikar (ketant)
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>]
>      >      >             *Sent:* Friday, February 28, 2020 11:11 AM
>      >      >             *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar
>     (ketant);
>      >      >             Chris Bowers
>      >      >             *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List;
>      >      >             draft-ietf-spring-srv6-network-programming;
>     Peter Psenak
>      >      >             (ppsenak)
>      >      >             *Subject:* RE: [Lsr] clarification of locator
>     block and
>      >      >             locator node in
>      >      >             and draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Bruno,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I believe the description and usage of Locator is
>      >     very well
>      >      >             described and covered in the net-pgm draft as
>     also the
>      >      >             corresponding IGP extensions. Is the question
>     is more
>      >     about
>      >      >             the “block” part of it (what is not in the
>     block part
>      >     is in
>      >      >             the node part as per the text in the net-pgm
>     draft)?____
>      >      >
>      >      >             ____
>      >      >
>      >      >             The “block” is again not a new thing. Please
>     check the
>      >      >             following:____
>      >      >
>      >      >             Under
>      >      >
>      >
>      >      >             … look for “block”____
>      >      >
>      >      > https://tools.ietf.org/html/rfc8402#section-2 … look under
>      >      >             SRGB for SRv6____
>      >      >
>      >      >             ____
>      >      >
>      >      >             [Bruno]____
>      >      >
>      >      >             To clarify, my question was not specific to
>     “block” but
>      >      >             related to the usage, by the receiver, of the
>     following
>      >      >             piece of information:____
>      >      >
>      >      >             ____
>      >      >
>      >      >                    LB Length: SRv6 SID Locator Block
>     length____
>      >      >
>      >      >                    LN Length: SRv6 SID Locator Node length____
>      >      >
>      >      >                    Fun. Length: SRv6 SID Function length____
>      >      >
>      >      >                    Arg. Length: SRv6 SID Arguments length____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             So perhaps I don’t get Chris’s point and would
>     wait
>      >     for him
>      >      >             to clarify.____
>      >      >
>      >      >             [Bruno] I’ll leave this to Chris.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Ketan____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     *On Behalf Of
>      >      >             [email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >      >             *Sent:* 28 February 2020 14:34
>      >      >             *To:* Ketan Talaulikar (ketant)
>      >      >             <ketant=[email-masked]
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>; Chris Bowers
>      >      >             <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>
>      >      >             *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List
>      >      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      >             draft-ietf-spring-srv6-network-programming
>      >      >           
>     <mailto:[email-masked]>>
>      >      >
>     <mailto:[email-masked]>>>>;
>      >      >             Peter Psenak (ppsenak) <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >             *Subject:* Re: [Lsr] clarification of locator
>     block and
>      >      >             locator node in
>      >      >             and draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Ketan,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr [mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>]
>     *On Behalf Of
>      >      >             *Ketan Talaulikar (ketant)
>      >      >             *Sent:* Friday, February 28, 2020 6:30 AM____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Hi Chris,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I agree with Peter and I would suggest to drop
>     LSR since
>      >      >             this is not a protocol specific thing.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I believe the text in
>      >      >             draft-ietf-spring-srv6-network-programming clears
>      >     says what
>      >      >             locator block and locator node are. What more
>     details
>      >     do you
>      >      >             think are required?____
>      >      >
>      >      >             ____
>      >      >
>      >      >             [Bruno] Speaking as an individual, the draft could
>      >     possibly
>      >      >             clarify the usage of these information/fields
>     by the
>      >      >             receiver. Possibly using the same name/term (e.g.
>      >     SRv6 SID
>      >      >             Locator Block length) to ease the references
>     between both
>      >      >             drafts.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             --Bruno____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Ketan____
>      >      >
>      >      >             ____
>      >      >
>      >      >             *From:*Lsr <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     *On Behalf Of *Chris Bowers
>      >      >             *Sent:* 27 February 2020 22:46
>      >      >             *To:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List
>      >      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >             *Cc:* Peter Psenak (ppsenak)
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >             *Subject:* [Lsr] clarification of locator
>     block and
>      >     locator
>      >      >             node in
>      >      >             draft-ietf-lsr-isis-srv6-extensions____
>      >      >
>      >      >             ____
>      >      >
>      >      >             SPRING and LSR WGs,____
>      >      >
>      >      >             ____
>      >      >
>      >      >             I think that we need a much more detailed
>     description
>      >     of the
>      >      >             locator block and locator node in either
>      >      >             draft-ietf-spring-srv6-network-programming or
>      >      >             draft-ietf-lsr-isis-srv6-extensions.  See
>     original email
>      >      >             below.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             Thanks,____
>      >      >
>      >      >             Chris____
>      >      >
>      >      >             ____
>      >      >
>      >      >             On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak
>      >      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____
>      >      >
>      >      >                 Hi Chris,
>      >      >
>      >      >                 On 27/02/2020 17:54, Chris Bowers wrote:
>      >      >                  > LSR WG,
>      >      >                  >
>      >      >                  > Section 9 of
>      >      >                 defines the  SRv6
>      >      >                  > SID Structure Sub-Sub-TLV. In
>     particular, it
>      >     defines
>      >      >                 encoding for the
>      >      >                  > locator block length and the locator
>     node length.
>      >      >                 The text refers to
>      >      >                  >
>     [I-D.ietf-spring-srv6-network-programming] for the
>      >      >                 definition of these
>      >      >                  > concepts.
>      >      >                  >
>      >      >                  > As far as I can tell, the only reference to
>      >     locator
>      >      >                 block and locator
>      >      >                  > node in
>      >      >                 is section 3.1
>      >      >                  > which has the following text:
>      >      >                  >
>      >      >                  >     A locator may be represented as B:N
>     where B is
>      >      >                 the SRv6 SID block
>      >      >                  >     (IPv6 subnet allocated for SRv6
>     SIDs by the
>      >      >                 operator) and N is the
>      >      >                  >     identifier of the parent node
>      >     instantiating the
>      >      >                 SID...
>      >      >                  >
>      >      >                  > I think that we need a much more detailed
>      >     description
>      >      >                 of the locator
>      >      >                  > block and locator node.
>      >      >
>      >      >                 sure, but that would be in the
>      >      >               
>       draft-ietf-spring-srv6-network-programming-10, not in
>      >      >                 draft-ietf-lsr-isis-srv6-extensions, as
>     these are
>      >     not a
>      >      >                 protocol
>      >      >                 specific constructs.
>      >      >
>      >      >                 thanks,
>      >      >                 Peter
>      >      >
>      >      >                  >
>      >      >                  > Thanks,
>      >      >                  >
>      >      >                  > Chris
>      >      >                  > ____
>      >      >
>      >      >
>      >     
>      >      >
>      >      >             ____
>      >      >
>      >      >             Ce message et ses pieces jointes peuvent
>     contenir des
>      >      >             informations confidentielles ou privilegiees et ne
>      >     doivent donc____
>      >      >
>      >      >             pas etre diffuses, exploites ou copies sans
>      >     autorisation. Si
>      >      >             vous avez recu ce message par erreur, veuillez le
>      >     signaler____
>      >      >
>      >      >             a l'expediteur et le detruire ainsi que les pieces
>      >     jointes.
>      >      >             Les messages electroniques etant susceptibles
>      >     d'alteration,____
>      >      >
>      >      >             Orange decline toute responsabilite si ce
>     message a ete
>      >      >             altere, deforme ou falsifie. Merci.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             This message and its attachments may contain
>      >     confidential or
>      >      >             privileged information that may be protected
>     by law;____
>      >      >
>      >      >             they should not be distributed, used or copied
>     without
>      >      >             authorisation.____
>      >      >
>      >      >             If you have received this email in error, please
>      >     notify the
>      >      >             sender and delete this message and its
>     attachments.____
>      >      >
>      >      >             As emails may be altered, Orange is not liable for
>      >     messages
>      >      >             that have been modified, changed or falsified.____
>      >      >
>      >      >             Thank you.____
>      >      >
>      >      >
>      >     
>      >      >
>      >      >             ____
>      >      >
>      >      >             Ce message et ses pieces jointes peuvent
>     contenir des
>      >      >             informations confidentielles ou privilegiees et ne
>      >     doivent donc____
>      >      >
>      >      >             pas etre diffuses, exploites ou copies sans
>      >     autorisation. Si
>      >      >             vous avez recu ce message par erreur, veuillez le
>      >     signaler____
>      >      >
>      >      >             a l'expediteur et le detruire ainsi que les pieces
>      >     jointes.
>      >      >             Les messages electroniques etant susceptibles
>      >     d'alteration,____
>      >      >
>      >      >             Orange decline toute responsabilite si ce
>     message a ete
>      >      >             altere, deforme ou falsifie. Merci.____
>      >      >
>      >      >             ____
>      >      >
>      >      >             This message and its attachments may contain
>      >     confidential or
>      >      >             privileged information that may be protected
>     by law;____
>      >      >
>      >      >             they should not be distributed, used or copied
>     without
>      >      >             authorisation.____
>      >      >
>      >      >             If you have received this email in error, please
>      >     notify the
>      >      >             sender and delete this message and its
>     attachments.____
>      >      >
>      >      >             As emails may be altered, Orange is not liable for
>      >     messages
>      >      >             that have been modified, changed or falsified.____
>      >      >
>      >      >             Thank you.____
>      >      >
>      >
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 7 Apr 2020 02:56:28 +0000

Hi Chris, Peter,

Here are some personal opinions about this discussion:

-            Keep LBL and LNL in the structure sub-TLV is better for protocol scalability and flexibility, an operator could choose to allocate SRv6 locator from the same locator block, or from different locator block.

-            It is suggested to design SID structure sub-TLV as a general TLV which could be used for BGP/BGP-LS/ISIS/OSPF.

-            SID is supposed to be advertised with suitable protocol based on the use case. Whether it contains argument or not is not relevant.

B.R.

Xuesong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Peter Psenak
Sent: Monday, April 6, 2020 7:03 PM
To: Chris Bowers <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Chris,

> locators are allocated from a single block (S/s).  If an

> implementation is expected to properly encode the case where locators

> are allocated from several different IPv6 address blocks, then I think

> that case should be explicitly described in these documents.

There is no statement in draft-ietf-spring-srv6-network-programming that the block is unique. As an example, Iliad authorized me to indicate that their SRv6 deployment involves several blocks.

> 2)   The response below says "To be able to find out where the func

> and arg are located, you need to know the LOC length, e.g. Block and

> Node length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried

> within the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID

> Sub-TLVs, which are carried within the SRv6 Locator TLV.

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in

SRv6 Locator TLV.

thanks,

Peter

> has a Loc-Size field.  Why would the value of the LOC length computed

> as the sum of the Block and Node length ever be different from the

> value in the Loc-Size field?

>      > Length, LN Length, Fun. Length, and Arg. Length to all ISIS

>     speakers is

>      > really the right approach.  However, if the WG determines that it

>     is the

>      > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As

>     discussed

>      > earlier in this thread, a network operator may choose to not

>     allocate

>      > all locators from a single block, so LB Length and LN Length may

>     not be

>     need to know the LOC (B+N) part. If you guarantee that it is the

>     same on

>      > Sub-Sub-TLV makes it difficult to represent this situation.  The

>     simple

>      > thing to do for nodes that don't have a well-defined value of LB

>     Length

>      > Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg.

>     Length

>      > into a single sub-sub-TLV, if a node wants to advertise values

>     for Fun.

>      > Length and Arg. Length, it also has to advertise values for LB

>     Length

>      > different sub-sub-TLVs, one for  LB Length and LN Length, and a

>     separate

>      > one for Fun. Length and Arg. Length to be able to better

>     represent this

>      > presumably advertise its own understanding of LB Length and LN

>     Length.

>      > A given node's understanding of LB Length and LN Length is a

>     property of

>      > proposed SRv6 SID Structure Sub-Sub-TLV however is carried within

>     each

>      > End SID Sub-TLV.  With the currently proposed encoding,

>     presumably an

>      > implementation is expected to send the exact same values of LB

>     Length

>      > and LN Length for all of the End SIDs that it advertises.  Not

>     only is

>      > this inefficient, but it creates the need for logic to decide

>     what to do

>      > values of LB Length and LN Length in their sub-sub-TLVs.  It

>     seems like

>      > understanding of the value of LB Length and LN Length in a

>     sub-TLV of

>     When we design the encoding, we have to define it such, that it

>     supports

>     single use case (allocate all locators from a single block) and does

>     not

>      > 3) At this point, the only use case that has been proposed for

>     flooding

>      > speakers is to make it more convenient for BGP-LS to get those

>     values to

>      > an external controller as part of a topology feed from any ISIS

>     node.

>      > No use case has been proposed for ISIS speakers themselves to

>     make use

>      > of the information.  It seems like a more scalable approach would

>     be to

>      > use BGP-LS sessions to collect the information from the subset of

>     nodes

>      > that actually produce the relevant information.  So far there are

>     no End

>      > Length.  If an End SID with non-zero Arg. Length were to be

>     proposed in

>      > the future as needing to be flooded to all ISIS nodes, it seems

>     likely

>      > that the new End SID would also be advertised using the BGP

>     IP/VPN/EVPN

>      > hypothetical future End SID would be to have the subset of nodes

>     that

>      > have non-zero Arg. Length values communicate to an external

>     controller

>      > via  BGP sessions. I think the WG needs a more detailed

>     discussion of a

>      > concrete use case in order to determine whether flooding LB

>     Length, LN

>      > Length, Fun. Length, and Arg. Length to all ISIS speakers is

>     really the

>      > problems with the currently proposed encodings for doing that, I

>     think

>      > draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB

>     The security use case has already been pointed out earlier in this

>     thread:

> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#

> section-5

>      > <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>> wrote:

>      >      > I think that the SRv6 SID Structure Sub-Sub-TLV should be

>      >      > Sub-Sub-TLV would result in interoperable

>      >     SRv6 protocol specs are advertising these values with the

>     SRv6 SID,

>      >      > discussion with Ketan below, it appears that use cases for

>      >      > receiving advertised values of LB Length, LN Length, Fun.

>      >      > to defer the definition of the SRv6 SID Structure

>      >      > <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>> wrote:

>      >      >     Dropping the

>      >      >     since we are now back to discussing the ISIS

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>;

>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]

>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>;

>      >      >     SPRING WG List <[email-masked]

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>;

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>;

>      >      >     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>> wrote:____

>      >      >         You are right in that there is no assumption that

>      >      >         locators in a domain are allocated from the same

>      >      >     [CB] Since you refer to "blocks" (plural) in this

>      >      >     not allocated from the same block, you would expect

>      >      >     routers in the same domain to advertise different

>      >      >     */[KT] While personally I believe it would not be the

>      >      >     For example, assume we have a network where all SRv6

>      >      >     an SRv6 Locator TLV with locator = 2000::/64, and an

>      >      >     sub-TLV with some endpoint behavior. Router B

>      >      >     Locator TLV with locator = 3000::/64, and an SRv6 End

>      >      >         the locally configured locator on the node via

>      >      >         receiver side, the IGP may not really do much with

>      >      >         from all nodes in the network to be advertised out

>      >      >         (or other mechanisms) as part of the topology

>      >      >         to perform network wide validation of the SRv6 SID

>      >      >         provisioning and can also help in automation of

>      >      >     [CB] If an ISIS speaker is not expected to do anything

>      >      >     then I think the text in

>      >      >     Arg. Length in the SRv6 SID Structure Sub-Sub-TLV .

>      >      >     Argument, so there is never a case where an SRv6 SID

>      >      >     Sub-Sub-TLV should have a non-zero value for Arg.

>      >      >     should an ISIS speaker do if it receives a non-zero

>      >      >     Are there any use cases envisioned where an ISIS

>      >      >     */[KT] The behaviors currently listed in the draft do

>      >      >     argument nor is the use of B and N required for them.

>      >      >     preclude a future use-case or extension where such

>      >      >     introduced are also applicable to ISIS. So IMHO ruling

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >         <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>

>     <mailto:[email-masked]>>>>; [email-masked]<mailto:[email-masked]>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >         <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>; SPRING WG

>      >     List <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >         <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>;

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >         <mailto:[email-masked]

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>      >      >         *Subject:* Re: [Lsr] clarification of locator

>      >      >         Based on current documents, allocating all SRv6

>      >      >         However, assuming for the moment that a network

>      >      >         chosen to allocate all SRv6 locators used in a

>      >      >         single block, so that there is a well-defined

>      >      >         across a domain, what is the use of having a

>      >      >         its own understanding of these two values?  And

>      >     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >             <mailto:[email-masked]

>      >      >             *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>; SPRING WG List;

>      >      >             draft-ietf-spring-srv6-network-programming;

>      >      >             *Subject:* RE: [Lsr] clarification of locator

>      >      >             described and covered in the net-pgm draft as

>      >      >             corresponding IGP extensions. Is the question

>      >      >             the “block” part of it (what is not in the

>      >      >             The “block” is again not a new thing. Please

>      >      >             To clarify, my question was not specific to

>      >      >                    LB Length: SRv6 SID Locator Block

>      >      >             So perhaps I don’t get Chris’s point and would

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>

>      >      >             [email-masked]<mailto:[email-masked]>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>      >      >             *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>; SPRING WG List

>      >      >             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>;

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >             <mailto:[email-masked]

>      >      >             *Subject:* Re: [Lsr] clarification of locator

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>]

>      >      >             I agree with Peter and I would suggest to drop

>      >      >             locator block and locator node are. What more

>      >      >             clarify the usage of these information/fields

>      >      >             Locator Block length) to ease the references

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>

>      >      >             *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>; SPRING WG List

>      >      >             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>>

>      >      >             *Cc:* Peter Psenak (ppsenak)

>     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >      >             <mailto:[email-masked]

>      >      >             *Subject:* [Lsr] clarification of locator

>      >      >             draft-ietf-lsr-isis-srv6-extensions.  See

>      >      >             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>      >     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

>     <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>>> wrote:____

>      >      >                  > SID Structure Sub-Sub-TLV. In

>      >      >                  > locator block length and the locator

>      >      >                  >     A locator may be represented as B:N

>      >      >                  >     (IPv6 subnet allocated for SRv6

>      >      >                 draft-ietf-lsr-isis-srv6-extensions, as

>      >      >             Ce message et ses pieces jointes peuvent

>      >      >             Orange decline toute responsabilite si ce

>      >      >             privileged information that may be protected

>      >      >             they should not be distributed, used or copied

>      >      >             Ce message et ses pieces jointes peuvent

>      >      >             Orange decline toute responsabilite si ce

>      >      >             privileged information that may be protected

>      >      >             they should not be distributed, used or copied

_______________________________________________

spring mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/spring

---

From: Derek Yeung <[email-masked]>
Date: Fri, 10 Apr 2020 06:43:49 +0000

Hi,

We at Arrcus have implemented support for this draft including the SID Structure sub-sub-TLV.
The proposed encodings for the SID Structure sub-sub-TLV is flexible and works fine.

Thanks,
Derek

Derek Yeung
[email-masked]
Main: 408.884.1965

2077 Gateway Place, Suite 400
San Jose, CA.  95110
 
The contents of this message, together with any attachments, are intended only for the use of the individual or entity to which they are addressed and may contain information that is confidential and proprietary to Arrcus. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you.

On 4/6/20, 4:03 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Chris,

    
    
    thanks,
    Peter

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 13 Apr 2020 14:50:08 +0800

Hi Xuesong,

I agree with Xuesong. 

It has been in the draft for quite some time and is useful. 

I do not see any issues with the proposed encodings for the SID Structure sub-TLV in the draft.

B.R.

Weiqiang Cheng

发件人: spring [mailto:[email-masked]] 代表 Gengxuesong (Geng Xuesong)
发送时间: 2020年4月7日 10:56
收件人: Peter Psenak; Chris Bowers
抄送: [email-masked]; SPRING WG List; Ketan Talaulikar (ketant); Bruno Decraene
主题: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Hi Chris, Peter,

B.R.

Xuesong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Peter Psenak
Sent: Monday, April 6, 2020 7:03 PM
To: Chris Bowers <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Chris,

 

SRv6 Locator TLV.

thanks,

Peter

> < <mailto:[email-masked]> mailto:[email-masked]>> wrote:

>  <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      > < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>> wrote:

>      >      > < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>> wrote:

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>;

>      >  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>> < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>; Peter

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>      >      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____

>      <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5____> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5____

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >      >         < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>;  <mailto:[email-masked]> [email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >      >         < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG

>      >     List < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >      >         < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>> wrote:____

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>>>]

>      >      >             *Cc:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List;

>      <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

>      >      >  <https://tools.ietf.org/html/rfc8402#section-2> https://tools.ietf.org/html/rfc8402#section-2 … look under

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>

>      >      >              <mailto:[email-masked]> [email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>; Chris Bowers

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>      >      >             *Cc:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List

>      >      >             < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>;

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>]

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>

>      >      >             *To:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>; SPRING WG List

>      >      >             < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>     < <mailto:[email-masked]> mailto:[email-masked]> <mailto:[email-masked]

>     < <mailto:[email-masked]> mailto:[email-masked]>>>>

>      >      >             < <mailto:[email-masked]%20%3cmailto:[email-masked]> [email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>

>      >     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>

>     < <mailto:[email-masked]%20%3cmailto:[email-masked]> mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____

 

spring mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/spring> https://www.ietf.org/mailman/listinfo/spring

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Apr 2020 14:21:51 +0000

Speaking as WG member:

In the past, we developed protocol encodings that afforded future extendibility. I don't see the problem with the including the SID structure sub-sub-TLV and would support progression.

Thanks,
Acee

On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Derek

    Derek Yeung
    [email-masked]
    Main: 408.884.1965

        Chris,

        thanks,
        Peter