Hi, Ketan: There are situation that such information is necessary: When several ASes are connected via the LAN interface, it is impossible to describe the inter-AS relationship with the current descriptors that provided by RFC5316 and RFC5392.
And another scenario is that when these stub links are used to correct servers, there is no remote-AS, remote ASBR ID information. But we can distinguish different stub link via their associated prefixes. Aijun Wang China Telecom > On Jul 28, 2022, at 15:03, Ketan Talaulikar <[email protected]> wrote: > > > Hi Aijun, > > Similar to Les, I disagree with you on the use of Prefix TLV as an attribute > of the "Stub Link". The reason is that this attribute is not required for the > identification of a link in BGP-LS (or in IGPs for that matter) that was the > main use case. I also don't see the use of that in Inter-AS links. Please > justify this. > > Thanks, > Ketan > > >> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang <[email protected]> >> wrote: >> Hi, Les: >> >> Please note the references to RFC5316/RFC5392 in >> draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what >> we are discussing are non-TE scenarios. >> For prefixes sub-TLV, would you like to revisit my responses to Ketan, >> before make any comments? For your convenience, I can elaborate again to >> you——-“The prefix sub-TLV is not the link identifier, it is just one kind of >> link attributes”. Is it clear enough? >> >> Based on these facts, I think it is unnecessary to response your other >> baseless comments. >> >> Aijun Wang >> China Telecom >> >>>> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) >>>> <[email protected]> wrote: >>>> >>> >>> Acee – >>> >>> >>> >>> I have a somewhat different take on this draft. >>> >>> >>> >>> I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is >>> relevant – but I disagree that the lsr-stub-link draft is needed at all. >>> >>> In fact one of the main points in the extensive discussion of this draft >>> that occurred several months ago ( see >>> https://mailarchive.ietf.org/arch/msg/lsr/8pY4d21J1XOb_GfwgrROJUijLQ8/ as >>> a pointer to one email in the thread) was that RFC 5316/RFC 5392 are >>> sufficient to support the use case. This is reinforced by the references to >>> those two RFCs in the bgpls-inter-as-topology draft. >>> >>> >>> >>> The other main point (discussed in #3 below) is that the use of a prefix as >>> a Link Identifier is a flawed concept and has been objected to by many WG >>> members. >>> >>> >>> >>> For these reasons I believe this draft is unnecessary and undesirable. >>> >>> >>> >>> Given the extensive review of the draft by many members of the WG and the >>> failed WG adoption, I believe the WG should move on to other priorities. I >>> understand that the authors of lsr-stub-link have not been convinced and >>> want to continue to advocate for the draft, but at some point the WG needs >>> to say we have done due diligence and the WG consensus is NOT to adopt the >>> draft. The continued discussion of this draft consumes WG resources >>> (including presentation slots) and diverts WG attention from other work. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) >>> Sent: Wednesday, July 27, 2022 11:37 AM >>> To: Ketan Talaulikar <[email protected]>; >>> [email protected] >>> Cc: lsr <[email protected]> >>> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes >>> >>> >>> >>> Hi Ketan, >>> >>> I’m glad you brought this up. The primary (and AFAIK only) reason for this >>> draft is to get the stub-link information to a router in the IGP domain >>> running BGP-LS so that it can be advertised to the controller. For >>> reference, see >>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt >>> figure 1. So, the IGP encoding is only to get the stub-link information >>> from B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are >>> not consuming the information, the problem could be avoid by simply running >>> BGP-LS on B1-B4. See inline. >>> >>> >>> >>> >>> >>> From: Lsr <[email protected]> on behalf of Ketan Talaulikar >>> <[email protected]> >>> Date: Wednesday, July 27, 2022 at 5:33 AM >>> To: "[email protected]" >>> <[email protected]> >>> Cc: lsr <[email protected]> >>> Subject: [Lsr] Comments on draft-wang-lsr-stub-link-attributes >>> >>> >>> >>> Hello Authors, >>> >>> >>> >>> Please find below my comments/suggestions on this draft. I am sharing them >>> upfront given the packed LSR agenda. >>> >>> >>> >>> Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not >>> sound in my opinion. I would say that the TE encoding may not be suitable >>> for use in all deployments as their advertisement results in the addition >>> of those Inter-AS links in a TE topology database and that may not be >>> desired. So, I would suggest that the draft keeps the option of use of >>> Inter-AS TE TLVs valid and goes ahead with the Stub Link proposal as an >>> alternative with broader applicability (also see the next comment). >>> >>> >>> Agree. >>> >>> >>> >>> For the proclaimed wider applicability (e.g., links to servers/hosts) in >>> the slides, there is no such text in the draft. The draft seems focused on >>> Inter-AS links. I hope the authors update either the draft or the slides - >>> to be in sync with their objectives. >>> >>> >>> It is solely for purposes of advertisement in BGP-LS and consumption by the >>> SDN controller as described in >>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt. >>> >>> >>> >>> >>> >>> The use of the prefix TLVs in this context is something that is (in my >>> opinion) broken from day 1 of this draft. Prefixes are for reachability. >>> For identification of links, we have the local/remote link identifiers >>> along with the local/remote IP addresses (NOT prefixes!). This to me is a >>> NO-GO for the progression of this document. >>> >>> >>> I agree, if this draft is to persist, these should be referred to as ASBR >>> addresses as in the IDR draft (the sole raison d’etre for this IGP draft). >>> >>> >>> >>> The placement of the Stub Link TLV should be top-level (similar to >>> other/existing links). I can share further suggestions offline, provided we >>> reach an agreement on the above points and we converge on the main >>> purpose/motivation for this work. >>> >>> >>> I feel that strongly here as this is analogous to the new BGP-LS NLRI type >>> in >>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt. >>> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Ketan >>> >>> >>> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
