Hi Acee,
On 14/10/2021 00:36, Acee Lindem (acee) wrote:
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.
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
Thanks,
Acee
On 10/13/21, 6:11 PM, "Lsr on behalf of Acee Lindem (acee)" <lsr-boun...@ietf.org
on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
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=40cisco....@dmarc.ietf.org> 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.
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
