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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Mar 2014 05:46:34 +0000

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, February 28, 2014 4:36 PM
To: zali <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

>Zafar,
>	I think you miss-parsed my words.  the instances I witnessed were rare.
>The protocol behaved as designed.
>
>Lou

Hi Lou and all: 

This is consistent with my experience - it works! The onus is on the
writer of this draft to connivence the WG that... Given the existing
"generalized" mechanisms work and are deployed, why we need to add
"technology specific" methods. LSPs in transport networks are long lived
and the setup rate is low; reducing signaling loop for Perr does not cut
it, IMO.  

I am all for writing an Info draft or a BCP doc, if it helps the
community. 

Thanks

Regards Š Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Mar 2014 08:05:06 +0000

John-

It is very unfair to quote snippet from a different and out-of-context thread/ conversation.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 1:02 PM
To: zali <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Network Assigned Upstream Label - Draft Update

Zafar,

Actually, it was *you* that used the P-word:

“For the other cases, please note that just because optical network is running GMPLS UNI for client interface does not mean that it is running RSVP-TE for the optical trail management. E.g., optical trail management can still using an already deployed proprietary mechanisms or an NMS based scheme.”

Thanks

Regards … Zafar”

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Friday, February 28, 2014 8:09 AM
To: John E Drake; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi-

Yes, if you call explicit text in RFC3473 and draft-ietf-ccamp-wson-signaling-06 as proprietary, please go ahead.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 10:05 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Network Assigned Upstream Label - Draft Update

Right, in your proprietary non-GMPLS product.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 28, 2014 7:00 AM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Pavan:

The acceptable label set is picked from the label set (e.g., one of the labels from the label set). So it's not a compromised solution. It works and is deployed.

Thanks

Regards … Zafar

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 9:16 AM
To: "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Vishnu,

On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> 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

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 3 Mar 2014 16:49:53 +0000

Gert,

back to the discussion (hope not to another flame ;-) )

Is there any name you use for the line between A and F? Sound like some sort of [U|E]NI … right?

Cheers
G

On 28 Feb 2014, at 15:53, Gert Grammel <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> on behalf of Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 28, 2014 3:44:33 PM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Friday, February 28, 2014 9:16 AM
To: Giovanni Martinelli (giomarti)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni, Hi!

Regards,
-Pavan

Cheers
G