Hi Bruno,
please see inline:
On 26/07/2023 16:38, bruno.decra...@orange.com wrote:
Peter,
please see inline
From: Peter Psenak <ppse...@cisco.com>
Sent: Tuesday, July 25, 2023 10:04 PM
Bruno,
please see inline:
On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
Peter,
Thank for you answer. Please see inline [Bruno]
From: Peter Psenak <ppse...@cisco.com>
Sent: Tuesday, July 25, 2023 6:11 PM
Bruno,
On 25/07/2023 14:39, bruno.decra...@orange.com 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
even routers with UPA processing enabled would only use IP2/24 in
forwarding. The UPA would only be used to send signal to apps like BGP.
you are correct.
(I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
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.
no, they will NOT consider that IP1/32 is unreachable.
UPA is only used to signal the unreachability to apps that are
interested.
"apps" are part of the router, in particular BGP.
So let me rephrase: the BGP protocol on UPA compliant routers will consider the
aggregate for the SPF/RIB, plus they will consider that IP1/32 is unreachable.
What the apps do with it is out of the scope of UPA.
Use of UPA have consequences. Some good (advertising loss of reachability),
some bads (forwarding loops for BGP prefixes which are routed hop by hop).
I don't think that we can claim the benefits (adopt UPA because it's useful for
e.g. BGP PIC edge) and refuse to talk about the drawbacks.
##PP
we basically leave the responsibility to the consumer of the UPA, as the
treatment of the UPA signal an its consequence on the app is app specific.
But we can clarify that in the draft.
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
- UPA processing is optional and disabled by default
- typically P1 and P2 would not run BGP at all, so there would be no
issues if UPA would be used on iPE1
- if you run BGP hop by hop, you would need to consistently enable UPA
on all routers.
Good that we agree on some bad consequences of UPA in case of partial
deployment.
Can we have a text, if not a section, in the draft to talk about that partial
deployment?
At least to raise awareness of the potential issues depending the
"application". Ideally, I would have a preference to specifically indicate the
cases that are problematic, but that would imply having a review from all routing WG.
Again, I think that the BGP case should be described as this the typical target
that had been discussed on the list to promote UPA, and both IS-IS and BGP are
important for the routing/network. I don't think IS-IS can shirk responsibility
for advertising reachability/unreachability to other protocols relying on IS-IS.
a first proposal could be
6.1 Partial Deployement
Partial deployment of UPA translates into inconsistent knowledge of the
unreachability of the UPA prefix. For some applications, and in particular for
routing/signaling protocols relying on this (un)reachability, this leads to
inconsistent routing decisions. In some cases this may not be problematic, in
others cases this may be problematic.
For example with BGP, if a tunnel is used to reach the BGP Next-Hop, this will
not be problematic. On the other hand if the packets are routed hop by hop,
this will lead to forwarding loops.
Applications and protocols using the UPA information SHOULD consider the
consequences of partial deployment before enabling their use of UPA.
##PP
I'm good to include the above in the draft.
In a nutshell, it is up to the consumer application of the UPA to be
configured correctly if the consistent usage of the UPA across the
network/area is required by the application itself.
thanks,
Peter
Thanks,
--Bruno
thanks,
Peter
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.
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
