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

[Tony Przygienda <[e-mail]>]

On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Tony,
>
> Please check inline below.
>
> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda <[e-mail]>
> 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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>>