Les, > I could be more specific regarding my opinion about various alternatives that > have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to > me to comment on proposals which have not actually been defined.
The proposals have been put forth in adequate detail for a preliminary discussion. They appear to be tractable and implementable and thus seem like feasible alternatives. > In the meantime, we started with the IGPs because: > > a)IGPs have the raw reachability info – they don’t have to get it from some > other entity > b)IGPs have the reliable flooding mechanism > > Given that we want to address a real deployment issue in a timely manner, we > want to move forward. You want to move forward. Not the rest of us. > We – meaning the WG/IETF – are tasked with defining practical solutions to > real problems. No. Our job is standardizing solutions. We are not tasked with defining them. Proof: you can unilaterally go off and define, implement, and deploy whatever solution you like today. We cannot stop you. In fact, it’s none of our business. However, when it comes to standardizing it, that’s when we (the IETF WG) get involved. At that point, the bar is somewhat raised. That’s when you have to convince the rest of us that you have a good solution to the problem. We are in no rush to move forward with a bad solution. Especially at scale. :-) > It’s fine to object to a proposal – but that doesn’t get us to a solution. > I am not saying that you specifically are responsible for defining an > alternate solution – but if “we” are to progress then we either need to > accept an IGP solution or define an alternative. > > Now, if you are saying the problem doesn’t need to be solved – then we just > disagree. The problem needs to be solved. No question. It doesn’t need to be solved with a rush to a bad solution. Architecturally, putting liveness reporting into the IGP is just a bad idea, for all of the reasons that we’ve already articulated, repeatedly. Our arguments have met with stubborn and somewhat disrespectful rejection without clear rationale about why our arguments are incorrect. This does not build consensus. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
