Peter,
Thank for you answer. Please see inline [Bruno]
> From: Peter Psenak <[email protected]>
> Sent: Tuesday, July 25, 2023 6:11 PM
>
> Bruno,
>
> On 25/07/2023 14:39, [email protected] wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
>
> why do you believe so? How is this different to an IGP prefix becoming
> unreachable without UPA?
[Bruno] Because, at least for IS-IS, this is a protocol extension.
When receiving:
IP1/32 with metric 0xFE000001
IP1/24 with metric 10 (covering aggregate)
Legacy routers will only consider the aggregate for the SPF/RIB
IP1/24 with metric 10
As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and used.
UPA compliant routers will consider the aggregate for the SPF/RIB, plus they
will consider that IP1/32 is unreachable.
As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not used.
(note that I have assume that the UPA signal is sent to BGP, but this is the
same picture if UPA is only used by BGP PIC Edge)
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
>
> I don't see a problem, please provide an example.
iPE1 ----- P1 ----- P2 ----- ABR1 ----- P3 ----- ePE2 (IP1)
|
|
ePE3 (IP1)
<--------L1--------------------><------------L2----------->
ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers in L2.
ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have both BGP
paths to IP1.
Traffic to IP1 is IP routed hop by hop from iPE1.
P2 support UPA, P1 does not.
ePE2 fails and ABR1 advertise UPA in level 1.
P1 does not support UPA so is unaware of ePE2 failure and keeps routing IP1
toward ePE2, hence P2.
P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes using
this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.
--> forwarding loop between P1 and P2 for destination IP1
A priori same thing with BGP PIC edge.
Thanks,
--Bruno
----
> If an ingress PE decides to switch to an alternate BGP path, how does
> that creates any potential loop? And why all egress PEs would need to do
> the same?
>
> >
> > This is not considered nor discussed in the draft. Quite the contrary,
> > draft says that recognition, processing and use of UPA is a local
> > consideration.
>
> yes, and we want to keep it that way.
>
> thanks,
> Peter
>
>
> >
> > I would suggest to at minimum present this draft to IDR and gets the
> > feedback from the IDR WG.
> >
> > --Bruno
> >
>
Orange Restricted
____________________________________________________________________________________________________________
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
