Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

["Acee Lindem (acee)" <[e-mail]>]

Hi Aijun,

From: <[e-mail]> on behalf of Aijun Wang <[e-mail]>
Date: Tuesday, November 10, 2020 at 6:27 PM
To: Acee Lindem <[e-mail]>
Cc: "Peter Psenak (ppsenak)" <[e-mail]>, Aijun Wang <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:
I have updated the draft according to the discussion with Peter on the list. The updated draft will be uploaded once the IETF repository reopen.
We define new TLV to contain the stub-link related information within OSPFv2/v3 and ISIS respectively. The presentation will also align with it.

Ok - Keep in mind that passive interface is not standardized. Also, as I stated previously, my view is you should advertise precisely what your use case requires rather than making uncertain inferences from the fact that an interface is configured as passive.

Together with the use case that described in Linda’s draft https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01, we think this extension is necessary and should be considered within IGP.

I have the a similar comment that stub link should not be used in this draft.

Thanks,
Acee

Thanks in advance.
Aijun Wang
China Telecom


On Nov 11, 2020, at 02:01, Acee Lindem (acee) <[e-mail]> wrote:
Aijun,

Speaking as WG member:

At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC 5340. Hence, this purely a vendor concept.
Additionally, it is a property, albeit a vendor property, of a link and not a prefix. It would be both inappropriate and profligate (considering the scarcity) to allocate a prefix option for the purpose of identifying a passive link associated with the prefix. Given your narrow use case of identifying the edge of an IGP domain, it would certainly be better to allocate a new TLV specifically for purpose and perhaps this doesn't belong in the IGPs at all and should be something you propose solely for BGP-LS consumption.

Speaking as WG Co-chair:

Given strong objections to this draft in its current form, I don't really see a good reason for present it at IETF 109. I believe it would just be a rehash of the discuss that has already taken place.

Thanks,
Acee

On 11/9/20, 4:44 AM, "Peter Psenak" <[e-mail]> wrote:

   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:[e-mail]]
Sent: Saturday, November 7, 2020 1:56 AM
To: Aijun Wang <[e-mail]>
Cc: Aijun Wang <[e-mail]>; Acee Lindem (acee) <[e-mail]>; lsr@i