Tony On Mon, Nov 29, 2021 at 11:02 PM Gyan Mishra <hayabusa...@gmail.com> wrote:
> > Tony > > On Mon, Nov 29, 2021 at 9:09 PM Tony Li <tony...@tony.li> wrote: > >> >> Les, >> >> >> Summarization is used in the network. >> But customer identifies a modest number of key nodes where it wants to >> detect loss of reachability ASAP. Unfortunately, customer is unable to >> assign addresses which are outside of the summary to these nodes. >> Customer assigns admin tags to the prefixes of interest and asks the IGP >> vendor to support advertising reachability to the tagged prefixes in >> addition to the summary (even though they are covered by summary). >> Are we still within the IGP set of responsibilities IYO? >> >> >> >> IMHO, no. >> >> You’re intentionally breaking summarization and advertising liveness. >> You can claim that it’s just reachability, but it’s not. If it were >> reachability, then you’d be ok with a static prefix assignment. >> > > > Gyan> This is a nice link that gives the historical definition of > liveliness from an IT perspective. > > https://liveness.com/#free > > When you think of liveliness you think of BFD data path bidirectional > liveliness detection or PM in-situ OAM telemetry. In this case with > PUA/PULSE is routing information and it’s the LPM component prefixes we are > tracking reachability of those specific prefixes. So it’s at the LPM > prefix level that we are tracking of events. What may have caused > confusion is talk about remote PE down tracking but all that we are > tracking is not the liveliness of the PE but the actual LPM loopback of the > PE which is the next hop for the service overlay routes. Hope this helps. > > Many Thanks! > >> Gyan> Sorry I meant to use the word “continuity” - When you think of liveliness you think of BFD data path bidirectional “continuity” detection or PM in-situ OAM telemetry. > >> >> Now, if the ABR so configured loses reachability to one of the tagged >> prefixes, what should it do? >> Clearly, it needs to stop advertising reachability for that prefix. >> >> >> >> No, it doesn’t. Static summarization is the preferred approach. It’s >> stable. >> >> You may recall back in the ‘90s that we did dynamic advertisement and >> withdrawl in BGP. That quickly got frowned on because of the resulting >> churn. No different here. >> >> >> What we propose is that if a customer wants to use summaries, they should >> feel free to do so. But if they want faster detection of loss of >> reachability to (some) destinations covered by the summary, there is a new >> advertisement which provides this which avoids the ambiguities mentioned >> above. >> Again, the IGP isn’t acquiring new information – it has always known this >> information – it just hasn’t had a way to advertise this in the presence of >> summaries. >> >> >> >> You’re propagating new information out of the area. And doing so at the >> wrong time. I would MUCH rather just leak the prefixes when things are >> working than add stress in failure modes. >> >> >> And, the use of tagging to identify the prefixes which may be advertised >> using the new mechanism is one way to deal with scale issues. >> >> >> >> How? If there are 10,000 tagged prefixes, how does that not become 10,000 >> negative leaks? >> >> Tony >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
