thanks,
Peter
On 06/01/2022 09:09, [email protected] wrote:
Hi Gyan,
You are referring to both summarization and BGP PIC (edge).
BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge
relies on the presence of the specific (/32) prefix information in the
FIB. Hence it’s not clear to me how you can have both prefix
summarization and BGP PIC edge benefits in the FIB on the BGP ingress node.
Taking the example from [1], below is a typical FIB chain for BGP Pic edge:
IP Leaf:Pathlist:IP Leaf:Pathlist:
--------+-------+--------+----------+
VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1
||BGP-NH2|-->....||IGP-NH2,I2|--->Adjacency2
|+-------+|+----------+
||
||
vv
OutLabel-List:OutLabel-List:
+----------------------++----------------------+
|VPN-L11 (VPN-IP1, NH1)||IGP-L11 (IGP-IP1, NH1)|
|VPN-L21 (VPN-IP1, NH2)||IGP-L12 (IGP-IP1, NH2)|
+----------------------++----------------------+
Figure 2 Shared Hierarchical Forwarding Chain at iPE
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2>
To help me get the picture, could you please highlight/draw the
change(s) that you have in mind assuming IGP prefix summarization and
PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
Thanks,
Regards,
-Bruno
Orange Restricted
*From:*Lsr <[email protected]> *On Behalf Of *Gyan Mishra
*Sent:* Thursday, January 6, 2022 12:27 AM
*To:* Robert Raszuk <[email protected]>
*Cc:* Greg Mirsky <[email protected]>; Les Ginsberg (ginsberg)
<[email protected]>; Christian Hopps <[email protected]>; Aijun Wang
<[email protected]>; Shraddha Hegde <[email protected]>; Tony
Li <[email protected]>; Hannes Gredler <[email protected]>; lsr
<[email protected]>; Peter Psenak <[email protected]>
*Subject:* Re: [Lsr] BGP vs PUA/PULSE
Hi Robert
The goal of the draft is providing egress protection when summarization
is used similar to RFC 8679 Egress protection framework, but without the
complexities.
An IGP RIB within a domain is made up on connected interfaces and
loopbacks. Of the two types, the critical prefix to be tracked is the
/32 or /128 host routes on egress PE which is the BGP next-hop attribute
via next-hop-self rewrite. So both connected and loopbacks can be
placed in the same range for large aggregation domains, however due to
the criticality of the next hop attribute the loopbacks are placed in a
separate range, and so not summarized and flooded domain wide.
The BGP next hop attribute is an MPLS exact match FEC binding for the
LSP. Flooding of loopbacks workaround is typically done for MPLS
domain due to issue with RFC 5283 inter area extension feature not being
viable solution for LPM summary matching, thus all the prefixes still
have to be flooded in LDP, so no net reduction in host route flooding.
With the PUA/Pulse feature allows the domain wide flooding of the
loopback host routes is now possible as can now we take advantage and of
summarization.
Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the
tracking of BGP next-hop-attribute component prefixes is critically
important to improved convergence and not rely on BGP dead timers to
expire. Even with BFD, LFA/RLFA/TILFA local protection , PIC and other
optimizations we still need an optimization to track the summary route
component prefixes to speed up convergence providing egress PE protection.
Kind Regards
Gyan
On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk <[email protected]
<mailto:[email protected]>> wrote:
Hi Aijun,
In most deployments summary routes are already crafted carefully to
only cover those destinations which are important and should be
reachable from outside of the area.
So I see no point in building yet another policy to select a subset
of summaries to be PUA eligible.
Along those lines I do not buy into the notion of "some prefixes
within summaries to be more important than others" - it is simply
impossible to say that this PE is more important than the other one
in all practical cases.
If we are to roll out a mechanism to signal unreachability it better
be robust and dependable - not just an optional hint. With that I
would welcome solution which says - if we have more then X prefixes
(or % of prefixes) to be advertised by ABR we stop advertising the
summary covering them (or deaggregate the summary).
Thx,
R.
On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang
<[email protected] <mailto:[email protected]>> wrote:
I think the mentioned solution can also address Robert and
Christian’s concerns.
Aijun Wang
China Telecom
On Jan 5, 2022, at 07:02, Aijun Wang
<[email protected]
<mailto:[email protected]>> wrote:
Hi, Greg:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-
annoucement-08#section-8
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-
annoucement-08#section-8> has
some description for such considerations:
“ In order to reduce the unnecessary advertisements of PUAM
messages on ABRs, the ABRs should support the configuration
of the
protected prefixes.Based on such information, the ABR will only
advertise the PUAM message when the protected prefixes(for
example,
the loopback addresses of PEs that run BGP) that within the
summary
address is missing.”
Aijun Wang
China Telecom
On Jan 5, 2022, at 03:56, Greg Mirsky
<[email protected] <mailto:[email protected]>>
wrote:
Hi Peter,
thank you for your response. I'm looking forward to the
new version of the draft. It will be interesting to
learn the criteria that enable an ABR to reliably
identify the scenarios you've suggested are outside the
scope of the PULSE draft and should be handled differently.
Regards,
Greg
On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak
<[email protected] <mailto:[email protected]>> wrote:
Hi Greg,
On 04/01/2022 18:13, Greg Mirsky wrote:
> Hi Peter,
> I'm probably missing something in the current
PULSE but I cannot find
> the mechanism that limits the number of the
pulses. Do you envision that
> being like a throttling mechanism? But delaying
the propagation of
> notification for some events might cause more
instability in a network.
no. It's a limit not a delay. If too many edge nodes
loose connectivity
to the ABR in its area, it's a result of the severe
event like area
partition or loss of area connectivity from ABR.
These are not types of
events that we are trying to address with pulses.
The limit is not described in the published version
of the draft.
We are working on the updated version that will
include the description
of it.
thanks,
Peter
>
> Regards,
> Greg
>
> On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak
<[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> Hi Greg,
>
> On 03/01/2022 23:17, Greg Mirsky wrote:
> > Happy New Year to All!
> >
> > Hi Peter,
> > Top-pasting:
> > In 99,99% of cases there will be only
single pulse generated when
> one PE
> > goes down. That itself is a very rare
event itself.
> >
> > We can easily limit the number of pulses
generated on ABR to a single
> > digit number to cover the unlikely case of
many PEs in area becoming
> > unreachable at the same time.
> >
> > I think that it is possible for the
summarizing ABR to get
> disconnected
> > from the IGP area in such a way that the
summarization is still
> valid.
> > If such a case is valid, would the ABR
generate PULSE for each
> > disconnected PE?
>
> obviously not. That's why I mentioned the
number of pulses will be
> limited on every ABR.
>
> thanks,
> Peter
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > wrote:
> >
> > Chris,
> >
> > On 03/01/2022 17:18, Christian Hopps
wrote:
> > >
> > > Peter Psenak <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> writes:
> > >
> > >> On 03/01/2022 16:21, Christian
Hopps wrote:
> > >>>
> > >>>> On Nov 29, 2021, at 7:39 PM, Les
Ginsberg (ginsberg)
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> wrote:
> > >>>>
> > >>>> Tony –
> > >>>> Let me try one example – see
if it helps.
> > >>>> Summarization is used in the
network.
> > >>>> But customer identifies a modest
number of key nodes
> where it
> > wants to detect loss of reachability
ASAP. Unfortunately,
> customer
> > is unable to assign addresses which
are outside of the summary to
> > these nodes.
> > >>>
> > >>> I think this does in fact capture
the problem trying to be
> > solved here, nicely.
> > >>
> > >> not really.
> > >> In fact assigning addresses to the
nodes in a way that
> they are
> > part of the
> > >> summary is the right thing to do.
> > >
> > > No, not if you want more detailed
information about specific
> > reachability it's not. And ....
> >
> >
> > typically you want to summarize all
prefixes inside the area when
> > advertising outside the area. And you
want to know about some
> of these
> > prefixes when they are lost to help
convergence.
> >
> >
> > >
> > >> The problem we are trying to solve
is to use the
> summarization
> > but without the
> > >> loss of the fast notification of
the node down event.
> > >
> > > You want more specific information
about reachability, but you
> > just want to do it when the network is
stressed and
> undergoing change.
> > >
> > > So the "works now" way of not
summarizing these important
> > prefixes has the state in the network
when it's working, so
> you know
> > adding and removing it is something
the network is already
> capable
> > of handling.
> > >
> > > New signaling that *only* is
created when things start
> failing,
> > tests the infrastructure at exactly
the wrong time.
> >
> > In 99,99% of cases there will be only
single pulse generated when
> > one PE
> > goes down. That itself is a very rare
event itself.
> >
> > We can easily limit the number of
pulses generated on ABR to
> a single
> > digit number to cover the unlikely
case of many PEs in area
> becoming
> > unreachable at the same time.
> >
> >
> > >
> > > If a failing network can handle the
extra state, then a
> > functioning stable network of course
can too.
> >
> > no, that's not what we claim. We want
network to be
> summarized all
> > times
> > and generate limited number of pulses
at any given time to
> help the
> > network converge fast in case where
single (or very few) PEs
> in an area
> > go down.
> >
> > thanks,
> > Peter
> >
> >
> >
> > >
> > > Thanks,
> > > Chris.
> > >
> > >>
> > >> thanks,
> > >> Peter
> > >>
> > >>
> > >>> One solution very simple solution
that works today is:
> > >>> - Tell the customer they can't do
this, but they *can*
> modify
> > their addressing
> > >>> (this is literally what they do
for a living) so that they
> > don't have this
> > >>> problem.
> > >>> Do we *really* want modify our
IGPs (a BIG ask) with some
> > pretty questionable
> > >>> changes, just to save the
operators the trouble of doing
> their
> > job correctly?
> > >>> Maybe the answer here is this
isn't a good idea, and we
> should
> > move on...
> > >>> Thanks,
> > >>> Chris.
> > >>> [as wg member]
> > >>>
_______________________________________________
> > >>> Lsr mailing list
> > >>> [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > >>>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>>
> >
<https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>>>
> > >>>
> > >
> > >
> >
> >
_______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>>
> >
<https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>>>
> >
>
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
--
<http://www.verizon.com/>
*Gyan Mishra*
/Network Solutions Architect /
/Email [email protected] <mailto:[email protected]>/
/M 301 502-1347/
______________________________________________________________________
___________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this
message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
