> But BGP service PIC is the use case this draft is targeting? For many emails on LSR and beyond I got point from authors against using BGP for such signalling as "BGP may not be running there at all".
So if the draft works *only* with service provided by BGP let's please state it clearly in the document. This is not my current assumption. Many thx, R. On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) <[email protected]> wrote: > Hi Robert, > > > > *From: *Robert Raszuk <[email protected]> > *Date: *Thursday, November 10, 2022 at 9:41 AM > *To: *Peter Psenak <[email protected]> > *Cc: *Bruno Decraene <[email protected]>, David Lamparter < > [email protected]>, Acee Lindem <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA > IS-IS semantics > > > > Peter, > > > > > But: > > - that is nonetheless a change which is non backward compatible with > people currently using such high metric without the intention to mean UPA > > - to differentiate different usages (e.g. your UPA, my other usage such > as "graceful shutdown" (still reachable but will disappear soon), endpoint > CPU load is 80%...) one > > well, the question is whether it would not make sense to trigger UPA for > the above mentioned usages as well. Because eventually the destination > is becoming unreachable anyway and I would want my services to reroute > to alternate egress node. But seems like folks want to have a way to > differentiate, so I'm not going to argue against it. > > > > I think You are right if there is a hierarchical service above it. > > > > But consider flat routing - where there is no BGP service on top. Example > - some DCs do use flat routing. > > > > With that I am afraid UPA triggers may not work well (or at all) ... > especially considering that they are history after the timeout irrespective > of the remote prefix state. > > > > But BGP service PIC is the use case this draft is targeting? For example, > there is no intent to install negative routes throughout the domain. > > > > Thanks, > Acee > > > > > > Cheers, > > R. > > > > > > > > > > > > > > > > > thanks, > Peter > > > would need to use different metric values that would need to be at least > locally registered. So why not have the IANA register a flag and avoid each > network operator to do that job? > > > > In all cases, I don't see a reason for UPA to change the meaning of all > the metric values >0xFE000000. You can pick a single value (e.g. > 0xFE000001) and that would equally work for your use case. > > > > Regards, > > --Bruno > > > > > > > > > >> > >>> > >>> I vaguely remember several years back we did indeed implement something > >>> (seriously no memory on details) that resulted in the creation of a new > >>> prefix reachability TLV with some experimental/local sub-TLVs. These > >>> prefixes did not exist in the IS-IS domain beforehand. I have no idea > >>> what the operational reality is on the existence of such things, but I > >>> know that /some/ code exists that does this. > >>> > >>> To boil this down into the core of the essence and be explicit, > >>> > >>> - you can create an IS-IS prefix reachability for some arbitrary > prefix, > >>> and stick > 0xfe000000 into the metric, and that won't have any > effect > >>> on the existing IS-IS domain > >>> - this has in fact been done to carry custom bits of information that > >>> for one reason or another were decided to be routing-related and > thus > >>> make sense to put there > >>> - the assumption for the use case is that there are indeed less > specific > >>> covering prefixes around, providing actual reachability > >>> - any setup doing that would now suddenly have fresh "unreachable" > >>> semantics attached to something that didn't have them before, which > >>> breaks things (or rather: prevents enabling/deployment of the UPA > >>> feature) > >> > >> and why that would be a problem? Such prefix would never be used to for > >> resolution of the BGP prefix. So the presence of such unreachable prefix > >> would never trigger any action even of the UPA processing was enabled on > >> the receiver. I don't see a problem. > >> > >>> - (if those extra prefixes are created with 0xffffffff metric, a > >>> configurable >= limit for UPA does not help either.) > >> > >> again, what is the problem? > >> > >>> > >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is > >>> (IMHO) not a significant cost, and completely eliminates this issue. > >>> The only reason against it (that I can think of) is that the > >>> advertisement might be a little bit larger; a new sub-TLV or flag bit > >>> should be completely invisible to existing implementations (= I don't > >>> see how this would create compatibility or rollout problems.) > >> > >> I'm afraid, you forgot to consider an operational aspect of the > solution. > >> > >> thanks, > >> Peter > >> > >>> > >>> Cheers, > >>> > >>> > >>> -David > >>> > >> > > > > 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 > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
