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. 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
