Re: [Lsr] 【Technical Discussion】"Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

["Les Ginsberg (ginsberg)" <[e-mail]>]

Aijun –


From: Aijun Wang <[e-mail]>
Sent: Friday, October 15, 2021 12:16 AM
To: Les Ginsberg (ginsberg) <[e-mail]>; Acee Lindem (acee) <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>; [e-mail]
Subject: RE: [Lsr] 【Technical Discussion】"Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"


Hi, Les and Acee:

The answer to your previous concerns are the followings.

For discussion convenience, I will use PUAM to represent “Prefix Unreachable Announcement Mechanism” later.



==================================================================================================================

1.  From Les:  https://mailarchive.ietf.org/arch/msg/lsr/IjiWOvYiXtcplVeQukbVRnmlEFY/

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.

【WAJ】：It is easy to make sure all of the routers within one domain to upgrade to support the PUAM feature. The similar requirements apply also to your introduced IS-IS Pulse PDU.



[LES:] In the case of PUA, if a legacy router were to see a PUA advertisement, it would treat it as a reachability advertisement and actually do the wrong thing with this information which will result in incorrect forwarding. (Acee has commented on this previously).

This means PUA simply cannot be used at all when any legacy router is present.



In the case of event notification, the worst thing that can happen is that a legacy router will get a PDU that it does not understand, and it will not use the information – so we are no worse off than if the information had not been sent.

This means that event notification can be safely used in partial deployments – though clearly the full benefits of the extension will not be realized until all of the routers who need to act on the new information have been upgraded.



Big qualitative difference in my opinion.





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

【WAJ】Would you like to elaborate more accurate?

[LES:] As you are using a persistent advertisement – and one which may impact scale – you have to come up procedures to try to assure its withdrawal from the network in a timely manner and assure that it does not significantly impact scale.

To address this, you have defined procedures (Section 7) which modify the conditions under which summary addresses may be used. These procedures alter existing behavior in ways a customer may not like (they decided to use summaries for a reason). And the logic depends upon the router knowing and remembering what is unreachable – something which is problematic if a router has restarted or had an adjacency which never came up. So, the behavior of the box under the same set of conditions may differ depending on what happened before the box was running.



You can argue (legitimately I think) that you have defined procedures to address these issues. (I did not say that it is impossible to address these issues – I said it is problematic.) But I would prefer not to have to face these issues – and we now have a solution (event notification) which does not have these issues at all.



HTH clarify.



   Les





2. From Acee:  https://mailarchive.ietf.org/arch/msg/lsr/SRmhsUCLphTqKRkMA_8BNNe9L54/



  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.

【WAJ】The updates of every routers within the domain can be done in deployment. We can add some capabilities bit in the “Router Information” LSA. The ABR should only announces the PUAM message when all of internal router supports this features.

  1.  The non-deterministic nature of the notification. Unreachability is advertised for any route that is subsumed by a range and become unreachable.

【WAJ】No. As described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-7, the ABR has the ability to control when and for which prefix to send out the PUAM.



Is this advertised forever if the route in question is taken out of service?

【WAJ】No. Please see also the description in last paragraph of https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-7



What about a route that is mistakenly put into service - will we advertise unreachability forever?

【WAJ】Should the question be “what about a route that is mistakenly put out of service?”, if so, the PUAM will be triggered. But it will not be advertised forever.



What if the PE is already unreachable when the ABR comes up - no reachability information will be advertised.

【WAJ】The PUAM will not be triggered. Please see the description in last sentence of https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-7

For discussion convenience, I copy the section 7 of PUAM draft here:

7<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-7>.  Deployment Considerations



   To support the PUA advertisement, the ABRs should be upgraded

   according to the procedures described in Section 4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-4>.  The PEs that

   want to accomplish the BGP switchover that described in Section 3.1<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-3.1>

   and Section 5<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-5> should also be upgraded to act upon the receive of the

   PUA message.  Other nodes within the network should ignore such PUA

   message if they don't care or don't support it.  The routers within

   the IGP domain should not install erroneously the route to the

   prefixes when they receives PUA message.



   As described in Section 4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-07#section-4>, the ABR will advertise the PUA message

   once it detects there is link or node down within the summary

   address.  In order to reduce the unnecessary advertisements of PUA

   messages on ABRs, the ABRs should support the configuration of the

   protected prefixes.  Based on such information, the ABR will only

   advertise the PUA message when the protected prefixes(for example,

   the loopback addresses of PEs that run BGP) that within the summary

   address is missing.



   The advertisement of PUA message should only last one configurable

   period to allow the services that run on the failure prefixes are

   converged or switchover.  If one prefix is missed before the PUA

   mechanism takes effect, the ABR will not declare its absence via the

   PUA mechanism.



  1.  Like the event notification draft, the unreachability notification will trigger BGP reconvergence.

【WAJ】Exactly, the above sentence should be “Event notification draft takes the similar procedure described in PUAM draft, that is the PUAM 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.

【WAJ】Without the aid of BFD, the convergence time of BGP should be in second scale. The process of IGP flooding is event driven, then will be quicker than BGP hello mechanism.



  1.  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.

【WAJ】Please gives some examples in detail, or we can discuss this later when the 1-3 concerns has been solved.

===================================================================================================================





-----Original Message-----
From: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 14, 2021 3:36 PM
To: 'Les Ginsberg (ginsberg)' <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; 'Acee Lindem (acee)' <acee=[e-mail]<mailto:acee=[e-mail]>>; 'Peter Psenak' <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"



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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Les Ginsberg (ginsberg)

Sent: Thursday, October 14, 2021 1:25 PM

To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Les Ginsberg (ginsberg)' <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; 'Acee Lindem (acee)' <acee=[e-mail]<mailto:acee=[e-mail]>>; 'Peter Psenak' <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; [e-mail]<mailto:[e-mail]>

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



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



> -----Original Message-----

> From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Aijun Wang

> Sent: Wednesday, October 13, 2021 7:50 PM

> To: 'Les Ginsberg (ginsberg)' <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>;

> 'Acee Lindem (acee)' <acee=[e-mail]<mailto:acee=[e-mail]>>; 'Peter Psenak'

> <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; [e-mail]<mailto:[e-mail]>

> Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and

> OSPF Extension for Event Notification"

>

> 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Les

> Ginsberg (ginsberg)

> Sent: Thursday, October 14, 2021 2:44 AM

> To: Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; Peter Psenak

> <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; [e-mail]<mailto:[e-mail]>

> Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and

> OSPF Extension for Event Notification"

>

> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Acee Lindem (acee)

> > Sent: Wednesday, October 13, 2021 9:49 AM

> > To: Peter Psenak <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and

> > OSPF Extension for Event Notification"

> >

> > Hi Peter,

> >

> > See inline.

> >

> > On 10/13/21, 4:42 AM, "Peter Psenak"

> > <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>> wrote:

> >

> >     Hi Acee,

> >

> >     On 12/10/2021 21:05, Acee Lindem (acee) 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.

> >

> >     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.

> >

> > One solution to this problem would have definitely been better.

> >

> >     > 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?

> >

> >     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.

> >

> > 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

> >

> >

> >     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.

> >

> >

> >     >  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 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

> >

> >     >

> >     > We’ll reserve any further discussion to “WG member” comments

> > on the two

> >     > approaches.

> >     >

> >     > Thanks,

> >     > Acee and Chris

> >     >

> >

> >

> > _______________________________________________

> > Lsr mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://www.ietf.org/mailman/listinfo/lsr

> _______________________________________________

> Lsr mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/lsr

>

> _______________________________________________

> Lsr mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________

Lsr mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/lsr