Hi, Peter: Currently, the inter-AS link TLV is advertised within the Inter-AS-TE-LSA for OSPF and Inter-AS Reachability TLV for ISIS. But I think these two places are not suitable for the stub-link information.
It seems that separating the stub-link information from the inter-as link information is better, because not all of the stub-links are inter-as link. If so, can we put the newly defined Stub-Link TLV within the Router LSA for OSPF and make it one new top TLV for ISIS? Best Regards Aijun Wang China Telecom -----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Saturday, November 7, 2020 1:56 AM To: Aijun Wang <[email protected]> Cc: Aijun Wang <[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected] Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt Aijun, On 05/11/2020 12:04, Aijun Wang wrote: > 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. yes, unless you can use or extend the existing inter-AS link advertisement. thanks, Peter > > 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
