Re: [CCAMP] OVRLY - signaling extensions

["Adrian Farrel" <[e-mail]>]

H Pawel,

> On the side note, I believe that e-mail exchange on the
> group does not push us in any direction. It really does
> seem people are sending e-mails just for the sake of 
> conversation. 

Please don't take that tone (unless, maybe, you were referring to yourself :-).

I have found the exchanges useful. They have caused me to go back and look at I-Ds that people have referenced (and to realise they said things I didn't recall that they said). 

More importantly, they caused me to understand better the line between fixing stuff to work with what we have, and dreaming up new extensions for a potential use in the future.

> If you are interested in discussing the points I’ve raised, I’ll be happy
> to have a conference call with you. If not, no problem than, let’s just
> forego this topic.

It's OK if you want to drop out of the discussion, and it's OK for you to talk to whoever you please, but please don't suggest that I should not talk about this topic on this list.

Anyway, your revised email says:

> I believe everybody agrees that there is a need in signaling for
> indication that “this service should be diverse from services/
> paths A-Z”, since it is a generic extension.

But there we go, I have to dash your belief.
The problem is that you are talking about "services". 
A "service" is "connectivity" not "a connection".
You don't talk about a service having diversity, you talk about it having resilience. The resilience is achieved by mapping the service request to a number of underlying connections and to making those connections observe a number of diversity and protection group relationships.

I don't know whether your use of "service" was accidental and you meant "LSP" or whether it indicates a more fundamental issue.

I think that for a transport equipment provider (I was one) there is a tendency to think of addressing a request of an LSP as providing a service. But it isn't except in the most simple case of a service.

This is the thing I have been banging on about for a while. The UNI is not a service request interface it is an LSP signaling interface. 

> I agree with Adrian, from architectural perspective, there needs to
> be a line beyond which putting steroids into a protocol becomes a 
> mess. E.g. I hope there will be no attempts to overcome multi-homed
> clients’ deficiencies via extensions to signaling.

Nice to be agreed with once in a while.
But, of course, we have a number of I-Ds kicking about that are trying to do exactly this. It isn't clear to me that the line is being drawn and features are creeping.

Adrian