On Oct 13, 2021, at 10:16, Robert Raszuk <[email protected]> wrote:
> 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)
<[email protected] <mailto:[email protected]>>
wrote:
Hi Peter,
See inline.
On 10/13/21, 4: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.
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
