Les,
> I am not convinced we are going to converge. I concur. I propose that we agree to disagree. > Note that my goal/expectation is not that one of us convinces the other as to > what is “best”. It is simply to get a clearer understanding regarding our > points of disagreement. But I am now less optimistic about that being > achievable. I think that we have achieved clarity. :-) > 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. > > [LES:] Your response mystifies me. I do not know how “static prefix > assignment” is relevant. I wasn’t proposing “dynamic prefix assignment”. Ok, would you be happier with ’static prefix advertisement’? > I was just trying to illustrate that prefixes covered by the summary could be > advertised using existing IGP advertisements even when the summary is being > advertised. > It is still reachability. The determination of when to advertise the prefix > and when not to is still based upon whether the ABR has a path to the prefix > based on latest SPF calculation. That smells much more like liveness. This is one disagreement. > You choose to rename such an advertisement as “liveness” rather than > “reachability” for no reason that I can see. It then allows you claim an > “architectural violation” – but this to me is a meaningless distraction. > I was hoping to get rid of this distraction – but no such luck I see. There’s very good reason. We make address assignments to areas so that we have a mapping from prefixes to topology. We make this a static mapping so that we don’t have to deal with continual flap. If a host within the prefix is up, then it is reachabie within that portion of the topology. That static property is what we call ‘reachability’. > No, it doesn’t. Static summarization is the preferred approach. It’s stable. > > > [LES:] This wasn’t the point of the example. It is the point of our disagreement. > I wasn’t promoting the example as desirable deployment choice. I was only > illustrating that it is the change in reachability(sic) that is the event. > With current IGP advertisements we would (of course) stop advertising > reachability when we do not have a path to a given prefix. The new > advertisements propose to advertise the loss of reachability to destinations > which are covered by a summary. That has advantages over a withdrawal (the > absence of an advertisement). While that is still distasteful for scalability reasons, that would be preferable to injecting additional information at failure time. What advantages does that have? > If you want to say that an operator should only have two choices: > a)Advertise a summary or > b)Advertise all reachable prefixes covered by a summary > > I understand your POV even if I do not agree with it. > But please do not obfuscate things by claiming a reachability advertisement > is now something else when it is triggered by the same event i.e., a change > in the reachability to a given destination. I would not say that. I think that the choices are simpler: a) Advertise a summary. b) Don’t bother with hierarchy. > 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? > > [LES:] This is one of many possible tools to address scaling issues. (I have > previously suggested others) Clearly this is only of benefit if, in a given > deployment, the number of prefixes for which loss of reachability > notifications is desired is modest and/or if used in conjunction w other > tools. > Please do not twist my words. I’m not trying to twist them, I’m trying to understand them. Tagging is not, in and of itself, a limitation. Harsh experience with previous scalability issues has taught me that what we think of as ‘modest’ becomes the customer’s version of ‘unlimited’. If there are other mechanisms, other than some arbitrary limit, they haven’t been discussed. We’re proposing new mechanisms. We need to understand how they will be used in the field and we know that they will be abused in the worst ways possible. My concern is never about 1 or 2 additional prefixes. My concern is that it becomes tens of thousands and expectations that they propagated in 10ms even with a mass failure. Our job is to ensure that the worst possible conditions still work. I’m not yet convinced and I don’t think we should be solving this in the IGP. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
