Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Jeff,

Please notice that WAN is not an IX.

While you can have full mesh of BFD sessions among all IXP participants
each bombarding each over over TB fabric every 100 ms or so to map the same
over global WAN is a different game. If nothing else RTT between IXP
participants in healthy IX is around 1 ms while RTT between PEs distributed
globally is often 100-200 ms.

Just imagine 1000 PEs in 10 areas distributed all over the world. That
means that in worst case scenario (say same mgmt VPN present on each PE)
you will establish 1000*999 BFD sessions. Now for this to make sense timer
needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
defeat the purpose as BGP withdraw will be faster.

Then we go into queuing issues. If BFD packets are queued at any interface
meltdowns may occur which can be far worse in consequences then waiting for
BGP service route removal. Such meltdowns often result in cascading effects
to the applications itself.

So this is not at all about autodiscovery with which address to setup the
BFD session. It is much more about operational aspects of going that
direction.

With that I am supportive of this work even if we label it as experimental
for some time. As each network is different what is optimal solution for
one design and deployment may not be optimal for the other.

Many thx,
Robert


On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura 
wrote:

> We have been discussing for quite some time and in different wg's (there’s
> IX with RS use case) BFD verification based on next-hop extraction, Robert
> - you should know. (also built a well working prototype in previous life).
>
> Very simple logic:
>
> Upon route import (BGP update received and imported), extract next-hop,
> walk BFD session table, if no match (no existing session) - establish
> (S)BFD session (Discriminators distribution is a solved problem) to the
> next-hop, associate fate of all routes received from it, keep timers
> reasonable to prevent false positives.
>
> State is limited to PE’s importing each others routes (sharing a service)
> only
> High degree of automation
> No IGP pollution
>
> Cheers,
> Jeff
> On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) ,
> wrote:
>
> Speaking as WG member:
>
>
>
> I think it would be good to hone in on the BGP PE failure convergence use
> case as suggested by Robert. It seems there is some interest here although
> I’m not convinced the IGP is the right place to solve this problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From:* Lsr  on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date:* Tuesday, November 17, 2020 at 4:02 AM
> *To:* Robert Raszuk 
> *Cc:* lsr , Jeff Tantsura , Aijun
> Wang , "Acee Lindem (acee)"  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>
>
>
>
>
>Robert, I believe the original intention was related to having the data
> plane converge quickly when summarization is used and flip so traffic
> converges from the Active ABR to the Backup ABR.
>
>
>
> I do not buy this use case. Flooding within the area is fast such that
> both ABRs will get the same info. As mentioned before there is no practical
> use of PUA for making any routing or fwd decision on which ABR to use. If
> your ABRs are not connected with min redundancy this draft is a worst patch
> ever to work around such a design.
>
>
>
>Gyan> Agreed.  The point of PUA in ABR use case is the ability to track
> the component prefixes and in case where component is down and traffic is
> still forwarded to the ABR and dropped.  The other more important use case
> is when links are down within the area and the area is partitioned and so
> one ABR has all component prefixes however other ABR is missing half the
> component prefixes.  So since the ABR will by default advertise the summary
> as long as their is one component UP the summary is still advertised.  So
> this use case is severely impacting as now you have an ECMP path to the
> other area for the summary via the two ABRs and you drop half your
> traffic.  So now with PUA the problem is fixed and the PUA is sent and now
> traffic is only sent to the ABR that has the component prefixes.
>
>
>
> Please present us a picture indicating before and after ABRs behaviour.
>
>
>
>  Gyan> will do
>
>
>
>However PUA can be used in the absence of area segmentation within a
> single area when a link or node fails to converge the data plane quickly by
> sending PUA for the backup path so the active path.
>
>
>
> If there is no area segmentation then there is no summaries. So what are
> we missing in the first place ?
>
>
>
> Gyan> Sorry I am stating that PUA feature can also be used intra area
> where if a link or node goes down to improve data plane convergence.
>
>
>
>
>
> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA &
> RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
>

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Hi Zhibo,

> However, if there is a summary or default route in the area, FIB Miss
cannot be triggered.

If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit.

Thx,
R.

On Wed, Nov 18, 2020 at 3:36 AM Huzhibo  wrote:

> Hi Tony:
>
>
>
> In fact, this protection use case protects the SRv6 mid-point.
> https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/.
> When the SRv6 mid-point fails, the PLR node can perform the next SID
> operation, which is triggered by FIB miss. However, if there is a summary
> or default route in the area, FIB Miss cannot be triggered.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *tony...@tony.li
> *Sent:* Tuesday, November 17, 2020 2:31 PM
> *To:* Aijun Wang 
> *Cc:* lsr ; Jeff Tantsura ; Robert
> Raszuk ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
> And how would that help connectivity restoration ?
>
> *[WAJ] This action will trigger the path protection procedures, which will
> divert the traffic to other backup path.*
>
>
>
>
>
> This seems to be making some major assumptions about how path protection
> features operate. Those assumptions need to be
>
> very explicitly called out.
>
>
>
> The path protection features that I’m familiar with are triggered by
> topological changes along the existing operable path. A PUA
>
> does not provide that.  Rather, it’s something of a temporary signal
> saying ’this broke’. Without more specifics about the failure, it’s
> difficult to
>
> understand exactly what path protection should make of this.  If a prefix
> is unreachable, the obvious implication is that the associated link has
>
> failed.  Path protection in a remote area is highly unlikely to have the
> topological details necessary to find an alternate path to that prefix.
>
>
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Acee:

 

From: Acee Lindem (acee)  
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem mailto:a...@cisco.com> >
Cc: 'lsr' mailto:lsr@ietf.org> >
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

 

Hi, Acee:

 

-Original Message-
From: lsr-boun...@ietf.org   mailto:lsr-boun...@ietf.org> > On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang mailto:wang...@chinatelecom.cn> >
Cc: 'lsr' mailto:lsr@ietf.org> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

 

Speaking as WG member and longtime steward  of the IGPs:

 

Hi Aijun, 

 

My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs. 

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of 
one independent IGP instance(as you proposed in 109 meeting) will be more 
expensive. Do you agree this statement?

 

No – bloating the primary LSAs with non-routing information will be more 
expensive due to the dynamics of LSA origination and route computation. 

[WAJ] what’s your recommendation then? The router can skip such information 
when they do SPF calculation, just need only add the information to the 
attached leaf router when the computation is completed. The LSA update is 
periodic and event driven. Advertising such information in a controlled manner 
does not deteriorate the flooding status. 

 

Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

[WAJ] Passive Interfaces are already deployed within the network in many 
places, as stated in the 
draft-wang-lsr-passive-interface-attribute-06#section-1 

 . What we want to know, is the position of passive interface. Previously, we 
want piggyback such information within its associated prefix, but after 
discussion on the mail list, define one new TLV to contain it and other future 
information may be more acceptable and extensible.

 

And how do identify and even define the position of the passive interface? 

[WAJ] Passive interface be certainly attached the router that advertises the 
associated stub-link TLV.  

 

As I stated previously, passive interfaces are not standardized. 

[WAJ] if you mentioned just the term, we can change it later. Or if so, what’s 
other term do you recommend then?

 

Knowing these information, the controller can learn the inter-as links via some 
methods that we have discussed in another thread, can know the boundary of 
network, can learn the link characteristic that associated with server etc. We 
have also mentioned it in the 
draft-wang-lsr-passive-interface-attribute-06#section-1 

  and think it is not appropriate to expand it intensely in one LSR draft.

 

I disagree. Precisely define your use case. 

[WAJ] which part of the introduction section is not clear enough? There are 
about 3 possible use cases of such information, aren’t they enough?

And, we have described one use case in detail in previous version of this draft 
draft-wang-lsr-passive-interface-attribute-04#section-3 

 . If necessary, we can add it back again in the next version. This is just one 
use case, you can also refer to draft-dunbar-lsr-5g-edge-compute-ospf-ext-01 
  for 
the detail of another use case.  

 

 

 

Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc). 

[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00 

 , you mentioned also the similar information that should be transferred via 
the OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol. 

 

This was just an example of so

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

[Acee Lindem (acee)]

From: Aijun Wang 
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem 
Cc: 'lsr' 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt


Hi, Acee:



-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt



Speaking as WG member and longtime steward  of the IGPs:



Hi Aijun,



My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs.

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of 
one independent IGP instance(as you proposed in 109 meeting) will be more 
expensive. Do you agree this statement?



No – bloating the primary LSAs with non-routing information will be more 
expensive due to the dynamics of LSA origination and route computation.



Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

[WAJ] Passive Interfaces are already deployed within the network in many 
places, as stated in the 
draft-wang-lsr-passive-interface-attribute-06#section-1.
 What we want to know, is the position of passive interface. Previously, we 
want piggyback such information within its associated prefix, but after 
discussion on the mail list, define one new TLV to contain it and other future 
information may be more acceptable and extensible.



And how do identify and even define the position of the passive interface? As I 
stated previously, passive interfaces are not standardized.



Knowing these information, the controller can learn the inter-as links via some 
methods that we have discussed in another thread, can know the boundary of 
network, can learn the link characteristic that associated with server etc. We 
have also mentioned it in the 
draft-wang-lsr-passive-interface-attribute-06#section-1
 and think it is not appropriate to expand it intensely in one LSR draft.



I disagree. Precisely define your use case.



Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc).

[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00,
 you mentioned also the similar information that should be transferred via the 
OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol.



This was just an example of something that could be offloaded to a separate 
instance in the slides. It is not a specification.



Thanks,

Acee







Thanks,

Acee



On 11/17/20, 1:08 AM, "wang...@chinatelecom.cn on behalf of Aijun 
Wang" 
mailto:wang...@chinatelecom.cn>> wrote:



Hi, Acee:



As discussed on the list and during the 109 meeting, we have updated the 
draft to reflect the comments from the LSR community.

Please see whether you have still other concerns or not and if there is no 
further comments on this direction, can we begin the WG adoption call then?

Thanks you and Peter for your intense discussions for this draft.



Thanks in advance.



Best Regards



Aijun Wang

China Telecom



> -Original Message-

> From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>

> Sent: Sunday, November 15, 2020 7:44 AM

> To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang

> mailto:wang...@chinatelecom.cn>>; Gyan S. Mishra 
mailto:gyan.s.mis...@verizon.com>>;

> Gyan Mishra mailto:gyan.s.mis...@verizon.com>>

> Subject: New Version Notification for

> draft-wang-lsr-passive-interface-attribute-06.txt

>

>

> A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt

> has been successfully submitted by Aijun Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-passive-interface-attribute

> Revision:   06

> Title:  Passive Interface Attribute

> Document date:   2020-11-15

> 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

We have been discussing for quite some time and in different wg's (there’s IX 
with RS use case) BFD verification based on next-hop extraction, Robert - you 
should know. (also built a well working prototype in previous life).

Very simple logic:

Upon route import (BGP update received and imported), extract next-hop, walk 
BFD session table, if no match (no existing session) - establish (S)BFD session 
(Discriminators distribution is a solved problem) to the next-hop, associate 
fate of all routes received from it, keep timers reasonable to prevent false 
positives.

State is limited to PE’s importing each others routes (sharing a service) only
High degree of automation
No IGP pollution

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) , wrote:
> Speaking as WG member:
>
> I think it would be good to hone in on the BGP PE failure convergence use 
> case as suggested by Robert. It seems there is some interest here although 
> I’m not convinced the IGP is the right place to solve this problem.
>
> Thanks,
> Acee
>
> From: Lsr  on behalf of Gyan Mishra 
> 
> Date: Tuesday, November 17, 2020 at 4:02 AM
> To: Robert Raszuk 
> Cc: lsr , Jeff Tantsura , Aijun Wang 
> , "Acee Lindem (acee)" 
> 
> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
> > quote_type
> >
> >
> > > quote_type
> > >    Robert, I believe the original intention was related to having the 
> > > data plane converge quickly when summarization is used and flip so 
> > > traffic converges from the Active ABR to the Backup ABR.
> >
> > I do not buy this use case. Flooding within the area is fast such that both 
> > ABRs will get the same info. As mentioned before there is no practical use 
> > of PUA for making any routing or fwd decision on which ABR to use. If your 
> > ABRs are not connected with min redundancy this draft is a worst patch ever 
> > to work around such a design.
>
>    Gyan> Agreed.  The point of PUA in ABR use case is the ability to track 
> the component prefixes and in case where component is down and traffic is 
> still forwarded to the ABR and dropped.  The other more important use case is 
> when links are down within the area and the area is partitioned and so one 
> ABR has all component prefixes however other ABR is missing half the 
> component prefixes.  So since the ABR will by default advertise the summary 
> as long as their is one component UP the summary is still advertised.  So 
> this use case is severely impacting as now you have an ECMP path to the other 
> area for the summary via the two ABRs and you drop half your traffic.  So now 
> with PUA the problem is fixed and the PUA is sent and now traffic is only 
> sent to the ABR that has the component prefixes.
> > quote_type
> >
> > Please present us a picture indicating before and after ABRs behaviour.
>
>      Gyan> will do
> > quote_type
> >
> > > quote_type
> > >    However PUA can be used in the absence of area segmentation within a 
> > > single area when a link or node fails to converge the data plane quickly 
> > > by sending PUA for the backup path so the active path.
> >
> > If there is no area segmentation then there is no summaries. So what are we 
> > missing in the first place ?
>
>     Gyan> Sorry I am stating that PUA feature can also be used intra area 
> where if a link or node goes down to improve data plane convergence.
> > quote_type
> >
> >
> > > quote_type
> > > With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA 
> > > & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the 
> > > convergence is well into sub second.  So for Intra area convergence with 
> > > all the optimizations mentioned I am not sure how much faster the data 
> > > plane will converge with PUA.
> >
> > Even without any of the above listed chain of acronymous things will 
> > generally work well intra-area without PUAs.
>
>     Gyan> Agreed which is why I mentioned the BGP next hop self use case if I 
> could figure out how PUA could help there that would be a major benefit of 
> PUA.
> > quote_type
> >
> > Thx,
> > R.
> >
> >
> --
> <>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

[wangyali]

Hi Tony,

Thanks for your question. Please see in line [Yali]. 
Please let me know your opinions.

Best,
Yali

-Original Message-
From: Tony Li [mailto:tony1ath...@gmail.com] 
Sent: Wednesday, November 18, 2020 1:41 AM
To: wangyali 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00



> Q1: are you using this information to determine the routing to the network? 
> On one hand, such advertisement does not effect on the normal SPF computation 
> and may be useful for traffic engineering. For example, for IOAM service, if 
> the HbH Processing Action of Node/Link is assigned to a slow processing 
> plane, the Node or Link should be excluded for path computation. If the HbH 
> Processing Action of Node/Link is ignore all extension Options header, the 
> Node/Link can be used as the normal IPv6 transit node/link. If the HbH 
> Processing Action of Node/Link is skip to Next extension Options header (e.g. 
> Routing Header), the Node/Link can be considered as Endpoints in SRv6 
> routing. On the other hand, such advertisement is useful for entities to 
> determine specific services encoded in HbH options header can be deployed in 
> a given path.
> 
> Q2: can you use the link color to compute paths?
> In the above, I answered, taking advantage of this advertisement, the exact 
> action taken by Node or Link to process HbH options header can be determined 
> (defined in Action Flag field), which can be useful for traffic engineering. 
> Hence, such advertisement is not only used to determine whether the HbH 
> options header supported by Node/Link or not. But the link color cannot 
> exactly indicate the exact action.

This suggests that you’re missing one bit of information.  Thus, could you use 
two link colors to differentiate between the two?
[Yali] I am not clear what does the "... to differentiate between the two" 
mean? Please let me know if I'm missing something. 

[Yali] While please let me clarify what does the "Processing Action" include in 
this draft. The "Processing Action" indicates the various of configurable 
processing behavior for Hop-by-Hop Options header, which are specified in 
RFC8200. The "Processing Action" includes ignore the Hop-by-Hop Options header, 
skip to the next extension header, drop packets containing a Hop-by-Hop Options 
header, or assign packets to a slow processing path. Besides, the "Service 
Flag" is also defined in this draft used to indicate which service/function 
Options supported by Node/Link.

[Yali] Hence, "two link colors" cannot differentiate the above vary 
combinations of "Processing Action Flag" and "Service Flag". Moreover, "Link 
Color" can only indicate whether or not include or exclude the Link for Traffic 
Engineering. But our use cases mentioned in Q1 is not so simple.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Huzhibo]

Hi Tony:

In fact, this protection use case protects the SRv6 mid-point. 
https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/. 
When the SRv6 mid-point fails, the PLR node can perform the next SID operation, 
which is triggered by FIB miss. However, if there is a summary or default route 
in the area, FIB Miss cannot be triggered.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, November 17, 2020 2:31 PM
To: Aijun Wang 
Cc: lsr ; Jeff Tantsura ; Robert Raszuk 
; Acee Lindem (acee) 
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases


And how would that help connectivity restoration ?
[WAJ] This action will trigger the path protection procedures, which will 
divert the traffic to other backup path.


This seems to be making some major assumptions about how path protection 
features operate. Those assumptions need to be
very explicitly called out.

The path protection features that I’m familiar with are triggered by 
topological changes along the existing operable path. A PUA
does not provide that.  Rather, it’s something of a temporary signal saying 
’this broke’. Without more specifics about the failure, it’s difficult to
understand exactly what path protection should make of this.  If a prefix is 
unreachable, the obvious implication is that the associated link has
failed.  Path protection in a remote area is highly unlikely to have the 
topological details necessary to find an alternate path to that prefix.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Acee:

 

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

 

Speaking as WG member and longtime steward  of the IGPs:

 

Hi Aijun, 

 

My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs. 

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of 
one independent IGP instance(as you proposed in 109 meeting) will be more 
expensive. Do you agree this statement?

 

Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

[WAJ] Passive Interfaces are already deployed within the network in many 
places, as stated in the 
draft-wang-lsr-passive-interface-attribute-06#section-1 

 . What we want to know, is the position of passive interface. Previously, we 
want piggyback such information within its associated prefix, but after 
discussion on the mail list, define one new TLV to contain it and other future 
information may be more acceptable and extensible.

Knowing these information, the controller can learn the inter-as links via some 
methods that we have discussed in another thread, can know the boundary of 
network, can learn the link characteristic that associated with server etc. We 
have also mentioned it in the 
draft-wang-lsr-passive-interface-attribute-06#section-1 

  and think it is not appropriate to expand it intensely in one LSR draft.

 

Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc). 

[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00 

 , you mentioned also the similar information that should be transferred via 
the OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol. 

 

 

 

Thanks,

Acee

 

On 11/17/20, 1:08 AM, " 
 
wang...@chinatelecom.cn on behalf of Aijun Wang" < 
 wang...@chinatelecom.cn> wrote:

 

Hi, Acee:

 

As discussed on the list and during the 109 meeting, we have updated the 
draft to reflect the comments from the LSR community.

Please see whether you have still other concerns or not and if there is no 
further comments on this direction, can we begin the WG adoption call then?

Thanks you and Peter for your intense discussions for this draft.

 

Thanks in advance.

 

Best Regards

 

Aijun Wang

China Telecom

 

> -Original Message-

> From:   internet-dra...@ietf.org < 
 internet-dra...@ietf.org>

> Sent: Sunday, November 15, 2020 7:44 AM

> To: Zhibo Hu <  huzh...@huawei.com>; Aijun Wang

> <  wang...@chinatelecom.cn>; Gyan S. 
Mishra <  gyan.s.mis...@verizon.com>;

> Gyan Mishra <  
gyan.s.mis...@verizon.com>

> Subject: New Version Notification for

> draft-wang-lsr-passive-interface-attribute-06.txt

> 

> 

> A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt

> has been successfully submitted by Aijun Wang and posted to the IETF

> repository.

> 

> Name:   draft-wang-lsr-passive-interface-attribute

> Revision:   06

> Title:  Passive Interface Attribute

> Document date:   2020-11-15

> Group:  Individual Submission

> Pages:   10

> URL:

>  

 https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t

> xt

> Status:

>  
 
https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/

> Htmlized:

>  

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Thanks Robert!

I will work on spelling out the scenario in updated LSR presentation.

Thanks

Gyan
On Tue, Nov 17, 2020 at 5:31 PM Robert Raszuk  wrote:

>
> Yes that is the case where I see some potential use case.
>
> Especially considering also https://tools.ietf.org/html/rfc5283 - which
> by many network operators is very desired, but not configured due to "slow
> BGP convergence" - pls let's not go there :)
>
> But again if someone knows how to configure BGP properly I think IGP
> speedup would be marginal or even null hence a grain of hesitation if we
> should use IGP flooding for it. Maybe in some scenarios ... which PUA
> authors need to spell out to move fwd I suppose.
>
> Cheers,
> R.
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra  wrote:
>
>>
>> Robert
>>
>> I am recalling now the BGP use case you mentioned.
>>
>> If the next hop is being summarized between areas which it would be, the
>> next hop failure component prefix is now hidden in the summary and now you
>> have to wait for BGP timer to pop and route withdrawal.
>>
>> So for this failure scenario one option is multihop BFD but that does get
>> way complicated.
>>
>> So here the obvious and best use case for PUA would be for the data plane
>> detection of the next hop component down at which time PUA is sent flooded
>> and the routers in the other area now set next hop to null for that next
>> hop and are forced to converge on alternate next hop.
>>
>> Let me update the presentation to add this use case.
>>
>> Thanks
>>
>> Gyan
>>
>> On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra 
>> wrote:
>>
>>> Agreed.
>>>
>>> Robert
>>>
>>> Can you explain the BGP scenario you had in mind that you have mentioned
>>> a number of times that you think this PUA feature would pertain?
>>>
>>> I will respond to your other email separately.  I was trying to guess
>>>  as to the BGP next hop use case you were referring to but apparently was
>>> way off.
>>>
>>> Thank you
>>>
>>> Gyan
>>>
>>> On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee) 
>>> wrote:
>>>
 Speaking as WG member:



 I think it would be good to hone in on the BGP PE failure convergence
 use case as suggested by Robert. It seems there is some interest here
 although I’m not convinced the IGP is the right place to solve this 
 problem.



 Thanks,

 Acee



 *From: *Lsr  on behalf of Gyan Mishra <
 hayabusa...@gmail.com>
 *Date: *Tuesday, November 17, 2020 at 4:02 AM
 *To: *Robert Raszuk 
 *Cc: *lsr , Jeff Tantsura ,
 Aijun Wang , "Acee Lindem (acee)" >>> 40cisco@dmarc.ietf.org>
 *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases







 On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk 
 wrote:





Robert, I believe the original intention was related to having the
 data plane converge quickly when summarization is used and flip so traffic
 converges from the Active ABR to the Backup ABR.



 I do not buy this use case. Flooding within the area is fast such that
 both ABRs will get the same info. As mentioned before there is no practical
 use of PUA for making any routing or fwd decision on which ABR to use. If
 your ABRs are not connected with min redundancy this draft is a worst patch
 ever to work around such a design.



Gyan> Agreed.  The point of PUA in ABR use case is the ability to
 track the component prefixes and in case where component is down and
 traffic is still forwarded to the ABR and dropped.  The other more
 important use case is when links are down within the area and the area is
 partitioned and so one ABR has all component prefixes however other ABR is
 missing half the component prefixes.  So since the ABR will by default
 advertise the summary as long as their is one component UP the summary is
 still advertised.  So this use case is severely impacting as now you have
 an ECMP path to the other area for the summary via the two ABRs and you
 drop half your traffic.  So now with PUA the problem is fixed and the PUA
 is sent and now traffic is only sent to the ABR that has the component
 prefixes.



 Please present us a picture indicating before and after ABRs behaviour.



  Gyan> will do



However PUA can be used in the absence of area segmentation within a
 single area when a link or node fails to converge the data plane quickly by
 sending PUA for the backup path so the active path.



 If there is no area segmentation then there is no summaries. So what
 are we missing in the first place ?



 Gyan> Sorry I am stating that PUA feature can also be used intra
 area where if a link or node goes down to improve data plane convergence.





 With the IGP tun

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Yes that is the case where I see some potential use case.

Especially considering also https://tools.ietf.org/html/rfc5283 - which by
many network operators is very desired, but not configured due to "slow BGP
convergence" - pls let's not go there :)

But again if someone knows how to configure BGP properly I think IGP
speedup would be marginal or even null hence a grain of hesitation if we
should use IGP flooding for it. Maybe in some scenarios ... which PUA
authors need to spell out to move fwd I suppose.

Cheers,
R.








On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra  wrote:

>
> Robert
>
> I am recalling now the BGP use case you mentioned.
>
> If the next hop is being summarized between areas which it would be, the
> next hop failure component prefix is now hidden in the summary and now you
> have to wait for BGP timer to pop and route withdrawal.
>
> So for this failure scenario one option is multihop BFD but that does get
> way complicated.
>
> So here the obvious and best use case for PUA would be for the data plane
> detection of the next hop component down at which time PUA is sent flooded
> and the routers in the other area now set next hop to null for that next
> hop and are forced to converge on alternate next hop.
>
> Let me update the presentation to add this use case.
>
> Thanks
>
> Gyan
>
> On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra  wrote:
>
>> Agreed.
>>
>> Robert
>>
>> Can you explain the BGP scenario you had in mind that you have mentioned
>> a number of times that you think this PUA feature would pertain?
>>
>> I will respond to your other email separately.  I was trying to guess  as
>> to the BGP next hop use case you were referring to but apparently was way
>> off.
>>
>> Thank you
>>
>> Gyan
>>
>> On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee) 
>> wrote:
>>
>>> Speaking as WG member:
>>>
>>>
>>>
>>> I think it would be good to hone in on the BGP PE failure convergence
>>> use case as suggested by Robert. It seems there is some interest here
>>> although I’m not convinced the IGP is the right place to solve this problem.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Lsr  on behalf of Gyan Mishra <
>>> hayabusa...@gmail.com>
>>> *Date: *Tuesday, November 17, 2020 at 4:02 AM
>>> *To: *Robert Raszuk 
>>> *Cc: *lsr , Jeff Tantsura ,
>>> Aijun Wang , "Acee Lindem (acee)" >> 40cisco@dmarc.ietf.org>
>>> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>>>
>>>
>>>
>>>
>>>
>>>Robert, I believe the original intention was related to having the
>>> data plane converge quickly when summarization is used and flip so traffic
>>> converges from the Active ABR to the Backup ABR.
>>>
>>>
>>>
>>> I do not buy this use case. Flooding within the area is fast such that
>>> both ABRs will get the same info. As mentioned before there is no practical
>>> use of PUA for making any routing or fwd decision on which ABR to use. If
>>> your ABRs are not connected with min redundancy this draft is a worst patch
>>> ever to work around such a design.
>>>
>>>
>>>
>>>Gyan> Agreed.  The point of PUA in ABR use case is the ability to
>>> track the component prefixes and in case where component is down and
>>> traffic is still forwarded to the ABR and dropped.  The other more
>>> important use case is when links are down within the area and the area is
>>> partitioned and so one ABR has all component prefixes however other ABR is
>>> missing half the component prefixes.  So since the ABR will by default
>>> advertise the summary as long as their is one component UP the summary is
>>> still advertised.  So this use case is severely impacting as now you have
>>> an ECMP path to the other area for the summary via the two ABRs and you
>>> drop half your traffic.  So now with PUA the problem is fixed and the PUA
>>> is sent and now traffic is only sent to the ABR that has the component
>>> prefixes.
>>>
>>>
>>>
>>> Please present us a picture indicating before and after ABRs behaviour.
>>>
>>>
>>>
>>>  Gyan> will do
>>>
>>>
>>>
>>>However PUA can be used in the absence of area segmentation within a
>>> single area when a link or node fails to converge the data plane quickly by
>>> sending PUA for the backup path so the active path.
>>>
>>>
>>>
>>> If there is no area segmentation then there is no summaries. So what are
>>> we missing in the first place ?
>>>
>>>
>>>
>>> Gyan> Sorry I am stating that PUA feature can also be used intra
>>> area where if a link or node goes down to improve data plane convergence.
>>>
>>>
>>>
>>>
>>>
>>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA
>>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
>>> convergence is well into sub second.  So for Intra area convergence with
>>> all the optimizations mentioned I am not sure how much faster the data
>>> plane will converge with PUA.
>>>
>>>
>>>
>>> Even

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Robert

I am recalling now the BGP use case you mentioned.

If the next hop is being summarized between areas which it would be, the
next hop failure component prefix is now hidden in the summary and now you
have to wait for BGP timer to pop and route withdrawal.

So for this failure scenario one option is multihop BFD but that does get
way complicated.

So here the obvious and best use case for PUA would be for the data plane
detection of the next hop component down at which time PUA is sent flooded
and the routers in the other area now set next hop to null for that next
hop and are forced to converge on alternate next hop.

Let me update the presentation to add this use case.

Thanks

Gyan

On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra  wrote:

> Agreed.
>
> Robert
>
> Can you explain the BGP scenario you had in mind that you have mentioned a
> number of times that you think this PUA feature would pertain?
>
> I will respond to your other email separately.  I was trying to guess  as
> to the BGP next hop use case you were referring to but apparently was way
> off.
>
> Thank you
>
> Gyan
>
> On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee)  wrote:
>
>> Speaking as WG member:
>>
>>
>>
>> I think it would be good to hone in on the BGP PE failure convergence use
>> case as suggested by Robert. It seems there is some interest here although
>> I’m not convinced the IGP is the right place to solve this problem.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> *From: *Lsr  on behalf of Gyan Mishra <
>> hayabusa...@gmail.com>
>> *Date: *Tuesday, November 17, 2020 at 4:02 AM
>> *To: *Robert Raszuk 
>> *Cc: *lsr , Jeff Tantsura , Aijun
>> Wang , "Acee Lindem (acee)" > 40cisco@dmarc.ietf.org>
>> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>>
>>
>>
>>
>>
>>Robert, I believe the original intention was related to having the
>> data plane converge quickly when summarization is used and flip so traffic
>> converges from the Active ABR to the Backup ABR.
>>
>>
>>
>> I do not buy this use case. Flooding within the area is fast such that
>> both ABRs will get the same info. As mentioned before there is no practical
>> use of PUA for making any routing or fwd decision on which ABR to use. If
>> your ABRs are not connected with min redundancy this draft is a worst patch
>> ever to work around such a design.
>>
>>
>>
>>Gyan> Agreed.  The point of PUA in ABR use case is the ability to
>> track the component prefixes and in case where component is down and
>> traffic is still forwarded to the ABR and dropped.  The other more
>> important use case is when links are down within the area and the area is
>> partitioned and so one ABR has all component prefixes however other ABR is
>> missing half the component prefixes.  So since the ABR will by default
>> advertise the summary as long as their is one component UP the summary is
>> still advertised.  So this use case is severely impacting as now you have
>> an ECMP path to the other area for the summary via the two ABRs and you
>> drop half your traffic.  So now with PUA the problem is fixed and the PUA
>> is sent and now traffic is only sent to the ABR that has the component
>> prefixes.
>>
>>
>>
>> Please present us a picture indicating before and after ABRs behaviour.
>>
>>
>>
>>  Gyan> will do
>>
>>
>>
>>However PUA can be used in the absence of area segmentation within a
>> single area when a link or node fails to converge the data plane quickly by
>> sending PUA for the backup path so the active path.
>>
>>
>>
>> If there is no area segmentation then there is no summaries. So what are
>> we missing in the first place ?
>>
>>
>>
>> Gyan> Sorry I am stating that PUA feature can also be used intra area
>> where if a link or node goes down to improve data plane convergence.
>>
>>
>>
>>
>>
>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA
>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
>> convergence is well into sub second.  So for Intra area convergence with
>> all the optimizations mentioned I am not sure how much faster the data
>> plane will converge with PUA.
>>
>>
>>
>> Even without any of the above listed chain of acronymous things will
>> generally work well intra-area without PUAs.
>>
>>
>>
>> Gyan> Agreed which is why I mentioned the BGP next hop self use case
>> if I could figure out how PUA could help there that would be a major
>> benefit of PUA.
>>
>>
>>
>> Thx,
>> R.
>>
>>
>>
>>
>>
>> --
>>
>> [image: Image removed by sender.] 
>>
>> 
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> 
>> *Silver Spring, MD
>> 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

On Tue, Nov 17, 2020 at 9:43 AM Robert Raszuk  wrote:

> Hi Gyan,
>
>   Gyan>. We could use Aijun’s passive interface new top level TLV to
>> link the next hop rewrite loopback to the PE-CE links all being set to
>> passive. So if any PE-CE link goes down a PUA is sent and the next hop
>> converges PIC core PE-CE link which is now associated with the Loopback.
>> This would be a major benefit of PUA for PIC core convergence when
>> next-hop-self is used which applies to MPLS and SR and IP based core.
>>
>
> I have read the above three sentences five times and came with two basic
> observations:
>
> * You are mixing PIC Core with PIC Edge - Please do not. Those are
> completely separate features and it is a feature not a bug to keep them
> that way.
>

   Gyan> Sorry for the confusion. I agree we are not taking BGP PIC core
which is H-FIB core feature for core failures resulting in IGP next hop
update.  Also we are not talking about BGP PIC edge pre programmed backup
paths.  What I was trying to address is use of PUA to resolve a issue with
BGP convergence related to using BCP use of next hop self rewrite so PE-CE
link next hops do not have to be flooded into the IGP.  Down side of
next-hop-self is for convergence in the core from edge failure, the edge
failure is not detected and you have to wait for route to be withdrawn. So
I was thinking maybe PUA data plane convergence mechanism would be a way to
help with convergence.  Not sure how or if possible but was thinking that
as a possible use case for PUA.

>
> * You are mixing external PE-CE interfaces with IGP passive interfaces -
> Please do not. There should be no IGP flooding of any sort associated with
> state of PE-CE interface. No need.
>

Understood.  Bad idea.

>
> Thx a lot,
> R.
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Agreed.

Robert

Can you explain the BGP scenario you had in mind that you have mentioned a
number of times that you think this PUA feature would pertain?

I will respond to your other email separately.  I was trying to guess  as
to the BGP next hop use case you were referring to but apparently was way
off.

Thank you

Gyan

On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
>
>
> I think it would be good to hone in on the BGP PE failure convergence use
> case as suggested by Robert. It seems there is some interest here although
> I’m not convinced the IGP is the right place to solve this problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Tuesday, November 17, 2020 at 4:02 AM
> *To: *Robert Raszuk 
> *Cc: *lsr , Jeff Tantsura , Aijun
> Wang , "Acee Lindem (acee)"  40cisco@dmarc.ietf.org>
> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>
>
>
>
>
>Robert, I believe the original intention was related to having the data
> plane converge quickly when summarization is used and flip so traffic
> converges from the Active ABR to the Backup ABR.
>
>
>
> I do not buy this use case. Flooding within the area is fast such that
> both ABRs will get the same info. As mentioned before there is no practical
> use of PUA for making any routing or fwd decision on which ABR to use. If
> your ABRs are not connected with min redundancy this draft is a worst patch
> ever to work around such a design.
>
>
>
>Gyan> Agreed.  The point of PUA in ABR use case is the ability to track
> the component prefixes and in case where component is down and traffic is
> still forwarded to the ABR and dropped.  The other more important use case
> is when links are down within the area and the area is partitioned and so
> one ABR has all component prefixes however other ABR is missing half the
> component prefixes.  So since the ABR will by default advertise the summary
> as long as their is one component UP the summary is still advertised.  So
> this use case is severely impacting as now you have an ECMP path to the
> other area for the summary via the two ABRs and you drop half your
> traffic.  So now with PUA the problem is fixed and the PUA is sent and now
> traffic is only sent to the ABR that has the component prefixes.
>
>
>
> Please present us a picture indicating before and after ABRs behaviour.
>
>
>
>  Gyan> will do
>
>
>
>However PUA can be used in the absence of area segmentation within a
> single area when a link or node fails to converge the data plane quickly by
> sending PUA for the backup path so the active path.
>
>
>
> If there is no area segmentation then there is no summaries. So what are
> we missing in the first place ?
>
>
>
> Gyan> Sorry I am stating that PUA feature can also be used intra area
> where if a link or node goes down to improve data plane convergence.
>
>
>
>
>
> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA &
> RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
> convergence is well into sub second.  So for Intra area convergence with
> all the optimizations mentioned I am not sure how much faster the data
> plane will converge with PUA.
>
>
>
> Even without any of the above listed chain of acronymous things will
> generally work well intra-area without PUAs.
>
>
>
> Gyan> Agreed which is why I mentioned the BGP next hop self use case
> if I could figure out how PUA could help there that would be a major
> benefit of PUA.
>
>
>
> Thx,
> R.
>
>
>
>
>
> --
>
> [image: Image removed by sender.] 
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> 
> *Silver Spring, MD
> 
>
>
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as WG member and longtime steward  of the IGPs:

Hi Aijun, 

My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs. 

Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc). 

Thanks,
Acee

On 11/17/20, 1:08 AM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:

As discussed on the list and during the 109 meeting, we have updated the 
draft to reflect the comments from the LSR community.
Please see whether you have still other concerns or not and if there is no 
further comments on this direction, can we begin the WG adoption call then?
Thanks you and Peter for your intense discussions for this draft.

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Sunday, November 15, 2020 7:44 AM
> To: Zhibo Hu ; Aijun Wang
> ; Gyan S. Mishra ;
> Gyan Mishra 
> Subject: New Version Notification for
> draft-wang-lsr-passive-interface-attribute-06.txt
> 
> 
> A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt
> has been successfully submitted by Aijun Wang and posted to the IETF
> repository.
> 
> Name: draft-wang-lsr-passive-interface-attribute
> Revision: 06
> Title:Passive Interface Attribute
> Document date:2020-11-15
> Group:Individual Submission
> Pages:10
> URL:
> 
https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t
> xt
> Status:
> 
https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/
> Htmlized:
> 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut
> e
> Htmlized:
> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06
> Diff:
> 
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06
> 
> Abstract:
>This document describes the mechanism that can be used to
>differentiate the passive interfaces from the normal interfaces
>within ISIS or OSPF domain.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

[Tony Li]

> Q1: are you using this information to determine the routing to the network? 
> On one hand, such advertisement does not effect on the normal SPF computation 
> and may be useful for traffic engineering. For example, for IOAM service, if 
> the HbH Processing Action of Node/Link is assigned to a slow processing 
> plane, the Node or Link should be excluded for path computation. If the HbH 
> Processing Action of Node/Link is ignore all extension Options header, the 
> Node/Link can be used as the normal IPv6 transit node/link. If the HbH 
> Processing Action of Node/Link is skip to Next extension Options header (e.g. 
> Routing Header), the Node/Link can be considered as Endpoints in SRv6 
> routing. On the other hand, such advertisement is useful for entities to 
> determine specific services encoded in HbH options header can be deployed in 
> a given path.
> 
> Q2: can you use the link color to compute paths?
> In the above, I answered, taking advantage of this advertisement, the exact 
> action taken by Node or Link to process HbH options header can be determined 
> (defined in Action Flag field), which can be useful for traffic engineering. 
> Hence, such advertisement is not only used to determine whether the HbH 
> options header supported by Node/Link or not. But the link color cannot 
> exactly indicate the exact action.

This suggests that you’re missing one bit of information.  Thus, could you use 
two link colors to differentiate between the two?

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Hi Gyan,

  Gyan>. We could use Aijun’s passive interface new top level TLV to
> link the next hop rewrite loopback to the PE-CE links all being set to
> passive. So if any PE-CE link goes down a PUA is sent and the next hop
> converges PIC core PE-CE link which is now associated with the Loopback.
> This would be a major benefit of PUA for PIC core convergence when
> next-hop-self is used which applies to MPLS and SR and IP based core.
>

I have read the above three sentences five times and came with two basic
observations:

* You are mixing PIC Core with PIC Edge - Please do not. Those are
completely separate features and it is a feature not a bug to keep them
that way.

* You are mixing external PE-CE interfaces with IGP passive interfaces -
Please do not. There should be no IGP flooding of any sort associated with
state of PE-CE interface. No need.

Thx a lot,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Acee Lindem (acee)]

Speaking as WG member:

I think it would be good to hone in on the BGP PE failure convergence use case 
as suggested by Robert. It seems there is some interest here although I’m not 
convinced the IGP is the right place to solve this problem.

Thanks,
Acee

From: Lsr  on behalf of Gyan Mishra 

Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk 
Cc: lsr , Jeff Tantsura , Aijun Wang 
, "Acee Lindem (acee)" 

Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases



On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:


   Robert, I believe the original intention was related to having the data 
plane converge quickly when summarization is used and flip so traffic converges 
from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both 
ABRs will get the same info. As mentioned before there is no practical use of 
PUA for making any routing or fwd decision on which ABR to use. If your ABRs 
are not connected with min redundancy this draft is a worst patch ever to work 
around such a design.

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track the 
component prefixes and in case where component is down and traffic is still 
forwarded to the ABR and dropped.  The other more important use case is when 
links are down within the area and the area is partitioned and so one ABR has 
all component prefixes however other ABR is missing half the component 
prefixes.  So since the ABR will by default advertise the summary as long as 
their is one component UP the summary is still advertised.  So this use case is 
severely impacting as now you have an ECMP path to the other area for the 
summary via the two ABRs and you drop half your traffic.  So now with PUA the 
problem is fixed and the PUA is sent and now traffic is only sent to the ABR 
that has the component prefixes.

Please present us a picture indicating before and after ABRs behaviour.

 Gyan> will do

   However PUA can be used in the absence of area segmentation within a single 
area when a link or node fails to converge the data plane quickly by sending 
PUA for the backup path so the active path.

If there is no area segmentation then there is no summaries. So what are we 
missing in the first place ?

Gyan> Sorry I am stating that PUA feature can also be used intra area where 
if a link or node goes down to improve data plane convergence.


With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA & RLFA 
for MPLS or TI-LFA for SR local protection - with those tweaks the convergence 
is well into sub second.  So for Intra area convergence with all the 
optimizations mentioned I am not sure how much faster the data plane will 
converge with PUA.

Even without any of the above listed chain of acronymous things will generally 
work well intra-area without PUAs.

Gyan> Agreed which is why I mentioned the BGP next hop self use case if I 
could figure out how PUA could help there that would be a major benefit of PUA.

Thx,
R.


--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

On Tue, Nov 17, 2020 at 4:01 AM Gyan Mishra  wrote:

>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>
>>
>>
>>Robert, I believe the original intention was related to having the
>>> data plane converge quickly when summarization is used and flip so traffic
>>> converges from the Active ABR to the Backup ABR.
>>>
>>
>> I do not buy this use case. Flooding within the area is fast such that
>> both ABRs will get the same info. As mentioned before there is no practical
>> use of PUA for making any routing or fwd decision on which ABR to use. If
>> your ABRs are not connected with min redundancy this draft is a worst patch
>> ever to work around such a design.
>>
>
>Gyan> Agreed.  The point of PUA in ABR use case is the ability to track
> the component prefixes and in case where component is down and traffic is
> still forwarded to the ABR and dropped.  The other more important use case
> is when links are down within the area and the area is partitioned and so
> one ABR has all component prefixes however other ABR is missing half the
> component prefixes.  So since the ABR will by default advertise the summary
> as long as their is one component UP the summary is still advertised.  So
> this use case is severely impacting as now you have an ECMP path to the
> other area for the summary via the two ABRs and you drop half your
> traffic.  So now with PUA the problem is fixed and the PUA is sent and now
> traffic is only sent to the ABR that has the component prefixes.
>
>>
>> Please present us a picture indicating before and after ABRs behaviour.
>>
>
>  Gyan> will do
>
>>
>>However PUA can be used in the absence of area segmentation within a
>>> single area when a link or node fails to converge the data plane quickly by
>>> sending PUA for the backup path so the active path.
>>>
>>
>> If there is no area segmentation then there is no summaries. So what are
>> we missing in the first place ?
>>
>
> Gyan> Sorry I am stating that PUA feature can also be used intra area
> where if a link or node goes down to improve data plane convergence.
>
>>
>>
>>
>>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA
>>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
>>> convergence is well into sub second.  So for Intra area convergence with
>>> all the optimizations mentioned I am not sure how much faster the data
>>> plane will converge with PUA.
>>>
>>
>> Even without any of the above listed chain of acronymous things will
>> generally work well intra-area without PUAs.
>>
>
> Gyan> Agreed which is why I mentioned the BGP next hop self use case
> if I could figure out how PUA could help there that would be a major
> benefit of PUA.
>

  Gyan>. We could use Aijun’s passive interface new top level TLV to
link the next hop rewrite loopback to the PE-CE links all being set to
passive. So if any PE-CE link goes down a PUA is sent and the next hop
converges PIC core PE-CE link which is now associated with the Loopback.
This would be a major benefit of PUA for PIC core convergence when
next-hop-self is used which applies to MPLS and SR and IP based core.


https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/

So the two main critical  use cases where this solution solves a problem is
partitioned area scenario and nest hop convergence when next-hop-self is
used scenario.

I will update the presentation deck and share.


>> Thx,
>> R.
>>
>>
>> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Discussion on draft-wang-lsr-hbh-process-00

[wangyali]

Hi all,

Many thanks for these value questions and comments from Chris, Ron, Acee in the 
LSR 109 session. I summarize them as follows, and supplement my answer. Waiting 
forwards to further discussion with WG.

Q1: are you using this information to determine the routing to the network? 
On one hand, such advertisement does not effect on the normal SPF computation 
and may be useful for traffic engineering. For example, for IOAM service, if 
the HbH Processing Action of Node/Link is assigned to a slow processing plane, 
the Node or Link should be excluded for path computation. If the HbH Processing 
Action of Node/Link is ignore all extension Options header, the Node/Link can 
be used as the normal IPv6 transit node/link. If the HbH Processing Action of 
Node/Link is skip to Next extension Options header (e.g. Routing Header), the 
Node/Link can be considered as Endpoints in SRv6 routing. On the other hand, 
such advertisement is useful for entities to determine specific services 
encoded in HbH options header can be deployed in a given path.

Q2: can you use the link color to compute paths?
In the above, I answered, taking advantage of this advertisement, the exact 
action taken by Node or Link to process HbH options header can be determined 
(defined in Action Flag field), which can be useful for traffic engineering. 
Hence, such advertisement is not only used to determine whether the HbH options 
header supported by Node/Link or not. But the link color cannot exactly 
indicate the exact action.

More questions and comments are welcome.

Thanks,
Yali


-Original Message-
From: wangyali [mailto:wangyal...@huawei.com] 
Sent: Thursday, October 29, 2020 9:20 PM
To: lsr@ietf.org
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hello WG,

Considering the Hop-by-Hop Options header has been used for IOAM 
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method 
[I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the 
Hop-by-Hop Options header is only examined and processed if it is explicitly 
configured. In this case, nodes may be configured to ignore the Hop-by-Hop 
Options header, drop packets containing a Hop-by-Hop Options header, or assign 
packets containing a Hop-by-Hop Options header to a slow processing path. Thus, 
the performance measurement does not account for all links and nodes along a 
path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, 
which gravely deteriorates network performance.

Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop 
Options header processing action at node and link granularity. Such 
advertisement is useful for entities (e.g., the centralized controller) to 
gather each router's processing action for achieving the computation of TE 
paths that be able to support a specific service encoded in the Hop-by-Hop 
Options header. 

Please let us know your opinion. Questions and comments are very welcome.

Best regards,
Yali


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou ; Huzhibo ; 
wangyali 
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt


A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.

Name:   draft-wang-lsr-hbh-process
Revision:   00
Title:  IGP Extensions for Advertising Hop-by-Hop Options Header 
Processing Action
Document date:  2020-10-29
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt
Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process
Htmlized:   https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00


Abstract:
   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  Such advertisements
   allow entities (e.g., centralized controllers) to determine whether
   the Hop-by-Hop Options header and specific services can be supported
   in a given network.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00

[wangyali]

Hi Huaimo,

Thanks a lot for your review and comments. Please find my responses in line 
[Yali].

Best regards,
Yali

From: Huaimo Chen [mailto:huaimo.c...@futurewei.com]
Sent: Tuesday, November 17, 2020 12:59 PM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hi Authors,

The draft describes extensions to IGP for a node to distribute
capabilities of its links. The capability information about
all the links in a network may be used by another entity such as
a controller.

I have following comments:
1). In section 3, the capabilities of a link or a node is represented
by "Processing Action" (refer to Fig. 1 in the draft). Why do you include
"Max EH Len" in the "Processing Action"? It is not a capability.
[Yali] Since the length of IPv6 Extensions Header exceeds the maximum limit the 
node is capable to process, the packets carried extensions header should be 
discarded. Hence, "Max EH Len" defined in this draft is used to indicate the 
maximum length of extension header supported by the Node or Link. So I think it 
is also a capability.
What's your thoughts?

2). The text describing the format of "Processing Action"
below seems not consistent with the format in Fig. 1.
"... processing action formed of
a tuple of a 1-octet Extension Header Options identifier and 8-bit
Processing Action Flag."
The above text occurs twice in the draft.
[Yali] I'll fix this in the next version. It should be "...processing action 
formed of a tuple of a 8-bit Processing Action Flag, a 16-bit Services Flag, 
and a one-octet Maximum Extensions Header Length."

3). It seems that using word "signal" or "signaling" in the draft
is not good. It is better to use another word and rephrase the related text.
[Yali] I will replace word "signal" by "advertise" and also revise the related 
text. Is it correct?

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
wangyali mailto:wangyal...@huawei.com>>
Sent: Thursday, October 29, 2020 9:19 AM
To: lsr@ietf.org mailto:lsr@ietf.org>>
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hello WG,

Considering the Hop-by-Hop Options header has been used for IOAM 
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method 
[I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the 
Hop-by-Hop Options header is only examined and processed if it is explicitly 
configured. In this case, nodes may be configured to ignore the Hop-by-Hop 
Options header, drop packets containing a Hop-by-Hop Options header, or assign 
packets containing a Hop-by-Hop Options header to a slow processing path. Thus, 
the performance measurement does not account for all links and nodes along a 
path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, 
which gravely deteriorates network performance.

Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop 
Options header processing action at node and link granularity. Such 
advertisement is useful for entities (e.g., the centralized controller) to 
gather each router's processing action for achieving the computation of TE 
paths that be able to support a specific service encoded in the Hop-by-Hop 
Options header.

Please let us know your opinion. Questions and comments are very welcome.

Best regards,
Yali


-Original Message-
From: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
Huzhibo mailto:huzh...@huawei.com>>; wangyali 
mailto:wangyal...@huawei.com>>
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt


A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.

Name:   draft-wang-lsr-hbh-process
Revision:   00
Title:  IGP Extensions for Advertising Hop-by-Hop Options Header 
Processing Action
Document date:  2020-10-29
Group:  Individual Submission
Pages:  10
URL:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-hbh-process-00.txt&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=tvJH5rnR%2BAj%2FxTTaxxbKJ6z%2F1OKAog3QdCCJnJkKB2I%3D&reserved=0
Status: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-hbh-process%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Wt7W0PL8HGI1EaPK8

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:

>
>
>Robert, I believe the original intention was related to having the data
>> plane converge quickly when summarization is used and flip so traffic
>> converges from the Active ABR to the Backup ABR.
>>
>
> I do not buy this use case. Flooding within the area is fast such that
> both ABRs will get the same info. As mentioned before there is no practical
> use of PUA for making any routing or fwd decision on which ABR to use. If
> your ABRs are not connected with min redundancy this draft is a worst patch
> ever to work around such a design.
>

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track
the component prefixes and in case where component is down and traffic is
still forwarded to the ABR and dropped.  The other more important use case
is when links are down within the area and the area is partitioned and so
one ABR has all component prefixes however other ABR is missing half the
component prefixes.  So since the ABR will by default advertise the summary
as long as their is one component UP the summary is still advertised.  So
this use case is severely impacting as now you have an ECMP path to the
other area for the summary via the two ABRs and you drop half your
traffic.  So now with PUA the problem is fixed and the PUA is sent and now
traffic is only sent to the ABR that has the component prefixes.

>
> Please present us a picture indicating before and after ABRs behaviour.
>

 Gyan> will do

>
>However PUA can be used in the absence of area segmentation within a
>> single area when a link or node fails to converge the data plane quickly by
>> sending PUA for the backup path so the active path.
>>
>
> If there is no area segmentation then there is no summaries. So what are
> we missing in the first place ?
>

Gyan> Sorry I am stating that PUA feature can also be used intra area
where if a link or node goes down to improve data plane convergence.

>
>
>
>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA
>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
>> convergence is well into sub second.  So for Intra area convergence with
>> all the optimizations mentioned I am not sure how much faster the data
>> plane will converge with PUA.
>>
>
> Even without any of the above listed chain of acronymous things will
> generally work well intra-area without PUAs.
>

Gyan> Agreed which is why I mentioned the BGP next hop self use case if
I could figure out how PUA could help there that would be a major benefit
of PUA.

>
> Thx,
> R.
>
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

   Robert, I believe the original intention was related to having the data
> plane converge quickly when summarization is used and flip so traffic
> converges from the Active ABR to the Backup ABR.
>

I do not buy this use case. Flooding within the area is fast such that both
ABRs will get the same info. As mentioned before there is no practical use
of PUA for making any routing or fwd decision on which ABR to use. If your
ABRs are not connected with min redundancy this draft is a worst patch ever
to work around such a design.

Please present us a picture indicating before and after ABRs behaviour.

   However PUA can be used in the absence of area segmentation within a
> single area when a link or node fails to converge the data plane quickly by
> sending PUA for the backup path so the active path.
>

If there is no area segmentation then there is no summaries. So what are we
missing in the first place ?



> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA &
> RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
> convergence is well into sub second.  So for Intra area convergence with
> all the optimizations mentioned I am not sure how much faster the data
> plane will converge with PUA.
>

Even without any of the above listed chain of acronymous things will
generally work well intra-area without PUAs.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

On Tue, Nov 17, 2020 at 3:06 AM Robert Raszuk  wrote:

>
> Moreover it seems that it will just also prevent any local protection to
>> locally bypass the failed destination.
>>
>> *[WAJ] No, It will trigger the local protection instead, not prevent.*
>>
>>
> You missed my point.
>
> I am talking about *local* protection in a sense of adjacent node(s) to
> the PE/ASBR which failed. *Local* to the failure.
>
> You are talking about *local* protection on ingress to the network. Let's
> focus on this:
>
> Q1 - You are installing a /dev/null route in a router. That means that any
> packet sent to this destination will be dropped. How is this of any
> protection ?
>
> Q2 - What you may be actually trying to say is that by installing such PUA
> into RIB you will via RIB let know those clients (ex: BGP) which track this
> route that it is gone and that their possibly best path is no longer valid.
> Sure that is one way to share such information between IGP and BGP. But
> this needs to be described in the document that this is your intention.
> Otherwise when you say you are installing a drop route in RIB & FIB I am
> not sure how helpful that is (well other then transiently relaxing the
> network to drop some traffic few router hops away).
>

   Robert, I believe the original intention was related to having the data
plane converge quickly when summarization is used and flip so traffic
converges from the Active ABR to the Backup ABR.

   However PUA can be used in the absence of area segmentation within a
single area when a link or node fails to converge the data plane quickly by
sending PUA for the backup path so the active path.

With the IGP tuned with BFD fast detection on ISIS or OSPF links and
LFA & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks
the convergence is well into sub second.  So for Intra area convergence
with all the optimizations mentioned I am not sure how much faster the data
plane will converge with PUA.

The  one use case I had mentioned to you in the past a while back is
related to BGP PIC core convergence which I mentioned during the
presentation as you brought up BGP next hop convergence as a use case on
the ML.  So in cases where you run BGP PIC edge and have the pre programmed
backup path best-external add-paths advertised backup paths you are set,
however with BGP PIC core prefix independent convergence with the H-FIB
next hop rib convergence - with next-hop-self rewrite to the loopback, the
loopback never goes down so that does impact iBGP path PIC core
convergence.  So a workaround is to not do next hop self and so when link
goes down its detected and that fixes the issue.  Downside is you now have
a massive LFIB FEC binding database if you have tons of customer edges.  So
I think PUA could help for this but I was trying to connect the dots and I
think there is something missing but maybe we can figure out how PUA can be
leveraged to fix the PIC Core convergence.  I am assuming that is what you
meant on the ML with next hop tracking convergence would be the obvious use
case for PUA.  So the tricky part here is you you can send a PUA when your
PE-CE link goes down and now your H-FIB IGP forwarding plane would now
converge immediately on the alternate PUA path, however you still have
next-hop-self rewrite happening to the loopback which is still Up.  So even
though PUA fixed the Core IGP detection of the PE-CE link failure, it did
not fix the next hop self rewrite to the loopback which is always Up.  I
guess there would be still an improvement with data plane convergence for
the PE-CE with the PUA being sent to converge the BGP next hop when "next
hop self" is not used.  It would be nice if there was some way to make PUA
fix the next-hop-self rewrite to loopback to improve PIC core convergence.
You would need a flag to tie the loopback to the PE-CE connected interfaces
state to be tracked.  I believe you wrote a draft way back that fixes that
issue but was never adopted I believe.  I would have to dig up on ML to
find it.

>
> Thx,
> R.
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>


-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

> Moreover it seems that it will just also prevent any local protection to
> locally bypass the failed destination.
>
> *[WAJ] No, It will trigger the local protection instead, not prevent.*
>
>
You missed my point.

I am talking about *local* protection in a sense of adjacent node(s) to the
PE/ASBR which failed. *Local* to the failure.

You are talking about *local* protection on ingress to the network. Let's
focus on this:

Q1 - You are installing a /dev/null route in a router. That means that any
packet sent to this destination will be dropped. How is this of any
protection ?

Q2 - What you may be actually trying to say is that by installing such PUA
into RIB you will via RIB let know those clients (ex: BGP) which track this
route that it is gone and that their possibly best path is no longer valid.
Sure that is one way to share such information between IGP and BGP. But
this needs to be described in the document that this is your intention.
Otherwise when you say you are installing a drop route in RIB & FIB I am
not sure how helpful that is (well other then transiently relaxing the
network to drop some traffic few router hops away).

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Thanks Acee for the feedback.

We will add more detail to the use cases.

Gyan

On Mon, Nov 16, 2020 at 3:45 AM Acee Lindem (acee)  wrote:

> When the PUA use cases were presented today in the LSR meeting, I made the
> comment that the RIB interactions for each use case would be different and
> needed to be specified.
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From: *Robert Raszuk 
> *Date: *Monday, November 16, 2020 at 3:25 AM
> *To: *Aijun Wang 
> *Cc: *Jeff Tantsura , lsr , Acee
> Lindem 
> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
> I was not bringing RIFT's negative routies example as something inherently
> negative. I was just pointing it out to illustrate that today's data plane
> lookup does not really support "if does not match" checks.
>
> *[WAJ] In data plane, the device do still the “match” check, not “does not
> match” check.  When the router receives the PUA information, it will
> install one black hole route for a short time.*
>
>
>
> So your idea is that you install route for unreachable prefix to /dev/null
> ?
>
>
>
> And how would that help connectivity restoration ?
>
>
>
> Moreover it seems that it will just also prevent any local protection to
> locally bypass the failed destination.
>
>
>
> Bottom line is that I agree with one problem statement. However IMHO
> described actions upon reception of PUA are questionable at best.
>
>
>
> Cheers,
> R.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>


-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr