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

Reply via email to