Hi, Peter: Then how about defines one new top TLV to flood such information within the IGP? Fox example, Stub-Link TLV? If so, other characteristics associated with the Link can also be advertised accordingly.
If acceptable, we can forward this draft along this direction. Aijun Wang China Telecom > On Nov 5, 2020, at 17:15, Peter Psenak <[email protected]> > wrote: > > Aijun, > > the point I was trying to make was that you should think of a similar > mechanism for your use cases - e.g. define something that advertises the link > without advertising the IS adjacency and not mess up with the prefix > advertisement. > > thanks, > Peter > >> On 05/11/2020 10:09, Aijun Wang wrote: >> Hi, Peter: >> Yes, RFC 5392 is the OSPF corresponding part for the inter-AS TE solution. >> But using these existing solutions has some limitation in deployment, as I >> explained in >> https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/. >> And, in some situations, not all of the passive interfaces are connected >> with another AS, then flag these interfaces using RFC 5316 or RFC 5392 is >> not appropriate. >> Do you agree? >> Best Regards >> Aijun Wang >> China Telecom >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Thursday, November 5, 2020 4:26 PM >> To: Aijun Wang <[email protected]>; 'Acee Lindem (acee)' >> <[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, >> please look at rfc5316, ISIS already have a way to advertise inter-AS link >> without forming an adjacency. >> thanks, >> Peter >>> On 05/11/2020 02:15, Aijun Wang wrote: >>> Hi, Acee: >>> >>> Thanks for this comments. >>> The consideration for the position of flagging the passive interface have >>> been stated in the updated 05 version >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-05#section-3, >>> as the followings: >>> >>> ISIS [RFC5029] defines the Link-Attributes Sub-TLV to carry the link >>> attribute information, but this Sub-TLV can only be carried within >>> the TLV 22, which is used to described the attached neighbor. For >>> passive interface, there is no ISIS neighbor, then it is not >>> appropriate to use this Sub-TLV to indicate the passive attribute of >>> the interface. >>> >>> OSPFv2[RFC2328] defines link type field within Router LSA, the type 3 >>> for connections to a stub network can be used to identified the >>> passive interface. But in OSPFv3 [RFC5340], type 3 within the >>> Router-LSA has been reserved. The information that associated with >>> stub network has been put in the Intra-Area-Prefix-LSAs. >>> >>> What about your opinions regarding to the above statements? Currently, we >>> think putting the flag within the prefix attribute that associated the >>> passive interface is appropriate. >>> If we can find other appropriate/acceptable place to hold this information, >>> we can also update the draft later accordingly. >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> -----Original Message----- >>> From: Acee Lindem (acee) [mailto:[email protected]] >>> Sent: Thursday, November 5, 2020 4:11 AM >>> To: Aijun Wang <[email protected]> >>> Cc: Aijun Wang <[email protected]>; Peter Psenak (ppsenak) >>> <[email protected]>; [email protected] >>> Subject: Re: [Lsr] FW: New Version Notification for >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> >>> Hi Aijun, >>> You still didn't answer the question as to why you didn't rework this draft >>> for passive interface to be an interface attribute rather than a prefix >>> attribute? >>> Thanks, >>> Acee >>> >>>> On 10/1/20, 6:13 AM, "Acee Lindem (acee)" <[email protected]> wrote: >>> >>> Hi Aijun, >>> You didn't answer my question and pruned my message. Other than your >>> attempt to expose the topology of areas outside the area, there is no other >>> reason to associate the passive interface attribute with a prefix. We seem >>> to be in a circular discussion.... >>> Acee >>> >>>> On 9/30/20, 10:43 PM, "[email protected] on behalf of Aijun >>>> Wang" <[email protected]> wrote: >>> >>> Hi, Acee: >>> Except the corner cases of unnumbered interface, would you like to >>> illustrate other scenarios that the process does not apply? >>> As mentioned in last mail, knowing the passive interfaces can >>> assist the nodes or controller know the boundaries of the network. >>> >>> Aijun Wang >>> China Telecom >>> >>> > On Sep 30, 2020, at 19:47, Acee Lindem (acee) <[email protected]> >>> wrote: >>> > >>> >>> >>> >>> >>> _______________________________________________ >>> 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
