Robert,
On 25/07/2023 19:50, Robert Raszuk wrote:
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.
that is certainly the main use case we are targeting.
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.
that is indeed the case. The forwarding based on the less specific route
is not affected by UPA.
thanks,
Peter
Thx,
R.
On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> 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
> <ppsenak=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>
<mailto:40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>>
> wrote:
>
> Bruno,
>
> On 25/07/2023 14:39, bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>
> <mailto:bruno.decra...@orange.com
<mailto: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?
>
> >
> > 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
> Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
<mailto:Lsr@ietf.org>>
> https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
