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

[Tony Przygienda <[e-mail]>]

ok, we in sync then ...

thanks

-- tony

On Sat, Jun 25, 2022 at 8:07 AM Ketan Talaulikar <[e-mail]>
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 <[e-mail]>
> wrote:
>
>>
>>
>> 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:
>>>>>>
>>>>>>