Hi Aijun, I am not particularly sold on the argument that the configuration requirements of RFC 5316/RFC 5392 are especially burdensome.
A PCE relies on the TEDB which comprises nodes & links, and it makes sense to have an inter-AS link represented as a "Link". Moreover, these links are TE-enabled and thus carry the TE properties of the link. You cannot avoid using this mechanism if Inter-AS Link's TE-properties need to be advertised. That is why I consider your proposal to be more applicable for non-TE use cases perhaps(?)! Thanks! Dhruv On Tue, Oct 13, 2020 at 8:03 AM Aijun Wang <[email protected]> wrote: > > Hi, Dhruv: > > Please see my explain to Jeff. > https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/ > > The solutions described in RFC 5316 and RFC 5392 are possible and > straightforward, but they have some constraints, especially for the > operation/configuration of the network. > > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, October 12, 2020 3:25 PM > To: Gyan Mishra <[email protected]> > Cc: Acee Lindem (acee) <[email protected]>; [email protected]; Aijun > Wang <[email protected]>; Aijun Wang <[email protected]>; Peter > Psenak (ppsenak) <[email protected]> > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > Hi Gyan, > > As far as PCE is concerned, we have the inter-AS link information via RFC > 5316 and RFC 5392. Both of these include a section on PCE's BRPC procedure > for instance. > > I see you have other use cases, but it would be good to highlight why for the > PCE use case the above is deficient. > > Thanks! > Dhruv > > > On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra <[email protected]> wrote: > > > > > > Hi Acee > > > > I believe what Aijun is trying to explain is that the primary purpose of > > PCE for active or passive path computation is for inter-as RSVP-TE PCALC > > path computation or SR-TE path computation. So PCE is solving a well known > > PCALC bin packing problem due to pcalc over subscribing RSVP tunnel > > bandwidth which is inherent an RSVP issue, but a bigger problematic issue > > is with being able to build an inter-as TE path with a single or multiple > > PCE controllers that can take the LSDB link attributes in the TEDs dB > > opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology > > topology from each TE domain to be able to build a congruent end to end > > RSVP TE or SR-TE traffic steered path instantiation. > > > > Without the use of PCE controllers as the LSDB link attribute information > > is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid > > loose path is built, failover due to crank back is impacted for reroute, > > due to not having a complete depiction of the other AS Link state topology > > by the head end or SR source node. > > > > So to build that entire end to end inter-as path for that end to end RSVP > > TE or SR-TE path instantiation it is critical to indentify the inter-as > > link eBGP tie link that may have static routes or BGP LU for RSVP head end > > to tail end reachability and SR-TE reachability to build out the end to end > > path instantiation. So the BGP-LS task to rebuild the lsdb topology of > > each inter connected AS that the RSVP TE or SR-TE steered path traverses, > > we need the accurate depiction and that includes the Identification of the > > critical inter-as tie link eBGP peering link that is passive for the PCE > > path computation logic for the end to end inter-as path instantiation. > > > > As for other interfaces using passive in the context of a operator service > > provider or enterprise core P and PE routers all links are transit with > > neighbors except the inter-as tie so having this new IGP TLV will help to > > that end. In the operator “core” network if there are other interfaces > > that don’t need to be advertised as stub, they can easily be excluded from > > being added into IGP. > > > > Kind Regards > > > > Gyan > > > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) > > <[email protected]> wrote: > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang <[email protected]> > >> Date: Friday, October 9, 2020 at 9:58 PM > >> To: Acee Lindem <[email protected]>, "Peter Psenak (ppsenak)" > >> <[email protected]>, 'Aijun Wang' <[email protected]> > >> Cc: "[email protected]" <[email protected]> > >> Subject: RE: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> > >> > >> From: [email protected] [mailto:[email protected]] On Behalf Of > >> Acee Lindem (acee) > >> Sent: Saturday, October 10, 2020 3:48 AM > >> To: Aijun Wang <[email protected]>; Peter Psenak (ppsenak) > >> <[email protected]>; 'Aijun Wang' <[email protected]> > >> Cc: [email protected] > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang <[email protected]> > >> Date: Thursday, October 8, 2020 at 11:09 PM > >> To: Acee Lindem <[email protected]>, "Peter Psenak (ppsenak)" > >> <[email protected]>, 'Aijun Wang' <[email protected]> > >> Cc: "[email protected]" <[email protected]> > >> Subject: RE: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> Sorry for the previous pruned mail. Let's reply you again along your > >> original question. > >> > >> Please see inline.[WAJ] > >> > >> > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of > >> Acee Lindem (acee) > >> Sent: Wednesday, September 30, 2020 7:47 PM > >> To: Aijun Wang <[email protected]>; Peter Psenak (ppsenak) > >> <[email protected]>; 'Aijun Wang' <[email protected]> > >> Cc: [email protected] > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi Aijun, > >> > >> Other than your ill-conceived topology discovery heuristic > >> > >> [WAJ] The topology discovery heuristic is not suitable for the corner use > >> case when the unnumbered interface is used, as explained in > >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B. > >> If you don’t agree, would you like to illustrate other non-applicable > >> scenarios? > >> > >> > >> > >> Right – and nobody other than yourself believes the IGPs should be > >> modified to expose the abstracted topology of an area outside that area. > >> > >> [WAJ] The modification doesn’t change the way and complexity of > >> route calculation within IGP. It just piggyback some extra > >> information, the bulk of the reconstruction work is done by the > >> controller. Such extra information can also have other usage, as > >> described in > >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06# > >> section-1 > >> > >> And, the proposal described in > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04 > >> is different with the problem you concerned. It has no relation with the > >> abstracted topology of an area. Maybe you are confused by these two > >> drafts? > >> > >> > >> > >> It is a similar problem. You are still trying to overload the prefix > >> advertisements with a link attribute (passive interface) so that it can be > >> conveyed outside the domain. We certainly wouldn’t waste a limited prefix > >> flag on this parochial application. > >> > >> > >> > >> > >> > >> You can solve the problem with BGP-LS session(s) between the router with a > >> BGP-LS session to the controller and a router in each area w/o a router > >> with a BGP-LS session to the controller. > >> > >> [WAJ] This is possible, but not efficient. For operation, we must also > >> consider the configuration/administration overhead. BGP-LS is designed > >> mainly for the northbound protocol, not east-west protocol. > >> > >> > >> > >> what other possible reason would there be for associating the passive > >> attribute with a prefix? > >> > >> [WAJ] To know the boundary of the IGP domain. After knowing the boundary, > >> the controller can safely apply and check the network security policy, the > >> inbound traffic control policy etc. > >> > >> > >> > >> It really isn’t relevant, but I have to ask…. How does the presence of a > >> prefix associated with a passive interface allow you to make this > >> deduction? > >> > >> [WAJ] Passive interfaces are deployed mainly at the boundary of IGP > >> domain. Is there any other exception? > >> > >> While passive interfaces are not standardized, there is nothing that > >> limits their usage to an IGP boundary. They can and are deployed on any > >> interface where adjacencies are not to be formed (e.g., a stub subnet > >> containing hosts). > >> > >> > >> > >> Thanks, > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 10:39 PM, "Aijun Wang" <[email protected]> wrote: > >> > >> > >> > >> Hi, Acee and Peter: > >> > >> Passive interface is mainly used at the edge of the network, where the > >> unnumbered interface will not be used. > >> > >> And the information to flag the passive interfaces is for positioning > >> the area boundary, not conflict with the abstract capabilities of the area > >> inside. > >> > >> > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Aijun Wang > >> > >> China Telecom > >> > >> > >> > >> -----Original Message----- > >> > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Acee Lindem (acee) > >> > >> Sent: Tuesday, September 29, 2020 9:16 PM > >> > >> To: Peter Psenak <[email protected]>; Aijun Wang > >> <[email protected]>; 'Aijun Wang' <[email protected]> > >> > >> Cc: [email protected] > >> > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, Peter, > >> > >> I agree with Peter - one of the main motivations for having areas is > >> to abstract the topology within the area. Now you're trying to supplant > >> this - one topological detail at a time with ill-conceived IGP features. > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" > >> <[email protected] on behalf of [email protected]> > >> wrote: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> On 29/09/2020 11:07, Aijun Wang wrote: > >> > >> > Hi, Peter: > >> > >> > > >> > >> > Thanks for your comments. > >> > >> > 1. For BGP-LS deployment, there normally only be one router > >> that within the > >> > >> > IGP domain to report the topology information, this router > >> should know such > >> > >> > passive links which exists mainly on other border routers > >> via the IGP > >> > >> > protocol. This is main reason to extension the IGP > >> protocol. > 2. For the solution, normally, the link within the IGP > >> connect two > >> > >> ends, but > >> > >> > passive interface is special and not fall in this space. We > >> have studied the > >> > >> > current TLVs that for link, and find no suitable container > >> to append this > >> > >> > information. This is the reason that we select the TLVs > >> that associated with > >> > >> > Prefix. > >> > >> > >> > >> if the link is unnumbered, your solution does not work. As I > >> said, if > >> > >> you need a knowledge about the link, you can not advertise it as a > >> prefix. > >> > >> > >> > >> thanks, > >> > >> Peter > >> > >> > >> > >> > >> > >> > > >> > >> >>From other POV, the OSPFv3 defines now the > >> "Intra-Area-Prefix LSA", which > >> > >> > isolate the prefix information that associated with link > >> into this > >> > >> > container, contains the stub link, local interface > >> information etc. Put such > >> > >> > attribute along with the prefix is then acceptable? > >> > >> > > >> > >> > > >> > >> > Best Regards > >> > >> > > >> > >> > Aijun Wang > >> > >> > China Telecom > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: [email protected] [mailto:[email protected]] On > >> Behalf Of Peter > >> > >> > Psenak > >> > >> > Sent: Tuesday, September 29, 2020 4:29 PM > >> > >> > To: Aijun Wang <[email protected]> > >> > >> > Cc: [email protected] > >> > >> > Subject: Re: [Lsr] FW: New Version Notification for > >> > >> > draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > > >> > >> > Hi Aijun, > >> > >> > > >> > >> > here's my comments: > >> > >> > > >> > >> > The purpose of this draft is to advertise passive links. > >> > >> > > >> > >> > 1. I'm not sure the problem needs to be solved by IGPs. I > >> tend to believe > >> > >> > ietf-idr-bgpls-inter-as-topology-ext is sufficient. > >> > >> > > >> > >> > 2. the solution that you proposed is wrong. You are trying > >> to derive > >> > >> > topological data about the passive links from the prefix > >> advertisement. > >> > >> > This is semantically incorrect and only works under very > >> specific condition. > >> > >> > If you need to advertise a link, advertise it as a "special" > >> > >> > link, not as a "special" prefix. > >> > >> > > >> > >> > thanks, > >> > >> > Peter > >> > >> > > >> > >> > On 29/09/2020 03:17, Aijun Wang wrote: > >> > >> >> Hi, Peter: > >> > >> >> > >> > >> >> Would you like to review and give comments on the updates > >> version of this > >> > >> > draft? > >> > >> >> We have also added the protocol extension proposal for OSPFv3. > >> > >> >> > >> > >> >> The update version of this draft can refer to > >> > >> >> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac > >> e > >> > >> >> -attribute > >> > >> >> Thanks in advance. > >> > >> >> > >> > >> >> > >> > >> >> Best Regards > >> > >> >> > >> > >> >> Aijun Wang > >> > >> >> China Telecom > >> > >> >> > >> > >> >>> -----Original Message----- > >> > >> >>> From: [email protected] > >> [mailto:[email protected]] > >> > >> >>> Sent: Monday, September 28, 2020 3:17 PM > >> > >> >>> To: Zhibo Hu <[email protected]>; Gyan Mishra > >> > >> >>> <[email protected]>; Aijun Wang > >> <[email protected]>; > >> > >> >>> Gyan S. Mishra <[email protected]> > >> > >> >>> Subject: New Version Notification for > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> > >> > >> >>> > >> > >> >>> A new version of I-D, > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> has been successfully submitted by Aijun Wang and posted > >> to the IETF > >> > >> >>> repository. > >> > >> >>> > >> > >> >>> Name: draft-wang-lsr-passive-interface-attribute > >> > >> >>> Revision: 04 > >> > >> >>> Title: Passive Interface Attribute > >> > >> >>> Document date: 2020-09-28 > >> > >> >>> Group: Individual Submission > >> > >> >>> Pages: 7 > >> > >> >>> URL: > >> > >> >>> > >> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. > >> > >> >>> txt > >> > >> >>> Status: > >> > >> >>> > >> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att > >> > >> >>> r > >> > >> >>> ibute/ > >> > >> >>> Htmlized: > >> > >> >>> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac > >> > >> >>> e > >> > >> >>> -attribut > >> > >> >>> e > >> > >> >>> Htmlized: > >> > >> >>> > >> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut > >> > >> >>> e > >> > >> >>> -04 > >> > >> >>> Diff: > >> > >> >>> > >> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at > >> > >> >>> t > >> > >> >>> ribute-04 > >> > >> >>> > >> > >> >>> Abstract: > >> > >> >>> This document describes the mechanism that can be used to > >> > >> >>> differentiate the passive interfaces from the normal > >> interfaces > >> > >> >>> within ISIS or OSPF domain. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> Please note that it may take a couple of minutes from the > >> time of > >> > >> >>> submission until the htmlized version and diff are > >> available at > >> > >> > tools.ietf.org. > >> > >> >>> > >> > >> >>> The IETF Secretariat > >> > >> >>> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> > > >> > >> > _______________________________________________ > >> > >> > 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 > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lsr > > > > -- > > > > > > Gyan Mishra > > > > Network Solutions Architect > > > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
