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

[Acee Lindem (acee)]

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"  wrote:

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
de...@arrcus.com
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"  wrote:

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> 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.


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  > 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 

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

[Derek Yeung]

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
de...@arrcus.com
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"  wrote:

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> 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.


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  > 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 

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

[Peter Psenak]

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:

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.



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 > 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 

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

[Chris Bowers]

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  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 

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

[Peter Psenak]

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 

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

[Chris Bowers]

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.  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.

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.

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.

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.

Thanks,
Chris

On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak  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 

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

[Peter Psenak]

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) 
mailto:ket...@cisco.com>> 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 mailto:chrisbowers.i...@gmail.com>>
*Sent:* 05 March 2020 21:53
*To:* Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
*Cc:* Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; lsr@ietf.org ;
SPRING WG List mailto:spr...@ietf.org>>;
draft-ietf-spring-srv6-network-programming
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>; Peter
Psenak (ppsenak) mailto:ppse...@cisco.com>>;
Bruno Decraene mailto:bruno.decra...@orange.com>>
*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)
mailto:ket...@cisco.com>> 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 

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

[Ketan Talaulikar (ketant)]

Hi Chris,

I am repeating the use-case described previously:
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
We do carry information in the IGPs for propagation as part of the topology 
information for enabling use-cases outside the router (e.g. via BGP-LS). We do 
not need to preclude a use-case for it in IGPs themselves in the future.

Thanks,
Ketan

From: Chris Bowers 
Sent: 12 March 2020 20:29
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Cc: lsr@ietf.org; SPRING WG List ; Bruno Decraene 

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

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) 
mailto:ket...@cisco.com>> 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 
mailto:chrisbowers.i...@gmail.com>>
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
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) 
mailto:ket...@cisco.com>> 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 

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

[Chris Bowers]

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) 
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 
> *Sent:* 05 March 2020 21:53
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING
> WG List ; draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak
> (ppsenak) ; Bruno Decraene 
> *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) <
> ket...@cisco.com> 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 
> *Sent:* 02 March 2020 23:39
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* Ketan Talaulikar (ketant)  <40cisco.@dmarc.ietf.org>>; lsr@ietf.org; SPRING WG List <
> spr...@ietf.org>; draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak
> (ppsenak) ; 

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

[Ketan Talaulikar (ketant)]

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 
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING WG List 
; draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
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) 
mailto:ket...@cisco.com>> 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 
mailto:chrisbowers.i...@gmail.com>>
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) 
mailto:40cisco.@dmarc.ietf.org>>; 
lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
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:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 

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

[Chris Bowers]

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) 
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?  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
?


>
>
> 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 ?

Thanks,
>
> Ketan
>
>
>
> *From:* Chris Bowers 
> *Sent:* 02 March 2020 23:39
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* Ketan Talaulikar (ketant) ;
> lsr@ietf.org; SPRING WG List ;
> draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak
> (ppsenak) ; Bruno Decraene 
> *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  wrote:
>
> Hi Ketan,
>
>
>
> Thanks fort the follow up.
>
> Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* lsr@ietf.org; 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 

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

[Ketan Talaulikar (ketant)]

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.

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

Thanks,
Ketan

From: Chris Bowers 
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; 
lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
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:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) 
mailto:40cisco@dmarc.ietf.org>>; Chris 
Bowers mailto:chrisbowers.i...@gmail.com>>
Cc: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
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:lsr-boun...@ietf.org] 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 

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

[Chris Bowers]

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  wrote:

> Hi Ketan,
>
>
>
> Thanks fort the follow up.
>
> Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* lsr@ietf.org; 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  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* 28 February 2020 14:34
> *To:* Ketan Talaulikar (ketant) ;
> Chris Bowers 
> *Cc:* lsr@ietf.org; SPRING WG List ;
> draft-ietf-spring-srv6-network-programming <
> draft-ietf-spring-srv6-network-programm...@ietf.org>; 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 Ketan,
>
>
>
>
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org ] *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  *On Behalf Of *Chris Bowers
> *Sent:* 27 February 2020 22:46
> *To:* lsr@ietf.org; SPRING WG List 
> *Cc:* Peter Psenak (ppsenak) 
> *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  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
> 

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

[bruno.decraene]

Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; 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  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; 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 Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
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 
mailto:ppse...@cisco.com>> 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 

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

[Ketan Talaulikar (ketant)]

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

So perhaps I don’t get Chris’s point and would wait for him to clarify.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; 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 Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
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 
mailto:ppse...@cisco.com>> 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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[bruno.decraene]

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] 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  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
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 
mailto:ppse...@cisco.com>> 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.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

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?

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
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 
mailto:ppse...@cisco.com>> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr