Hi Robert, From: Robert Raszuk <[email protected]> Date: Thursday, November 10, 2022 at 10:51 AM To: Acee Lindem <[email protected]> Cc: Peter Psenak <[email protected]>, Bruno Decraene <[email protected]>, David Lamparter <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics
> 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. I think the point of this was that it could be other applications where an ephemeral unreachability notification is useful. For this type of notification, recursive route resolution is the primary application. However, I’ll defer to the authors. Thanks, Acee Many thx, R. On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Robert, From: Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Thursday, November 10, 2022 at 9:41 AM To: Peter Psenak <[email protected]<mailto:[email protected]>> Cc: Bruno Decraene <[email protected]<mailto:[email protected]>>, David Lamparter <[email protected]<mailto:[email protected]>>, Acee Lindem <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
