Re: [CCAMP] OVRLY - signaling extensions

[Paweł Brzozowski <[e-mail]>]

Adrian,

I take your point. I'll work on my tone. It was never my intention to insult anybody.

Now, on the technical side.

You raise a very interesting point: " The UNI is not a service request interface it is an LSP signaling interface." I agree, that obviously an lsp and not a service is signaled via UNI. But ... lsp signaling can trigger the network to create a service, which provides the connectivity for the client lsp. Do you agree with this statement? E.g. in OIF UNI 2.0 specification, there is a "service level" RSVP sub-object, which allows the client lsp to tell the network the capabilities of supporting hierarchical service, e.g. whether it should be restorable, reversible, have 1+1 protection, etc. 

You are right, I used unfortunate wording when I said "this service should be diverse from services/ paths A-Z". What I should have said is the following: path of this lsp should be diverse from a list of paths of some lsps. From my perspective it's crucial how the list of these paths is specified. For overlay networks, I think that ideal solution should allow:

a) to specify paths to be diverse from only once during setup of client lsp and require no updates afterwards. In particular it would be impractical if diversity specification would need to change in case referenced client lsps went through make-before-break and hence changed their IDs and possibly paths (e.g. in case restoration happened in client layer)
b) some diversity toggles like link-disjoint, node-disjoint, diversity required only on setup/diversity required to be maintained throughout the lifetime of lsp, what should network do if diversity cannot be maintained when performing restoration, etc.
c) (optional) in case client lsps are supported by hierarchical services with restoration or protection, to specify what does being diverse from a client lsp really mean for the network, e.g. should the protection legs of hierarchies be diverse from each other.

I do like the proposal of how the paths could be referenced in draft-ietf-ccamp-lsp-diversity. I believe that if paths to be diverse from were referenced by session object of client lsps, this would suit point (a) very well, i.e. path will be disjoint from all client lsps matching the session.

IMHO the diversity specification applies to client-network interface, irrespective of the protocols used on the boundary. This information could be used by the network for constraining path computation of hierarchical services supporting client lsps when e.g. performing restoration of hierarchical services due to failure in optical network. This obviously implies that network can:
* extract the needed information from client lsps
* translate client lsp identifiers into EROs meaningful to the network
* apply those EROs as constraints for path computation

But a solution like stateful PCE should be able to handle this.

Regards,
Pawel

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Wednesday, March 19, 2014 6:34 PM
To: Paweł Brzozowski; 'Zhangxian (Xian)'; 'Gert Grammel'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

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