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 <chrisbowers.i...@gmail.com>
Sent: 12 March 2020 20:29
To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar (ketant) 
<ket...@cisco.com>
Cc: lsr@ietf.org; SPRING WG List <spr...@ietf.org>; Bruno Decraene 
<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

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) 
<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.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to