Hi, > So we have a way to achieve consistency if it is ever needed.
Well you do not have any protocol way to assure that operational configuration mistakes will not result in inconsistent routing. But overall I do agree that for the vast majority of applications that concern is not really applicable ? In fact I would be happy if you limit the UPA scope *only* for services which use end to end encapsulation. It is also important to observe that this is not negative routing and that P nodes will continue to forward packets to destinations marked as UPA as the information will not be really reflected as holes/drops in their respective FIBs. Thx, R. On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak <[email protected]> wrote: > 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. For most > cases, the network wide consistency is not needed. > > 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> > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
