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: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg
(ginsberg)
Sent: Thursday, October 14, 2021 2:44 AM
To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org>; lsr@ietf.org
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 <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, October 13, 2021 9:49 AM
> To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; lsr@ietf.org
> 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=40cisco....@dmarc.ietf.org> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
