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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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 protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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 protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *Sent:* 05 March 2020 21:53
> > *To:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > *Cc:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>;
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>;
> > SPRING WG List <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>;
> > draft-ietf-spring-srv6-network-programming
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >
<mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>; Peter
> > Psenak (ppsenak) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>;
> > Bruno Decraene <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *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 protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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 protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *Sent:* 02 March 2020 23:39
> > *To:* Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > *Cc:* Ketan Talaulikar (ketant)
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>; [email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>; SPRING WG
> List <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>;
> > draft-ietf-spring-srv6-network-programming
> >
<[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>;
> > Peter Psenak (ppsenak) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>;
> Bruno Decraene
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *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 protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> wrote:____
> >
> > Hi Ketan,____
> >
> > ____
> >
> > Thanks fort the follow up.____
> >
> > Clarification inline [Bruno]____
> >
> > ____
> >
> > *From**:*Ketan Talaulikar (ketant)
> [mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>]
> > *Sent:* Friday, February 28, 2020 11:11 AM
> > *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar
(ketant);
> > Chris Bowers
> > *Cc:* [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>; 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 protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
*On Behalf Of
> > *[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> > *Sent:* 28 February 2020 14:34
> > *To:* Ketan Talaulikar (ketant)
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>; Chris Bowers
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>
> > *Cc:* [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>; SPRING WG List
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>;
> > draft-ietf-spring-srv6-network-programming
> >
<[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>;
> > Peter Psenak (ppsenak) <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *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 protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>]
*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 protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
*On Behalf Of *Chris Bowers
> > *Sent:* 27 February 2020 22:46
> > *To:* [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>; SPRING WG List
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > *Cc:* Peter Psenak (ppsenak)
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
> > *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 protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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.____
> >
>
