Hi, Robert: I think your proposal are valid. Option C like deployment can also use such information to select the optimized inter-AS link to reach the routers in other domain. The final effect will be like the EPE scenario.
Aijun Wang China Telecom > On Jul 29, 2022, at 16:44, Robert Raszuk <[email protected]> wrote: > > > 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) >> <[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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
