Re: Possibility of empty Link Descriptors in BGP-LS?

Hi Nandan,

An updated version has been posted to address your comments as discussed below.


https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-02

Thanks,
Ketan

From: Nandan Saha <[email protected]>
Sent: 09 October 2019 21:21
To: Ketan Talaulikar (ketant) <[email protected]>
Cc: [email protected]; [email protected]; Prakash Badrinarayanan <[email protected]>
Subject: Re: Possibility of empty Link Descriptors in BGP-LS?

Hi Ketan,

On Wed, Oct 9, 2019 at 7:52 PM Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> wrote:
Hi Nandan,

How about adding the following text in Sec 4.2.2?

The TLVs/sub-TLVs corresponding to the interface addresses and/or the local/remote identfiers may not always be signaled in the IGPs unless their advertisement is enabled specifically. In such cases, a BGP-LS Producer may not be able to generate valid Link NLRIs for such link advertisements from the IGPs.
Sounds good!

Thanks,
Ketan

From: Nandan Saha <[email protected]<mailto:[email protected]>>
Sent: 16 September 2019 10:11
To: Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Prakash Badrinarayanan <[email protected]<mailto:[email protected]>>
Subject: Re: Possibility of empty Link Descriptors in BGP-LS?

Hi Ketan,
    Thank you for your patience. I thought I had replied to this, but somehow hadn't.
On Tue, Aug 20, 2019 at 11:31 PM Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> wrote:
Hi Nandan,

You are correct that an ISIS implementation (in non-TE/SR) environment will not advertise the necessary link descriptors without which it will not be possible to describe links completely. It is not just about empty link descriptors, but when there are parallel links, they will end up overwriting each other's attributes in BGP-LS as those NLRIs would get mixed up. IMHO it does not serve much purpose advertising such links via BGP-LS.

What text would you suggest we add in the BGP-LS specification for this?
Something along the lines that a BGP-LS producer may not be able to generate valid link NLRIs in the absence of the required sub-TLVs in the IGP. I'm mostly thinking from the point of view of guiding operators that the IGP needs to be configured appropriately.
I'm not fully in agreement about leaving out such links. In the case there's only one p2p link between devices we'll simply be losing information in BGP-LS, since it's possible to identify such a link uniquely. (Though it's an academic discussion since most deployments are likely to use bgp-ls for TE)
In anycase, I don't feel too strong about adding new text in case you feel it's obvious from the rest of the text.

Thanks,
Ketan

-----Original Message-----
From: Nandan Saha <[email protected]<mailto:[email protected]>>
Sent: 20 August 2019 21:48
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Cc: Prakash Badrinarayanan <[email protected]<mailto:[email protected]>>; Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>>
Subject: Possibility of empty Link Descriptors in BGP-LS?

Hi folks,

I'm wondering whether some text needs to be added to
https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis-01#section-4.2.2
for the case where neither the ipv4/6 address sub tlvs nor link/remote identifiers are present in the IGP's LSP/LSA.
For IS-IS specifically, it seems to me that an IS-IS implementation (in a non-TE) scenario is free to leave out the ipv4/6 interface/neighbor address sub-tlvs based on https://tools.ietf.org/html/rfc5305#section-3.2, and https://tools.ietf.org/html/rfc5305#section-3.3. The link/remote link identifiers also appear optional.

In such a case, the link descriptor in the link nlri will be empty which is problematic in the case where there are multiple links between 2 nodes as there's no way to distinguish between the different links.

Thanks,
Nandan

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr