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 <[email protected]> wrote: > > > On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar <[email protected]> > wrote: > >> Hi Tony, >> >> Please check inline below. >> >> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
