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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 4 Nov 2020 20:11:23 +0000

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-masked]> 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-masked] on behalf of Aijun Wang" <[email-masked]> 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-masked]> wrote:
        >

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 5 Nov 2020 09:15:36 +0800

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-masked]] 
Sent: Thursday, November 5, 2020 4:11 AM
To: Aijun Wang <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

    Hi Aijun, 

        Hi, Acee:

        Aijun Wang
        China Telecom

---

From: Peter Psenak <[email-masked]>
Date: Thu, 5 Nov 2020 09:25:54 +0100

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:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 5 Nov 2020 17:09:15 +0800

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-masked] [mailto:[email-masked]] 
Sent: Thursday, November 5, 2020 4:26 PM
To: Aijun Wang <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Aijun Wang' <[email-masked]>
Cc: [email-masked]
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:
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-wang-lsr-passive-interface-attribute-04.txt
> 
> Hi Aijun,

---

From: Peter Psenak <[email-masked]>
Date: Thu, 5 Nov 2020 10:15:03 +0100

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

---

From: Aijun Wang <[email-masked]>
Date: Thu, 5 Nov 2020 19:04:33 +0800

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 <ppsenak=[email-masked]> 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
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 6 Nov 2020 18:55:36 +0100

Aijun,

> 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

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 9 Nov 2020 14:35:18 +0800

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-masked]] 
Sent: Saturday, November 7, 2020 1:56 AM
To: Aijun Wang <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Aijun,

thanks,
Peter

>>> To: Aijun Wang <[email-masked]>; 'Acee Lindem (acee)' 
>>> <[email-masked]>; 'Aijun Wang' <[email-masked]>
>>> Cc: [email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Mon, 9 Nov 2020 10:43:54 +0100

Hi Aijun,

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 10 Nov 2020 17:58:18 +0000

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" <[email-masked]> wrote:

    Hi Aijun,

    thanks,
    Peter

---

From: Aijun Wang <[email-masked]>
Date: Wed, 11 Nov 2020 07:27:35 +0800

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.

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.
Thanks in advance.

Aijun Wang
China Telecom

> On Nov 11, 2020, at 02:01, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Aijun, 
> 
> Speaking as WG member:
> 
>> Cc: Aijun Wang <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr@i

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Nov 2020 16:16:28 +0000

Hi Aijun,

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

Hi, Acee:

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.

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

Speaking as WG member:

Speaking as WG Co-chair:

Thanks,
Acee

   Hi Aijun,

Hi, Peter:

   thanks,
   Peter

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]]
Sent: Saturday, November 7, 2020 1:56 AM
To: Aijun Wang <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr@i