Hi Aijun,
On 09/11/2020 07:35, Aijun Wang wrote:
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?
Router LSA does not have TLVs, you would have to add the data to
Extended Prefix Link TLV (RFC7684), or define a net top-level TLV under
the OSPFv2 Extended Link Opaque LSA.
For ISIS you don't have a choice really, you need to define a new
top-level TLV.
thanks,
Peter
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
