Subject: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 3 Nov 2013 16:11:41 +0000

Hi Igor and co-authors-

Please note that [RFC3473] already considers the case where upstream label may not be acceptable to a downstream node. Specifically, [RFC3473] states that:
"when a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set Object".
Acceptable_Label_Set objects may be carried in PathErr and ResvErr messages [RFC3473].

However, your draft does not mention or cover this already defined method.

Thanks

Regards … Zafar

---

From: John E Drake <[email-masked]>
Date: Sun, 3 Nov 2013 16:57:32 +0000

Zafar,
That because this already defined method has the following issues:
1)  Using an error indication as a part of normal protocol operation is not good design practice
2)  Acceptable Label Set is optional so its presence is not guaranteed
3)  The information it provides may be out of date by the time the LSP is re-signaled
4)  Most importantly, Acceptable Label Set is generated hop by hop, unlike Upstream Label Set which exercises the entire path.  This means that its use to determine a valid wavelength would require a potentially unbounded number of crankbacks, both single and multi-hop, with no guarantee that such a wavelength could be found.
Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Sunday, November 03, 2013 8:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Igor and co-authors-

Thanks

Regards ... Zafar

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 4 Nov 2013 06:16:02 +0000

Thanks John. Let me add a couple of comments that are along the same lines as yours.

1.      As you correctly pointed out, in the UNI scenario ingress UNI-N represents not just itself. In particular, in case of alien wavelength it can specify exactly one label in the acceptable label set - the one that has been already agreed upon by all nodes along the path (including the egress UNI-C), allocated and bound into the cross-connects. The question is what the ingress UNI-C is supposed to do if it does not like the label signaled in the acceptable label set? In this case the ingress UNI-C has no other choice but to tear down the LSP and try the setup again via *guessing* another upstream label, This potentially means a very lengthy ping-pong exacerbated by the fact that the disagreement wrt upstream label is discovered at the latest stage of each iteration;

2.      From the point of view of data plane both directions of a bi-directional LSP are equally important. So it does not make much sense to have a rather flexible way for the label negotiation in one direction, and such a clumsy way to do so for the opposite direction.

3.      Today we do not have a way to say that the upstream label must be assigned by the network, Nor we have a way to say that a given bi-directional LSP must use the same label(s) in both directions, i.e. to be label-symmetrical, while this is by far the most important use case for WDM G LSPs.
Hence the enhancements introduced by the draft.
Cheers,
Igor

From: John E Drake [mailto:[email-masked]]
Sent: Sunday, November 03, 2013 11:58 AM
To: Zafar Ali (zali); Igor Bryskin
Cc: [email-masked]
Subject: RE: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Zafar,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Sunday, November 03, 2013 8:12 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Igor and co-authors-

Thanks

Regards ... Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 4 Nov 2013 06:51:11 +0000

Hi John:

Please see in-line.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 3, 2013 11:57 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Zafar,
That because this already defined method has the following issues:
1)  Using an error indication as a part of normal protocol operation is not good design practice.
Use of Path error and notify message is an integral part of the RSVP-TE design. Also please note that we are not debating about a new procedure being proposed but talking about a procedure that is already implemented and deployed.
2)  Acceptable Label Set is optional so its presence is not guaranteed
So is the case of newly defined upstream label set. Also please note that many part of the RSVP-TE protocol are designed using optional objects.
3)  The information it provides may be out of date by the time the LSP is re-signaled.
This is an implementation issue. A node sending the acceptable label set has the responsibility to guarantee that information provides in the acceptable label set remains valid for re-signaling time. E.g., UNI-N implementation can cache the label for the re-signaling time.
4)  Most importantly, Acceptable Label Set is generated hop by hop, unlike Upstream Label Set which exercises the entire path.  This means that its use to determine a valid wavelength would require a potentially unbounded number of crankbacks, both single and multi-hop, with no guarantee that such a wavelength could be found.
In the use case of align wavelength addressed in this draft, the acceptable label set communication is restricted to the UNI-C and UNI-N node.
Yours Irrespectively,

John

Hi Igor and co-authors-

Thanks

Regards … Zafar

---

From: John E Drake <[email-masked]>
Date: Mon, 4 Nov 2013 15:26:11 +0000

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Sunday, November 03, 2013 10:51 PM
To: John E Drake; [email-masked]
Cc: [email-masked]
Subject: Re: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi John:

Please see in-line.

Thanks

Regards ... Zafar

Zafar,

[JD] You missed the part about "normal protocol operation".'

[JD]  The combination of it being useless and optional is definitely a winning combination.

[JD]  So, each node in the network is going to reserve all of the labels associated with every acceptable label set it has issued.  The combination of this and 4) is almost guarantees network gridlock.

[JD]  That's completely incorrect.  The same procedures are used inside the server network.

Yours Irrespectively,

John

Hi Igor and co-authors-

Thanks

Regards ... Zafar

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 4 Nov 2013 16:57:31 +0000

Zafar,

IB>> The way I interpret this discussion is something like this:

John: I believe that white is a lighter color than black.
Zafa: Well, John, black is an integral part of the color pallet. Many mature applications successfully use black for their various purposes. My implementations, for example, use black for pretty much everything..... So, it is not clear which color is lighter, and why do we need other colors at all. :=)

I mean to say that your, Zafar, comments IMHO are not constructive technical arguments.
Igor

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, November 04, 2013 1:51 AM
To: John E Drake; Igor Bryskin
Cc: [email-masked]
Subject: Re: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi John:

Please see in-line.

Thanks

Regards ... Zafar

Zafar,

John

Hi Igor and co-authors-

Thanks

Regards ... Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 4 Nov 2013 17:42:35 +0000

Igor, John-

Please see in-line.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 4, 2013 8:57 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Zafar,

John: I believe that white is a lighter color than black.
Zafa: Well, John, black is an integral part of the color pallet. Many mature applications successfully use black for their various purposes. My implementations, for example, use black for pretty much everything….. So, it is not clear which color is lighter, and why do we need other colors at all. :=)

Hi Igor and John:

This is really funny. This is the first time I have heard that running code has no merit at IETF :) This is especially when the running code is directly coming from RFC3473. You are calling it "not constructive technical arguments"! Last I heard we believed in running code (See your T-shirt from the election day from IETF Atlanta).

Your draft is ONLY applicable for a use case where upstream and downstream alien wavelength are different. When upstream and downstream alien wavelength are same, use of acceptable label set and label set objects constitute the running code. However, your draft neither makes that applicability statement nor makes any mention or cover or reference to procedure I quoted from RFC3473.

Thanks

Regards…Zafar

Hi John:

Please see in-line.

Thanks

Regards … Zafar

Zafar,

John

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)

Hi Igor and co-authors-

Thanks

Regards … Zafar

---

From: John E Drake <[email-masked]>
Date: Mon, 4 Nov 2013 18:24:40 +0000

Zafar,

Both Igor and I have listed technical issues with RFC3473 and your response is that you really really like RFC3473.  I'm happy for you but unimpressed.

John

Sent from my iPhone

On Nov 4, 2013, at 9:43 AM, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>> wrote:

Igor, John-

Please see in-line.

Zafar,

Hi Igor and John:

Thanks

Regards…Zafar

Hi John:

Please see in-line.

Thanks

Regards … Zafar

Zafar,

John

Hi Igor and co-authors-

Thanks

Regards … Zafar

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Nov 2013 14:18:34 -0500

John, (authors)

	Perhaps it would be useful to refocus a moment on the specific
limitations the draft is focusing on.

There's no question that 3473 made certain choices based on expected
uses and probabilities that may not hold, but we do need to be careful
when changing fundamentals of the protocol (e.g. moving away from the
use of the upstream label object as the basic object that indicates a
bidirectional LSP.)

So is it fair to say that the main limitation that the draft is trying
to address is the inability to support downstream selection of upstream
labels?

The draft also allows for both symmetric and asymmetric label value
allocation.  IS this a requirement, or asymmetric just included for
completeness?

Are there other requirements / limitations you are trying to address?

Lou

On 11/04/2013 01:24 PM, John E Drake wrote:
> Zafar,
> 
> Both Igor and I have listed technical issues with RFC3473 and your
> response is that you really really like RFC3473.  I'm happy for you but
> unimpressed.
> 
> John
> 
> Sent from my iPhone
> 
>> From: "[email-masked] <mailto:[email-masked]>"
>> <[email-masked] <mailto:[email-masked]>>
>> To: zali <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>> Subject: RE: Comments about
>> draft-beeram-ccamp-network-assigned-upstream-label-00
>>
>>     Zafar,
>>
>>     Use of Path error and notify message is an integral part of the
>>     RSVP-TE design. Also please note that we are not debating about a
>>     new procedure being proposed but talking about a procedure that is
>>     already implemented and deployed. 
>>
>>      
>>
>>     Zafa: Well, John, black is an integral part of the color pallet.
>>     Many mature applications successfully use black for their various
>>     purposes. My implementations, for example, use black for pretty
>>     much everything….. So, it is not clear which color is lighter, and
>>     why do we need other colors at all. :=)
>>
>>      
>>
>> This is really funny. This is the first time I have heard that running
>> code has no merit at IETF :) This is especially when the running code
>> is directly coming from RFC3473. You are calling it "not constructive
>> technical arguments"! Last I heard we believed in running code (See
>> your T-shirt from the election day from IETF Atlanta). 
>>
>> Your draft is ONLY applicable for a use case where upstream and
>> downstream alien wavelength are different. When upstream and
>> downstream alien wavelength are same, use of acceptable label set and
>> label set objects constitute the running code. However, your draft
>> neither makes that applicability statement nor makes any mention or
>> cover or reference to procedure I quoted from RFC3473. 
>>
>> Thanks
>>
>> Regards…Zafar 
>>
>>      
>>
>>      
>>
>>     *From:*Zafar Ali (zali) [mailto:[email-masked]]
>>     *Sent:* Monday, November 04, 2013 1:51 AM
>>     *To:* John E Drake; Igor Bryskin
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: Comments about
>>     draft-beeram-ccamp-network-assigned-upstream-label-00
>>
>>      
>>
>>     Hi John: 
>>
>>      
>>
>>     Please see in-line. 
>>
>>      
>>
>>     Thanks
>>
>>      
>>
>>     Regards … Zafar
>>
>>      
>>
>>     *From: *"[email-masked] <mailto:[email-masked]>"
>>     <[email-masked] <mailto:[email-masked]>>
>>     *Date: *Sunday, November 3, 2013 11:57 AM
>>     *To: *zali <[email-masked] <mailto:[email-masked]>>,
>>     "[email-masked] <mailto:[email-masked]>"
>>     <[email-masked] <mailto:[email-masked]>>
>>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Subject: *RE: Comments about
>>     draft-beeram-ccamp-network-assigned-upstream-label-00
>>
>>      
>>
>>         Zafar,
>>
>>     Use of Path error and notify message is an integral part of the
>>     RSVP-TE design. Also please note that we are not debating about a
>>     new procedure being proposed but talking about a procedure that is
>>     already implemented and deployed. 
>>
>>     So is the case of newly defined upstream label set. Also please
>>     note that many part of the RSVP-TE protocol are designed using
>>     optional objects. 
>>
>>     This is an implementation issue. A node sending the acceptable
>>     label set has the responsibility to guarantee that information
>>     provides in the acceptable label set remains valid for
>>     re-signaling time. E.g., UNI-N implementation can cache the label
>>     for the re-signaling time. 
>>
>>         4)  Most importantly, Acceptable Label Set is generated hop by
>>         hop, unlike Upstream Label Set which exercises the entire
>>         path.  This means that its use to determine a valid wavelength
>>         would require a potentially unbounded number of crankbacks,
>>         both single and multi-hop, with no guarantee that such a
>>         wavelength could be found.
>>
>>     In the use case of align wavelength addressed in this draft, the
>>     acceptable label set communication is restricted to the UNI-C and
>>     UNI-N node. 
>>
>>         Yours Irrespectively,
>>
>>          
>>
>>         John
>>
>>          
>>
>>         *From:[email-masked] <mailto:[email-masked]>
>>         [mailto:[email-masked]] *On Behalf Of *Zafar Ali (zali)
>>         *Sent:* Sunday, November 03, 2013 8:12 AM
>>         *To:* [email-masked] <mailto:[email-masked]>
>>         *Cc:* [email-masked] <mailto:[email-masked]>
>>         *Subject:* [CCAMP] Comments about
>>         draft-beeram-ccamp-network-assigned-upstream-label-00
>>
>>          
>>
>>         Hi Igor and co-authors- 
>>
>>          
>>
>>         Please note that [RFC3473] already considers the case where
>>         upstream label may not be acceptable to a downstream
>>         node. Specifically, [RFC3473] states that:
>>
>>         "/when a Path message containing an Upstream_Label object is
>>         received, the receiver first verifies that the upstream label
>>         is acceptable. If the label is not acceptable, the receiver
>>         /*MUST*/issue a PathErr message with a "Routing
>>         problem/Unacceptable label value" indication. The generated
>>         PathErr message MAY include an Acceptable Label Set Object/". 
>>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 4 Nov 2013 21:51:24 +0000

Hi Lou,
Please, see my comments in-line.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, November 04, 2013 2:19 PM
To: John E Drake; Zafar Ali (zali)
Cc: [email-masked]
Subject: Re: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

John, (authors)

	Perhaps it would be useful to refocus a moment on the specific limitations the draft is focusing on.

There's no question that 3473 made certain choices based on expected uses and probabilities that may not hold, but we do need to be careful when changing fundamentals of the protocol (e.g. moving away from the use of the upstream label object as the basic object that indicates a bidirectional LSP.)

IB>> There is no intention to do so.

So is it fair to say that the main limitation that the draft is trying to address is the inability to support downstream selection of upstream labels?

IB>> Correct. Considering that both directions are equally important for the LSP user, it does not make much sense to have different tools to negotiate labels in each direction.
But there are other limitations as well. See below.

The draft also allows for both symmetric and asymmetric label value allocation.  IS this a requirement, or asymmetric just included for completeness?

IB>> Even in case of WDM layer there are scenarios (e.g. single-fiber configurations) when the same wavelength cannot be used for both directions. For non-WDM layer it is perfectly OK to use label-asymmetrical LSPs. So we do want to maintain both options.

Are there other requirements / limitations you are trying to address?
IB>> Today there is no way to *require* a bi-directional LSP to be label-symmetrical.

Lou

On 11/04/2013 01:24 PM, John E Drake wrote:
> response is that you really really like RFC3473.  I'm happy for you 
> but unimpressed.
> 
> John
> 
> Sent from my iPhone
> 
>> To: zali <[email-masked] <mailto:[email-masked]>>, 
>> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>     much everything..... So, it is not clear which color is lighter, and
>> This is really funny. This is the first time I have heard that 
>> running code has no merit at IETF :) This is especially when the 
>> running code is directly coming from RFC3473. You are calling it "not 
>> constructive technical arguments"! Last I heard we believed in 
>> running code (See your T-shirt from the election day from IETF Atlanta).
>>
>> Regards...Zafar

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 4 Nov 2013 17:49:48 -0500

Lou,

The extensions defined in this draft do not impose any backwards
compatibility issues. The intent is definitely not to change the
fundamental aspects of the protocol. As you would agree, it is not
mandatory to try and fit the extensions defined in RFC3473 to all and
sundry. New extensions are being introduced only where the existing
extensions fall short. Let me walk through the requirements that we are
looking at and that would hopefully explain the limitations of the existing
extensions.

Base requirement  :
Need a mechanism for a given node to say that it cannot assign an
upstream-label on its own and that it needs the network (read downstream)
to assign it instead.

Corollary requirements :
1. Need a mechanism for a given node to ask for a network-assigned upstream
label without having to specify any inputs on what label needs to get
picked.
2. Need a mechanism for a given node to ask for a network-assigned upstream
label and also specify some choices for the label that needs to get picked.
3. If labels are symmetric, a given node can simply use the label returned
in the LABEL object of the RESV message for both directions. In practice,
most bidirectional LSPs have label symmetricity on each hop along the path
of the LSP. But this is something that cannot be assumed by default. Hence,
there is a need to have a mechanism for the ingress to request "label
symmetricity" at each hop along the path of the LSP.

Can you somehow fit  a solution using the current extensions and cater to
the above requirements?
We believe the answer is NO. One suggestion on the mailing list was to set
a random UPSTREAM_LABEL and send it out on a fishing expedition. The idea
was that the downstream node would then respond with a PATH-ERR carrying an
ACCEPTABLE_LABEL_SET. John and Igor have provided a list of reasons on why
that isn't a great idea. Let me add another point -
- As per RFC3473 - when a node receives an UPSTREAM_LABEL object in the
PATH, it means that the upstream node MUST have already
installed/programmed this label. In the alien wavelength use-case
(discussed in the draft), when the network receives this message,  it would
mean that the laser has already been tuned to this wavelength at the
client. That beats the very purpose of requesting a network assigned
upstream label. Doesn't it? So, the point is that with the current
semantics of an UPSTREAM_LABEL, you cannot use it for the case where the
upstream-label hasn't been installed/programmed yet. If some implementation
decides to ignore these semantics, how would the network know whether the
ingress-client has already installed this label or not (whether the laser
is already tuned or not).

RFC3473 states that a Bidirectional-LSP setup request is identified by the
presence of an "UPSTREAM_LABEL" object in the PATH msg. This draft does
propose 2 other mechanisms:
- The presence of the "Label Symmetricity Required" Flag in the PATH
- The presence of the "UPSTREAM_LABEL_SET" object in the PATH
If a downstream node does not understand any of the above indications, it
would reject the setup request. In both scenarios - after the network has
assigned the upstream-label, the concerned node is allowed to start
signaling the UPSTREAM_LABEL object in the PATH. I don't understand how
adding two other mechanisms for Bidirectional LSP setup translates to
changing fundamental aspects of the protocol. Implementations that can
support these extensions can. Others can still be happy with their "running
code".

Regards,
-Pavan

On Mon, Nov 4, 2013 at 2:18 PM, Lou Berger <[email-masked]> wrote:

> >>         *To:* [email-masked] <mailto:[email-masked]
> >

---

From: Julien Meuric <[email-masked]>
Date: Tue, 05 Nov 2013 03:35:43 +0100

Hi Pavan.

Even though I agree with your unassigned Upstream_Label requirement, I 
need to disagree with the data plane rationale you mention.

The Upstream_Label refers to the client's optical receiver: you don't 
need to tune a laser on the receiver side. The data transmission could 
even work without sending the actual Upstream_Label in RSVP-TE messages 
to the client: I am not really a fan of that approach, but that would 
fit cases where optical policies are left to the optical network...

Moreover, I have doubts on putting label symmetry within the protocol. 
This is more an allocation policy in the hands of allocating nodes: 
requesting an allocation mode from an ingress node would mean doing the 
server job, I am not sure it is desirable.

Julien

On 11/04/2013 23:49, Vishnu Pavan Beeram wrote:
> extensions fall short. Let me walk through the requirements that we 
> are looking at and that would hopefully explain the limitations of the 
> existing extensions.
>
> Base requirement :
> upstream-label on its own and that it needs the network (read 
> downstream) to assign it instead.
>
> Corollary requirements :
> 1. Need a mechanism for a given node to ask for a network-assigned 
> upstream label without having to specify any inputs on what label 
> needs to get picked.
> 2. Need a mechanism for a given node to ask for a network-assigned 
> upstream label and also specify some choices for the label that needs 
> to get picked.
> 3. If labels are symmetric, a given node can simply use the label 
> returned in the LABEL object of the RESV message for both directions. 
> In practice, most bidirectional LSPs have label symmetricity on each 
> hop along the path of the LSP. But this is something that cannot be 
> assumed by default. Hence, there is a need to have a mechanism for the 
> ingress to request "label symmetricity" at each hop along the path of 
> the LSP.
>
> Can you somehow fit a solution using the current extensions and cater 
> to the above requirements?
> We believe the answer is NO. One suggestion on the mailing list was to 
> set a random UPSTREAM_LABEL and send it out on a fishing expedition. 
> The idea was that the downstream node would then respond with a 
> PATH-ERR carrying an ACCEPTABLE_LABEL_SET. John and Igor have provided 
> a list of reasons on why that isn't a great idea. Let me add another 
> point -
> - As per RFC3473 - when a node receives an UPSTREAM_LABEL object in 
> the PATH, it means that the upstream node MUST have already 
> (discussed in the draft), when the network receives this message, it 
> would mean that the laser has already been tuned to this wavelength at 
> the client. That beats the very purpose of requesting a network 
> assigned upstream label. Doesn't it? So, the point is that with the 
> current semantics of an UPSTREAM_LABEL, you cannot use it for the case 
> where the upstream-label hasn't been installed/programmed yet. If some 
> implementation decides to ignore these semantics, how would the 
> network know whether the ingress-client has already installed this 
> label or not (whether the laser is already tuned or not).
>
> RFC3473 states that a Bidirectional-LSP setup request is identified by 
> the presence of an "UPSTREAM_LABEL" object in the PATH msg. This draft 
> does propose 2 other mechanisms:
> If a downstream node does not understand any of the above indications, 
> it would reject the setup request. In both scenarios - after the 
> network has assigned the upstream-label, the concerned node is allowed 
> to start signaling the UPSTREAM_LABEL object in the PATH. I don't 
> understand how adding two other mechanisms for Bidirectional LSP setup 
> translates to changing fundamental aspects of the protocol. 
> Implementations that can support these extensions can. Others can 
> still be happy with their "running code".
>
> Regards,
> -Pavan
>
>
>
> On Mon, Nov 4, 2013 at 2:18 PM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     John, (authors)
>
>     > On Nov 4, 2013, at 9:43 AM, "Zafar Ali (zali)" <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >> Igor, John-
>     >>
>     >> Please see in-line.
>     >>
>     >> From: "[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>"
>     >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> To: zali <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     "[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>"
>     <[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> Cc: "[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     running
>     >> *From:*Zafar Ali (zali) [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >> *From: *"[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> *To: *zali <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     >> "[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> *Cc: *"[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >> [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Zafar Ali (zali)
>     >> *To:* [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 5 Nov 2013 03:38:08 +0000

Hi Pavan,

Understood what you said in principle, but could you give an example to show there are asymmertric labels (wavelength?) for the bidirectiaonal LSPs (especiall for the transport networks) in the real implementations?

================================================================================================================
In practice, most bidirectional LSPs have label symmetricity on each hop along the path of the LSP. But this is something that cannot be assumed by default.

Thanks

Fatai

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Julien Meuric [[email-masked]]
发送时间: 2013年11月5日 10:35
收件人: Vishnu Pavan Beeram
抄送: [email-masked]
主题: Re: [CCAMP] Comments about  draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Pavan.

Julien

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Nov 2013 20:00:00 -0800

Thanks Igor.  See below.

> IB>> There is no intention to do so.

I think you have proposed at least a couple of pretty major changes, but
if we focus on these details, we risk missing the main point -- so I'd
like to leave this until there is understanding, and perhaps agreement
on the requirement.

> IB>> Correct. Considering that both directions are equally important
> for the LSP user, it does not make much sense to have different tools
> to negotiate labels in each direction.
> 

Minimizing mechanisms / avoiding duplication is always a good design
objective.  Of course, this also means that if there is a defined
mechanism we should avoiding changing it unless there's good reason,
e.g., it's broken.

> IB>> Even in case of WDM layer there are scenarios (e.g. single-fiber
> configurations) when the same wavelength cannot be used for both
> directions. For non-WDM layer it is perfectly OK to use
> label-asymmetrical LSPs. So we do want to maintain both options.
> 

okay. it is good to differentiate desirable vs required capabilities.

> IB>> Today there is no way to *require* a bi-directional LSP to be label-symmetrical.

True.  This has always been a local allocation policy.  It's probably
worth describing in greater detail why you see it needs to be changed.

Thanks,
Lou
>> <mailto:[email-masked]>> wrote:
>>
>>> Igor, John-
>>>
>>> Please see in-line. 
>>>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 5 Nov 2013 07:29:18 +0000

Hi- 

Furthermore, when (alien) wavelength is same in forward and reverse
direction, we can use label set along with acceptable label set - as
defined in RFC3473. The only use case this draft addresses is when alien
wavelength are asymmetrical in forward and reverse direction. I am not
aware of any example of such use case.

Thanks

Regards … Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Monday, November 4, 2013 7:38 PM
To: "[email-masked]" <[email-masked]>, Vishnu Pavan
Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [CCAMP] 答复:  Comments
about	draft-beeram-ccamp-network-assigned-upstream-label-00

>Hi Pavan,
>
>Understood what you said in principle, but could you give an example to
>show there are asymmertric labels (wavelength?) for the bidirectiaonal
>LSPs (especiall for the transport networks) in the real implementations?
>
>In practice, most bidirectional LSPs have label symmetricity on each hop
>along the path of the LSP. But this is something that cannot be assumed
>by default.
>
>
>
>Thanks
>
>Fatai
>
>主题: Re: [CCAMP] Comments about
>>     >> I mean to say that your, Zafar, comments IMHO are not
>>constructive
>>     >> technical arguments.
>>     >>
>>     >> Igor
>>     >>
>>     >>
>>     >>
>>     >> Hi Igor and John:
>>     >>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 5 Nov 2013 08:25:03 -0500

I see a pattern in the questions that are being raised. I'll try and see if
I can answer them all using the following Q&A.

A. "Label Symmetricity":

(1) Aren't labels always symmetric in practice? Are there any asymmetric
label scenarios at all?
Ans: Yes, labels are almost always symmetric in practice. The draft
explicitly states that. I haven't come across any single scenario/product
where asymmetric labels are used. As Igor pointed out in an earlier email,
there could be in theory some single-fiber configurations where the same
wavelength cannot be used for both directions. But I don't know if anyone
really uses that.

(2) Then why do you need an explicit request from the ingress to make them
symmetric at each hop?
Ans: This is because the extensions in RFC3473 allows "Label Asymmetricity"
and and as a result symmetricity cannot be assumed by default. There is
currently no way of mandating symmetricity at each hop along the path of
the LSP.

(3) Say, we all agree that "Symmetricity" is always guaranteed (maybe we
even state it explicitly in some standard document). Would you then be able
to use existing extensions and address the "alien-wavelength" setup
use-case?
Ans: No, the existing extensions still fall short. What does the
ingress-client fill in the UPSTREAM_LABEL when it has no knowledge on what
needs to be used? As per current extensions, the UPSTREAM_LABEL needs to be
filled in with a valid label before sending the PATH out. We still need the
ingress-client to have some mechanism to tell the network - "please ignore
what I'm filling in the UPSTREAM_LABEL; just take the LABEL_SET into
account if I fill one; I'll use what is returned in the RESV-LABEL for both
directions."

(4) Label allocation has always been a local choice. Why should the ingress
request how labels are allocated at some downstream hop?
Ans: The ingress has always been the one to request the downstream node to
allocate labels in both directions. All that the draft is proposing is a
mechanism for the ingress to say that these two labels need to be symmetric.

B. "Label Asymmetricity"

(4) Have the "Label Asymmetricity" extensions been included just for
completion sake? Can those be jettisoned if we there is no need for
asymmetric labels?
Ans: Yes. The primary reason why those extensions are included in the draft
is because RFC3473 allows asymmetricity. We don't need to discuss those if
we explicitly state somewhere (in some standard document) that "labels are
always symmetric" and that all previous extensions defined for
asymmetricity are use-less.

C. "Use-Case"

(5) I don't understand any of the above. Why do we need the network to
assign an upstream label?
Ans: Please read the draft. Section 5 discusses a specific use-case.

Regards,
-Pavan

On Tue, Nov 5, 2013 at 2:29 AM, Zafar Ali (zali) <[email-masked]> wrote:

> >>     <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >>     <mailto:[email-masked] <mailto:[email-masked]
> >>"
> >>     <mailto:[email-masked] <mailto:[email-masked]
> >>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 5 Nov 2013 08:57:34 -0500

A small update to Question (1) - to clarify the context [There is no
non-WDM use-case discussed in the draft (yet) - so keeping the discussion
pertinent]

(1) Aren't labels always symmetric in practice at the WDM layer? Are there
any asymmetric label scenarios at all?
Ans: Yes, labels are almost always symmetric in practice at the WDM layer.
The draft explicitly states that. I haven't come across any single
WDM-layer scenario/product where asymmetric labels are used. As Igor
pointed out in an earlier email, there could be in theory some single-fiber
configurations where the same wavelength cannot be used for both
directions. But I don't know if anyone really uses that. (That said, the
extensions defined in the draft make no assumption of what the "label"
actually represents; they are applicable to all types of Bidirectional LSPs)

-Pavan

On Tue, Nov 5, 2013 at 8:25 AM, Vishnu Pavan Beeram
<[email-masked]>wrote:

> I see a pattern in the questions that are being raised. I'll try and see
> if I can answer them all using the following Q&A.
>
> A. "Label Symmetricity":
>
> Ans: This is because the extensions in RFC3473 allows "Label
> Asymmetricity" and and as a result symmetricity cannot be assumed by
> default. There is currently no way of mandating symmetricity at each hop
> along the path of the LSP.
>
> (4) Label allocation has always been a local choice. Why should the
> ingress request how labels are allocated at some downstream hop?
> Ans: Yes. The primary reason why those extensions are included in the
> draft is because RFC3473 allows asymmetricity. We don't need to discuss
> those if we explicitly state somewhere (in some standard document) that
> "labels are always symmetric" and that all previous extensions defined for

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 07:20:13 -0800

Pavan,
	I think this is helpful in trying to understand what the goals are of
the draft.  Again, I'll resist arguing about the mechanisms that are
proposed until we've agreed on what requirements need to be addressed.
(While the mechanism details, i.e., the "how", are certainly important,
arguing those doesn't really answer the larger question of "what" you'd
like to accomplish.)

So the list of requirements is now the addition of:
1. Downstream selection of the upstream label

2. An option to allow upstream node to provide set of labels that
   should be used in the downstream nodes' choice of upstream label

3. The use of symmetric labels when the downstream node
   is selecting the label.

4. Allowing for asymmetric labels is not a new requirement, nor do
   you really care about it.

Is this correct?

Thanks,
Lou

On 11/5/2013 5:25 AM, Vishnu Pavan Beeram wrote:
> explicitly states that. I haven't come across any single
> scenario/product where asymmetric labels are used. As Igor pointed out
> in an earlier email, there could be in theory some single-fiber
> directions. But I don't know if anyone really uses that. 
> 
> (2) Then why do you need an explicit request from the ingress to make
> them symmetric at each hop?
> even state it explicitly in some standard document). Would you then be
> able to use existing extensions and address the "alien-wavelength" setup
> use-case?
> ingress-client fill in the UPSTREAM_LABEL when it has no knowledge on
> what needs to be used? As per current extensions, the UPSTREAM_LABEL
> needs to be filled in with a valid label before sending the PATH out. We
> still need the ingress-client to have some mechanism to tell the network
> - "please ignore what I'm filling in the UPSTREAM_LABEL; just take the
> LABEL_SET into account if I fill one; I'll use what is returned in the
> RESV-LABEL for both directions."
> 
> Ans: The ingress has always been the one to request the downstream node
> to allocate labels in both directions. All that the draft is proposing
> is a mechanism for the ingress to say that these two labels need to be
> symmetric.
> 
> B. "Label Asymmetricity"
> 
> "labels are always symmetric" and that all previous extensions defined
> for asymmetricity are use-less.
> 
> C. "Use-Case"
> 
> On Tue, Nov 5, 2013 at 2:29 AM, Zafar Ali (zali) <[email-masked]
>     From: Fatai Zhang <[email-masked] <mailto:[email-masked]>>
>     To: "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>, Vishnu
>     Pavan
>     Beeram <[email-masked] <mailto:[email-masked]>>
>     >发件人: [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] 代表 Julien
>     Meuric
>     >[[email-masked] <mailto:[email-masked]>]
>     >发送时间: 2013年11月5日 10:35
>     >收件人: Vishnu Pavan Beeram
>     >抄送: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>     John, (authors)
>     >>
>     >>     use of the upstream label object as the basic object that
>     indicates
>     >>a
>     >>     bidirectional LSP.)
>     >>
>     >>     > On Nov 4, 2013, at 9:43 AM, "Zafar Ali (zali)"
>     <[email-masked] <mailto:[email-masked]>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >>     >
>     >>     >> Igor, John-
>     >>     >>
>     >>     >> Please see in-line.
>     >>     >>
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>>>"
>     >>     >> <[email-masked]
>     >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>,
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>"
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>" <[email-masked]
>     <mailto:[email-masked]>
>     >>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>     >> new procedure being proposed but talking about a procedure
>     that
>     >>is
>     >>     >> neither makes that applicability statement nor makes any
>     mention
>     >>or
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>]
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>"
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>,
>     >>     >> "[email-masked]
>     >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>"
>     >>     >> <[email-masked]
>     >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>" <[email-masked]
>     <mailto:[email-masked]>
>     >>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >>     >> new procedure being proposed but talking about a procedure
>     that
>     >>is
>     >>     >> *From:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     >>     >> [mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 5 Nov 2013 10:49:32 -0500

Lou,

Yes, your summarized points are correct.

Thanks,
-Pavan.

> arguing those doesn't really answer the larger question of "what" you'd

VPB: Agree.

> >     >>     when changing fundamentals of the protocol (e.g. moving away
> from
> >     >>the
> >     >>     So is it fair to say that the main limitation that the draft
> is
> >     >>trying
> >     >>     > response is that you really really like RFC3473. I'm happy
> for
> >     >>     you but
> >     >>     > unimpressed.
> >     >>     >
> >     >>     > John
> >     >>     >
> >     >>     > Sent from my iPhone
> >     >>     >
> >     >>     >> much everything….. So, it is not clear which color is
> lighter,
> >     >>and
> >     >>     >> technical arguments"! Last I heard we believed in running
> code
> >     >>(See
> >     >>     >> downstream alien wavelength are same, use of acceptable
> label
> >     >>     set and
> >     >>     >> label set objects constitute the running code. However,
> your
> >     >>draft
> >     >>     >> 3) The information it provides may be out of date by the
> time
> >     >>     >> the LSP is re-signaled.
> >     >>     >>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 5 Nov 2013 16:15:34 +0000

Lou,
Please, see in-line.

Igor

> IB>> There is no intention to do so.

I think you have proposed at least a couple of pretty major changes, but if we focus on these details, we risk missing the main point -- so I'd like to leave this until there is understanding, and perhaps agreement on the requirement.

IB>> Which in your opinion of proposed changes may cause problems for existing deployments?

> to negotiate labels in each direction.

Minimizing mechanisms / avoiding duplication is always a good design objective.  Of course, this also means that if there is a defined mechanism we should avoiding changing it unless there's good reason, e.g., it's broken.

IB>> This depends on the definition of "broken". I hope you agree that the whole business with the upstream label is meaningful only if one assumes that for a given bidirectional G- LSP labels for the forward and reverse directions do not match necessarily. This IMHO is a correct assumption even for WDM layer and also in accordance with RFC3473 addressing other layers as well. But if one makes such an assumption, one also has to assume that there could be distinct acceptable label sets in the forward and reverse directions. Let assume that ingress UNI-C likes labels 1,3,5,7,.... In forward direction and 2,4,6,8,... in reverse direction. When the UNI-C originates Path message, it specifies, for example:
Suggested DS label : 1; DS label set: 1,3,5,7,....; US label: 2
Let's assume that the network sets up the tail of the LSP with DS label = 3, and US label=7 (i.e. it cannot accommodate label 2 for whatever reason). According to RFC3473 UNI-N will send PathErr with the acceptable upstream label set consisting of exactly one label 7. Please, note that UNI-N in case of the WDM layer will always provide exactly one label in the acceptable upstream label set - the one which is already reserved by the network and egress UNI-C for this LSP. All other labels that might be available at the time of the path computation are not reserved and hence could be taken by other LSPs. The question is *what the ingress UNI-C is supposed to do with the signaled acceptable label 7, which is not acceptable for the ingress UNI-C as an upstream label?* It will have no other choice but to tear down the established G-LSP and to try it again, guessing another upstream label, e.g. 4. This potentially very lengthy ping-pong process will repeat itself until the ingress UNI-C either guesses correctly or runs out of guesses. Although it could take an hour to complete the process, technically the approach is not broken, however, unacceptable if compared to the one signaling round approach suggested in the draft.  

> IB>> Today there is no way to *require* a bi-directional LSP to be label-symmetrical.

True.  This has always been a local allocation policy.  It's probably worth describing in greater detail why you see it needs to be changed.

IB>> As John and Pavan mentioned many times already, for a UNI-C (e.g. router) in the majority of the cases it is required for upstream/downstream labels to be the same. It cannot afford to rely on the UNI-N local policies, which for whatever reason (e.g. existence of uni-directional P2P or P2MP G-LSPs) may locally decide to assign different labels. The point is that UNI-C has no way today to *request* the label symmetricity.  

Thanks,
Lou
>>> running code is directly coming from RFC3473. You are calling it 
>>> "not constructive technical arguments"! Last I heard we believed in 
>>> downstream alien wavelength are same, use of acceptable label set 
>>> and label set objects constitute the running code. However, your 
>>> draft neither makes that applicability statement nor makes any 
>>> mention or cover or reference to procedure I quoted from RFC3473.
>>>
>>> Thanks
>>>
>>> Regards...Zafar
>>>
>>>      
>>>
>>>      
>>>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 5 Nov 2013 16:20:12 +0000

I would add:
5. A way for US node (e.g. UNI-C) to mandate the label symmetricity.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, November 05, 2013 10:50 AM
To: Lou Berger
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Lou,

Thanks,
-Pavan.

On Tue, Nov 5, 2013 at 10:20 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Pavan,

VPB: Agree.

Is this correct?

Thanks,
Lou

On 11/5/2013 5:25 AM, Vishnu Pavan Beeram wrote:
> On Tue, Nov 5, 2013 at 2:29 AM, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi-
>
>     From: Fatai Zhang <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>"
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Vishnu
>     Pavan
>     Beeram <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >发件人: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>] 代表 Julien
>     Meuric
>     >[[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>]
>     >发送时间: 2013年11月5日 10:35
>     >收件人: Vishnu Pavan Beeram
>     >抄送: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     >> On Mon, Nov 4, 2013 at 2:18 PM, Lou Berger <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >>
>     >>     John, (authors)
>     >>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:
>     >>     >
>     >>     >> Igor, John-
>     >>     >>
>     >>     >> Please see in-line.
>     >>     >>
>     >>     >> From: "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>"
>     >>     >> <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> To: zali <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>,
>     >>     "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     >> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>"
>     >>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     >> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     >> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> *From:*Zafar Ali (zali) [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>]
>     >>     >> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     >>     >> *From: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>"
>     >>     >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> *To: *zali <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>,
>     >>     >> "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>"
>     >>     >> <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> *Cc: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     >> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>
>     >>     >> *From:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>
>     >>     >> [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>]
>     >>     >> *To:* [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>
>     >>     >> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     >>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 08:28:40 -0800

Igor,
	So you are adding to 3 to cover the case when the upstream node selects
the label, right?

Lou

On 11/5/2013 8:20 AM, Igor Bryskin wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Vishnu Pavan Beeram
> *Sent:* Tuesday, November 05, 2013 10:50 AM
> *To:* Lou Berger
> *Cc:* [email-masked]
> *Subject:* Re: [CCAMP] 答复: Comments about
>     >     From: Fatai Zhang <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     >     To: "[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>"
>     >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>, Vishnu
>     >     Pavan
> 
>     >     Beeram <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     >发件人: [email-masked]
>     >     [[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>] 代
>     表 Julien
>     >     Meuric
>     >     >[[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>]
> 
>     >     >发送时间: 2013年11月5日 10:35
>     >     >收件人: Vishnu Pavan Beeram
> 
>     >     >> current semantics of an UPSTREAM_LABEL, you cannot use it
>     for the
>     >     case
>     >     >> where the upstream-label hasn't been installed/programmed
>     yet. If
>     >     some
>     >     >> the presence of an "UPSTREAM_LABEL" object in the PATH msg.
>     This
>     >     draft
>     >     >> understand how adding two other mechanisms for
>     Bidirectional LSP
>     >     setup
>     >     >> On Mon, Nov 4, 2013 at 2:18 PM, Lou Berger
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
> 
>     >     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >>
>     >     >>     John, (authors)
>     >     >>
>     >     >>     uses and probabilities that may not hold, but we do
>     need to be
>     >     >>careful
>     >     >>     when changing fundamentals of the protocol (e.g. moving
>     away from
>     >     >>the
>     >     >>     So is it fair to say that the main limitation that the
>     draft is
>     >     >>trying
>     >     >>     to address is the inability to support downstream
>     selection of
>     >     >>     upstream
>     >     >>     labels?
>     >     >>
>     >     >>     The draft also allows for both symmetric and asymmetric
>     label
>     >     value
>     >     >>     Are there other requirements / limitations you are
>     trying to
>     >     >>address?
>     >     >>
>     >     >>     Lou
>     >     >>
>     >     >>     > response is that you really really like RFC3473. I'm
>     happy for
>     >     >>     you but
>     >     >>     > unimpressed.
>     >     >>     >
>     >     >>     > John
>     >     >>     >
>     >     >>     > Sent from my iPhone
>     >     >>     >
>     >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>     >     >>     >
>     >     >>     >> Igor, John-
>     >     >>     >>
>     >     >>     >> Please see in-line.
>     >     >>     >>
>     <mailto:[email-masked]>
> 
>     <mailto:[email-masked]>>> <mailto:[email-masked]
>     <mailto:[email-masked]>
> 
>     <mailto:[email-masked]>>>>"
>     <mailto:[email-masked]>>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     >     >>     >> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>"
>     >     >>     >> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>" <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >     >>     >> 1) Using an error indication as a part of normal
>     protocol
>     >     >>     >> operation is not good design practice.
>     >     >>     >>
>     >     >>     >> RSVP-TE design. Also please note that we are not
>     debating
>     >     about a
>     >     >>     >> IB>> The way I interpret this discussion is
>     something like
>     >     this:
>     >     >>     >>
>     >     >>     >>
>     >     >>     >>
>     >     >>     >> Many mature applications successfully use black for
>     their
>     >     various
>     >     >>     >> much everything….. So, it is not clear which color
>     is lighter,
>     >     >>and
>     >     >>     >> technical arguments"! Last I heard we believed in
>     running code
>     >     >>(See
>     >     >>     >> downstream alien wavelength are same, use of
>     acceptable label
>     >     >>     set and
>     >     >>     >> label set objects constitute the running code.
>     However, your
>     >     >>draft
>     <mailto:[email-masked] <mailto:[email-masked]>>>]
>     >     >>     >> *From: *"[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>"
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     <mailto:[email-masked]>>>>"
>     <mailto:[email-masked]>
> 
>     <mailto:[email-masked]>>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>" <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >     >>     >> That because this already defined method has the
>     following
>     >     >>issues:
>     >     >>     >>
>     >     >>     >> 1) Using an error indication as a part of normal
>     protocol
>     >     >>     >> operation is not good design practice.
>     >     >>     >>
>     >     >>     >> RSVP-TE design. Also please note that we are not
>     debating
>     >     about a
>     >     >>     >> 2) Acceptable Label Set is optional so its presence
>     is not
>     >     >>     >> guaranteed
>     >     >>     >>
>     >     >>     >> 3) The information it provides may be out of date by
>     the time
>     >     >>     >> the LSP is re-signaled.
>     >     >>     >>
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
> 
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
> 
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>]
>     <mailto:[email-masked]>
> 
>     <mailto:[email-masked]>>> <mailto:[email-masked]
>     <mailto:[email-masked]>
> 
>     >     >>     >> Acceptable_Label_Set objects may be carried in
>     PathErr and
>     >     >>     >> ResvErr messages [RFC3473].
>     >     >>     >>
>     >     >>     >>
>     >     >>     >>
>     >     >>     >> However, your draft does not mention or cover this
>     already
>     >     >>     >> defined method.
>     >     >>     >>
>     >     >>     >>
>     >     >>     >>
>     >     >>     >> Thanks
>     >     >>     >>
>     >     >>     >>
>     >     >>     >>
>     >     >>     >> Regards … Zafar
>     >     >>     >>
>     >     >>     >
>     >     >>     >
>     >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>     <mailto:[email-masked] <mailto:[email-masked]>
> 
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 5 Nov 2013 16:38:27 +0000

Actually, I want to have an option for UNI-C to say:
a) I want the network to assign both labels;
b) I don't care about the values, but US label must be the same as DS lablel

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 11:29 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Igor,
	So you are adding to 3 to cover the case when the upstream node selects the label, right?

Lou

On 11/5/2013 8:20 AM, Igor Bryskin wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Vishnu Pavan Beeram
>         I think this is helpful in trying to understand what the goals 
> are of the draft.  Again, I'll resist arguing about the mechanisms 
> that are proposed until we've agreed on what requirements need to be 
> addressed.
> (While the mechanism details, i.e., the "how", are certainly 
> important, arguing those doesn't really answer the larger question of 
> "what" you'd like to accomplish.)
> 
>  
> 
> VPB: Agree.
> 
>  
> 
> 
> <mailto:[email-masked]>>]
> 
>     >     >发送时间: 2013年11月5日 10:35
>     >     >收件人: Vishnu Pavan Beeram
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 10:05:51 -0800

Igor,

I'm sorry. I don't understand how what your are saying differs from 1 and 3 
below.  Does it, or are you just agreeing?

 Lou

On November 5, 2013 8:38:27 AM Igor Bryskin <[email-masked]> wrote:
> From: Lou Berger [mailto:[email-masked]] Sent: Tuesday, November 05, 2013 
> 11:29 AM
> Subject: Re: [CCAMP] 答复: Comments about 
> >         I think this is helpful in trying to understand what the goals > 
> are of the draft.  Again, I'll resist arguing about the mechanisms > that 
> are proposed until we've agreed on what requirements need to be > addressed.
> >        should be used in the downstream nodes' choice of upstream > label
> >     <mailto:[email-masked] > <mailto:[email-masked]>>]
> >     >     >发送时间: 2013年11月5日 10:35
> >     >     >收件人: Vishnu Pavan Beeram

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 5 Nov 2013 19:01:28 +0000

Lou,

>        you really care about it.
I agree with 1-3. But 4. should not be ignored

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 11:29 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Igor,

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 14:21:24 -0500

Great. So this is a nice short list.  I think the utility of
requirements 1 and 2 are pretty clear. You have stated that both
symmetric and asymmetric labels are needed in optical for single fiber
rings.  While I'm personally amazed that these still exist, I  (with no
hat on) accept the use case.

I suspect that some are not convinced on the need to "put label symmetry
into the protocol" (Juilien's question)

Can you (authors) elaborate on why this needs to be changed?

Thanks,
Lou

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 5 Nov 2013 19:42:45 +0000

Lou,
In majority of the cases UNI-Cs would want to have their G-LSPs label-symmetrical. 
 If the label symmetricity is left to the local policy of the network, the latter may decide (e.g. because of existing unidirectional LSPs set up for other users or P2MP LSPs) to assign different labels for US and DS unless there is an explicit constraint signaled from the UNI-C to make symmetrical or fail the setup.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 2:21 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Great. So this is a nice short list.  I think the utility of requirements 1 and 2 are pretty clear. You have stated that both symmetric and asymmetric labels are needed in optical for single fiber rings.  While I'm personally amazed that these still exist, I  (with no hat on) accept the use case.

I suspect that some are not convinced on the need to "put label symmetry into the protocol" (Juilien's question)

Thanks,
Lou

On 11/05/2013 02:01 PM, Igor Bryskin wrote:
>>         I think this is helpful in trying to understand what the 
>> goals are of the draft.  Again, I'll resist arguing about the 
>> mechanisms that are proposed until we've agreed on what requirements 
>> need to be addressed.

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 14:47:30 -0800

Igor,

> In majority of the cases UNI-Cs would want to have their G-LSPs label-symmetrical. 

Every time you say UNI-C I've been assuming you mean ingress, is this
correct?

> If the label symmetricity is left to the local policy of the network,
> the latter may decide (e.g. because of existing unidirectional LSPs
> set up for other users or P2MP LSPs) to assign different labels for
> US and DS unless there is an explicit constraint signaled from the
> UNI-C to make symmetrical or fail the setup.
> 

So you believe there is a use case where some nodes will assign
asymmetric labels for the same service, and other nodes along the LSP
only support symmetric labels.  Right?

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 5 Nov 2013 23:20:56 +0000

Hi,

For the transport/GMPLS networks, I would repeat the bidirectional LSPs are always symmetric in practice, so there are no cases for some nodes to assign asymmetric labels.

However, I would agree on the requirements if we just do some research in theory. 

Thanks

Fatai

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Lou Berger [[email-masked]]
发送时间: 2013年11月6日 6:47
收件人: Igor Bryskin; Vishnu Pavan Beeram
抄送: [email-masked]
主题: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Igor,

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Nov 2013 01:50:47 +0000

Please, see below. 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, November 05, 2013 5:48 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Igor,

> In majority of the cases UNI-Cs would want to have their G-LSPs label-symmetrical. 

Every time you say UNI-C I've been assuming you mean ingress, is this correct?

IB>> Correct

> set up for other users or P2MP LSPs) to assign different labels for US 
> and DS unless there is an explicit constraint signaled from the UNI-C 
> to make symmetrical or fail the setup.
> 

So you believe there is a use case where some nodes will assign asymmetric labels for the same service, and other nodes along the LSP only support symmetric labels.  Right?

IB>> Correct.

Lou

> I suspect that some are not convinced on the need to "put label 
> symmetry into the protocol" (Juilien's question)
> 
>>> important, arguing those doesn't really answer the larger question 
>>> of "what" you'd like to accomplish.)
>>>
>>>  
>>>
>>> VPB: Agree.
>>>
>>>  
>>>
>>>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 06 Nov 2013 02:54:39 +0100

Hi Pavan and Igor,

I share Fatai's concerns - as far as transport networks are
concerned, LSPs are bidirectional in nature

and the labels are symmetric. It would be nice if you could
elaborate a bit more and provide some

practical application examples that justify the
requirement of asymmetric labels.

Thanks,

Dieter

On 06.11.2013 00:20, Fatai Zhang wrote:

Hi,

Thanks

Fatai

Igor,

Lou,

Lou

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 2:21 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Thanks,
Lou

Lou,

2. An option to allow upstream node to provide set of labels that
should be used in the downstream nodes' choice of upstream
label

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 11:29 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: Comments about

Igor,

Lou

I would add:

Lou,

Thanks,

-Pavan.

On Tue, Nov 5, 2013 at 10:20 AM, Lou Berger <[email-masked]
<mailto:[email-masked]>> wrote:

Pavan,

VPB: Agree.

2. An option to allow upstream node to provide set of labels that
should be used in the downstream nodes' choice of upstream
label

Is this correct?

Thanks,
Lou

<mailto:[email-masked]>

for the
yet. If
This
Bidirectional LSP

need to be
away from
draft is
selection of
label
trying to
happy for
<mailto:[email-masked]>>

protocol
debating
something like
their
is lighter,
running code
acceptable label
However, your
<mailto:[email-masked]>

following
protocol
debating
is not
the time

PathErr and
already

<mailto:[email-masked]>>
<mailto:[email-masked]>>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 6 Nov 2013 01:58:43 +0000

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Tuesday, November 5, 2013 3:20 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [CCAMP] 答复:  答复: Comments about
draft-beeram-ccamp-network-assigned-upstream-label-00

>For the transport/GMPLS networks, I would repeat the bidirectional LSPs
>are always symmetric in practice, so there are no cases for some nodes to
>assign asymmetric labels.
>

I agree. Just want to add as CCAMP should NOT be assuming some research
work. 

Thanks

Regards...Zafar

---

From: Rajan Rao <[email-masked]>
Date: Wed, 6 Nov 2013 02:15:00 +0000

Architecturally it makes sense to cover this case.  In my past experience, I have worked on ROADM system which mandated asymmetric add/drop!!

I can think of multi-failure scenario (unidirectional) which could take advantage of available spectrum in different fibers to complete E2E path setup.  As long as hardware is capable of supporting this I do not see a reason for CP to block it.

Thx
Rajan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Tuesday, November 05, 2013 5:55 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Pavan and Igor,

I share Fatai's concerns - as far as transport networks are concerned, LSPs are bidirectional in nature
and the labels are symmetric. It would be nice if you could elaborate a bit more and provide some
practical application examples that justify the requirement of asymmetric labels.

Thanks,
Dieter

Hi,

Thanks

Fatai

发件人: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] 代表 Lou Berger [[email-masked]<mailto:[email-masked]>]

发送时间: 2013年11月6日 6:47

抄送: [email-masked]<mailto:[email-masked]>

Igor,

Lou,

correct?

Lou

Igor

-----Original Message-----

Thanks,

Lou

Lou,

label

       is selecting the label.

-----Original Message-----

Igor,

       is selecting the label.

Lou

I would add:

*To:* Lou Berger

*Cc:* [email-masked]<mailto:[email-masked]>

Lou,

Thanks,

-Pavan.

On Tue, Nov 5, 2013 at 10:20 AM, Lou Berger <[email-masked]<mailto:[email-masked]>

<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Pavan,

need to be addressed.

VPB: Agree.

label

       is selecting the label.

    Is this correct?

    Thanks,

    Lou

    On 11/5/2013 5:25 AM, Vishnu Pavan Beeram wrote:

    > I see a pattern in the questions that are being raised. I'll try

    and see

    > (1) Aren't labels always symmetric in practice? Are there any

    asymmetric

    > default. There is currently no way of mandating symmetricity at

    each hop

    > (3) Say, we all agree that "Symmetricity" is always guaranteed

    (maybe we

    > able to use existing extensions and address the "alien-wavelength"

    setup

    > needs to be filled in with a valid label before sending the PATH

    out. We

    > still need the ingress-client to have some mechanism to tell the

    network

    > Ans: The ingress has always been the one to request the downstream

    node

    > draft is because RFC3473 allows asymmetricity. We don't need to

    discuss

    > those if we explicitly state somewhere (in some standard document)

    that

    > On Tue, Nov 5, 2013 at 2:29 AM, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    > <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>> wrote:

    >     Furthermore, when (alien) wavelength is same in forward and

    reverse

    >     direction, we can use label set along with acceptable label

    set - as

    >     defined in RFC3473. The only use case this draft addresses is

    when alien

    >     wavelength are asymmetrical in forward and reverse direction.

    I am not

    >     From: Fatai Zhang <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>

    >     To: "[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>"

    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>>>, Vishnu

    >     Beeram <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >Understood what you said in principle, but could you give an

    example to

    >     >show there are asymmertric labels (wavelength?) for the

    bidirectiaonal

    >     >LSPs (especiall for the transport networks) in the real

    >     implementations?

    >==========================================================================

    >     >======================================

    >     >In practice, most bidirectional LSPs have label symmetricity on

    >     each hop

    >     >along the path of the LSP. But this is something that cannot

    be assumed

    >     >发件人: [email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>] 代

    表 Julien

    >     >[[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

<mailto:[email-masked]><mailto:[email-masked]>>]

    >     >抄送: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >Even though I agree with your unassigned Upstream_Label

    requirement, I

    >     >The Upstream_Label refers to the client's optical receiver:

    you don't

    >     >need to tune a laser on the receiver side. The data

    transmission could

    >     >even work without sending the actual Upstream_Label in

    RSVP-TE messages

    >     >to the client: I am not really a fan of that approach, but

    that would

    >     >fit cases where optical policies are left to the optical

    network...

    >     >Moreover, I have doubts on putting label symmetry within the

    protocol.

    >     >This is more an allocation policy in the hands of allocating

    nodes:

    >     >requesting an allocation mode from an ingress node would mean

    doing the

    >     >> The extensions defined in this draft do not impose any

    backwards

    >     >> compatibility issues. The intent is definitely not to

    change the

    >     >> fundamental aspects of the protocol. As you would agree, it

    is not

    >     >> mandatory to try and fit the extensions defined in RFC3473

    to all and

    >     >> sundry. New extensions are being introduced only where the

    existing

    >     >> extensions fall short. Let me walk through the requirements

    that we

    >     >> are looking at and that would hopefully explain the limitations

    >     of the

    >     >> Need a mechanism for a given node to say that it cannot

    assign an

    >     >> 1. Need a mechanism for a given node to ask for a

    network-assigned

    >     >> upstream label without having to specify any inputs on what

    label

    >     >> 2. Need a mechanism for a given node to ask for a

    network-assigned

    >     >> upstream label and also specify some choices for the label

    that needs

    >     >> 3. If labels are symmetric, a given node can simply use the

    label

    >     >> returned in the LABEL object of the RESV message for both

    directions.

    >     >> In practice, most bidirectional LSPs have label

    symmetricity on each

    >     >> hop along the path of the LSP. But this is something that

    cannot be

    >     >> assumed by default. Hence, there is a need to have a mechanism

    >     >> ingress to request "label symmetricity" at each hop along

    the path of

    >     >> Can you somehow fit a solution using the current extensions

    and cater

    >     >> We believe the answer is NO. One suggestion on the mailing list

    >     was to

    >     >> set a random UPSTREAM_LABEL and send it out on a fishing

    expedition.

    >     >> PATH-ERR carrying an ACCEPTABLE_LABEL_SET. John and Igor have

    >     provided

    >     >> a list of reasons on why that isn't a great idea. Let me

    add another

    >     >> - As per RFC3473 - when a node receives an UPSTREAM_LABEL

    object in

    >     >> installed/programmed this label. In the alien wavelength

    use-case

    >     >> (discussed in the draft), when the network receives this

    message, it

    >     >> would mean that the laser has already been tuned to this

    >     wavelength at

    >     >> assigned upstream label. Doesn't it? So, the point is that

    with the

    for the

    yet. If

    >     >> network know whether the ingress-client has already

    installed this

    >     >> RFC3473 states that a Bidirectional-LSP setup request is

    >     identified by

    This

    >     >> - The presence of the "Label Symmetricity Required" Flag in

    the PATH

    >     >> If a downstream node does not understand any of the above

    >     indications,

    >     >> it would reject the setup request. In both scenarios -

    after the

    >     >> network has assigned the upstream-label, the concerned node is

    >     allowed

    >     >> to start signaling the UPSTREAM_LABEL object in the PATH. I

    don't

    Bidirectional LSP

    >     >> Implementations that can support these extensions can.

    Others can

    >     >> On Mon, Nov 4, 2013 at 2:18 PM, Lou Berger

    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >> <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>> wrote:

    >     >>     Perhaps it would be useful to refocus a moment on the

    specific

    >     >>     There's no question that 3473 made certain choices based on

    >     expected

    need to be

    away from

    draft is

    selection of

    label

    >     >>     allocation. IS this a requirement, or asymmetric just

    >     included for

    trying to

    >     >>     > Both Igor and I have listed technical issues with RFC3473

    >     and your

    happy for

    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     > <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>> wrote:

    >     >>     >> From: "[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>>"

    >     >>     >> <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>>>

    >     >>     >> To: zali <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>,

    >     >>     "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     >> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>"

    >     >>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     >> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>

    >     >>     >> Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>" <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     >> <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>

    protocol

    >     >>     >> Use of Path error and notify message is an integral part

    >     of the

    debating

    >     >>     >> new procedure being proposed but talking about a

    procedure

    something like

    >     >>     >> John: I believe that white is a lighter color than

    black.

    >     >>     >> Zafa: Well, John, black is an integral part of the color

    >     pallet.

    their

    >     >>     >> purposes. My implementations, for example, use black for

    >     pretty

    is lighter,

    >     >>     >> This is really funny. This is the first time I have

    heard that

    >     >>     >> code has no merit at IETF :) This is especially when the

    >     >>     >> is directly coming from RFC3473. You are calling it "not

    running code

    >     >>     >> Your draft is ONLY applicable for a use case where

    >     upstream and

    >     >>     >> downstream alien wavelength are different. When

    upstream and

    acceptable label

    However, your

    >     >>     >> *From:*Zafar Ali (zali) [mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>]

    >     >>     >> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>

    >     >>     >> *From: *"[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>"

    >     >>     >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>

    >     >>     >> *To: *zali <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>,

    >     >>     >> "[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>>"

    >     >>     >> <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>>>

    >     >>     >> *Cc: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>" <[email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     >> <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>>

    following

    protocol

    >     >>     >> Use of Path error and notify message is an integral part

    >     of the

    debating

    >     >>     >> new procedure being proposed but talking about a

    procedure

    is not

    >     >>     >> So is the case of newly defined upstream label set. Also

    >     please

    >     >>     >> note that many part of the RSVP-TE protocol are

    designed using

    the time

    >     >>     >> This is an implementation issue. A node sending the

    acceptable

    >     >>     >> label set has the responsibility to guarantee that

    information

    >     >>     >> re-signaling time. E.g., UNI-N implementation can cache

    >     the label

    >     >>     >> 4) Most importantly, Acceptable Label Set is

    generated hop by

    >     >>     >> hop, unlike Upstream Label Set which exercises the

    entire

    >     >>     >> path. This means that its use to determine a valid

    wavelength

    >     >>     >> would require a potentially unbounded number of

    crankbacks,

    >     >>     >> In the use case of align wavelength addressed in this

    >     draft, the

    >     >>     >> acceptable label set communication is restricted to the

    >     UNI-C and

    >     >>     >> *From:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>

    >     >>     >> [mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>]

    >     >>     >> *To:* [email-masked]<mailto:[email-masked]>

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >>     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>>>

    >     >>     >> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>

    >     >>     >> Please note that [RFC3473] already considers the

    case where

    >     >>     >> "/when a Path message containing an Upstream_Label

    object is

    >     >>     >> received, the receiver first verifies that the

    upstream label

    >     >>     >> is acceptable. If the label is not acceptable, the

    receiver

    >     >>     >> problem/Unacceptable label value" indication. The

    generated

    >     >>     >> PathErr message MAY include an Acceptable Label Set

    Object/".

    PathErr and

    already

    >     >>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

    >     <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>

    >     >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>

    >     >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    >     >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]

    <mailto:[email-masked]><mailto:[email-masked]>>

    > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

CCAMP mailing list

CCAMP mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Nov 2013 02:15:19 +0000

Dieter and Fatai,

We are talking about modifying RFC3473, which never says that all bi-directional LSPs are symmetrical.  If there is no case for asymmetrical G-LSPs, then there is no need for Upstream Label object except for indicating that this is a bi-directional G-LSP.   It also means that the label negotiated for the DS direction must be automatically used as US label, which is not the behavior of current implementations. Are you suggesting that we should just explicitly deprecate asymmetrical LSPs?

Igor

From: Dieter Beller [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 8:55 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Fatai Zhang; Lou Berger; [email-masked]
Subject: Re: [CCAMP] 答复: 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Pavan and Igor,

Thanks,
Dieter

Hi,

Thanks

Fatai

发送时间: 2013年11月6日 6:47

Igor,

Lou,

correct?

Lou

Igor

-----Original Message-----

Thanks,

Lou

Lou,

label

       is selecting the label.

-----Original Message-----

Igor,

       is selecting the label.

Lou

I would add:

*To:* Lou Berger

Lou,

Thanks,

-Pavan.

Pavan,

need to be addressed.

VPB: Agree.

label

       is selecting the label.

    Is this correct?

    Thanks,

    Lou

    and see

    asymmetric

    each hop

    (maybe we

    setup

    out. We

    network

    node

    discuss

    that

    reverse

    set - as

    when alien

    I am not

    example to

    bidirectiaonal

    be assumed

    表 Julien

    requirement, I

    you don't

    transmission could

    RSVP-TE messages

    that would

    network...

    protocol.

    doing the

    backwards

    change the

    is not

    to all and

    existing

    that we

    assign an

    network-assigned

    label

    network-assigned

    that needs

    label

    directions.

    symmetricity on each

    cannot be

    the path of

    and cater

    expedition.

    add another

    object in

    use-case

    message, it

    with the

    for the

    yet. If

    installed this

    This

    the PATH

    after the

    don't

    Bidirectional LSP

    Others can

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>> wrote:

    specific

    need to be

    away from

    draft is

    selection of

    label

    trying to

    happy for

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>> wrote:

    protocol

    debating

    procedure

    something like

    black.

    their

    is lighter,

    heard that

    running code

    upstream and

    acceptable label

    However, your

    following

    protocol

    debating

    procedure

    is not

    designed using

    the time

    acceptable

    information

    generated hop by

    entire

    wavelength

    crankbacks,

    case where

    object is

    upstream label

    receiver

    generated

    Object/".

    PathErr and

    already

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Nov 2013 02:35:55 +0000

Hi Igor,

Good point.

I am not sure if we need to deprecate Upstream Label object or just leave it (even though it might not useful), but I  don't think it is a good idea to make protocol more complex based on the un-practical assumption.

Some RFCs really defined some useless stuff (like Lou's draft to deprecate PSC-1, PSC-2...), but please don't make the thing happen repeatedly.

Thanks

Fatai

________________________________
发件人: Igor Bryskin [[email-masked]]
发送时间: 2013年11月6日 10:15
收件人: Dieter Beller; Vishnu Pavan Beeram
抄送: Fatai Zhang; Lou Berger; [email-masked]
主题: RE: [CCAMP] 答复: 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Dieter and Fatai,

Igor

Hi Pavan and Igor,

Thanks,
Dieter

Hi,

Thanks

Fatai

发送时间: 2013年11月6日 6:47

Igor,

Lou,

correct?

Lou

Igor

-----Original Message-----

Thanks,

Lou

Lou,

label

       is selecting the label.

-----Original Message-----

Igor,

       is selecting the label.

Lou

I would add:

*To:* Lou Berger

Lou,

Thanks,

-Pavan.

Pavan,

need to be addressed.

VPB: Agree.

label

       is selecting the label.

    Is this correct?

    Thanks,

    Lou

    and see

    asymmetric

    each hop

    (maybe we

    setup

    out. We

    network

    node

    discuss

    that

    reverse

    set - as

    when alien

    I am not

    example to

    bidirectiaonal

    be assumed

    表 Julien

    requirement, I

    you don't

    transmission could

    RSVP-TE messages

    that would

    network...

    protocol.

    doing the

    backwards

    change the

    is not

    to all and

    existing

    that we

    assign an

    network-assigned

    label

    network-assigned

    that needs

    label

    directions.

    symmetricity on each

    cannot be

    the path of

    and cater

    expedition.

    add another

    object in

    use-case

    message, it

    with the

    for the

    yet. If

    installed this

    This

    the PATH

    after the

    don't

    Bidirectional LSP

    Others can

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>> wrote:

    specific

    need to be

    away from

    draft is

    selection of

    label

    trying to

    happy for

    <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>>>> wrote:

    protocol

    debating

    procedure

    something like

    black.

    their

    is lighter,

    heard that

    running code

    upstream and

    acceptable label

    However, your

    following

    protocol

    debating

    procedure

    is not

    designed using

    the time

    acceptable

    information

    generated hop by

    entire

    wavelength

    crankbacks,

    case where

    object is

    upstream label

    receiver

    generated

    Object/".

    PathErr and

    already

CCAMP mailing list

CCAMP mailing list