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)
<ket...@cisco.com <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 <chrisbowers.i...@gmail.com
<mailto:chrisbowers.i...@gmail.com>>
*Sent:* 05 March 2020 21:53
*To:* Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>>
*Cc:* Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>;
SPRING WG List <spr...@ietf.org <mailto:spr...@ietf.org>>;
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org
<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>; Peter
Psenak (ppsenak) <ppse...@cisco.com <mailto:ppse...@cisco.com>>;
Bruno Decraene <bruno.decra...@orange.com
<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)
<ket...@cisco.com <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 <chrisbowers.i...@gmail.com
<mailto:chrisbowers.i...@gmail.com>>
*Sent:* 02 March 2020 23:39
*To:* Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>>
*Cc:* Ketan Talaulikar (ketant)
<ketant=40cisco....@dmarc.ietf.org
<mailto:40cisco.....@dmarc.ietf.org>>; lsr@ietf.org
<mailto:lsr@ietf.org>; SPRING WG List <spr...@ietf.org
<mailto:spr...@ietf.org>>;
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org
<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
Peter Psenak (ppsenak) <ppse...@cisco.com
<mailto:ppse...@cisco.com>>; Bruno Decraene
<bruno.decra...@orange.com <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 <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>> wrote:____
Hi Ketan,____
____
Thanks fort the follow up.____
Clarification inline [Bruno]____
____
*From**:*Ketan Talaulikar (ketant) [mailto:ket...@cisco.com
<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 <mailto: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 <lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>> *On Behalf Of
*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
*Sent:* 28 February 2020 14:34
*To:* Ketan Talaulikar (ketant)
<ketant=40cisco....@dmarc.ietf.org
<mailto:40cisco.....@dmarc.ietf.org>>; Chris Bowers
<chrisbowers.i...@gmail.com <mailto:chrisbowers.i...@gmail.com>>
*Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; SPRING WG List
<spr...@ietf.org <mailto:spr...@ietf.org>>;
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org
<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
Peter Psenak (ppsenak) <ppse...@cisco.com
<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 <lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>> *On Behalf Of *Chris Bowers
*Sent:* 27 February 2020 22:46
*To:* lsr@ietf.org <mailto:lsr@ietf.org>; SPRING WG List
<spr...@ietf.org <mailto:spr...@ietf.org>>
*Cc:* Peter Psenak (ppsenak) <ppse...@cisco.com
<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
<ppse...@cisco.com <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.____
_____________________________________________________________________________________________________________________________
____
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.____
