Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Robert Raszuk]

Hello,

I have a question ... likely to the WG chairs.

Why
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-flood-reflection-07
does not have a YANG section ? Is there a separate document for it just
like we see a separate document for BGP-LS encoding ?

Isn't the YANG section a requirement for all protocol extension
documents before they are sent for publications these days ?

The reason I am asking this is in fact in light of the other discussions we
have on IDR list where at least one mode of link state state advertisement
can be done using YANG encoding. Is YANG section optional in LSR WG
documents which define new protocol extensions and new functionality ? If
an implementation uses YANG to push LSDB how the new TLVs defined in the
draft are going to be shared across ?

Many thx,
Robert


On Wed, Jun 29, 2022 at 10:56 PM Susan Hares  wrote:

> Greetings:
>
>
>
> I want to thank all the people who contributed to this WG adoption call.
>
>
>
> There are four points I pull from the adoption call:
>
>
>
> 1. IDR participants desire to discuss other potential ways to pass data
> currently past in IDR
>
>
>
> I will start a thread noted as “BGP-LS” alternative.   This thread has 2
> subjects:
>
> 1) clear problem statements on BGP-LS
>
> 2) Discussion of alternatives (e.g. Droid (draft-li-lsr-droid-00.txt)
>
>
>
> If there is enough on list discussion, IDR may hold an interim on the
> topic.
>
>
>
> 2.  Operators wish to deploy this draft
>
>
>
> I have confirmation on requests for deploying this draft.
>
> Like some other BGP features, it may not be widely deployed.
>
>
>
> 3. The WG wishes to add these features to this experimental draft.
>
>
>
> draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt
>
>
>
> Based on the call, this draft should include the changes promised on the
> call.
>
> The authors should resubmit the draft with this name.
>
>
>
> 4. The IDR + LSR chairs should review the agreements relating to
>
> BGP-LS TLVs at IETF-114 in their WG.
>
>
>
> The IDR chairs will request a time at IDR + LSR for this topic.
>
> Let  me know if a short video be better than slides.
>
> If so, we’ll post the video on YouTube before IETF and
>
> Take questions at LSR or IDR.
>
>
>
> Cheers, Sue Hares
>
>
>
> *From:* Lsr  *On Behalf Of * Susan Hares
> *Sent:* Friday, June 24, 2022 9:29 AM
> *To:* Tony Przygienda ; Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Cc:* Jordan Head ; i...@ietf.org; lsr 
> *Subject:* Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
> call (6/6 to 6/20)
>
>
>
>
>
> Tony P, Ketan and IDR WG:
>
>
>
> Thank you for input on this draft.
>
> I am closing the WG adoption call for this draft.
>
> The IDR Chairs will discuss the results of this consensus call, and
>
> Announce the results by July 8th.
>
>
>
> Cheers,
>
>
>
> Sue Hares
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Wednesday, June 22, 2022 12:11 PM
> *To:* Ketan Talaulikar 
> *Cc:* Jordan Head ; Susan Hares ;
> i...@ietf.org; lsr 
> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
> (6/6 to 6/20)
>
>
>
>
>
> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
> we try to put into BGP-LS here only the stuff that is strictly needed for
> topology discovery and understanding for advanced computation and nothing
> else. And hence, since the 1:1 TLV correspondence is nowhere to be seen by
> now if you look at ospf/isis encoding and what BGP-LS formats are today
> your requirements are interesting but I'm not sure where they came from.
>
>
>
> The flag indicates already whether something is client or reflector on an
> adjacency. cluster ID is there as well to differentiate between different
> clusters. L2 C/FR adjacencies will show up as well. good enough to
> understand topology and compute AFAIS.  All this is achievable by putting
> this element on the link TLV (the draft should explain it better, it just
> grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
> annotate just the node assuming strict adherence to the IGP draft today but
> putting the element on the link descriptor follows the IGP spec itself and
> will allow to break the RFC if necessary later also in BGP-LS (by e.g.
> allowing a node to be client of two different clusters or even a node being
> reflector for 2 different clusters. Observe that this will not work in case
> of auto-discoery since that's on node caps ;-) But those are sutble
> discussions that need to be documented into the BGP-LS draft as procedures
> once adopted. Those discuss

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Susan Hares]

Greetings:

I want to thank all the people who contributed to this WG adoption call.

There are four points I pull from the adoption call:

1. IDR participants desire to discuss other potential ways to pass data 
currently past in IDR

I will start a thread noted as “BGP-LS” alternative.   This thread has 2 
subjects:
1) clear problem statements on BGP-LS
2) Discussion of alternatives (e.g. Droid (draft-li-lsr-droid-00.txt)

If there is enough on list discussion, IDR may hold an interim on the topic.

2.  Operators wish to deploy this draft

I have confirmation on requests for deploying this draft.
Like some other BGP features, it may not be widely deployed.

3. The WG wishes to add these features to this experimental draft.

draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt

Based on the call, this draft should include the changes promised on the call.
The authors should resubmit the draft with this name.

4. The IDR + LSR chairs should review the agreements relating to
BGP-LS TLVs at IETF-114 in their WG.

The IDR chairs will request a time at IDR + LSR for this topic.
Let  me know if a short video be better than slides.
If so, we’ll post the video on YouTube before IETF and
Take questions at LSR or IDR.

Cheers, Sue Hares

From: Lsr  On Behalf Of Susan Hares
Sent: Friday, June 24, 2022 9:29 AM
To: Tony Przygienda ; Ketan Talaulikar 

Cc: Jordan Head ; i...@ietf.org; lsr 
Subject: Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call 
(6/6 to 6/20)

Tony P, Ketan and IDR WG: Thank you for input on this draft. I am closing the 
WG adoption call for this draft. The IDR Chairs will discuss the results of 
this consensus call, and Announce the results
Danger: External (sha...@ndzh.com<mailto:sha...@ndzh.com>)
Spoofed Internal Sender   
Details<https://protection.inkyphishfence.com/details?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2E5NTg4ZTlkNDg2YjRmMWM5OTE1NmY1MWFhMmQwZTZhLzE2NTYwNzc0MjQuODQ=#key=fd2a161745cea225d9689d66ded1958b>
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2E5NTg4ZTlkNDg2YjRmMWM5OTE1NmY1MWFhMmQwZTZhLzE2NTYwNzc0MjQuODQ=#key=fd2a161745cea225d9689d66ded1958b>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Tony P, Ketan and IDR WG:

Thank you for input on this draft.
I am closing the WG adoption call for this draft.
The IDR Chairs will discuss the results of this consensus call, and
Announce the results by July 8th.

Cheers,

Sue Hares

From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Wednesday, June 22, 2022 12:11 PM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Cc: Jordan Head mailto:jh...@juniper.net>>; Susan Hares 
mailto:sha...@ndzh.com>>; i...@ietf.org<mailto:i...@ietf.org>; 
lsr mailto:lsr@ietf.org>>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 
6/20)


hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced computation and nothing else. And 
hence, since the 1:1 TLV correspondence is nowhere to be seen by now if you 
look at ospf/isis encoding and what BGP-LS formats are today  your requirements 
are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an 
adjacency. cluster ID is there as well to differentiate between different 
clusters. L2 C/FR adjacencies will show up as well. good enough to understand 
topology and compute AFAIS.  All this is achievable by putting this element on 
the link TLV (the draft should explain it better, it just grabs codepoints in 
node/link/prefix & e'thing else ;-). Yes, we could annotate just the node 
assuming strict adherence to the IGP draft today but putting the element on the 
link descriptor follows the IGP spec itself and will allow to break the RFC if 
necessary later also in BGP-LS (by e.g. allowing a node to be client of two 
different clusters or even a node being reflector for 2 different clusters. 
Observe that this will not work in case of auto-discoery since that's on node 
caps ;-) But those are sutble discussions that need to be documented into the 
BGP-LS draft as procedures once adopted. Those discussions are natural and 
necessary since BGP-LS is NOT IGP  database but a distorted, simplified view 
for topology discovery. Or at least that's how it's used in reality based on 
the shortcomings of its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't belong 
into BGP-LS FR information, otherwise will show up in BGP-LS naturally. Neither 
does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send IIHs 
in BGP-LS either to discover MTU mismatch so I don't see that's wh

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

ok, we in sync then ...

thanks

-- tony

On Sat, Jun 25, 2022 at 8:07 AM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> Just allowing sub-TLVs for the BGP-LS ISIS Flood Reflection TLV will
> address my concerns for this draft. For the rest, new TLVs/sub-TLVs can be
> introduced on a need basis down the line.
>
> Thanks,
> Ketan
>
>
> On Fri, Jun 24, 2022 at 11:43 PM Tony Przygienda 
> wrote:
>
>>
>>
>> On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> Please check inline below.
>>>
>>> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda 
>>> wrote:
>>>
 hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1
 translation we try to put into BGP-LS here only the stuff that is strictly
 needed for topology discovery and understanding for advanced computation
 and nothing else.

>>>
>>> KT> I don't agree with the "nothing else".  At least I can't claim to
>>> have the full knowledge of all the solutions being designed and deployed
>>> using BGP-LS.
>>>
>>
>> I can't answer to that except BGP-LS doesn't have enough information as
>> it stands to do a lot of stuff that you can do using full IGP database. And
>> I try to define a minimum set of what is useful already. We can always add
>> more stuff later but maybe we cannot given what we defined and I miss your
>> point (which seems to be the case reading rest of your email).
>>
>>
>>>
>>>
 And hence, since the 1:1 TLV correspondence is nowhere to be seen by
 now if you look at ospf/isis encoding and what BGP-LS formats are today
 your requirements are interesting but I'm not sure where they came from.

>>>
>>> KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
>>> follows closely the semantics and encoding (with due consideration for
>>> normalization across the IGPs). So I don't support the design of BGP-LS
>>> encodings that are different from the underlying IGPs without strong
>>> justification.
>>>
>>
>> well, no, it doesn't. if you look e.g. at MT encoding it's upside down
>> compared to ISIS encoding. it's encoded within link descriptor while in
>> ISIS it's its own TLV with MT being on top. BGP-LS encoding is nothing like
>> the original ISIS encoding in most parts e.g. by already cumulating lots
>> stuff into same descriptior which in ISIS can be spread across multiple
>> TLVs and fragments.
>>
>> Unless you point me to a normative reference where it says that BGP-LS is
>> following IGP encoding closely I take it just as an assertion you make and
>> we disagree, Ketan.
>>
>>
>>>
>>>


 The flag indicates already whether something is client or reflector on
 an adjacency. cluster ID is there as well to differentiate between
 different clusters. L2 C/FR adjacencies will show up as well. good enough
 to understand topology and compute AFAIS.  All this is achievable by
 putting this element on the link TLV (the draft should explain it better,
 it just grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we
 could annotate just the node assuming strict adherence to the IGP draft
 today but putting the element on the link descriptor follows the IGP spec
 itself and will allow to break the RFC if necessary later also in BGP-LS
 (by e.g. allowing a node to be client of two different clusters or even a
 node being reflector for 2 different clusters. Observe that this will not
 work in case of auto-discoery since that's on node caps ;-) But those are
 sutble discussions that need to be documented into the BGP-LS draft as
 procedures once adopted.

>>>
>>> KT> So you see the scope for adding some more of the sub-TLVs from the
>>> ISIS flood-reflection draft into this BGP-LS document? If so, great - we
>>> can always extend on a need basis.
>>>
>>
>> agreed
>>
>>
>>>
>>>
 Those discussions are natural and necessary since BGP-LS is NOT IGP
 database but a distorted, simplified view for topology discovery. Or at
 least that's how it's used in reality based on the shortcomings of its
 design ;-)

 As I explained, unless L1 adjacencies are being formed IMO they don't
 belong into BGP-LS FR information, otherwise will show up in BGP-LS
 naturally. Neither does IMO auto-discovery of FR.

 As to mismatch of e.g. cluster ID/role. good observation but we don't
 send IIHs in BGP-LS either to discover MTU mismatch so I don't see that's
 what BGP-LS is here for

>>>
>>> KT> The main sticking point for me here is that you have not allowed for
>>> the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the
>>> case with its underlying ISIS Flood Reflection TLV. It is a very minor
>>> thing that can be easily fixed and I am unable to understand why this
>>> cannot or should not be done. Anyway, I rest my case :-)
>>>
>>
>> ah. ok. if that's your only thing, sure. we can allow for sub-TLVs.
>> suggest encoding change or Jordan can make it so sub-TLVs can be 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Ketan Talaulikar]

Hi Tony,

Just allowing sub-TLVs for the BGP-LS ISIS Flood Reflection TLV will
address my concerns for this draft. For the rest, new TLVs/sub-TLVs can be
introduced on a need basis down the line.

Thanks,
Ketan


On Fri, Jun 24, 2022 at 11:43 PM Tony Przygienda 
wrote:

>
>
> On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar 
> wrote:
>
>> Hi Tony,
>>
>> Please check inline below.
>>
>> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda 
>> wrote:
>>
>>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1
>>> translation we try to put into BGP-LS here only the stuff that is strictly
>>> needed for topology discovery and understanding for advanced computation
>>> and nothing else.
>>>
>>
>> KT> I don't agree with the "nothing else".  At least I can't claim to
>> have the full knowledge of all the solutions being designed and deployed
>> using BGP-LS.
>>
>
> I can't answer to that except BGP-LS doesn't have enough information as it
> stands to do a lot of stuff that you can do using full IGP database. And I
> try to define a minimum set of what is useful already. We can always add
> more stuff later but maybe we cannot given what we defined and I miss your
> point (which seems to be the case reading rest of your email).
>
>
>>
>>
>>> And hence, since the 1:1 TLV correspondence is nowhere to be seen by now
>>> if you look at ospf/isis encoding and what BGP-LS formats are today  your
>>> requirements are interesting but I'm not sure where they came from.
>>>
>>
>> KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
>> follows closely the semantics and encoding (with due consideration for
>> normalization across the IGPs). So I don't support the design of BGP-LS
>> encodings that are different from the underlying IGPs without strong
>> justification.
>>
>
> well, no, it doesn't. if you look e.g. at MT encoding it's upside down
> compared to ISIS encoding. it's encoded within link descriptor while in
> ISIS it's its own TLV with MT being on top. BGP-LS encoding is nothing like
> the original ISIS encoding in most parts e.g. by already cumulating lots
> stuff into same descriptior which in ISIS can be spread across multiple
> TLVs and fragments.
>
> Unless you point me to a normative reference where it says that BGP-LS is
> following IGP encoding closely I take it just as an assertion you make and
> we disagree, Ketan.
>
>
>>
>>
>>>
>>>
>>> The flag indicates already whether something is client or reflector on
>>> an adjacency. cluster ID is there as well to differentiate between
>>> different clusters. L2 C/FR adjacencies will show up as well. good enough
>>> to understand topology and compute AFAIS.  All this is achievable by
>>> putting this element on the link TLV (the draft should explain it better,
>>> it just grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we
>>> could annotate just the node assuming strict adherence to the IGP draft
>>> today but putting the element on the link descriptor follows the IGP spec
>>> itself and will allow to break the RFC if necessary later also in BGP-LS
>>> (by e.g. allowing a node to be client of two different clusters or even a
>>> node being reflector for 2 different clusters. Observe that this will not
>>> work in case of auto-discoery since that's on node caps ;-) But those are
>>> sutble discussions that need to be documented into the BGP-LS draft as
>>> procedures once adopted.
>>>
>>
>> KT> So you see the scope for adding some more of the sub-TLVs from the
>> ISIS flood-reflection draft into this BGP-LS document? If so, great - we
>> can always extend on a need basis.
>>
>
> agreed
>
>
>>
>>
>>> Those discussions are natural and necessary since BGP-LS is NOT IGP
>>> database but a distorted, simplified view for topology discovery. Or at
>>> least that's how it's used in reality based on the shortcomings of its
>>> design ;-)
>>>
>>> As I explained, unless L1 adjacencies are being formed IMO they don't
>>> belong into BGP-LS FR information, otherwise will show up in BGP-LS
>>> naturally. Neither does IMO auto-discovery of FR.
>>>
>>> As to mismatch of e.g. cluster ID/role. good observation but we don't
>>> send IIHs in BGP-LS either to discover MTU mismatch so I don't see that's
>>> what BGP-LS is here for
>>>
>>
>> KT> The main sticking point for me here is that you have not allowed for
>> the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the
>> case with its underlying ISIS Flood Reflection TLV. It is a very minor
>> thing that can be easily fixed and I am unable to understand why this
>> cannot or should not be done. Anyway, I rest my case :-)
>>
>
> ah. ok. if that's your only thing, sure. we can allow for sub-TLVs.
> suggest encoding change or Jordan can make it so sub-TLVs can be plugged in
> later
>
> thanks for the comments and careful read
>
> -- tony
>
>
>>
>> Thanks,
>> Ketan
>>
>>
>>>
>>> -- tony
>>>
>>> On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
>>> wrote:
>>>
 Hi Tony,

 I may 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> Please check inline below.
>
> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda 
> wrote:
>
>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
>> we try to put into BGP-LS here only the stuff that is strictly needed for
>> topology discovery and understanding for advanced computation and nothing
>> else.
>>
>
> KT> I don't agree with the "nothing else".  At least I can't claim to have
> the full knowledge of all the solutions being designed and deployed using
> BGP-LS.
>

I can't answer to that except BGP-LS doesn't have enough information as it
stands to do a lot of stuff that you can do using full IGP database. And I
try to define a minimum set of what is useful already. We can always add
more stuff later but maybe we cannot given what we defined and I miss your
point (which seems to be the case reading rest of your email).


>
>
>> And hence, since the 1:1 TLV correspondence is nowhere to be seen by now
>> if you look at ospf/isis encoding and what BGP-LS formats are today  your
>> requirements are interesting but I'm not sure where they came from.
>>
>
> KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
> follows closely the semantics and encoding (with due consideration for
> normalization across the IGPs). So I don't support the design of BGP-LS
> encodings that are different from the underlying IGPs without strong
> justification.
>

well, no, it doesn't. if you look e.g. at MT encoding it's upside down
compared to ISIS encoding. it's encoded within link descriptor while in
ISIS it's its own TLV with MT being on top. BGP-LS encoding is nothing like
the original ISIS encoding in most parts e.g. by already cumulating lots
stuff into same descriptior which in ISIS can be spread across multiple
TLVs and fragments.

Unless you point me to a normative reference where it says that BGP-LS is
following IGP encoding closely I take it just as an assertion you make and
we disagree, Ketan.


>
>
>>
>>
>> The flag indicates already whether something is client or reflector on an
>> adjacency. cluster ID is there as well to differentiate between different
>> clusters. L2 C/FR adjacencies will show up as well. good enough to
>> understand topology and compute AFAIS.  All this is achievable by putting
>> this element on the link TLV (the draft should explain it better, it just
>> grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
>> annotate just the node assuming strict adherence to the IGP draft today but
>> putting the element on the link descriptor follows the IGP spec itself and
>> will allow to break the RFC if necessary later also in BGP-LS (by e.g.
>> allowing a node to be client of two different clusters or even a node being
>> reflector for 2 different clusters. Observe that this will not work in case
>> of auto-discoery since that's on node caps ;-) But those are sutble
>> discussions that need to be documented into the BGP-LS draft as procedures
>> once adopted.
>>
>
> KT> So you see the scope for adding some more of the sub-TLVs from the
> ISIS flood-reflection draft into this BGP-LS document? If so, great - we
> can always extend on a need basis.
>

agreed


>
>
>> Those discussions are natural and necessary since BGP-LS is NOT IGP
>> database but a distorted, simplified view for topology discovery. Or at
>> least that's how it's used in reality based on the shortcomings of its
>> design ;-)
>>
>> As I explained, unless L1 adjacencies are being formed IMO they don't
>> belong into BGP-LS FR information, otherwise will show up in BGP-LS
>> naturally. Neither does IMO auto-discovery of FR.
>>
>> As to mismatch of e.g. cluster ID/role. good observation but we don't
>> send IIHs in BGP-LS either to discover MTU mismatch so I don't see that's
>> what BGP-LS is here for
>>
>
> KT> The main sticking point for me here is that you have not allowed for
> the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the
> case with its underlying ISIS Flood Reflection TLV. It is a very minor
> thing that can be easily fixed and I am unable to understand why this
> cannot or should not be done. Anyway, I rest my case :-)
>

ah. ok. if that's your only thing, sure. we can allow for sub-TLVs. suggest
encoding change or Jordan can make it so sub-TLVs can be plugged in later

thanks for the comments and careful read

-- tony


>
> Thanks,
> Ketan
>
>
>>
>> -- tony
>>
>> On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> I may not be the best judge, for this feature, of which of the ISIS
>>> sub-TLV need to get into BGP-LS and which do not. In my limited
>>> understanding of the feature and its deployment, the other 3 sub-TLVs would
>>> be equally useful to get into BGP-LS. Isn't the Flood Reflection
>>> Adjacency Sub-TLV the one that distinguishes a "normal" ISIS adjacency
>>> from a reflector adjacency formed over the tunnel? Isn't it useful 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Ketan Talaulikar]

Hi Tony,

Please check inline below.

On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda  wrote:

> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
> we try to put into BGP-LS here only the stuff that is strictly needed for
> topology discovery and understanding for advanced computation and nothing
> else.
>

KT> I don't agree with the "nothing else".  At least I can't claim to have
the full knowledge of all the solutions being designed and deployed using
BGP-LS.


> And hence, since the 1:1 TLV correspondence is nowhere to be seen by now
> if you look at ospf/isis encoding and what BGP-LS formats are today  your
> requirements are interesting but I'm not sure where they came from.
>

KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
follows closely the semantics and encoding (with due consideration for
normalization across the IGPs). So I don't support the design of BGP-LS
encodings that are different from the underlying IGPs without strong
justification.


>
>
> The flag indicates already whether something is client or reflector on an
> adjacency. cluster ID is there as well to differentiate between different
> clusters. L2 C/FR adjacencies will show up as well. good enough to
> understand topology and compute AFAIS.  All this is achievable by putting
> this element on the link TLV (the draft should explain it better, it just
> grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
> annotate just the node assuming strict adherence to the IGP draft today but
> putting the element on the link descriptor follows the IGP spec itself and
> will allow to break the RFC if necessary later also in BGP-LS (by e.g.
> allowing a node to be client of two different clusters or even a node being
> reflector for 2 different clusters. Observe that this will not work in case
> of auto-discoery since that's on node caps ;-) But those are sutble
> discussions that need to be documented into the BGP-LS draft as procedures
> once adopted.
>

KT> So you see the scope for adding some more of the sub-TLVs from the ISIS
flood-reflection draft into this BGP-LS document? If so, great - we can
always extend on a need basis.


> Those discussions are natural and necessary since BGP-LS is NOT IGP
> database but a distorted, simplified view for topology discovery. Or at
> least that's how it's used in reality based on the shortcomings of its
> design ;-)
>
> As I explained, unless L1 adjacencies are being formed IMO they don't
> belong into BGP-LS FR information, otherwise will show up in BGP-LS
> naturally. Neither does IMO auto-discovery of FR.
>
> As to mismatch of e.g. cluster ID/role. good observation but we don't send
> IIHs in BGP-LS either to discover MTU mismatch so I don't see that's what
> BGP-LS is here for
>

KT> The main sticking point for me here is that you have not allowed for
the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the case
with its underlying ISIS Flood Reflection TLV. It is a very minor thing
that can be easily fixed and I am unable to understand why this cannot or
should not be done. Anyway, I rest my case :-)

Thanks,
Ketan


>
> -- tony
>
> On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
> wrote:
>
>> Hi Tony,
>>
>> I may not be the best judge, for this feature, of which of the ISIS
>> sub-TLV need to get into BGP-LS and which do not. In my limited
>> understanding of the feature and its deployment, the other 3 sub-TLVs would
>> be equally useful to get into BGP-LS. Isn't the Flood Reflection
>> Adjacency Sub-TLV the one that distinguishes a "normal" ISIS adjacency
>> from a reflector adjacency formed over the tunnel? Isn't it useful to know
>> what sort of tunnel encapsulation is being signaled so a discrepancy
>> between the two ends can be detected?
>>
>> I am copying LSR WG which probably is the better group than IDR to review
>> and comment on this.
>>
>> In any case, I am ok to go ahead and skip the inclusion of certain ISIS
>> sub-TLVs in BGP-LS - they can be always added later on.
>>
>> But I am not ok that while the ISIS Flood Reflection TLV has support for
>> sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
>> for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
>> in my opinion.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda 
>> wrote:
>>
>>> Ketan, AFAIS tunnel status is not part of IGP state and should be
>>> derived from alternate mechanisms just like interface up/down state on the
>>> node. We don't carry interface up/down in BGP-LS today and should not
>>> (observe that I really mean admin/phy up/down and not IGP adj up/down
>>> here).  And then, those L1 tunnels either form IGP adjacencies on them in
>>> which case you'll get them in BGP-LS as neighbors or they use something
>>> alternate like e.g. BFD (or nothing at all possibly) and at this point it
>>> will become really weird to carry in BGP-LS an L1 tunnel which does not

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Susan Hares]

Tony P, Ketan and IDR WG:

Thank you for input on this draft.
I am closing the WG adoption call for this draft.
The IDR Chairs will discuss the results of this consensus call, and
Announce the results by July 8th.

Cheers,

Sue Hares

From: Tony Przygienda 
Sent: Wednesday, June 22, 2022 12:11 PM
To: Ketan Talaulikar 
Cc: Jordan Head ; Susan Hares ; 
i...@ietf.org; lsr 
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 
6/20)

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced co
External (tonysi...@gmail.com)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced computation and nothing else. And 
hence, since the 1:1 TLV correspondence is nowhere to be seen by now if you 
look at ospf/isis encoding and what BGP-LS formats are today  your requirements 
are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an 
adjacency. cluster ID is there as well to differentiate between different 
clusters. L2 C/FR adjacencies will show up as well. good enough to understand 
topology and compute AFAIS.  All this is achievable by putting this element on 
the link TLV (the draft should explain it better, it just grabs codepoints in 
node/link/prefix & e'thing else ;-). Yes, we could annotate just the node 
assuming strict adherence to the IGP draft today but putting the element on the 
link descriptor follows the IGP spec itself and will allow to break the RFC if 
necessary later also in BGP-LS (by e.g. allowing a node to be client of two 
different clusters or even a node being reflector for 2 different clusters. 
Observe that this will not work in case of auto-discoery since that's on node 
caps ;-) But those are sutble discussions that need to be documented into the 
BGP-LS draft as procedures once adopted. Those discussions are natural and 
necessary since BGP-LS is NOT IGP  database but a distorted, simplified view 
for topology discovery. Or at least that's how it's used in reality based on 
the shortcomings of its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't belong 
into BGP-LS FR information, otherwise will show up in BGP-LS naturally. Neither 
does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send IIHs 
in BGP-LS either to discover MTU mismatch so I don't see that's what BGP-LS is 
here for

-- tony

On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
Hi Tony,

I may not be the best judge, for this feature, of which of the ISIS sub-TLV 
need to get into BGP-LS and which do not. In my limited understanding of the 
feature and its deployment, the other 3 sub-TLVs would be equally useful to get 
into BGP-LS. Isn't the Flood Reflection Adjacency Sub-TLV the one that 
distinguishes a "normal" ISIS adjacency from a reflector adjacency formed over 
the tunnel? Isn't it useful to know what sort of tunnel encapsulation is being 
signaled so a discrepancy between the two ends can be detected?

I am copying LSR WG which probably is the better group than IDR to review and 
comment on this.

In any case, I am ok to go ahead and skip the inclusion of certain ISIS 
sub-TLVs in BGP-LS - they can be always added later on.

But I am not ok that while the ISIS Flood Reflection TLV has support for 
sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow for 
sub-TLVs. The encoding needs to be consistent. That is a show-stopper in my 
opinion.

Thanks,
Ketan


On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:
Ketan, AFAIS tunnel status is not part of IGP state and should be derived from 
alternate mechanisms just like interface up/down state on the node. We don't 
carry interface up/down in BGP-LS today and should not (observe that I really 
mean admin/phy up/down and not IGP adj up/down here).  And then, those L1 
tunnels either form IGP adjacencies on them in which case you'll get them in 
BGP-LS as neighbors or they use something alternate like e.g. BFD (or nothing 
at all possibly) and at this point it will become really weird to carry in 
BGP-LS an L1 tunnel which does not have IGP adjacency on it ...

open to suggestions but AFAIS the FR/client L2 adjacencies are in BGP-LS 
already per normal 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Tony Przygienda]

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
we try to put into BGP-LS here only the stuff that is strictly needed for
topology discovery and understanding for advanced computation and nothing
else. And hence, since the 1:1 TLV correspondence is nowhere to be seen by
now if you look at ospf/isis encoding and what BGP-LS formats are today
your requirements are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an
adjacency. cluster ID is there as well to differentiate between different
clusters. L2 C/FR adjacencies will show up as well. good enough to
understand topology and compute AFAIS.  All this is achievable by putting
this element on the link TLV (the draft should explain it better, it just
grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
annotate just the node assuming strict adherence to the IGP draft today but
putting the element on the link descriptor follows the IGP spec itself and
will allow to break the RFC if necessary later also in BGP-LS (by e.g.
allowing a node to be client of two different clusters or even a node being
reflector for 2 different clusters. Observe that this will not work in case
of auto-discoery since that's on node caps ;-) But those are sutble
discussions that need to be documented into the BGP-LS draft as procedures
once adopted. Those discussions are natural and necessary since BGP-LS is
NOT IGP  database but a distorted, simplified view for topology discovery.
Or at least that's how it's used in reality based on the shortcomings of
its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't
belong into BGP-LS FR information, otherwise will show up in BGP-LS
naturally. Neither does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send
IIHs in BGP-LS either to discover MTU mismatch so I don't see that's what
BGP-LS is here for

-- tony

On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> I may not be the best judge, for this feature, of which of the ISIS
> sub-TLV need to get into BGP-LS and which do not. In my limited
> understanding of the feature and its deployment, the other 3 sub-TLVs would
> be equally useful to get into BGP-LS. Isn't the Flood Reflection
> Adjacency Sub-TLV the one that distinguishes a "normal" ISIS adjacency
> from a reflector adjacency formed over the tunnel? Isn't it useful to know
> what sort of tunnel encapsulation is being signaled so a discrepancy
> between the two ends can be detected?
>
> I am copying LSR WG which probably is the better group than IDR to review
> and comment on this.
>
> In any case, I am ok to go ahead and skip the inclusion of certain ISIS
> sub-TLVs in BGP-LS - they can be always added later on.
>
> But I am not ok that while the ISIS Flood Reflection TLV has support for
> sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
> for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
> in my opinion.
>
> Thanks,
> Ketan
>
>
> On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda 
> wrote:
>
>> Ketan, AFAIS tunnel status is not part of IGP state and should be derived
>> from alternate mechanisms just like interface up/down state on the node. We
>> don't carry interface up/down in BGP-LS today and should not (observe that
>> I really mean admin/phy up/down and not IGP adj up/down here).  And then,
>> those L1 tunnels either form IGP adjacencies on them in which case you'll
>> get them in BGP-LS as neighbors or they use something alternate like e.g.
>> BFD (or nothing at all possibly) and at this point it will become really
>> weird to carry in BGP-LS an L1 tunnel which does not have IGP adjacency on
>> it ...
>>
>> open to suggestions but AFAIS the FR/client L2 adjacencies are in BGP-LS
>> already per normal procedures (and the fact that you see client/reflector
>> flag on both nodes & cluster ID allows you to derive the property of the
>> adjacency) but the L1 mesh (if used) has no business in BGP-LS unless it
>> forms IGP L1 adjacencies.
>>
>> -- tony
>>
>> On Wed, Jun 22, 2022 at 3:26 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Jordan,
>>>
>>> Thanks for your response and please check inline below for what needs
>>> further discussion.
>>>
>>>
>>> On Tue, Jun 21, 2022 at 11:10 PM Jordan Head  wrote:
>>>
 Hi Ketan,



 Thanks for reading the draft and taking the time to comment.



 [Ketan]

 *1) The status of this should also be experimental so it is aligned
 with the IGP spec.*



 [Jordan]

 As Sue said, good catch, I’ll update this draft to align with the other
 draft.



 [Ketan]

 *2) Though not strictly required, I would suggest adding some text that
 covers the description/motivation for adding this into BGP-LS - perhaps a
 use case or scenario. 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Ketan Talaulikar]

Hi Tony,

I may not be the best judge, for this feature, of which of the ISIS sub-TLV
need to get into BGP-LS and which do not. In my limited understanding of
the feature and its deployment, the other 3 sub-TLVs would be
equally useful to get into BGP-LS. Isn't the Flood Reflection Adjacency
Sub-TLV the one that distinguishes a "normal" ISIS adjacency from a
reflector adjacency formed over the tunnel? Isn't it useful to know what
sort of tunnel encapsulation is being signaled so a discrepancy between the
two ends can be detected?

I am copying LSR WG which probably is the better group than IDR to review
and comment on this.

In any case, I am ok to go ahead and skip the inclusion of certain ISIS
sub-TLVs in BGP-LS - they can be always added later on.

But I am not ok that while the ISIS Flood Reflection TLV has support for
sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
in my opinion.

Thanks,
Ketan


On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda  wrote:

> Ketan, AFAIS tunnel status is not part of IGP state and should be derived
> from alternate mechanisms just like interface up/down state on the node. We
> don't carry interface up/down in BGP-LS today and should not (observe that
> I really mean admin/phy up/down and not IGP adj up/down here).  And then,
> those L1 tunnels either form IGP adjacencies on them in which case you'll
> get them in BGP-LS as neighbors or they use something alternate like e.g.
> BFD (or nothing at all possibly) and at this point it will become really
> weird to carry in BGP-LS an L1 tunnel which does not have IGP adjacency on
> it ...
>
> open to suggestions but AFAIS the FR/client L2 adjacencies are in BGP-LS
> already per normal procedures (and the fact that you see client/reflector
> flag on both nodes & cluster ID allows you to derive the property of the
> adjacency) but the L1 mesh (if used) has no business in BGP-LS unless it
> forms IGP L1 adjacencies.
>
> -- tony
>
> On Wed, Jun 22, 2022 at 3:26 PM Ketan Talaulikar 
> wrote:
>
>> Hi Jordan,
>>
>> Thanks for your response and please check inline below for what needs
>> further discussion.
>>
>>
>> On Tue, Jun 21, 2022 at 11:10 PM Jordan Head  wrote:
>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> Thanks for reading the draft and taking the time to comment.
>>>
>>>
>>>
>>> [Ketan]
>>>
>>> *1) The status of this should also be experimental so it is aligned with
>>> the IGP spec.*
>>>
>>>
>>>
>>> [Jordan]
>>>
>>> As Sue said, good catch, I’ll update this draft to align with the other
>>> draft.
>>>
>>>
>>>
>>> [Ketan]
>>>
>>> *2) Though not strictly required, I would suggest adding some text that
>>> covers the description/motivation for adding this into BGP-LS - perhaps a
>>> use case or scenario. Normally, the TE use cases are obvious but I am
>>> unable to understand the motivation in this case. As an example, we don't
>>> have an equivalent of OSPFv2 Type 4 LSA information being signaled into
>>> BGP-LS - just because there was no pressing need for it. There are a few
>>> other such IGP extensions not exposed to BGP-LS ... but I don't want to
>>> give more ideas ;-)*
>>>
>>>
>>>
>>> [Jordan]
>>>
>>> I see your point, my answers to #5 and #6 should hopefully make things
>>> more obvious.
>>>
>>>
>>>
>>> [Ketan]
>>>
>>> *3) Reference to RFC8714 is required in addition to RFC2119.*
>>>
>>>
>>>
>>> [Jordan]
>>>
>>> I assume you mean RFC8174. Good catch, I’ll add it.
>>>
>>>
>>>
>>> [Ketan]
>>>
>>> *4) It would be more appropriate to name this TLV as IS-IS Flood
>>> Reflection TLV, unless there was some plan to introduce similar for OSPF.*
>>>
>>>
>>>
>>> [Jordan]
>>>
>>> Sure, I’ll update it accordingly.
>>>
>>>
>>>
>>> [Ketan]
>>>
>>> *5) The IS-IS TLV has sub-TLVs but that has not been defined for BGP-LS.
>>> Why?*
>>>
>>>
>>>
>>> *6) Why just this one TLV and not the others from the IS-IS spec?
>>> Perhaps the use case (my comment (2)) below can help justify why only this
>>> one is required and not the others? Another reason why, IMHO, it is better
>>> to keep this extension in the fridge until someone really needs it as an
>>> ingredient to cook a deployment solution. *
>>>
>>>
>>>
>>> [Jordan]
>>>
>>> #5 and #6 seem quite similar, so I’ll combine my answers.
>>>
>>>
>>>
>>> The other TLVs are for auto-discovery signal that a node is *capable *of
>>> FR and to signal a potential *desire* to automatically create tunnels
>>> between nodes. An operator may choose to use that functionality or simply
>>> configure things manually. Regardless of which option is used, we need to
>>> be able to describe the *operational* IGP state rather than *desired*
>>> state as the two may not necessarily align.
>>>
>>
>> KT> The operational IGP info is what is advertised in BGP-LS. So you are
>> saying that the Flood Reflection Discovery Sub-TLV is also