Hi Aijun, How does this proposal impacts BGP path selection ?
Note that it is common to do next hop self on the ASBRs towards the intradomain. So your proposal would not require any signalling to be effective on a given ASBR. Local decision. Originally I was under impression that you want to enhance TE for option C like deployments. But if not then I see not much point of doing it. Thx, R. On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang <[email protected]> wrote: > Hi, Ketan: > > > > In the inter-AS scenario, we will not deploy BGP session on each p2p link. > The BGP session exists only within the loopback address of each ASBR pair. > > Such deployment is also same in the LAN scenario. Then there is no mesh or > partial p2p link that congruent to the BGP sessions. > > But such LAN interfaces are sharing the same prefixes. > > > > And regarding to your comments on Prefix sub-TLV: yes, if we redistribute > such external prefixes into the IGP, then they will be transported within > the associated “External Prefixes TLV”. > > But for these stub links, if we configure them as “passive” only( no > redistributed action), then the prefixes of these stub links will not > exists within the IGP LSA. > > Attach the prefixes information with these stub links can certainly fill > such gap. There will be no redundancy information. > > > > And, regarding to your comments: “… …- at least let us not go overboard > and repeat the same info in multiple places. ”, this is also the main > reason that we don’t want to use the RFC5316/RFC5392 mechanism to > accomplish the goal for the inter-as topology recovery------there will be > many redundancy information being flooded within the IGP area. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Thursday, July 28, 2022 4:54 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Acee > Lindem (acee) <[email protected]>; lsr <[email protected]> > *Subject:* Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes > > > > Hi Aijun, > > > > Please check inline below. > > > > On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang <[email protected]> > wrote: > > 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. > > > > KT> Note that we have BGP running on these Inter-AS links. Even when there > is an underlying LAN, the BGP sessions are p-t-p and maybe a full or > partial mesh. Therefore, I believe representing such a LAN as a mesh of > p-t-p links that are congruent to the BGP sessions is the right approach. I > am happy to be corrected. In any case, I still fail to see how a prefix > associated with the links helps here. > > > > > > 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. > > > > KT> I disagree - such stub links can be identified by their local > interface ids along with their local IP address. Note that we already have > the corresponding prefix being advertised as prefix reachability. So I > don't see the need to repeat. All of this is already overloading IGPs with > info that is not used by IGPs - at least let us not go overboard and repeat > the same info in multiple places. > > > > Please check the new fresh thread about use-cases. > > > > Thanks, > > Ketan > > > > > > 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) <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. > > > > 1. 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. > > > > 2. 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 > . > > > > > > 3. 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). > > > > 4. 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
