Subject: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Oct 2021 19:05:42 +0000

Speaking as WG Chairs:

The authors of “Prefix Unreachable Announcement” have requested an adoption. The crux of the draft is to signal unreachability of a prefix across OSPF or IS-IS areas when area summarization is employed and prefix is summarised. We also have “IS-IS and OSPF Extension for Event Notification” which can be used to address the same use case. The drafts take radically different approaches to the problem and the authors of both drafts do not wish to converge on the other draft’s method so it is understandable that merging the drafts really isn’t an option.

Before an adoption call for either draft, I’d like to ask the WG:

  1.  Is this a problem that needs to be solved in the IGPs? The use case offered in both drafts is signaling unreachability of a BGP peer. Could this better solved with a different mechanism  (e.g., BFD) rather than flooding this negative reachability information across the entire IGP domain?
  2.  Assuming we do want to take on negative advertisement in the IGP, what are the technical merits and/or detriments of the two approaches?

We’ll reserve any further discussion to “WG member” comments on the two approaches.

Thanks,
Acee and Chris

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Oct 2021 21:51:43 +0200

Hi Acee,

I would like to make a comment on your point #1.

You said:

"Is this a problem that needs to be solved in the IGPs? The use case
offered in both drafts is signaling unreachability of a BGP peer. Could
this better solved with a different mechanism  (e.g., BFD)..."

That is not a very precise statement - simply due to the fact that to
signal anything in any solution requires a peer to detect giben network
event.

In both cases such an event will likely be detected using BFD (if we are
talking about unreachability of a BGP or IGP peer).

Neither of the drafts mentioned here replaces local BFD detection.

I do infer from your message that what was meant to be said was an
alternative to support BFD sessions across areas/levels for example between
PEs. Clearly that would get very ugly very quickly.

However IMO the natural signalling in this case would be to use BGP itself.
Here are the few reasons:

* detection time will be the same for IGP or BGP
* only those network elements which keep "interesting" state will be
notified
* speed of withdraw can be argued to be as fast as IGP flooding especially
considering hierarchical IGP design
* withdraws can be easily aggregated (when we loose PE single prefix can be
used to remove all paths advertised by given PE)
* withdraws can be injected as the next hop /32 or /128 prefixes and remote
next hop validation can be set not to consider less specific routes to
resolve next hops (in any case due to MPLS data plane host routes are used
in many networks today to resolve BGP service routes to LSPs in spite of
efforts to make this more scalable).

Only when we prove that BGP based solutions are not sufficient we
could/should explore moving such signalling to IGPs.

Kind regards,
R.

On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Speaking as WG Chairs:
>
>
>
> The authors of “Prefix Unreachable Announcement” have requested an
> adoption. The crux of the draft is to signal unreachability of a prefix
> across OSPF or IS-IS areas when area summarization is employed and prefix
> is summarised. We also have “IS-IS and OSPF Extension for Event
> Notification” which can be used to address the same use case. The drafts
> take radically different approaches to the problem and the authors of both
> drafts do not wish to converge on the other draft’s method so it is
> understandable that merging the drafts really isn’t an option.
>
>
>
>    1. Is this a problem that needs to be solved in the IGPs? The use case
>    offered in both drafts is signaling unreachability of a BGP peer. Could
>    this better solved with a different mechanism  (e.g., BFD) rather than
>    flooding this negative reachability information across the entire IGP
>    domain?
>    2. Assuming we do want to take on negative advertisement in the IGP,
>    what are the technical merits and/or detriments of the two approaches?
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Oct 2021 20:15:07 +0000

Speaking as WG member:

Hi Robert,

I think you are envisioning a use case beyond section 3 in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ where the unreachable prefix is the loopback of PE. If not, I don’t  see your concern with BFD between the PEs. What are you worried about? Scaling?

In any case, we both agree that flooding this unreachability information to everyone in the IGP domain is possibly not the best way to solve the problem.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, October 12, 2021 at 3:52 PM
To: "Acee Lindem (acee)" <acee=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Acee,

You said:

"Is this a problem that needs to be solved in the IGPs? The use case offered in both drafts is signaling unreachability of a BGP peer. Could this better solved with a different mechanism  (e.g., BFD)..."

That is not a very precise statement - simply due to the fact that to signal anything in any solution requires a peer to detect giben network event.

In both cases such an event will likely be detected using BFD (if we are talking about unreachability of a BGP or IGP peer).

I do infer from your message that what was meant to be said was an alternative to support BFD sessions across areas/levels for example between PEs. Clearly that would get very ugly very quickly.

However IMO the natural signalling in this case would be to use BGP itself. Here are the few reasons:

* detection time will be the same for IGP or BGP
* only those network elements which keep "interesting" state will be notified
* speed of withdraw can be argued to be as fast as IGP flooding especially considering hierarchical IGP design
* withdraws can be easily aggregated (when we loose PE single prefix can be used to remove all paths advertised by given PE)
* withdraws can be injected as the next hop /32 or /128 prefixes and remote next hop validation can be set not to consider less specific routes to resolve next hops (in any case due to MPLS data plane host routes are used in many networks today to resolve BGP service routes to LSPs in spite of efforts to make this more scalable).

Only when we prove that BGP based solutions are not sufficient we could/should explore moving such signalling to IGPs.

Kind regards,
R.

On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG Chairs:

Thanks,
Acee and Chris

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Oct 2021 22:27:29 +0200

Hi,

> What are you worried about? Scaling?

Yes if we were to establish BFD sessions between say 1000 PEs then each PE
would need to handle such a number of BFD sessions (as long as at least one
prefix comes with given PE's next hop).

As you know those would be multihop BFD sessions running on REs/RPs which
often are not hardware accelerated as p2p BFD with line card offloading.

Then honestly it is not obvious if in such case BFD adds real value as
compared to ICMP or UDP next hop periodic probing (as part of next hop
periodic reachability validation).

Thx,
Robert

On Tue, Oct 12, 2021 at 10:15 PM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as WG member:
>
>
>
> Hi Robert,
>
>
>
> I think you are envisioning a use case beyond section 3 in
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> where the unreachable prefix is the loopback of PE. If not, I don’t  see
> your concern with BFD between the PEs. What are you worried about? Scaling?
>
>
>
> In any case, we both agree that flooding this unreachability information
> to everyone in the IGP domain is possibly not the best way to solve the
> problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Tuesday, October 12, 2021 at 3:52 PM
> *To: *"Acee Lindem (acee)" <acee=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and
> OSPF Extension for Event Notification"
>
>
>
> Hi Acee,
>
>
>
> * withdraws can be easily aggregated (when we loose PE single prefix can
> be used to remove all paths advertised by given PE)
>
> * withdraws can be injected as the next hop /32 or /128 prefixes and
> remote next hop validation can be set not to consider less specific routes
> to resolve next hops (in any case due to MPLS data plane host routes are
> used in many networks today to resolve BGP service routes to LSPs in spite
> of efforts to make this more scalable).
>
>
>
> 1.      Is this a problem that needs to be solved in the IGPs? The use
> case offered in both drafts is signaling unreachability of a BGP peer.
> Could this better solved with a different mechanism  (e.g., BFD) rather
> than flooding this negative reachability information across the entire IGP
> domain?
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Oct 2021 21:02:12 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Tuesday, October 12, 2021 at 4:27 PM
To: Acee Lindem <[email-masked]>
Cc: "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi,

> What are you worried about? Scaling?

Yes if we were to establish BFD sessions between say 1000 PEs then each PE would need to handle such a number of BFD sessions (as long as at least one prefix comes with given PE's next hop).

As you know those would be multihop BFD sessions running on REs/RPs which often are not hardware accelerated as p2p BFD with line card offloading.

Ok – I think BFD should be implement in the data plane like it is for SDWAN tunnels (at least on the data center routers). But that is a different discussion.

Then honestly it is not obvious if in such case BFD adds real value as compared to ICMP or UDP next hop periodic probing (as part of next hop periodic reachability validation).

Usage of BFD with protocols is standard. Alternatives would work as well. You should put your BGP solution out there as well.

Thanks,
Acee

Thx,
Robert

On Tue, Oct 12, 2021 at 10:15 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

Hi Robert,

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 12, 2021 at 3:52 PM
To: "Acee Lindem (acee)" <acee=[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Acee,

You said:

Kind regards,
R.

Thanks,
Acee and Chris

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Oct 2021 23:10:39 +0200

> You should put your BGP solution out there as well.

Well honestly I did not say anything new. All options I enumerated have
been described in public a long time ago.

Some vendors support those already for years.

Operators are free to select the best methods to design their BGP overlays
which fits to their scale and connectivity restoration requirements. IMO
what is missing is not protocol gaps, but proper configuration of already
available features.

Many thx,
Robert.

On Tue, Oct 12, 2021 at 11:02 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Tuesday, October 12, 2021 at 4:27 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"Acee Lindem (acee)" <acee=[email-masked]>, "
> [email-masked]" <[email-masked]>
> Ok – I think BFD should be implement in the data plane like it is for
> SDWAN tunnels (at least on the data center routers). But that is a
> different discussion.
>
>
>
>
>
> Usage of BFD with protocols is standard. Alternatives would work as well.
> You should put your BGP solution out there as well.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thx,
>
> Robert
>
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 13 Oct 2021 09:26:57 +0800

Hi, Robert:

Answers to your comments are inline below.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, October 13, 2021 3:52 AM
To: Acee Lindem (acee) <acee=[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Acee,

You said:  

[WAJ] No. Link or Node Failures are not detected via BFD within one IGP domain. It just rely on the normal IGP flooding procedures. Once the ABRs receive the updated LSA, they will make the calculation and find the missing prefixes.

[WAJ] Deploy such mechanisms can replace the BFD for BGP configuration between PEs that located in different IGP domains.

[WAJ] How the BGP peer be detected that the peer has been unreachable? Via BFD for BGP?

[WAJ] It is the ABR’s summarization action hides the unreachable prefixes, then BGP peers located in different IGP domains can’t know the failure as quickly as IGP within the same domain.

[WAJ] To be more accurate, your above statement should be   【* only those network elements which keep "interesting" state will act upon the PUA messages.】

[WAJ] When we let ABR send the PUA messages, not hide them, the speed of withdraw can certainly be accelerated.

[WAJ] This is the effects PUA mechanism. when the BGP peer receives the PUA message that includes the PE itself, all the path advertised by the given PE can certainly be removed.

[WAJ]This the effect of PUA mechanism.

[WAJ] Do the above responses prove the BGP based solution are not sufficient?

Kind regards,

R.

 

 

 

On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> > wrote:

Speaking as WG Chairs: 

Thanks,
Acee and Chris

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

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 13 Oct 2021 09:41:17 +0800

Hi, Acee:

Thanks for you to initiate this discussion. Some responses for your questions are the followings:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, October 13, 2021 3:06 AM
To: [email-masked]
Subject: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Speaking as WG Chairs: 

[WAJ] Actually, such mechanism can also be used in other scenarios, for example, the tunnel endpoint detection etc.  We have also compared the PUA solution with BFD before and all we know that BFD requires many configuration overheads and also the burden of process on the participated routers.   BFD is actually one “pull” mechanism, it is not efficient as the “push” mechanism that proposed in these two drafts.

[WAJ] I thinks both approaches are acceptable. The vendor and operator can select either of them to solve the mentioned problem.

Thanks,
Acee and Chris

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 12 Oct 2021 19:43:13 -0700

Hi Aijun,
could you help me  to understand the requirement for defect detection time
for the method you propose? Single seconds? Tens of seconds?

Regards,
Greg

On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email-masked]> wrote:

> *From:* [email-masked] <[email-masked]> *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, October 13, 2021 3:52 AM
> *To:* Acee Lindem (acee) <acee=[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and
> *[WAJ] No. Link or Node Failures are not detected via BFD within one IGP
> domain. It just rely on the normal IGP flooding procedures. Once the ABRs
> receive the updated LSA, they will make the calculation and find the
> missing prefixes.*
>
>
>
> *[WAJ] Deploy such mechanisms can replace the BFD for BGP configuration
> between PEs that located in different IGP domains.*
>
>
>
> *[WAJ] How the BGP peer be detected that the peer has been unreachable?
> Via BFD for BGP?*
>
>
>
> *[WAJ] It is the ABR’s summarization action hides the unreachable
> prefixes, then BGP peers located in different IGP domains can’t know the
> failure as quickly as IGP within the same domain.*
>
>
>
> *[WAJ] To be more accurate, your above statement should be   **【* only
> those network elements which keep "interesting" state will act upon the PUA
> messages.】*
>
>
>
> *[WAJ] When we let ABR send the PUA messages, not hide them, the speed of
> withdraw can certainly be accelerated.*
>
>
>
> *[WAJ] This is the effects PUA mechanism. when the BGP peer receives the
> PUA message that includes the PE itself, all the path advertised by the
> given PE can certainly be removed.*
>
> *[WAJ]This the effect of PUA mechanism.*
>
>
>
> *[WAJ] Do the above responses prove the BGP based solution are not
> sufficient?*
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 13 Oct 2021 12:06:32 +0800

Hi, Greg:

The defect detection time should be same as the IGP flooding speed. It can achieve such goals via the PUA mechanism.

Or else, we must depends on other mechanism, such as BFD, which requires configuration overhead, and the process pressure especially when the timer is decreased in multi-hop BFD mode.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Greg Mirsky
Sent: Wednesday, October 13, 2021 10:43 AM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; Robert Raszuk <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Aijun,

could you help me  to understand the requirement for defect detection time for the method you propose? Single seconds? Tens of seconds?

Regards,

Greg

On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Wednesday, October 13, 2021 3:52 AM
To: Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Acee,

You said:  

Kind regards,

R.

 

 

 

Speaking as WG Chairs: 

Thanks,
Acee and Chris

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Wed, 13 Oct 2021 07:34:37 +0000

Hi Acee,

This solution is mainly used for the Edge PEs.  In most cases, the performance of the edge PE is poor. We may not have so much BFD resources to do detection.
When we do aggregate for remote PE’s locator route, the Edge PE will only detect remote PE’s failure on BGP neighbors’ down and route’s withdraw.
So I think use negative advertisement to found remote PE’s failure is necessary.

Regards,
Haibo

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, October 13, 2021 3:06 AM
To: [email-masked]
Subject: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Speaking as WG Chairs:

Thanks,
Acee and Chris

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Oct 2021 10:42:13 +0200

Hi Acee,

On 12/10/2021 21:05, Acee Lindem (acee) wrote:
> across OSPF or IS-IS areas when area summarization is employed and 
> prefix is summarised. We also have “IS-IS and OSPF Extension for Event 
> take radically different approaches to the problem and the authors of 
> both drafts do not wish to converge on the other draft’s method so it is 

just for the record, I offered authors of "Prefix Unreachable 
Announcement" co-authorship on "Event notification" draft, arguing the 
the event base solution addresses their use case in a more elegant and 
scalable way. They decided to push their idea regardless.

>     offered in both drafts is signaling unreachability of a BGP peer.
>     Could this better solved with a different mechanism  (e.g., BFD)
>     rather than flooding this negative reachability information across
>     the entire IGP domain?

we have looked at the various options. None of the existing ones would 
fit the large scale deployment with summarization in place. Using BFD 
end to end to track reachability between PEs simply does not scale.

Some people believe this should be solved by BGP, but it is important to 
realize that while the problem statement at the moment is primarily 
targeted for egress PE reachability loss detection for BGP, the 
mechanism proposed is generic enough and can be used to track the peer 
reachablity loss for other cases (e.g GRE endpoint, etc) that do not 
involve BGP.

We went even further and explored the option to use completely out of 
band mechanism that do not involve any existing protocols.

Simply, the advantage of using IGP is that it follows the existing MPLS 
model, where the endpoint reachability is provided by IGPs. Operators 
are familiar with IGPs and know how to operate them.

On top of the above, IGP event notification can find other use cases in 
the future, the mechanism defined in draft is generic enough.

>     what are the technical merits and/or detriments of the two approaches? 

we have listed some requirements at:

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3

 From my perspective the solution should be optimal in terms of amount 
of data and state that needs to be maintained, ideally separated from 
the traditional LS data. I also believe that having a generic mechanism 
to distribute events has it own merits.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 12:23:41 +0200

Hi Peter,

In your example of GRE between PEs .. what is the purpose of this GRE ?
Isn't it to connect services advertised via BGP ?

In any case perhaps one size does not fit all. Maybe some networks can use
BGP signalling (withdraws), maybe other will like to see bad even
notification in IGPs.

Considering that node down events are extremely rare in practice (what
really happens much more often is link down/flap or node brownouts) this
solution will not harm the network even if flooded blind everywhere.

So my email was not to discourage progressing
draft-ppsenak-lsr-igp-event-notification-00
<https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3>
it
was more triggered by Acee's question to use BFD end to end as an
alternative.

>From those two drafts I agree that your proposal is more generic and at the
WG adoption call (if ever happens) you have my vote ;).

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 12:24:35 +0200

*> [WAJ] No. Link or Node Failures are not detected via BFD within one IGP
domain.*

What makes you say so ?

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Oct 2021 12:31:51 +0200

Hi Robert,

> Isn't it to connect services advertised via BGP ?

not necessarily.

There are providers that provide L2/L3 connectivity through their 
backbone using some sort of L3 tunnel, with no BGP at all.

> 
> In any case perhaps one size does not fit all. Maybe some networks can 
> use BGP signalling (withdraws), maybe other will like to see bad even 
> notification in IGPs.
> 

agree. In some cases though a link down or an SRLG down event may result 
in a node becoming unreachable. Efficiency is still required.

> <https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3> it 
>  From those two drafts I agree that your proposal is more generic and at 
> the WG adoption call (if ever happens) you have my vote ;).

good :)

thanks,
Peter

> 
> Cheers,
> R.
> 
> On Wed, Oct 13, 2021 at 10:42 AM Peter Psenak 
> <ppsenak=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi Acee,
> 
>      > We’ll reserve any further discussion to “WG member” comments on
>     the two
>      > approaches.
>      >
>      > Thanks,
>      > Acee and Chris
>      >
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 06:36:59 -0700

Hi Aijun,
thank you for your quick response. Please find my further notes in-line
below tagged GIM>>.

Regards,
Greg

On Tue, Oct 12, 2021 at 9:06 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Greg:
>
>
>
> The defect detection time should be same as the IGP flooding speed.
>
GIM>>  I think that that would not be the only component that contributes
to the overall detection delay. An instance of IGP needs something to
detect the local failure that triggers the LSA update and flooding. AFAIK,
if that process is based on IGP, it is in the single-second, at the
minimum, range. As a result, that time will determine overall time to
detect and propagate the notification of a defect in the IGP domain.

> It can achieve such goals via the PUA mechanism.
>
> Or else, we must depends on other mechanism, such as BFD, which requires
> configuration overhead, and the process pressure especially when the timer
> is decreased in multi-hop BFD mode.
>
GIM>> I agree that using an additional protocol increases complexity. On
another hand, if the IGP-based solution cannot guarantee the required
defect detection time, it seems that an operator is more likely to choose
the BFD-based solution.

>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Greg
> Mirsky
> *Sent:* Wednesday, October 13, 2021 10:43 AM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]; Robert Raszuk <[email-masked]>; Acee Lindem (acee)
> <acee=[email-masked]>
> *[WAJ] It is the ABR**’s summarization action hides the unreachable

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Oct 2021 15:41:36 +0200

Greg,

On 13/10/2021 15:36, Greg Mirsky wrote:
> On Tue, Oct 12, 2021 at 9:06 PM Aijun Wang <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi, Greg:____
> 
>     __ __
> 
> GIM>>  I think that that would not be the only component that 
> contributes to the overall detection delay. An instance of IGP needs 
> something to detect the local failure that triggers the LSA update and 
> flooding. AFAIK, if that process is based on IGP, it is in the 
> single-second, at the minimum, range. As a result, that time will 
> determine overall time to detect and propagate the notification of a 
> defect in the IGP domain.
> 
>     It can achieve such goals via the PUA mechanism.____
> 
>     Or else, we must depends on other mechanism, such as BFD, which
>     requires configuration overhead, and the process pressure especially
>     when the timer is decreased in multi-hop BFD mode.
> 
> defect detection time, it seems that an operator is more likely to 
> choose the BFD-based solution.

the requirement here is not for sub-50ms, it has never been the case 
with BGP PIC anyway. The target is sub-second which is doable with IGP 
based solution.

thanks,
Peter

> 
>     ____
> 
>     __ __
> 
>     __ __
> 
>     Best Regards____
> 
>     __ __
> 
>     Aijun Wang____
> 
>     China Telecom____
> 
>     __ __
> 
>     *From:[email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>> *On Behalf Of
>     *Greg Mirsky
>     *To:* Aijun Wang <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee)
>     <acee=[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS
>     and OSPF Extension for Event Notification"____
> 
>     __ __
> 
>     Hi Aijun,____
> 
>     could you help me  to understand the requirement for defect
>     detection time for the method you propose? Single seconds? Tens of
>     seconds?____
> 
>     __ __
> 
>     Regards,____
> 
>     Greg____
> 
>     __ __
> 
>     On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Hi, Robert:____
> 
>         ____
> 
>         Answers to your comments are inline below.____
> 
>         ____
> 
>         ____
> 
>         Best Regards____
> 
>         ____
> 
>         Aijun Wang____
> 
>         China Telecom____
> 
>         ____
> 
>         *From:[email-masked] <mailto:[email-masked]>
>         <[email-masked] <mailto:[email-masked]>> *On Behalf
>         Of *Robert Raszuk
>         *To:* Acee Lindem (acee) <acee=[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and
>         "IS-IS and OSPF Extension for Event Notification"____
> 
>         ____
> 
>         Hi Acee,____
> 
>         ____
> 
>         I would like to make a comment on your point #1. ____
> 
>         ____
> 
>         You said: ____
> 
>         ____
> 
>         "Is this a problem that needs to be solved in the IGPs? The use
>         case offered in both drafts is signaling unreachability of a BGP
>         peer. Could this better solved with a different mechanism
>           (e.g., BFD)..."____
> 
>         ____
> 
>         That is not a very precise statement - simply due to the fact
>         that to signal anything in any solution requires a peer to
>         detect giben network event. ____
> 
>         ____
> 
>         In both cases such an event will likely be detected using BFD
>         (if we are talking about unreachability of a BGP or IGP peer). ____
> 
>         */[WAJ] No. Link or Node Failures are not detected via BFD
>         within one IGP domain. It just rely on the normal IGP flooding
>         procedures. Once the ABRs receive the updated LSA, they will
>         make the calculation and find the missing prefixes./*____
> 
>         ____
> 
>         Neither of the drafts mentioned here replaces local BFD
>         detection. ____
> 
>         */[WAJ] Deploy such mechanisms can replace the BFD for BGP
>         configuration between PEs that located in different IGP
>         domains./*____
> 
>         ____
> 
>         I do infer from your message that what was meant to be said was
>         an alternative to support BFD sessions across areas/levels for
>         example between PEs. Clearly that would get very ugly very
>         quickly. ____
> 
>         ____
> 
>         However IMO the natural signalling in this case would be to use
>         BGP itself. Here are the few reasons: ____
> 
>         */[WAJ] How the BGP peer be detected that the peer has been
>         unreachable? Via BFD for BGP?/*____
> 
>         ____
> 
>         * detection time will be the same for IGP or BGP____
> 
>         */[WAJ] It is the ABR/**/’s summarization action hides the
>         unreachable prefixes, then BGP peers located in different IGP
>         domains can’t know the failure as quickly as IGP within the same
>         domain./*____
> 
>         ____
> 
>         * only those network elements which keep "interesting" state
>         will be notified____
> 
>         */[WAJ] To be more accurate, your above statement should be /**
>         /【* only those network elements which keep "interesting" state
>         will _act upon the PUA messages.__】_/*____
> 
>         ____
> 
>         * speed of withdraw can be argued to be as fast as IGP flooding
>         especially considering hierarchical IGP design ____
> 
>         */[WAJ] When we let ABR send the PUA messages, not hide them,
>         the speed of withdraw can certainly be accelerated./*____
> 
>         ____
> 
>         * withdraws can be easily aggregated (when we loose PE single
>         prefix can be used to remove all paths advertised by given PE)____
> 
>         */[WAJ] This is the effects PUA mechanism. when the BGP peer
>         receives the PUA message that includes the PE itself, all the
>         path advertised by the given PE can certainly be removed./*____
> 
>         * withdraws can be injected as the next hop /32 or /128 prefixes
>         and remote next hop validation can be set not to consider less
>         specific routes to resolve next hops (in any case due to MPLS
>         data plane host routes are used in many networks today to
>         resolve BGP service routes to LSPs in spite of efforts to make
>         this more scalable). ____
> 
>         */[WAJ]This the effect of PUA mechanism./*____
> 
>         ____
> 
>         Only when we prove that BGP based solutions are not sufficient
>         we could/should explore moving such signalling to IGPs. ____
> 
>         */[WAJ] Do the above responses prove the BGP based solution are
>         not sufficient?/*____
> 
>         ____
> 
>         Kind regards,____
> 
>         R.____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee)
>         <acee=[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
>             Speaking as WG Chairs: ____
> 
>             ____
> 
>             The authors of “Prefix Unreachable Announcement”have
>             requested an adoption. The crux of the draft is to signal
>             unreachability of a prefix across OSPF or IS-IS areas when
>             area summarization is employed and prefix is summarised. We
>             also have “IS-IS and OSPF Extension for Event
>             Notification”which can be used to address the same use case.
>             The drafts take radically different approaches to the
>             problem and the authors of both drafts do not wish to
>             converge on the other draft’s method so it is understandable
>             that merging the drafts really isn’t an option. ____
> 
>             ____
> 
>             Before an adoption call for either draft, I’d like to ask
>             the WG: ____
> 
>             ____
> 
>             1.Is this a problem that needs to be solved in the IGPs? The
>             use case offered in both drafts is signaling unreachability
>             of a BGP peer. Could this better solved with a different
>             mechanism  (e.g., BFD) rather than flooding this negative
>             reachability information across the entire IGP domain?____
> 
>             2.Assuming we do want to take on negative advertisement in
>             the IGP, what are the technical merits and/or detriments of
>             the two approaches? ____
> 
>             ____
> 
>             We’ll reserve any further discussion to “WG member”comments
>             on the two approaches.____
> 
>             ____
> 
>             Thanks,
>             Acee and Chris____
> 
>             ____
> 
>             ____
> 
>             https://www.ietf.org/mailman/listinfo/lsr____
> 
>         https://www.ietf.org/mailman/listinfo/lsr____
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 15:51:07 +0200

Dear Aijun,

Let me reply to other your other comments ...

> receive the updated LSA, they will make the calculation and find the

Normal IGP flooding must be triggered by detection of failure. In this case
node failure. If you intend to rely on IGP keepalives to detect the adj
down  from the node immediately connected to the PE(s) then clearly we have
different network connectivity restoration goals in place.

> between PEs that located in different IGP domains.*

I have never seen deployment of multihop BFD between PEs located in
different IGP domains.

> *[WAJ] How the BGP peer be detected that the peer has been unreachable?

Yes. Just like adjacent IGP peer will.

> failure as quickly as IGP within the same domain.*

Not true. BGP is a recursive protocol and already propagate remote next
hops in number of deployments. For example RFC3107 but not only.

> those network elements which keep "interesting" state will act upon the PUA

Nope. I meant that if I have decent size network with 10 areas and use
L3VPNs. Only those PEs in some areas will get withdraws which keep routes
from given src PEs. No other PE (nor P for that matter) will get any
control message about it.

> withdraw can certainly be accelerated.*

The withdraw propagation via 2 or 3 RRs IMO will be much faster then IGP
flooding via say 20 IGP nodes.

> given PE can certainly be removed.*

As stated this is pretty infrequent that PE goes down. Sure there are also
poorly designed networks with PEs attached over single link to the P nodes.
Contrary to this if focus on using BGP for such signalling not only we can
propagate node down but also any other failure affecting subset of services
hosted by such PEs.

> *[WAJ]This the effect of PUA mechanism.*

Not sure you got the point, but yes both methods IGP or BGP can be used. It
is just a matter of right judgement of pros and cons of each. And as I
wrote to Peter maybe one size does not fit all.

> *[WAJ] Do the above responses prove the BGP based solution are not

No. They are sufficient if supported by the network elements and deployed
correctly.

Cheers
R.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 09:19:09 -0700

Hi Peter,
I am familiar with solutions that guarantee sub-second defect detection in
an IGP domain. But these are based on the single-hop BFD. Do you mean that
a standard-based IGP without any BFD involvement can guarantee sub-second
detection of a failure in the domain? Would be interesting to learn about
that and I much appreciate any reference or a pointer.

Regards,
Greg

On Wed, Oct 13, 2021 at 6:41 AM Peter Psenak <[email-masked]> wrote:

> >     <acee=[email-masked] <mailto:[email-masked]
> >>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Oct 2021 16:48:41 +0000

Hi Peter, 

See inline. 

On 10/13/21, 4:42 AM, "Peter Psenak" <ppsenak=[email-masked]> wrote:

    Hi Acee,

One solution to this problem would have definitely been better. 

It seems to me that scaling of BFD should be "roughly" proportional to BGP session scaling but I seem to be in the minority. My opinion is based on SDWAN tunnel scaling, where BFD is used implicitly in our solution. How many other PEs does a BGP edge PE maximally peer with? 
Thanks,
Acee

    thanks,
    Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 19:15:49 +0200

> How many other PEs does a BGP edge PE maximally peer with?

Typically on IBGP side you will see 2-4 peers. Those are RRs.

Due to no autodiscovery of BGP sessions no many people do iBGP full mesh
between PEs.

Best,
R.

On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> case
> It seems to me that scaling of BFD should be "roughly" proportional to BGP
> session scaling but I seem to be in the minority. My opinion is based on
> SDWAN tunnel scaling, where BFD is used implicitly in our solution. How
> many other PEs does a BGP edge PE maximally peer with?
> Thanks,
> Acee
>
>
>     > We’ll reserve any further discussion to “WG member” comments on the
> two
>     > approaches.
>     >
>     > Thanks,
>     > Acee and Chris
>     >
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Oct 2021 17:20:20 +0000

From: Robert Raszuk <[email-masked]>
Date: Wednesday, October 13, 2021 at 1:16 PM
To: Acee Lindem <[email-masked]>
Cc: "Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Due to no autodiscovery of BGP sessions no many people do iBGP full mesh between PEs.

Then in this case, how many PE next-hops in an IBGP domain? I guess the RR scenario is where we are BFD limited…

Thanks,
Acee

Best,
R.

On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Hi Peter,

See inline.

On 10/13/21, 4:42 AM, "Peter Psenak" <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:

    Hi Acee,

    thanks,
    Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 19:24:52 +0200

Below ..

> *Date: *Wednesday, October 13, 2021 at 1:16 PM
> *Cc: *"Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <
> [email-masked]>

I have seen networks from 10s of PEs to 1000s of PEs. Of course when we
talk about say 100-200 PEs there are usually in multiple areas/domains, but
this is not the hard rule. They can be in a flat one too.

Not sure what you mean that we are BFD limited in RR case.

First it is the RR which may trigger the withdrawal.

Second infrastructure routes do not need to follow and be congruent with
service routes topology.

Thx,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 13 Oct 2021 10:28:32 -0700

Number of BGP peers isn’t representative here, classical deployments would have a number of RR’s to circumvent full mesh. What counts is the total number of PEs (next-hops) that originate the prefix that is locally imported (needs to be tracked). For further optimization, only multihomed prefixes are of interest (if a PE that has a CE that is single-homed to goes away, there’s no convergence).
A possible solution (discussed a number of times here) is to extract next-hop from an UPDATE, compare to the list of next-hops already learnt and establish multi-hop BFD session according to the business logic.
Modern mid-high end platforms can easily run a 1000 MH BFD session @1sec

Cheers,
Jeff

> On Oct 13, 2021, at 10:16, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
>> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) <acee=[email-masked]> wrote:
>> Hi Peter, 
>> 
>> See inline. 
>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 19:37:25 +0200

Jeff,

The point is about the right architecture, not a brute force method.

Do you see it as elegant to bombard 1000s PE with a probe every second ? I
do not. Especially considering that PEs rarely go down.

And that should be compared with even driven notification.

BGP: - Local BFD detect the failure in say 100-200 ms
          - propagation via RR is max in ms (I recall in Cisco we measured
this to actually by much faster on dedicated control plane only RRs)
          - then interesting PE (RT filter) can be notified about the
failure in less then 300 ms - be conservative 500 ms.

IGP:  - Local BFD detect the failure in say 100-200 ms
         - Failure get's flooded to local ABR(s)
         - LSA/LSP get's generated and flooded hop by hop via say 20 hops
all over the network via say core and additional area.
          Maybe the entire process takes also 500 ms ... I do not have any
estimate here, but I am sure folks on LSR do.

In any case the event driven notification is a much better choice.

Kind regards,
R.

On Wed, Oct 13, 2021 at 7:28 PM Jeff Tantsura <[email-masked]>
wrote:

> Number of BGP peers isn’t representative here, classical deployments would
> have a number of RR’s to circumvent full mesh. What counts is the total
> number of PEs (next-hops) that originate the prefix that is locally
> imported (needs to be tracked). For further optimization, only multihomed
> prefixes are of interest (if a PE that has a CE that is single-homed to
> goes away, there’s no convergence).
> A possible solution (discussed a number of times here) is to extract
> next-hop from an UPDATE, compare to the list of next-hops already learnt
> and establish multi-hop BFD session according to the business logic.
>> It seems to me that scaling of BFD should be "roughly" proportional to
>> BGP session scaling but I seem to be in the minority. My opinion is based
>> on SDWAN tunnel scaling, where BFD is used implicitly in our solution. How

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Oct 2021 18:43:54 +0000

This thread is becoming "diverse".
We are trying to talk about many different solutions (IGP, BGP, BFD) - all of which may be useful and certainly are not mutually exclusive.

If we can agree that an IGP solution is useful, then we can use this thread to set a direction for the IGP solution - which seems to me to be something we should do independent of whether the other solutions are also pursued.

With that in mind,  here is my input on the IGP solutions:

PUA
-------

For me, the solution has two major drawbacks:

1)It tries to repurpose an existing (and fundamental) Reachability Advertisement into an UnReachability advertisement under certain conditions

The interoperability risks associated with this make me very reluctant to go down this path.
And the use of the same advertisement to indicate Reachability and Unreachability is IMO highly undesirable.

2)The withdrawal of the "Unreachability Advertisement" after some delay (which is necessary)  remains problematic despite the authors attempts to address thus

Event Notification
------------------------

This avoids the drawbacks of PUA and is flexible enough to handle future and unforeseen types of notifications. 

I would like to extend the offer already made by Peter to the authors of PUA to join us and work on the Event Notification draft.
The authors of PUA certainly deserve credit for raising awareness of the problem space and it would be good to have them working with us on a single IGP solution.

But PUA is not an alternative that I can support.

    Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, October 13, 2021 9:49 AM
> To: Peter Psenak <ppsenak=[email-masked]>; [email-masked]
> On 10/13/21, 4:42 AM, "Peter Psenak"
> <ppsenak=[email-masked]> wrote:
> 
>     Hi Acee,
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Oct 2021 21:04:21 +0200

Hi Jeff,

On 13/10/2021 19:28, Jeff Tantsura wrote:
> Number of BGP peers isn’t representative here, classical deployments 
> would have a number of RR’s to circumvent full mesh. What counts is the 
> total number of PEs (next-hops) that originate the prefix that is 
> locally imported (needs to be tracked). For further optimization, only 
> multihomed prefixes are of interest (if a PE that has a CE that is 
> single-homed to goes away, there’s no convergence).

sure, but do you really want to maintain a full mesh of MH BFD sessions 
between all PEs? I guess no.

thanks,
Peter

>> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) 
>>     <ppsenak=[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi Acee,
>>
>>         > Speaking as WG Chairs:
>>         >
>>         > The authors of “Prefix Unreachable Announcement” have
>>     requested an
>>         > adoption. The crux of the draft is to signal unreachability
>>     of a prefix
>>         > across OSPF or IS-IS areas when area summarization is
>>     employed and
>>         > prefix is summarised. We also have “IS-IS and OSPF Extension
>>     for Event
>>         > Notification” which can be used to address the same use
>>     case. The drafts
>>         > take radically different approaches to the problem and the
>>     authors of
>>         > both drafts do not wish to converge on the other draft’s
>>     method so it is
>>         > understandable that merging the drafts really isn’t an option.
>>
>>         > Before an adoption call for either draft, I’d like to ask
>>     the WG:
>>         >
>>         >  1. Is this a problem that needs to be solved in the IGPs?
>>     The use case
>>         >     offered in both drafts is signaling unreachability of a
>>     BGP peer.
>>         >     Could this better solved with a different mechanism 
>>     (e.g., BFD)
>>         >     rather than flooding this negative reachability
>>     information across
>>         >     the entire IGP domain?
>>
>>     It seems to me that scaling of BFD should be "roughly"
>>     proportional to BGP session scaling but I seem to be in the
>>     minority. My opinion is based on SDWAN tunnel scaling, where BFD
>>     is used implicitly in our solution. How many other PEs does a BGP
>>     edge PE maximally peer with?
>>     Thanks,
>>     Acee
>>
>>
>>         >  2. Assuming we do want to take on negative advertisement in
>>     the IGP,
>>         >     what are the technical merits and/or detriments of the
>>     two approaches?
>>
>>         >
>>         > We’ll reserve any further discussion to “WG member” comments
>>     on the two
>>         > approaches.
>>         >
>>         > Thanks,
>>         > Acee and Chris
>>         >
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 21:52:17 +0200

Hi Les,

> If we can agree that an IGP solution is useful, then we can use this
thread to
> set a direction for the IGP solution

I think this thread aimed to answer both of those questions hence some
comments.

But even if we assume that Event Flooding via IGP have a valid use case
(regardless if PE down is a right one) I am a bit concerned with adding
this new such functionality to existing IGPs. Event flooding with IGPs (the
way I see similar opaque information and how they got into other protocols)
may quickly become a huge burden to them.

Yes I see you are already proposing separation of LSDBs via FSP Scope
Specific LSDB - but is this enough ?

How about redistribution between IGP instances across domains ?

So assuming we want to do that new event transport how about running new
instance of link state dedicated for event flooding ? It seems (no matter
how we look at it) that there are many differences in operational models
for state advertisement vs events in an IGP.

Moreover such new instance could only be spanning PEs and if we do it right
it can be based on a pub/sub model.

Thx,
R.

On Wed, Oct 13, 2021 at 8:44 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> We are trying to talk about many different solutions (IGP, BGP, BFD) - all
> of which may be useful and certainly are not mutually exclusive.
>
> If we can agree that an IGP solution is useful, then we can use this
> thread to set a direction for the IGP solution - which seems to me to be
> something we should do independent of whether the other solutions are also
> pursued.
>
> 1)It tries to repurpose an existing (and fundamental) Reachability
> Advertisement into an UnReachability advertisement under certain conditions
>
> And the use of the same advertisement to indicate Reachability and
> Unreachability is IMO highly undesirable.
>
> 2)The withdrawal of the "Unreachability Advertisement" after some delay
> (which is necessary)  remains problematic despite the authors attempts to
> address thus
>
> Event Notification
> ------------------------
>
> I would like to extend the offer already made by Peter to the authors of
> PUA to join us and work on the Event Notification draft.
> The authors of PUA certainly deserve credit for raising awareness of the
> problem space and it would be good to have them working with us on a single
> IGP solution.
>
> BGP

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Oct 2021 20:37:36 +0000

Robert –

Inline.

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, October 13, 2021 12:52 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les,

> If we can agree that an IGP solution is useful, then we can use this thread to

I think this thread aimed to answer both of those questions hence some comments.

[LES:] Yes – and all discussion is very relevant. I am suggesting that maybe it would be more productive to have separate threads/solution.
I am of the opinion that we need an IGP solution – but I believe a BGP based solution could also prove useful.

But even if we assume that Event Flooding via IGP have a valid use case (regardless if PE down is a right one) I am a bit concerned with adding this new such functionality to existing IGPs. Event flooding with IGPs (the way I see similar opaque information and how they got into other protocols) may quickly become a huge burden to them.

Yes I see you are already proposing separation of LSDBs via FSP Scope Specific LSDB - but is this enough ?

How about redistribution between IGP instances across domains ?
[LES:] Redistribution is a local behavior which has never been subject to standardization.
Certainly, an implementation could choose to support this.

So assuming we want to do that new event transport how about running new instance of link state dedicated for event flooding ? It seems (no matter how we look at it) that there are many differences in operational models for state advertisement vs events in an IGP.

Moreover such new instance could only be spanning PEs and if we do it right it can be based on a pub/sub model.

[LES:] So, you know I am a staunch advocate of restricting what the IGPs advertise.
In this use case, however, I think use of the “routing instance” is appropriate.
It is the fact that the IGP is advertising the summary address that makes the advertisement of the loss of reachability to specific nodes covered by that summary by the same IGP instance an attractive choice.
The nodes to whom this information needs to be flooded are the same nodes which have received the summary address advertisement.

I can imagine that for other uses cases, event notification might well be done by a separate instance.
We can certainly add a discussion of the use of a separate instance into the event notification draft.

   Les

Thx,
R.

On Wed, Oct 13, 2021 at 8:44 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
This thread is becoming "diverse".
We are trying to talk about many different solutions (IGP, BGP, BFD) - all of which may be useful and certainly are not mutually exclusive.

PUA
-------

Event Notification
------------------------

    Les

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
> To: Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:
>
>     Hi Acee,
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 13:45:26 -0700

Hi Les, et al.,
I've just read the draft-ppsenak-lsr-igp-event-notification. Event
notification is usually viewed as the function of the Fault Management OAM,
not of a control plane protocol. Thus, I find the idea of using an IGP
protocol to distribute event notifications troubling. One of my concerns is
with the ability to control the scope of who receives the notification.
Even though the proposal follows RFC 7356, it might still be too broad. In
my experience, usually only designated systems in a domain are to receive a
notification about the particular class of events. In fact,
a publish-subscribe model for event notification is seen as more suitable
than flooding. AFAIK, there are different solutions for publish-subscribe
event notifications using gRPC, Kafka, etc.

Regards,
Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 13 Oct 2021 13:51:15 -0700

Peter,

Not “ALL” but these that share a service (import each other routes).

I agree that this is a brute force solution that isn’t necessarily to win a beauty contest. However this is deployable and implementable.

Back to LSR scoop ;-) in general i agree with Les’ points

Cheers,
Jeff

> On Oct 13, 2021, at 12:04, Peter Psenak <[email-masked]> wrote:
> 
> Hi Jeff,
> 
> sure, but do you really want to maintain a full mesh of MH BFD sessions between all PEs? I guess no.
> 
> thanks,
> Peter
> 
>> Cheers,
>> Jeff
>>>> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>    Hi Peter,
>>> 
>>>    See inline.
>>> 
>>>        > We’ll reserve any further discussion to “WG member” comments
>>>    on the two
>>>        > approaches.
>>>        >
>>>        > Thanks,
>>>        > Acee and Chris
>>>        >
>>> 
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Oct 2021 22:57:27 +0200

Hi Les,

I agree with all you said except this:

*The nodes to whom this information needs to be flooded are the same nodes
which have received the summary address advertisement.*

I really do not think so. Only a subset of nodes which received IGP summary
route may need to know about the failures of nodes covered by such summary.
That's important to agree on.

That includes both P and PE routers. I would argue that in any real network
where some form of encapsulation is used for services no P router is
interested to know in holes summary information in the adjacent domains
(well unless you envision such holes to be converted to ACLs to blindly
drop traffic as early as possible :)

Then in many many networks PEs usually carry subset of services originating
in other PE's hence they careless in holes in any other PEs they do not
have active next hops for.

Cheers,
R.

On Wed, Oct 13, 2021 at 10:37 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, October 13, 2021 12:52 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; [email-masked]
> *[LES:] Yes – and all discussion is very relevant. I am suggesting that
> maybe it would be more productive to have separate threads/solution.*
>
> *I am of the opinion that we need an IGP solution – but I believe a BGP
> based solution could also prove useful.*
>
>
>
> *[LES:] Redistribution is a local behavior which has never been subject to
> standardization.*
>
> *Certainly, an implementation could choose to support this.*
>
>
>
> Moreover such new instance could only be spanning PEs and if we do it
> right it can be based on a pub/sub model.
>
>
>
> *[LES:] So, you know I am a staunch advocate of restricting what the IGPs
> advertise.*
>
> *In this use case, however, I think use of the “routing instance” is
> appropriate.*
>
> *It is the fact that the IGP is advertising the summary address that makes
> the advertisement of the loss of reachability to specific nodes covered by
> that summary by the same IGP instance an attractive choice.*
>
> *The nodes to whom this information needs to be flooded are the same nodes
> which have received the summary address advertisement.*
>
>
>
> *I can imagine that for other uses cases, event notification might well be
> done by a separate instance.*
>
> *We can certainly add a discussion of the use of a separate instance into
> the event notification draft.*
>
>
>
> *   Les*
>
>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Oct 2021 22:10:25 +0000

Speaking as a mere WG member...

Assuming that there are enough remote PEs that need this unreachability information and we want to use the IGPs for this, here is what I don't like about PUA (Les has taken away much of my thunder __): 

    1. Usage of the prefix-originator for unreachability notification requires that every router in the domain support the extension before it can be used. If a router don't support it and ignores the prefix-originator sub-TLV, it will actually prefer the advertising ABR (due to LPM) and blackhole the data. 
    2. The non-deterministic nature of the notification. Unreachability is advertised for any route that is subsumed by a range and become unreachable. Is this advertised forever if the route in question is taken out of service? What about a route that is mistakenly put into service - will we advertise unreachability forever? What if the PE is already unreachable when the ABR comes up - no reachability information will be advertised. 
    3. Like the event notification draft, the unreachability notification will trigger BGP reconvergence. Additionally, an ABR that has the route is supposed to advertise a more specific route. However, by the time this happens, BGP reconvergence should have already taken place. 
    4. The interaction of MAA and reachable prefixes could cause quite a bit of churn when there are oscillations. However, given 1-3, I don't think we'll have to worry about this. 

Thanks,
Acee

On 10/13/21, 2:44 PM, "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]> wrote:

    PUA
    -------

    Event Notification
    ------------------------

        Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Oct 2021 22:14:00 +0000

Greg –

The draft is introducing a new IGP mechanism to signal events.
That does not mean that it should be used for any and all event notifications.

We don’t discuss the latter point in any detail in the draft – but it is only V-00. 😊

The first use case (described in Section2) seems very appropriate for the IGP.

So, I agree with your point. We need to do a better job of describing appropriate use cases. But, if you are arguing that we should NEVER do this in the IGP then we are not in full agreement.

   Les

From: Lsr <[email-masked]> On Behalf Of Greg Mirsky
Sent: Wednesday, October 13, 2021 1:45 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: [email-masked]; Peter Psenak <ppsenak=[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les, et al.,
I've just read the draft-ppsenak-lsr-igp-event-notification. Event notification is usually viewed as the function of the Fault Management OAM, not of a control plane protocol. Thus, I find the idea of using an IGP protocol to distribute event notifications troubling. One of my concerns is with the ability to control the scope of who receives the notification. Even though the proposal follows RFC 7356, it might still be too broad. In my experience, usually only designated systems in a domain are to receive a notification about the particular class of events. In fact, a publish-subscribe model for event notification is seen as more suitable than flooding. AFAIK, there are different solutions for publish-subscribe event notifications using gRPC, Kafka, etc.

Regards,
Greg

On Wed, Oct 13, 2021 at 11:44 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
This thread is becoming "diverse".
We are trying to talk about many different solutions (IGP, BGP, BFD) - all of which may be useful and certainly are not mutually exclusive.

PUA
-------

Event Notification
------------------------

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Oct 2021 22:22:57 +0000

Robert –

You are (of course) right. But the question is whether it is worth the effort to define a specific flooding topology for this use case? If the answer to that is “yes”, then  I think a BGP solution would probably make more sense.
Alternatively, we could use a separate IGP instance for this use case. Nothing in the event notification draft precludes that. I do think, however, that it significantly raises the bar for deployment, and it may well be more practical to flood the info on the routing topology and let the nodes who can make use of the info use it and have the rest ignore it.

If this was expected to be a large amount of information and needed to be sent with great frequency, I think your preference might well make more sense – but for the given use case that amount/rate of traffic would be unusual.

   Les

Sent: Wednesday, October 13, 2021 1:57 PM

Hi Les,

I really do not think so. Only a subset of nodes which received IGP summary route may need to know about the failures of nodes covered by such summary. That's important to agree on.

That includes both P and PE routers. I would argue that in any real network where some form of encapsulation is used for services no P router is interested to know in holes summary information in the adjacent domains (well unless you envision such holes to be converted to ACLs to blindly drop traffic as early as possible :)

Then in many many networks PEs usually carry subset of services originating in other PE's hence they careless in holes in any other PEs they do not have active next hops for.

Cheers,
R.

On Wed, Oct 13, 2021 at 10:37 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Inline.

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 13, 2021 12:52 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les,

   Les

Thx,
R.

PUA
-------

Event Notification
------------------------

    Les

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 15:24:05 -0700

Hi Les,
thank you for your consideration of my note. No, I am not saying "never". I
agree with you that extending the discussion on the applicability of the
proposed solution is helpful. Looking forward to that.

Regards,
Greg

On Wed, Oct 13, 2021 at 3:14 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> So, I agree with your point. We need to do a better job of describing
> appropriate use cases. But, if you are arguing that we should NEVER do this
> in the IGP then we are not in full agreement.
>
>
>
>    Les
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * Greg Mirsky
> *Sent:* Wednesday, October 13, 2021 1:45 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
> *Cc:* [email-masked]; Peter Psenak <ppsenak=[email-masked]>;
> Acee Lindem (acee) <acee=[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Oct 2021 22:36:54 +0000

Speaking from the deepest, darkest depths of WG membership:

Again, assuming that putting this unreachability information in the IGPs is a good idea, here are the things I like an don't like about "IGP Event Notification"

I like the fact that it reflects the ephemeral context of a route becoming unreachable in that it only advertises the it once. I also like the fact that it uses separate PDUs to advertise the unreachability information. What I don't like about it is that it is a moderately radical change to the IGPs so we should be sure we really want to advertise this information there. Also, I think the extensions could benefit from a discussion of what happens if only a subset of the routers in the domain support it. One consideration, would be an hello level notification of whether these "pulses" are supported. 

Thanks,
Acee

On 10/13/21, 6:11 PM, "Lsr on behalf of Acee Lindem (acee)" <[email-masked] on behalf of acee=[email-masked]> wrote:

    Thanks,
    Acee

        PUA
        -------

        Event Notification
        ------------------------

            Les

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Oct 2021 00:40:24 +0200

Hi Les,

Indeed "for the given use case that amount/rate of traffic would be
unusual." that is completely right and that is why I said to Peter that I
will support this draft if it comes to WG adoption.

But what is the mechanism the gate will stop to only allow light event
notification like PE down events to ride on top of this ?

As you may know most required and missing feature is to carry
external peer's down events when we set next hop self. Today workaround is
to set external interfaces as passive and do propagate such transitions in
IGP as state for IPv4/v6 routes. For other address families which relay on
next-hop-self this is much more difficult and we use BGP for it.

I can already envision folks writing a two page draft adding interface ID
to BGP PATH_INFO and asking IGP to send such notifications all over as
events. Out of the sudden from a very innocent extension we can turn to a
monster feature as external interfaces do flap a lot.

But anyway - as you and all know I always endorse good innovation !

Cheers,
R.

On Thu, Oct 14, 2021 at 12:23 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> You are (of course) right. But the question is whether it is worth the
> effort to define a specific flooding topology for this use case? If the
> answer to that is “yes”, then  I think a BGP solution would probably make
> more sense.
>
> Alternatively, we could use a separate IGP instance for this use case.
> Nothing in the event notification draft precludes that. I do think,
> however, that it significantly raises the bar for deployment, and it may
> well be more practical to flood the info on the routing topology and let
> the nodes who can make use of the info use it and have the rest ignore it.
>
>
>
> If this was expected to be a large amount of information and needed to be
> sent with great frequency, I think your preference might well make more
> sense – but for the given use case that amount/rate of traffic would be
> unusual.
>
>
>
>    Les
>
>
>
>
>
> *Sent:* Wednesday, October 13, 2021 1:57 PM
> I really do not think so. Only a subset of nodes which received IGP
> summary route may need to know about the failures of nodes covered by such
> summary. That's important to agree on.
>
>
>
> That includes both P and PE routers. I would argue that in any real
> network where some form of encapsulation is used for services no P router
> is interested to know in holes summary information in the adjacent domains
> Then in many many networks PEs usually carry subset of services
> originating in other PE's hence they careless in holes in any other PEs
> they do not have active next hops for.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:37 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert –
>
>
>
> Inline.
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Oct 2021 22:46:29 +0000

Hi Greg,
One thing to consider here is that this is not E2E OAM notification. Based on the discussion of scale, there could be 1000+ remote PEs that need to know about the outage. Also, as Peter pointed out, the target audience is a proper audience of the IGP routers receiving the summary advertisement.
Thanks,
Acee

From: Greg Mirsky <[email-masked]>
Date: Wednesday, October 13, 2021 at 6:24 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les,
thank you for your consideration of my note. No, I am not saying "never". I agree with you that extending the discussion on the applicability of the proposed solution is helpful. Looking forward to that.

Regards,
Greg

On Wed, Oct 13, 2021 at 3:14 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Greg –

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: Wednesday, October 13, 2021 1:45 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les, et al.,

Regards,
Greg

PUA
-------

Event Notification
------------------------

    Les

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 20:38:18 -0400

Hi Greg

This draft would utilize the same IGP optimizations used today such as IGP
single hop BFD for core link failure detection tuning down to sub second.
Most modern routers LC’s are to process BFD control packet processing in
hardware.  We are assuming all typical optimizations are in utilized for
close to hitless convergence such as LFA, RLFA, BGP PIC etc.

Even with all the optimizations, we still need a method of tracking
component prefixes when summarization is employed in very large domains
carved up into many areas or levels.

The goal of the PUA and Event Notification draft is to be able to track the
component prefixes of ASBR summary advertisement in the use case of BGP
next hop attribute set to self loopback0 on each PE. With the PUA mechanism
a negative advertisement PUA is flooded to force the control plane to
converge when the PE goes down and loopback0 component prefix.  This same
mechanism of PUA component prefix tracking of a summary advertisement is
also done via the Event Notification draft IGP extension.

So an alternative has been proposed to use loopback to loopback multi hop
BFD to track the iBGP peering directly as a mechanism of tracking the same
component prefixes of a summary advertisement if the individual iBGP PE-RR
peering went down.  That would be more complicated and convoluted and maybe
not as scalable is the thought for large scale network with 1000s of PEs.

Kind Regards

Gyan

On Wed, Oct 13, 2021 at 12:07 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Greg:
>
>
>
> The defect detection time should be same as the IGP flooding speed. It can
> achieve such goals via the PUA mechanism.
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Oct 2021 17:47:59 -0700

Hi,

I’ve said it many times before, in many different venues: “BGP is not a dump truck!”.

Is the fact that I didn’t mention the IGPs taken as some indication that they are fair game?

No, the IGPs aren’t a dump truck either.

We have a clear, unambiguous way of signaling individual system outages already.  You advertise a loopback address as a /32 or /128.
If your host goes down, the address is no longer routable.  Done.

If this technique is not sufficient, then perhaps it doesn’t belong in routing.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 21:04:35 -0400

Hi Tony

This is a real world problem for large scale networks where an service
providers core network is broken up into OSPF areas or ISIS levels and each
PEs loopback BGP next hop attribute  for 1000s of PEs within an area are
summarized at the P router ASBR ISIS L1-2 router or OSPF ABR and the next
hop attribute loopback0 component prefix of the summary goes down.

So we need a mechanism to signal via PUA or event notification mechanism
that the component went down that is part of the summary to force
immediately control plane convergence to avoid black hole of traffic during
the failure.

Kind Regards

Gyan
On Wed, Oct 13, 2021 at 8:48 PM Tony Li <[email-masked]> wrote:

> We have a clear, unambiguous way of signaling individual system outages
> already.  You advertise a loopback address as a /32 or /128.
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 18:05:14 -0700

Hi Gyan,
thank you for the most detailed information. With the addition of the
single-hop BFD the puzzle is complete. Or almost complete. What I am
wondering, is the fact that a PE is likely to be a part of a mesh network
that provides more resilient service. As a result, a single BFD session
going down would not mean that the PE is disconnected from the network and
generating an update seems sub-optimal. I've likely missed how such a
scenario is handled in the drafts. Need to read more carefully.

Regards,
Greg

On Wed, Oct 13, 2021 at 5:38 PM Gyan Mishra <[email-masked]> wrote:

> The goal of the PUA and Event Notification draft is to be able to track
> the component prefixes of ASBR summary advertisement in the use case of BGP
>> The defect detection time should be same as the IGP flooding speed. It
>> can achieve such goals via the PUA mechanism.
>>
>> *Cc:* [email-masked]; Robert Raszuk <[email-masked]>; Acee Lindem
>> (acee) <acee=[email-masked]>
>> could you help me  to understand the requirement for defect detection
>> time for the method you propose? Single seconds? Tens of seconds?
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> especially considering hierarchical IGP design
>>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Oct 2021 10:50:10 +0800

Hi, Les:

Thanks for your invitation. We are considering how to merge our directions to the same aim.

The reason that we want to finalize the PUA solution is due to it has been discussed intensely on the previous IETF meetings and on the mail list.(we start the discussion on October 2019, two years passed, now in version 07) 
We have changed and updated the draft a lot to reflect the comments from the LSR experts, including the comments from you.
The use cases, solution procedures are almost finished, then we think it is time to start the adoption call for PUA draft.
For the remaining questions, we think we have plenty of time to solve it after the adopt

But for "IS-IS and OSPF Extension for Event Notification" draft, it just began the travel for the standardization activities.
I think it is one alternative solution to the PUA draft, but as we have seen the comments on the list, whether to open the gate for the event notification mechanism within IGP is needed to further intense discussion.
There may be some hidden problems has not been investigated for this direction.  

And, there is no any restriction within IETF that we should rely on one solution to solve the same problem. Think about how many solutions exist for the Traffic Engineering requirements? 
Even within LSR WG, we have flooding reduction, flooding reflection and TTZ solutions for the similar problems.

We have never mixed them for discussion and compare. There is seldom solutions can satisfy all our preferences. 

So, in conclusion, I recommend to standardize firstly the PUA draft, and then to discuss whether to open the gate for the event notification mechanism within IGP. 
Anyway, for the general solution, currently we have only the same use case in mind as that in PUA draft.

We are also kind to invite you, Peter, Acee to participate the PUA solution, to solve the problems that you are worrying. Other LSR experts(Tony Li, Greg, Robert, Jeff etc.) are also welcome
The design, implementation, deployment experiences of PUA mechanism can certainly give the guides for the more general solution for further notification event.
And, I still think PUA solution is the easiest way to solve the problem, I think all of your concerning points will emerge later in "IS-IS and OSPF Extension for Event Notification" draft.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, October 14, 2021 2:44 AM
To: Acee Lindem (acee) <acee=[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

PUA
-------

Event Notification
------------------------

    Les

> BGP session scaling but I seem to be in the minority. My opinion is 
> based on SDWAN tunnel scaling, where BFD is used implicitly in our 
> solution. How many other PEs does a BGP edge PE maximally peer with?
> Thanks,
> Acee
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 23:00:57 -0400

Hi Greg

PUA Section 5 really helps describe a primary use case for both PUA and
event notification draft, tracking of egress PE BGP next hop attribute
component prefixes that are part of a summary and I used the example of RFC
5283 MPLS LDP Inter-area extension LPM matching but can apply to any use
case even IP data plane or SRv6 forwarding plane improvements in
convergence.

Kind Regards

Gyan
On Wed, Oct 13, 2021 at 9:05 PM Greg Mirsky <[email-masked]> wrote:

>> This draft would utilize the same IGP optimizations used today such as
>> IGP single hop BFD for core link failure detection tuning down to sub
>> second.  Most modern routers LC’s are to process BFD control packet
>> processing in hardware.  We are assuming all typical optimizations are in
>> utilized for close to hitless convergence such as LFA, RLFA, BGP PIC etc.
>>
>>> *[WAJ] When we let ABR send the PUA messages, not hide them, the speed
>>> of withdraw can certainly be accelerated.*
>>>
>>>
>>>
>>> Notification” which can be used to address the same use case. The
>>> drafts take radically different approaches to the problem and the authors
>>> of both drafts do not wish to converge on the other draft’s method so
>>> it is understandable that merging the drafts really isn’t an option.
>>>
>>>
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Oct 2021 20:52:38 -0700

Hi Gyan,

I fully understand the request.

I still question whether it should be solved by routing.  This is not a path computation problem. It’s reachability and more significantly, liveness.

That really seems like it’s looking for a slightly different architectural tool.

Yours in IS-IS,
Tony

> On Oct 13, 2021, at 6:04 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Hi Tony 
> 
> This is a real world problem for large scale networks where an service providers core network is broken up into OSPF areas or ISIS levels and each PEs loopback BGP next hop attribute  for 1000s of PEs within an area are summarized at the P router ASBR ISIS L1-2 router or OSPF ABR and the next hop attribute loopback0 component prefix of the summary goes down.  
> 
> So we need a mechanism to signal via PUA or event notification mechanism that the component went down that is part of the summary to force immediately control plane convergence to avoid black hole of traffic during the failure. 
> 
> Kind Regards 
> 
> Gyan
> On Wed, Oct 13, 2021 at 8:48 PM Tony Li <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Hi,
> 
> 
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>
> -- 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Oct 2021 05:25:18 +0000

Aijun -

I appreciate the continued dialogue.

You no doubt remember that Peter and I discussed PUA with you and co-authors several times over the years (at your kind invitation)  - even before you had submitted the draft.
We raised the same concerns with you then that I have mentioned earlier in this thread.

None of the changes you have made have altered the basic mechanism that you use - so my objections remain the same. And that isn’t going to change...I don’t think PUA is a good solution.

The rest of your argument seems to be that we should move forward w the PUA solution just because the draft has been around for a long time. Sorry, that isn’t a valid argument.
Either the WG thinks PUA is good solution or it doesn't - that is the only basis on which a decision to adopt/not adopt should be made. The fact that you keep refreshing/updating the draft carries no weight.

   Les

> From: Lsr <[email-masked]> On Behalf Of Aijun Wang
> Sent: Wednesday, October 13, 2021 7:50 PM
> To: 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 'Acee
> Lindem (acee)' <acee=[email-masked]>; 'Peter Psenak'
> <ppsenak=[email-masked]>; [email-masked]
> The reason that we want to finalize the PUA solution is due to it has been
> discussed intensely on the previous IETF meetings and on the mail list.(we
> start the discussion on October 2019, two years passed, now in version 07)
> We have changed and updated the draft a lot to reflect the comments from
> the LSR experts, including the comments from you.
> The use cases, solution procedures are almost finished, then we think it is
> time to start the adoption call for PUA draft.
> But for "IS-IS and OSPF Extension for Event Notification" draft, it just began
> the travel for the standardization activities.
> I think it is one alternative solution to the PUA draft, but as we have seen the
> comments on the list, whether to open the gate for the event notification
> mechanism within IGP is needed to further intense discussion.
> And, there is no any restriction within IETF that we should rely on one
> solution to solve the same problem. Think about how many solutions exist
> for the Traffic Engineering requirements?
> We have never mixed them for discussion and compare. There is seldom
> solutions can satisfy all our preferences.
> 
> So, in conclusion, I recommend to standardize firstly the PUA draft, and then
> to discuss whether to open the gate for the event notification mechanism
> within IGP.
> We are also kind to invite you, Peter, Acee to participate the PUA solution, to
> solve the problems that you are worrying. Other LSR experts(Tony Li, Greg,
> Robert, Jeff etc.) are also welcome
> The design, implementation, deployment experiences of PUA mechanism
> can certainly give the guides for the more general solution for further
> notification event.
> And, I still think PUA solution is the easiest way to solve the problem, I think
> all of your concerning points will emerge later in "IS-IS and OSPF Extension
> for Event Notification" draft.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> To: Acee Lindem (acee) <acee=[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>; [email-masked]
> We are trying to talk about many different solutions (IGP, BGP, BFD) - all of
> which may be useful and certainly are not mutually exclusive.
> 
> set a direction for the IGP solution - which seems to me to be something we
> should do independent of whether the other solutions are also pursued.
> 
> I would like to extend the offer already made by Peter to the authors of PUA
> to join us and work on the Event Notification draft.
> problem space and it would be good to have them working with us on a
> single IGP solution.
> 
> drafts

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Oct 2021 05:36:36 +0000

Tony –

Given that IGPs provide the ability to advertise summaries (in the interest of scalability), I think it is reasonable to say that being able to advertise reachability changes of endpoints covered by the summary also can be considered as a legitimate use of the IGP.
IGPs certainly advertise reachability and do update those advertisements in response to liveness changes.
So, I don’t agree w your conclusion that this isn’t logically a routing protocol function.

It is fair for you to think the solution is good or bad – happy to hear more thoughts from you on that.  But I don’t think arguing that the routing protocol has no business being involved in this is on the mark.

   Les

From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, October 13, 2021 8:53 PM
To: Gyan Mishra <[email-masked]>
Cc: lsr <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Gyan,

Yours in IS-IS,
Tony

On Oct 13, 2021, at 6:04 PM, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony

Kind Regards

Gyan
On Wed, Oct 13, 2021 at 8:48 PM Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Tony

_______________________________________________
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: Tony Li <[email-masked]>
Date: Wed, 13 Oct 2021 22:50:33 -0700

Les,

If you’re advertising loopbacks that are outside of the summarized space, then you end up with reachability and liveness.  Yes, there’s a cost in scalability… it ain’t free.

Tony

> On Oct 13, 2021, at 10:36 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Tony –
>  
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of Tony Li
> To: Gyan Mishra <[email-masked] <mailto:[email-masked]>>
> Cc: lsr <[email-masked] <mailto:[email-masked]>>
> On Oct 13, 2021, at 6:04 PM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> Hi Tony 
>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Oct 2021 14:37:57 +0800

Hi, Tony:

Yes, we should find the least cost to solve the problem.

The mentioned failure prefixes/loopback will only be advertised under some conditions. The ABR should have such controls, as described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-7

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Thursday, October 14, 2021 1:51 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: lsr <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Les,

Tony

On Oct 13, 2021, at 10:36 PM, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> > wrote:

Tony –

   Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Tony Li
Sent: Wednesday, October 13, 2021 8:53 PM
To: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Cc: lsr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Gyan,

Yours in IS-IS,

Tony

On Oct 13, 2021, at 6:04 PM, Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Tony 

Kind Regards 

Gyan

On Wed, Oct 13, 2021 at 8:48 PM Tony Li <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Tony

-- 

Gyan Mishra

M 301 502-1347

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Oct 2021 09:22:14 +0200

Tony,

On 14/10/2021 07:50, Tony Li wrote:
> 
> Les,
> 
> If you’re advertising loopbacks that are outside of the summarized 
> space, then you end up with reachability and liveness.  Yes, there’s a 
> cost in scalability… it ain’t free.

the whole point is to summarize loopbacks of PE devices, so above would 
not help.

thanks,
Peter

> 
> Tony
> 
> 
>> On Oct 13, 2021, at 10:36 PM, Les Ginsberg (ginsberg) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Tony –
>> Given that IGPs provide the ability to advertise summaries (in the 
>> interest of scalability), I think it is reasonable to say that being 
>> able to advertise reachability changes of endpoints covered by the 
>> summary also can be considered as a legitimate use of the IGP.
>> IGPs certainly advertise reachability and do update those 
>> advertisements in response to liveness changes.
>> It is fair for you to think the solution is good or bad – happy to 
>> hear more thoughts from you on that.  But I don’t think arguing that 
>> the routing protocol has no business being involved in this is on the 
>> mark.
>>    Les
>> *From:*Lsr <[email-masked] <mailto:[email-masked]>>*On 
>> Behalf Of*Tony Li
>> *Sent:*Wednesday, October 13, 2021 8:53 PM
>> *To:*Gyan Mishra <[email-masked] <mailto:[email-masked]>>
>> *Cc:*lsr <[email-masked] <mailto:[email-masked]>>
>> *Subject:*Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and 
>> I still question whether it should be solved by routing.  This is not 
>> a path computation problem. It’s reachability and more significantly, 
>> liveness.
>>     This is a real world problem for large scale networks where an
>>     service providers core network is broken up into OSPF areas or
>>     ISIS levels and each PEs loopback BGP next hop attribute  for
>>     1000s of PEs within an area are summarized at the P router ASBR
>>     ISIS L1-2 router or OSPF ABR and the next hop attribute loopback0
>>     component prefix of the summary goes down.
>>     So we need a mechanism to signal via PUA or event notification
>>     mechanism that the component went down that is part of the summary
>>     to force immediately control plane convergence to avoid black hole
>>     of traffic during the failure.
>>     Kind Regards
>>     Gyan
>>         We have a clear, unambiguous way of signaling individual
>>         system outages already.  You advertise a loopback address as a
>>         /32 or /128.
>>     /Network Solutions Architect /
>>     /[email-masked] <mailto:[email-masked]>/
>>
>>     /M 301 502-1347/
>>
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Oct 2021 09:30:08 +0200

Greg,

On 13/10/2021 22:45, Greg Mirsky wrote:
> notification is usually viewed as the function of the Fault Management 
> OAM, not of a control plane protocol. Thus, I find the idea of using an 
> IGP protocol to distribute event notifications troubling. One of my 
> concerns is with the ability to control the scope of who receives the 
> notification. Even though the proposal follows RFC 7356, it might still 
> be too broad. In my experience, usually only designated systems in a 
> domain are to receive a notification about the particular class of 
> events. In fact, a publish-subscribe model for event notification is 
> seen as more suitable than flooding. AFAIK, there are different 
> solutions for publish-subscribe event notifications using gRPC, Kafka, etc.

sure, we have even tried something like that. We soon realized that to 
distribute the "publish-subscribe event notifications" between all PEs 
in a scalable, reliable and fast way you would need a some sort of 
distribution infra as doing full mesh is not going to work. And once you 
get to build that distribution infra you will end up defining a new 
protocol.

So while I appreciate your concern, we are not attempting to advertise 
any type of events in the IGPs. We limit it to the events related to the 
routing and path computation, which is what IGPs are used for.

thanks,
Peter

> 
> Regards,
> Greg
> 
> On Wed, Oct 13, 2021 at 11:44 AM Les Ginsberg (ginsberg) 
> <ginsberg=[email-masked] 
>     We are trying to talk about many different solutions (IGP, BGP, BFD)
>     - all of which may be useful and certainly are not mutually exclusive.
> 
>     thread to set a direction for the IGP solution - which seems to me
>     to be something we should do independent of whether the other
>     solutions are also pursued.
> 
>     2)The withdrawal of the "Unreachability Advertisement" after some
>     delay (which is necessary)  remains problematic despite the authors
>     attempts to address thus
> 
>     Event Notification
>     ------------------------
> 
>     This avoids the drawbacks of PUA and is flexible enough to handle
>     future and unforeseen types of notifications.
> 
>     I would like to extend the offer already made by Peter to the
>     authors of PUA to join us and work on the Event Notification draft.
>     The authors of PUA certainly deserve credit for raising awareness of
>     the problem space and it would be good to have them working with us
>     on a single IGP solution.
> 
>      > From: Lsr <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Acee Lindem (acee)
>      > To: Peter Psenak <ppsenak=[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>      > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS
>     and OSPF
>      > Extension for Event Notification"
>      >
>      > Hi Peter,
>      >
>      > See inline.
>      >
>      >     > prefix is summarised. We also have “IS-IS and OSPF
>     Extension for Event
>     proportional to BGP
>      >     >  2. Assuming we do want to take on negative advertisement
>     in the IGP,
>      >     >     what are the technical merits and/or detriments of the two
>      > approaches?
>      >
>      >     > We’ll reserve any further discussion to “WG member”
>     comments on the
>      > two
>      >     > approaches.
>      >     >
>      >     > Thanks,
>      >     > Acee and Chris
>      >     >
>      >
>      >

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Oct 2021 15:36:25 +0800

Hi, Les:

I know you are the main person that guards the improvement of IS-IS protocol, but the liveness of this protocol should be from various contributions. 
I admire your opinions, but think you should be more flexible to hear/adopt other options. 

What I worry is that do we need the seemed generalized solution to the one mentioned use case in current stage? I think the basis to approach this direction is not mature until now. 
Let's give you one example that you have developed(please do not angry):  https://datatracker.ietf.org/doc/html/rfc6823 (December 2010) describe the "GENINFO TLV" to transfer the application information within the ISIS, but until now, only one application ID(1 for TRILL) is defined out of the reserved 65535 values.
I will not expand the history and future of RFC6823. What I want to do is that we do not repeat its experiences.

One additional comments, the PUA draft has been updated based on the comments/suggestions from the LSR experts, it has passed several rounds reviews of the LSR WG members. 
We can focus to solve your remaining concerns later.

Let's first hear more opinions from other experts on the direction to solve this problem. We all agree it can and should be solved via IGP protocol. 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, October 14, 2021 1:25 PM
To: Aijun Wang <[email-masked]>; 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]>; 'Peter Psenak' <ppsenak=[email-masked]>; [email-masked]
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Aijun -

   Les

> To: 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 
> 'Acee Lindem (acee)' <acee=[email-masked]>; 'Peter Psenak'
> The reason that we want to finalize the PUA solution is due to it has 
> been discussed intensely on the previous IETF meetings and on the mail 
> list.(we start the discussion on October 2019, two years passed, now 
> in version 07) We have changed and updated the draft a lot to reflect 
> the comments from the LSR experts, including the comments from you.
> The use cases, solution procedures are almost finished, then we think 
> it is time to start the adoption call for PUA draft.
> But for "IS-IS and OSPF Extension for Event Notification" draft, it 
> just began the travel for the standardization activities.
> I think it is one alternative solution to the PUA draft, but as we 
> have seen the comments on the list, whether to open the gate for the 
> event notification mechanism within IGP is needed to further intense discussion.
> And, there is no any restriction within IETF that we should rely on 
> one solution to solve the same problem. Think about how many solutions 
> exist for the Traffic Engineering requirements?
> Even within LSR WG, we have flooding reduction, flooding reflection 
> and TTZ solutions for the similar problems.
> 
> So, in conclusion, I recommend to standardize firstly the PUA draft, 
> and then to discuss whether to open the gate for the event 
> notification mechanism within IGP.
> We are also kind to invite you, Peter, Acee to participate the PUA 
> solution, to solve the problems that you are worrying. Other LSR 
> experts(Tony Li, Greg, Robert, Jeff etc.) are also welcome The design, 
> implementation, deployment experiences of PUA mechanism can certainly 
> give the guides for the more general solution for further notification 
> event.
> And, I still think PUA solution is the easiest way to solve the 
> problem, I think all of your concerning points will emerge later in 
> "IS-IS and OSPF Extension for Event Notification" draft.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> We are trying to talk about many different solutions (IGP, BGP, BFD) - 
> all of which may be useful and certainly are not mutually exclusive.
> 
> thread to set a direction for the IGP solution - which seems to me to 
> be something we should do independent of whether the other solutions are also pursued.
> 
> I would like to extend the offer already made by Peter to the authors 
> of PUA to join us and work on the Event Notification draft.
> the problem space and it would be good to have them working with us on 
> a single IGP solution.
> 
> >     > The authors of “Prefix Unreachable Announcement” have 
> > requested
> an
> > It seems to me that scaling of BFD should be "roughly" proportional 
> > to BGP session scaling but I seem to be in the minority. My opinion 
> > is based on SDWAN tunnel scaling, where BFD is used implicitly in 
> > our solution. How many other PEs does a BGP edge PE maximally peer with?
> > Thanks,
> > Acee
> >
> >
> >     mechanism proposed is generic enough and can be used to track 
> > the
> peer

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Oct 2021 09:58:51 +0200

Hi Acee,

> I like the fact that it reflects the ephemeral context of a route becoming unreachable in that it only advertises the it once. I also like the fact that it uses separate PDUs to advertise the unrea…

yes, Event Notification is an innovative concept.

Given that the event notifications are optional in nature, it is 
sufficient for a subset of the routers to support it. Event 
notifications may be flooded only on a subset of the IGP topology. 
Obviously to get the full benefit, you would want all PEs to be part of 
it, but the incremental deployment is possible and fully functional.

And yes, similar to rfc7356, announcing the supported scopes for Pulse 
LSPs is possible.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Thu, 14 Oct 2021 05:26:03 -0400

> On Oct 14, 2021, at 1:25 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> 

I sort of got this feeling as well.

> Either the WG thinks PUA is good solution or it doesn't - that is the only basis on which a decision to adopt/not adopt should be made. The fact that you keep refreshing/updating the draft carries…

Speaking as a WG chair here -- this is spot on. Drafts may exist and be commented on by a WG for years, with the authors making edits they feel address some or all of those comments. The fact that the draft keeps being revised and resubmitted does not imply that it is somehow ready for adoption or that the WG is required to do so. It is not a guarantee that it will achieve standardization. It may be that through revision it gets there, and it may be that it doesn't. 

Consider that there are plenty of drafts that are submitted and adopted based on their first submission. Sometimes in very little time indeed -- this happens when there's an obvious problem that needs solving, the proposed solution is very good and everyone in the WG clearly agrees on it.

Thanks,
Chris.

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Oct 2021 17:57:50 +0800

Hi, Christian:

We all know these principles.
Don’t you realize there are some preferences existing?
Let's focus on the solutions analyzes.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Thursday, October 14, 2021 5:26 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: Aijun Wang <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Thanks,
Chris.

---

From: tom petch <[email-masked]>
Date: Thu, 14 Oct 2021 11:15:00 +0000

Top posting for a different topic

My ESP, one of the larger ones in the world, is classifying most of the LSR e-mails as junk.  Yes,  I have reported them as not junk but doubt if it will make a difference.

To me it is obvious that anything with that well known abbreviation that was coined by ISO for their IGP in the subject line is going to receive unfavourable treatment so it may be that while many are  responding there are others who like me have an  ESP who is busy filling their junk folder.

Equally if I send an e-mall with that abbreviation it goes into a black hole with no MDN nothirng

Tom Petch

ps perhaps this is the considered opinion of the ESP on the I-D:-)

________________________________________
From: Lsr <[email-masked]> on behalf of Acee Lindem (acee) <acee=[email-masked]>
Sent: 12 October 2021 20:05
To: [email-masked]

Speaking as WG Chairs:

The authors of “Prefix Unreachable Announcement” have requested an adoption. The crux of the draft is to signal unreachability of a prefix across OSPF or  areas when area summarization is employed and prefix is summarised. We also have “ and OSPF Extension for Event Notification” which can be used to address the same use case. The drafts take radically different approaches to the problem and the authors of both drafts do not wish to converge on the other draft’s method so it is understandable that merging the drafts really isn’t an option.

Thanks,
Acee and Chris

---

From: Christian Hopps <[email-masked]>
Date: Thu, 14 Oct 2021 08:13:48 -0400

Does it junk the mail if the one true and proper form is used: "IS-IS" (i.e., with the hyphen)? :)

Thanks,
Chris.

> On Oct 14, 2021, at 7:15 AM, tom petch <[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Oct 2021 15:06:33 +0000

Speaking as WG chair:

Agree totally with Chris here. 

Thanks,
Acee

    Thanks,
    Chris.

---

From: tom petch <[email-masked]>
Date: Thu, 14 Oct 2021 15:42:02 +0000

From: Christian Hopps <[email-masked]>
Sent: 14 October 2021 13:13

<tp>

Yes.  That is what the thread about Prefix unreachable that Acee kicked off has in the Subject:  and it has junked about 60 of those for me.  Of course they still exist, I just have to remember to look for them, whereas ones I send with that character string do not make it to the list although they are in the Sent folder.  Sometimes it seems to inspect the body and junk on the basis of that but clearly not in this case as I have received your e-mail.

It even junked an e-mail that I sent to another WG but I cannot see what it saw in that!

Tom Petch

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Oct 2021 16:23:29 +0000

Hey Tom, 
If you can't get this fixed, you know there are alternative Email services that you could use for IETF work. We're not going to change the protocol name... I'll make it a point to use "IS-IS" (with the hyphen) since that should be easier to get removed from your ESP's filters. 
Thanks,
Acee

On 10/14/21, 11:42 AM, "Lsr on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    <tp>

    Tom Petch

    Thanks,
    Chris.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Oct 2021 00:56:11 -0400

Hi Les & Peter

Thank you for the offer to join the Event Notification draft.  I agree the
Event Notification draft is an innovative solution to the problem statement
presented by PUA using a new pulse PDU.  I read through the draft and even
though it’s a major IGP change to add event notification, using the RFC
7346  Flood scope LSP for the FS PDU does make it a possible solution.

As the PUA draft originally presented the problem statement and solution,
could the draft be adopted and advanced as a problem statement draft
instead of a solutions draft if WG adoption of the PUA draft as it stands
 is not possible.

We have addressed the concerns mentioned on ML and during the last few
presentations of PUA, however the draft has not gained traction from a
solution side,  but had indeed spurred interest in the real world problem
space and finding of a possible  solution with the  now Event Notification
draft.

Few comments on the Event notification draft.

RFC 7346 defines ISIS flooding scope LSPs and the PDU type field in ISIS
PDU is encoded with 5 bit field yielding a maximum of 32 PDU types. In
order to minimize the need to introduce additional PDU types in the future
the new PDUs introduced in RFC 7346
allows for multiple flooding scopes to be associated with the same PDU.
Therefore if new flooding scopes are required the same PDUs can be utilized.

This Event Notification draft defines a new FS PDU type 8 IANA request.  So
it burns up PDU type of the maximum 32 available.   This maybe a concern
for future PDU types that LSR may want to use and is this a good use of
defining a new PDU type.

Section 4 states that all flood scopes are supported that FSP-LSP,
FSP-PSNP, however FSP-CSNP is not required due to FSP LSP not being
synchronized on adjacency establishment or GR.  So all flood scopes are not
supported however RFC 7346 states that all flood scopes must be supported
by all new PDUs.

Section 3 of RFC 7346 states that for all new PDUs that for new flood
scopes all 3 PDUs below are required.  The event notification draft states
the FS-CSNP is not required however per RFC 7346 it is required.

3 <https://datatracker.ietf.org/doc/html/rfc7356#section-3>.
Definition of New PDUs

   In support of new flooding scopes, the following new PDUs are
   required:

   o  Flooding Scope LSPs (FS-LSPs)

   o  Flooding Scope Complete Sequence Number PDUs (FS-CSNPs)

   o  Flooding Scope Partial Sequence Number PDUs (FS-PSNPs)

Section 4.2 of RFC 7346 states that synchronization of all FS-LSDBs is
required so FS-CNSP for all supported scopes must be sent when new
adjacency is formed per below. The event notification draft does not seem
to be following the requirements of the FS PDU being utilized.

4.2 <https://datatracker.ietf.org/doc/html/rfc7356#section-4.2>.
Operation on Point-to-Point Circuits

   When a new adjacency is formed, synchronization of all FS-LSDBs
   supported on that circuit is required; therefore, FS-CSNPs for all
   supported scopes MUST be sent when a new adjacency reaches the UP
   state.  The Send Receive Message (SRM) bit MUST be set for all
   FS-LSPs associated with the scopes supported on that circuit.
   Receipt of an FS-PSNP with the U bit equal to 1 indicates that the
   neighbor does not support that scope (although it does support FS
   PDUs).  This MUST cause the SRM bit to be cleared for all FS-LSPs
   with the matching scope, which are currently marked for flooding on
   that circuit.

The bottom of section 5 needs to clearly state how the SCRLP TLV that is
flooded by the ASBR and how all the internal routers within the area act on
the SCRLP TLV to force the control plane convergence onto the alternative
PE LPM or exact match FEC binding  or SRv6 node-sid destination.

That is exactly what the PUA does with the negative advertisement flood
which forces all the internal routers in that area that receives the ASBR
summary to set to bit bucket /dev/null any packets to the LPM thus forcing
the convergence to the alternative PE.  That is also why all the internal
routers in the area acting on the PUA require a code upgrade.

For the Event Notification to work the SCRLP TLV that is flooded somehow as
it’s a different scope LSDB different LS PDU, it somehow has to update the
instance MTID LSDB of LSP on the circuit.

It’s a bit more tricky then just that as the internal router have the
summary and traffic for the LSP is black holed on the ASBR doing the
summarization.

Somehow with the SCRLP TLV flooded to all internal routers, they have to
perform a special action just like the action on the PUA negative
advertisement, they have to force convergence so the internal routers in
the area treats the SCRLP TLV like a PUA negative advertisement and stops
using the summary route for the component prefix that is no longer
reachable.

   “When an IS-IS L1/L2 router or an IS-IS Autonomous Boundary Router
   (ASBR) is performing prefix summarization and it loses the
   reachability to one or more previously reachable component(s) of the
   summary-prefix inside the area or domain for which the summarization
   is done, it MAY originate the SCRLP TLV to inform routers in other
   areas or domains about such summary component-prefix reachability
   loss.

   An originator of the SCRLP TLV chooses to advertise it in FSP-LSP
   with L1 flooding scope and/or FSP-LSP with L2 flooding scope.

   The IS-IS SCRLP TLV MAY be leaked between levels on L1/L2 router,
   subject to local policy of such L1/L2 router.

   IS-IS SCRLP TLV MUST NOT be leaked inside the area if the summary
   prefix carried in IS-IS SCRLP TLV (Summary Prefix, Summ-Pfx Length)
   is advertised from such area by L1/L2 router.“

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Oct 2021 06:29:34 +0000

Gyan –

Your comments are lengthy – I will start with some general explanation.

I believe that you are confused about the hierarchy between PDUs types and scopes. If that were more clear to you, I believe many of your comments would no longer need to be made.

PDUs are a container for sending protocol information. Each PDU is associated with a specific scope and a specific flooding behavior.

Base IS-IS has always supported scopes – but they are limited to Level-1 and Level-2 – and the scope is bound to the PDU type.
When we wanted to introduce support for additional flooding scopes in RFC 7356, we could have simply extended the one-to-one mapping between a PDU type and a scope, but with the limited bits available for PDU type (5 bits) that could not scale.
So, we invented new PDU types (FS-LSP, FS-PSNP, FS-CSNP) that supported a scope field in the header of the PDU. Now we could support a large number of scopes w only three new PDU types.

It is important to note that the flooding behavior associated with the new PDU types defined by RFC 7356 is completely analogous to the base LSP, CSNP, PSNP PDU types. This is specified in RFC 7356.

In the event notification draft, we are defining two new PDU  types (FSP-LSP, FSP-PSNP). These new PDU types support scope in the same manner as their FS-xxx cousins from RFC7356.
However, the flooding behavior associated with the new FSP-xxx PDUs is significantly different.  This is discussed in https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.3
The PDU functionality specified in RFC 7356 does not apply to the new FSP-xxx PDUs. Therefore, suggesting that the lack of an FSP-CSNP is in violation of RFC 7356 is simply not correct.

You seem to suggest below that we shouldn’t have used new PDUs but rather should have used new scopes in the event notification draft. But this would not scale. As the flooding behavior for FSP-xxx PDUs is different, we would have to encode that in the scope in order to differentiate from RFC 7356 flooding behavior. That would have meant duplicating every currently defined scope (we are now up to 81 defined scopes (out of a possible 127) based on https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04#section-11.4 ).
using scope for this wouldn’t have scaled – and would have violated the current relationship hierarchy between PDU type and scope.

Some additional responses inline. If I did not specifically respond inline, please look to this introductory response for the answers.

From: Lsr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Thursday, October 14, 2021 9:56 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: [email-masked]; Peter Psenak <ppsenak=[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Les & Peter

Thank you for the offer to join the Event Notification draft.  I agree the Event Notification draft is an innovative solution to the problem statement presented by PUA using a new pulse PDU.  I read through the draft and even though it’s a major IGP change to add event notification, using the RFC 7346  Flood scope LSP for the FS PDU does make it a possible solution.

As the PUA draft originally presented the problem statement and solution, could the draft be adopted and advanced as a problem statement draft instead of a solutions draft if WG adoption of the PUA draft as it stands  is not possible.

[LES:] You are asking me to comment on a draft which does not yet exist – which doesn’t seem fair. 😊
I will say that it isn’t clear to me why, in this particular case, we would need two documents (problem statement and protocol extensions). Historically one document has sufficed for both in many cases.
But, this is a separate question which belongs in a separate thread – if need arises.

We have addressed the concerns mentioned on ML and during the last few presentations of PUA, however the draft has not gained traction from a solution side,  but had indeed spurred interest in the real world problem space and finding of a possible  solution with the  now Event Notification draft.

RFC 7346 defines ISIS flooding scope LSPs and the PDU type field in ISIS PDU is encoded with 5 bit field yielding a maximum of 32 PDU types. In order to minimize the need to introduce additional PDU types in the future the new PDUs introduced in RFC 7346
allows for multiple flooding scopes to be associated with the same PDU.  Therefore if new flooding scopes are required the same PDUs can be utilized.

This Event Notification draft defines a new FS PDU type 8 IANA request.  So it burns up PDU type of the maximum 32 available.   This maybe a concern for future PDU types that LSR may want to use and is this a good use of defining a new PDU type.

[LES:] I have explained above why using new PDUs was chosen. In addition to what I stated above, I would add that you might want to take a look at https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04. This introduces even more new PDU types (7 new ones I believe) – but the good news is it also extends PDU type to an 8 bit field (the 3 MSBs were Reserved and never used for anything – so this is possible). 😊
The same document also introduces lots more scopes.

Section 4 states that all flood scopes are supported that FSP-LSP, FSP-PSNP, however FSP-CSNP is not required due to FSP LSP not being synchronized on adjacency establishment or GR.  So all flood scopes are not supported however RFC 7346 states that all flood scopes must be supported by all new PDUs.

Section 3 of RFC 7346 states that for all new PDUs that for new flood scopes all 3 PDUs below are required.  The event notification draft states the FS-CSNP is not required however per RFC 7346 it is required.

3<https://datatracker.ietf.org/doc/html/rfc7356#section-3>.  Definition of New PDUs

   required:

Section 4.2 of RFC 7346 states that synchronization of all FS-LSDBs is required so FS-CNSP for all supported scopes must be sent when new adjacency is formed per below. The event notification draft does not seem to be following the requirements of the FS PDU being utilized.

4.2<https://datatracker.ietf.org/doc/html/rfc7356#section-4.2>.  Operation on Point-to-Point Circuits

   that circuit.

The bottom of section 5 needs to clearly state how the SCRLP TLV that is flooded by the ASBR and how all the internal routers within the area act on the SCRLP TLV to force the control plane convergence onto the alternative PE LPM or exact match FEC binding  or SRv6 node-sid destination.

[LES:] Actually we don’t – and we shouldn’t. 😊
Existing IGP specifications do NOT specify how an implementation uses the output of an SPF. What happens when the same route is learned from two different sources, how redistribution is done, etc.
No need to do so here.

That is exactly what the PUA does with the negative advertisement flood which forces all the internal routers in that area that receives the ASBR summary to set to bit bucket /dev/null any packets to the LPM thus forcing the convergence to the alternative PE.  That is also why all the internal routers in the area acting on the PUA require a code upgrade.

For the Event Notification to work the SCRLP TLV that is flooded somehow as it’s a different scope LSDB different LS PDU, it somehow has to update the instance MTID LSDB of LSP on the circuit.

[LES:] The SCRLP TLV includes MTID as part of the advertisement for each of the prefixes it advertises. See Section 5. This is analogous to how it is done in prefix  reachability advertisements.

    Les

It’s a bit more tricky then just that as the internal router have the summary and traffic for the LSP is black holed on the ASBR doing the summarization.

Somehow with the SCRLP TLV flooded to all internal routers, they have to perform a special action just like the action on the PUA negative advertisement, they have to force convergence so the internal routers in the area treats the SCRLP TLV like a PUA negative advertisement and stops using the summary route for the component prefix that is no longer reachable.

   loss.

Kind Regards

Gyan

On Wed, Oct 13, 2021 at 2:44 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
This thread is becoming "diverse".
We are trying to talk about many different solutions (IGP, BGP, BFD) - all of which may be useful and certainly are not mutually exclusive.

PUA
-------

Event Notification
------------------------

    Les

Gyan Mishra

M 301 502-1347

---

From: tom petch <[email-masked]>
Date: Fri, 15 Oct 2021 15:49:47 +0000

From: Lsr <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 14 October 2021 16:42
From: Christian Hopps <[email-masked]>
Sent: 14 October 2021 13:13

<tp>

<tp2>
Having made some 50 or more reports that this is not junk, then the subsequent e-mails have made it to my Inbox and not the Junk folder so my ESP does take notice eventually!  I suspect though that it will not learn and when another message with those four or five characters appear in the Subject: then I will again have to retrieve them from Junk.

Of course I do not expect you to stop using the abbreviation, with or without a hyphen - rather I was flagging it in the expectation that others whose domains are serviced by this ESP may be experiencing the same as me but had not noticed.  Normally I get very little e-mail classified as Junk (despite getting a lot of phishing e-mail from within the domain).

Tom Petch

Thanks,
Chris.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Oct 2021 18:10:39 +0200

Hi Tom & Acee,

To the best of my knowledge what may have triggered spam in this thread for
you is not ISIS nor IS-IS words.

It is used twice "quote" "quote" as such special characters are very
rear and unsual in the subjects of normal email communication.

Thx,
Robert

On Fri, Oct 15, 2021 at 5:50 PM tom petch <[email-masked]> wrote:

> Yes.  That is what the thread about Prefix unreachable that Acee kicked
> off has in the Subject:  and it has junked about 60 of those for me.  Of
> course they still exist, I just have to remember to look for them, whereas
> ones I send with that character string do not make it to the list although
> they are in the Sent folder.  Sometimes it seems to inspect the body and
> junk on the basis of that but clearly not in this case as I have received
> your e-mail.
>
> Having made some 50 or more reports that this is not junk, then the
> subsequent e-mails have made it to my Inbox and not the Junk folder so my
> ESP does take notice eventually!  I suspect though that it will not learn
> and when another message with those four or five characters appear in the
> Subject: then I will again have to retrieve them from Junk.
>
> Of course I do not expect you to stop using the abbreviation, with or
> without a hyphen - rather I was flagging it in the expectation that others
> whose domains are serviced by this ESP may be experiencing the same as me
> but had not noticed.  Normally I get very little e-mail classified as Junk
> (despite getting a lot of phishing e-mail from within the domain).
>
> Tom Petch
>
> Thanks,
> Chris.
>
> > My ESP, one of the larger ones in the world, is classifying most of the
> LSR e-mails as junk.  Yes,  I have reported them as not junk but doubt if
> it will make a difference.
> >
> > To me it is obvious that anything with that well known abbreviation that
> was coined by ISO for their IGP in the subject line is going to receive
> unfavourable treatment so it may be that while many are  responding there
> are others who like me have an  ESP who is busy filling their junk folder.
> >
> across OSPF or  areas when area summarization is employed and prefix is
> summarised. We also have “ and OSPF Extension for Event Notification” which
> can be used to address the same use case. The drafts take radically
> different approaches to the problem and the authors of both drafts do not
> wish to converge on the other draft’s method so it is understandable that
> merging the drafts really isn’t an option.
> >

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Oct 2021 11:06:25 -0400

Hi Les

Thank you for the detailed explanation and progress on the ISIS extended
hierarchy draft which will be a substantial scalability improvement for
operators.

Responses In-line

Kind Regards

Gyan

I believe that you are confused about the hierarchy between PDUs types and
scopes. If that were more clear to you, I believe many of your comments
would no longer need to be made.

PDUs are a container for sending protocol information. Each PDU is
associated with a specific scope and a specific flooding behavior.

 Gyan> Understood

Base IS-IS has always supported scopes – but they are limited to Level-1
and Level-2 – and the scope is bound to the PDU type.
    Gyan> Understood

> When we wanted to introduce support for additional flooding scopes in RFC
> 7356, we could have simply extended the one-to-one mapping between a PDU
> type and a scope, but with the limited bits available for PDU type (5 bits)
> that could not scale.
>
   Gyan> Understood.  Thank you for explaining.

> So, we invented new PDU types (FS-LSP, FS-PSNP, FS-CSNP) that supported a
scope field in the header of the PDU. Now we could support a large number
of scopes w only three new PDU types.

Gyan> Makes sense

> It is important to note that the flooding behavior associated with the new
PDU types defined by RFC 7356 is completely analogous to the base LSP,
CSNP, PSNP PDU types. This is specified in RFC 7356.

 Gyan> Understood

In the event notification draft, we are defining two new PDU  types
(FSP-LSP, FSP-PSNP). These new PDU types support scope in the same manner
as their FS-xxx cousins from RFC7356.
   Gyan> Understood

> However, the flooding behavior associated with the new FSP-xxx PDUs is
> significantly different.  This is discussed in
> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.3
>
>
   Gyan> Understood that a new modified scope for the short lived ephemeral
nature of the events being flooded

> The PDU functionality specified in RFC 7356 does not apply to the new
> FSP-xxx PDUs. Therefore, suggesting that the lack of an FSP-CSNP is in
> violation of RFC 7356 is simply not correct.
>
> Gyan> Understood and agreed as this is a special flood use case suited for
> PSNP request/ack as LSP state synchronization is not required here.
>
> You seem to suggest below that we shouldn’t have used new PDUs but rather
> should have used new scopes in the event notification draft. But this would
> not scale. As the flooding behavior for FSP-xxx PDUs is different, we would
> have to encode that in the scope in order to differentiate from RFC 7356
> flooding behavior. That would have meant duplicating every currently
> defined scope (we are now up to 81 defined scopes (out of a possible 127)
> based on
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04#section-11.4
> ).
>
> using scope for this wouldn’t have scaled – and would have violated the
> current relationship hierarchy between PDU type and scope.
>
> Gyan> I  understand we require two new PDU types as this is a unique case
> that maybe leveraged in the future extensible for other event style
> notification future use cases.
>
> Some additional responses inline. If I did not specifically respond
> inline, please look to this introductory response for the answers.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, October 14, 2021 9:56 PM
> *[LES:] You are asking me to comment on a draft which does not yet exist –
> which doesn’t seem fair. **😊*
>
     Gyan> Understood.

> *I will say that it isn’t clear to me why, in this particular case, we
> would need two documents (problem statement and protocol extensions).
> Historically one document has sufficed for both in many cases.*
>
     Gyan> Understood that problem statement and solution is generally in
the same document.

> *But, this is a separate question which belongs in a separate thread – if
> need arises.*
>
>  Gyan> Understood
>
> This Event Notification draft defines a new FS PDU type 8 IANA request.
> So it burns up PDU type of the maximum 32 available.   This maybe a concern
> *[LES:] I have explained above why using new PDUs was chosen. In addition
> to what I stated above, I would add that you might want to take a look at
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04>.
> This introduces even more new PDU types (7 new ones I believe) – but the
> good news is it also extends PDU type to an 8 bit field (the 3 MSBs were
> Reserved and never used for anything – so this is possible). **😊*
>
> *The same document also introduces lots more scopes.*
>
>  Gyan> Thank you for the detailed explanation!
>
> *3 <https://datatracker.ietf.org/doc/html/rfc7356#section-3>.  Definition of New PDUs*
>
>
>
> *4.2 <https://datatracker.ietf.org/doc/html/rfc7356#section-4.2>.  Operation on Point-to-Point Circuits*
>
>
>
> *[LES:] Actually we don’t – and we shouldn’t. **😊*
>
> *Existing IGP specifications do NOT specify how an implementation uses the
> output of an SPF. What happens when the same route is learned from two
> different sources, how redistribution is done, etc.*
>
> *No need to do so here. *
>
>  Gyan> Understood.  In the PUA draft we have this detail and that had been
> the rub as it’s as you stated is in implementation space so can be
> omitted.  That would simplify the draft.
>
> For the Event Notification to work the SCRLP TLV that is flooded somehow
> as it’s a different scope LSDB different LS PDU, it somehow has to update
> the instance MTID LSDB of LSP on the circuit.
>
>
>
> *[LES:] The SCRLP TLV includes MTID as part of the advertisement for each
> of the prefixes it advertises. See Section 5. This is analogous to how it
> is done in prefix  reachability advertisements.*
>
> * Gyan> Understood.  *
>
> *    Les*
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*