Peter, > From: Peter Psenak <[email protected]> > Sent: Tuesday, July 25, 2023 7:38 PM > To: Robert Raszuk <[email protected]> > > Hi Robert, > > > > On 25/07/2023 18:51, Robert Raszuk wrote: > > Hey Peter, > > > > I think the point Bruno is making is valid ... Imagine dual or triple > > vendor network and hop by hop routing (no end to end SAFI). > > > > That means that all nodes should be in synch in terms to react on UPA, > > chapter 7 of the draft says: > > "Processing of the received UPAs is optional and SHOULD be controlled by > the configuration at the receiver. The receiver itself, based on its > configuration, decides what the UPA will be used for and what > applications, if any, will be notified when UPA is received." > > So we have a way to achieve consistency if it is ever needed.
Assuming that all nodes in the flooding domain support UPA, and that consistent configuration is applied on all nodes, and that UPA is enabled on a flag day/second. > For most > cases, the network wide consistency is not needed. Since we agree that there is a consistency issue in some cases, it would be good for the draft to be explicit about this and says when the draft is not applicable. Thanks, --Bruno > thanks, > Peter > > > > > Of course you will say that this is up to wise operator to enable it > > only when it makes sense ... but I think the point is still valid and > > clearly for none tunneled networks (if ever to use UPA) this is NOT a > > local decision, > > > > For vast majority it is local as forwarding is using some sort of PE-PE > > encapsulation. > > > > Cheers, > > R. > > > > > > On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak > > <[email protected] <mailto:[email protected]>> > > wrote: > > > > Bruno, > > > > On 25/07/2023 14:39, [email protected] > > <mailto:[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? > > > > > > > > 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. > > 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 > > > > > > > > > > ____________________________________________________________________________________________________________ > > > 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] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > 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
