Re: [CCAMP] Network Assigned Upstream Label - Draft Update

["Zafar Ali (zali)" <[e-mail]>]

Hi Gert-

Yes, it may require Perr for label correction but it works, deployed and is based on what is already documented in RFC3473 and wson-signaling WG document. What you are asking for is a "redundant/ duplicate" method just for the sake of an academic optimization!

Thanks

Regards … Zafar

From: Gert Grammel <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 28, 2014 11:29 AM
To: zali <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>, "Giovanni Martinelli (giomarti)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Zafar,

I was responding to Giovanni's comment: GM> for the wson case the LABEL_SET might be an output from the RWA process, so the signalling likely pick up a good label first time.

So the ingress has to take an educated decision to get to a 'good label'. However in a world where the ingress has no idea of which label is available, it is not 'educated' and simply has to guess.
This is related to visibility a client may have of the network. Full, partial or none. (You can translate this into your preferred model)

Network assigned upstream labels can work well in either case as there is no pre-knowledge about labels assumed.

Gert


________________________________
From: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 28, 2014 5:04:34 PM
To: Gert Grammel; Igor Bryskin; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Gert-

What label has to do with overlay vs. peer? If so, there is a terminology document in this area that WG is working on – please contribute to it first.

Thanks

Regards … Zafar

From: Gert Grammel <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 28, 2014 9:53 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>, "Giovanni Martinelli (giomarti)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni,

In other words, ACCEPTABLE_LABEL_SET is a mechanism that can work in a peer-to-peer model where label information is shared beforehand. It is not adequate for an overlay case where no label information is shared between client and network.

Gert

________________________________
From: CCAMP <[e-mail]<mailto:[e-mail]>> on behalf of Igor Bryskin <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 28, 2014 3:44:33 PM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi,
It is funny that we have to go through the same arguments again and again every 4 months :=)
One point that I made when I was 4 months younger is that Acceptable Label Set is an exceptionally bad idea in the context of overlay networks (UNI, ENNI, etc.). Consider the following scenario:

1.      Ingress UNI-C guesses upstream label for its LSP L to be X;

2.      Network made its own decision that the upstream label cannot be X - has to be Y. This decision is a function of many things: selected path, capabilities of network nodes along the path, capabilities of egress UNI-C. etc. *Only when the entire tail of client LSP is established the ingress UNI-N can definitively report the acceptable upstream label;* The point is that the signaled acceptable label set cannot contain more than one value.

3.      If label Y is not acceptable for ingress UNI-C, it will have no other choice other than to guess another upstream label Z, and start the process again;

4.      This can go on for quite a while until ingress UNI-C runs out of guesses and gives up.

Cheers,
Igor

From: CCAMP [mailto:[e-mail]] On Behalf Of Vishnu Pavan Beeram
Sent: Friday, February 28, 2014 9:16 AM
To: Giovanni Martinelli (giomarti)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni, Hi!

Can you please elaborate on why you think the LABEL_SET having good labels help in this context/argument? If the upstream-node doesn't guess right (when picking the upstream-label), you'll get a PATH-ERR back with the ACCEPTABLE_LABEL_SET. And this would happen for every setup request. Wouldn't you call this a compromised solution?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 7:54 AM, Giovanni Martinelli (giomarti) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Vishnu,

On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>> wrote:


(2) The use of Label-Set/Acceptable Label-Set was meant to be used for exceptions. Using it always for every setup request is a compromised solution.


At the time we discussed the wson signaling (http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the acceptable label set was considered good enough. Not sure it comes into play at every request since your label_set should have reasonably good labels.

Cheers
G