Thanks Robert, you got my point. More inline. From: Robert Raszuk <[email protected]> Sent: Tuesday, July 25, 2023 7:51 PM To: Peter Psenak <[email protected]> Cc: DECRAENE Bruno INNOV/NET <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
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. +1 But overall I do agree that for the vast majority of applications that concern is not really applicable ? In all cases, the draft needs to say when it’s applicable and when it’s not applicable and must not be used. In fact I would be happy if you limit the UPA scope *only* for services which use end to end encapsulation. Yes but AFAIK currently BGP decision process and BGP PIC edge does not make the different if the same loopback is used both for encapsulating traffic for some AFI/SAFI and for hop by hop routing for some others AFI/SAFI. 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. Absolutely, that is not negative forwarding and forwarding to the IGP prefix is unchanged. But that is a negative reachability signal in routing. Thanks, --Bruno Thx, R. On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak <[email protected]<mailto:[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]> > <mailto:[email protected]<mailto:[email protected]>>> > wrote: > > Bruno, > > On 25/07/2023 14:39, > [email protected]<mailto:[email protected]> > <mailto:[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]> > <mailto:[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
