Subject: [Lsr] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 29 Jul 2021 20:23:21 +0000

Speaking as WG member:

Authors,

I think this draft is still flawed. Regarding the terminology, I don’t think it should refer to passive interfaces at all since they aren’t referenced in protocol documents. Rather, you should use stub-link consistently – including the title. However, I don’t think this makes any difference as I think you need to “go back to the drawing board”.

Why do other routers in the domain need to know the link if it isn’t connected to any other routers? The stub-link is an artifact of OSPFv2 used to advertise local prefixes. As you noticed, it was removed in OSPFv3 and local prefixes are advertised in Intra-Area-Prefix LSAs (and E-Inter-Area-Prefix-LSAs). I really think you are trying to advertise attributes of a prefix and not a link. In fact, in OSPFv3 there is no address associated with the link – I see you have attempted to remedy this by adding a sub-TLV to advertise the prefix associated with the link ;^). So, now this local prefix will be advertised two different ways?

Specifically, what is BGP controller going to do with the stub link advertisement that it couldn’t do with a prefix advertisement?  Also, why can’t the AS boundary router report the inter-AS prefix via BGP-LS? The other routers in the IGP domain have no use for this information.

What is the use-case for knowing that a prefix is associated with a loopback? We already have the N-Flag (Node) for prefixes… What is your loopback use case?

Also, what is the Vlan interface use case? What possible use could other routers in the domain have for this information?

Thanks,
Acee

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 29 Jul 2021 22:24:06 -0400

Hi Acee

In-line

On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Speaking as WG member:
>
>
>
> Authors,
>
>
>
> I think this draft is still flawed. Regarding the terminology, I don’t
> think it should refer to passive interfaces at all since they aren’t
> referenced in protocol documents. Rather, you should use stub-link
> consistently – including the title. However, I don’t think this makes any
> difference as I think you need to “go back to the drawing board”.
>
>  Gyan> Agreed.  We will change any references to passive  to stub.
>
> Why do other routers in the domain need to know the link if it isn’t
> connected to any other routers? The stub-link is an artifact of OSPFv2 used
> to advertise local prefixes. As you noticed, it was removed in OSPFv3 and
> local prefixes are advertised in Intra-Area-Prefix LSAs (and
> E-Inter-Area-Prefix-LSAs). I really think you are trying to advertise
> attributes of a prefix and not a link. In fact, in OSPFv3 there is no
> address associated with the link – I see you have attempted to remedy this
> by adding a sub-TLV to advertise the prefix associated with the link ;^).
> So, now this local prefix will be advertised two different ways?
>
> Gyan>(We did remedy as you asked)  Per yours and I believe Peters a d
> others recommendation with OSPFV2 update RFC 7684 change from fixed format
> LSA to TLV based similar to OSPFV3 RFC 8362 which the other big change was
> the breakout of “topological” construct from the prefix creating separate
> router links LSA for “topological” and prefix LSA for prefixes.  As the
> passive or stub concept as you have reiterated to the authors is really
> topological and  of prefix based to use router links and not router prefix
> to add the new stub TLV so that is what we did for both OSPFV2 and OSPFV3
> and added new top level stub  TLV for ISIS.
>
> Specifically, what is BGP controller going to do with the stub link
> advertisement that it couldn’t do with a prefix advertisement?  Also, why
> can’t the AS boundary router report the inter-AS prefix via BGP-LS? The
> other routers in the IGP domain have no use for this information.
>
>  Gyan> From a use case perspective the goal is to make this new stub TLV
> generic so it can be used for any use case where you have a stub LSA that
> is advertised that can be tracked by the PCE controller for the NB BGP-LS
> building of the topological graphs and being able to distinguish any stub
> nets from  transit nets with neighbors.
>
> What is the use-case for knowing that a prefix is associated with a
> loopback? We already have the N-Flag (Node) for prefixes… What is your
> loopback use case?
>
> Gyan> When NBI BGP-LS builds the topological graphs it’s any stub link
> which could be inter-as or loopbacks or any interfaces so they can be
> differentiated when the LSDB is build for the TEDs database.
>
> Also, what is the Vlan interface use case? What possible use could other
> routers in the domain have for this information?
>
> Gyan> I believe vlan is just another example but it’s really any interface
> that is a stub link with no neighbors can be treated differently by the NBI
> BGP-LS, when the topological graph is built.
>
> Thanks,
> Acee
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 30 Jul 2021 17:00:11 +0000

Hi Gyan,

See brief inlines.

From: Gyan Mishra <[email-masked]>
Date: Thursday, July 29, 2021 at 10:24 PM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute

Hi Acee

In-line

On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

Authors,

I think this draft is still flawed. Regarding the terminology, I don’t think it should refer to passive interfaces at all since they aren’t referenced in protocol documents. Rather, you should use stub-link consistently – including the title. However, I don’t think this makes any difference as I think you need to “go back to the drawing board”.
 Gyan> Agreed.  We will change any references to passive  to stub.
Why do other routers in the domain need to know the link if it isn’t connected to any other routers? The stub-link is an artifact of OSPFv2 used to advertise local prefixes. As you noticed, it was removed in OSPFv3 and local prefixes are advertised in Intra-Area-Prefix LSAs (and E-Inter-Area-Prefix-LSAs). I really think you are trying to advertise attributes of a prefix and not a link. In fact, in OSPFv3 there is no address associated with the link – I see you have attempted to remedy this by adding a sub-TLV to advertise the prefix associated with the link ;^). So, now this local prefix will be advertised two different ways?
Gyan>(We did remedy as you asked)  Per yours and I believe Peters a d others recommendation with OSPFV2 update RFC 7684 change from fixed format LSA to TLV based similar to OSPFV3 RFC 8362 which the other big change was the breakout of “topological” construct from the prefix creating separate router links LSA for “topological” and prefix LSA for prefixes.  As the passive or stub concept as you have reiterated to the authors is really topological and  of prefix based to use router links and not router prefix to add the new stub TLV so that is what we did for both OSPFV2 and OSPFV3 and added new top level stub  TLV for ISIS.
I’m glad you didn’t modify the base LSAs. However, my question is why the entity you are trying to describe isn’t just a local prefix – why do we need to create a stub-link?

Specifically, what is BGP controller going to do with the stub link advertisement that it couldn’t do with a prefix advertisement?  Also, why can’t the AS boundary router report the inter-AS prefix via BGP-LS? The other routers in the IGP domain have no use for this information.
 Gyan> From a use case perspective the goal is to make this new stub TLV generic so it can be used for any use case where you have a stub LSA that is advertised that can be tracked by the PCE controller for the NB BGP-LS building of the topological graphs and being able to distinguish any stub nets from  transit nets with neighbors.
What is the use-case for knowing that a prefix is associated with a loopback? We already have the N-Flag (Node) for prefixes… What is your loopback use case?
Gyan> When NBI BGP-LS builds the topological graphs it’s any stub link which could be inter-as or loopbacks or any interfaces so they can be differentiated when the LSDB is build for the TEDs database.
Also, what is the Vlan interface use case? What possible use could other routers in the domain have for this information?
Gyan> I believe vlan is just another example but it’s really any interface that is a stub link with no neighbors can be treated differently by the NBI BGP-LS, when the topological graph is built.
I don’t see why this attribute can’t be associated with a prefix and why we need a link. Furthermore, I don’t see any of the types as being useful other than inter-AS. And for inter-AS, it can be advertised in BGP-LS. Clearly, if there is an inter-AS interface, the router is running BGP.
Thanks,
Acee

Thanks,
Acee
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Aijun Wang <[email-masked]>
Date: Sat, 31 Jul 2021 06:44:13 +0800

Hi, Acee:

Thanks for your comments.
Please see the replies inline.

Aijun Wang
China Telecom

> On Jul 31, 2021, at 01:00, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> Hi Gyan,
>  
> See brief inlines.
>  
> On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (acee) <acee=[email-masked]> wrote:
> Speaking as WG member:
>  
> Authors,
>  

[WAJ] There are other attributes need to be associated and advertised with these stub links. Please refer to the discussion at https://mailarchive.ietf.org/arch/msg/lsr/0Lk8IPxsD1BJYT9D-NcRQJEnwHU/ for 5G edge computation use case.

> I don’t see why this attribute can’t be associated with a prefix and why we need a link. Furthermore, I don’t see any of the types as being useful other than inter-AS. And for inter-AS, it can be a…

[WAJ] As stated above, there are other attributes that should be associated with the stub links. There are also other use cases for theses information on the controller. For example, the controller can deploy network boundaries security policy once it knows which interfaces are facing the external world.
It can also release the operator from deploying BGP-LS on every border router for inter-AS use case.
The 5G edge computation that described in https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ is another use case for these stub links on IGP routers.

> Email [email-masked]
> M 301 502-1347
> 
>