Hi Robert,
On 13/10/2021 12:23, Robert Raszuk wrote:
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 ?
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.
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.
agree. In some cases though a link down or an SRLG down event may result
in a node becoming unreachable. Efficiency is still required.
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 ;).
good :)
thanks,
Peter
Cheers,
R.
On Wed, Oct 13, 2021 at 10:42 AM Peter Psenak
<[email protected] <mailto:[email protected]>>
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.
>
> 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.
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
