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

[Fatai Zhang <[e-mail]>]

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 [[e-mail]]
发送时间: 2013年11月6日 10:15
收件人: Dieter Beller; Vishnu Pavan Beeram
抄送: Fatai Zhang; Lou Berger; [e-mail]
主题: RE: [CCAMP] 答复: 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

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:[e-mail]]
Sent: Tuesday, November 05, 2013 8:55 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Fatai Zhang; Lou Berger; [e-mail]
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

On 06.11.2013 00:20, Fatai Zhang wrote:

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





________________________________________

发件人: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] 代表 Lou Berger [[e-mail]<mailto:[e-mail]>]

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

收件人: Igor Bryskin; Vishnu Pavan Beeram

抄送: [e-mail]<mailto:[e-mail]>

主题: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00



Igor,



On 11/5/2013 11:42 AM, Igor Bryskin wrote:

Lou,

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



Igor



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

From: Lou Berger [mailto:[e-mail]]

Sent: Tuesday, November 05, 2013 2:21 PM

To: Igor Bryskin; Vishnu Pavan Beeram

Cc: [e-mail]<mailto:[e-mail]>

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)



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



Thanks,

Lou



On 11/05/2013 02:01 PM, Igor Bryskin wrote:

Lou,



    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.



I agree with 1-3. But 4. should not be ignored



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

From: Lou Berger [mailto:[e-mail]]

Sent: Tuesday, November 05, 2013 11:29 AM

To: Igor Bryskin; Vishnu Pavan Beeram

Cc: [e-mail]<mailto:[e-mail]>

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?

    3. The use of symmetric labels when the downstream node

       is selecting the label.



Lou



On 11/5/2013 8:20 AM, Igor Bryskin wrote:

I would add:



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







*From:*[e-mail] [mailto:[e-mail]] *On

Behalf Of *Vishnu Pavan Beeram

*Sent:* Tuesday, November 05, 2013 10:50 AM

*To:* Lou Berger

*Cc:* [e-mail]<mailto:[e-mail]>

*Subject:* Re: [CCAMP] 答复: Comments about

draft-beeram-ccamp-network-assigned-upstream-label-00







Lou,







Yes, your summarized points are correct.







Thanks,



-Pavan.







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

<mailto:[e-mail]><mailto:[e-mail]>> wrote:



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.)







VPB: Agree.









    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:

    > 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) <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>



    > <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>> wrote:

    >

    >     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 <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>

    >     Date: Monday, November 4, 2013 7:38 PM



    >     To: "[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>"

    >     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>, Vishnu

    >     Pavan



    >     Beeram <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     Cc: "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     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

    >     >

    >     >________________________________________



    >     >发件人: [e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     [[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>] 代

    表 Julien

    >     Meuric

    >     >[[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail]

<mailto:[e-mail]><mailto:[e-mail]>>]



    >     >发送时间: 2013年11月5日 10:35

    >     >收件人: Vishnu Pavan Beeram



    >     >抄送: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     >主题: Re: [CCAMP] Comments about

    >     >draft-beeram-ccamp-network-assigned-upstream-label-00

    >     >

    >     >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:

    >     >> 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

    <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     >> <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>> wrote:

    >     >>

    >     >>     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

    >     >>     >

    >     >>     > On Nov 4, 2013, at 9:43 AM, "Zafar Ali (zali)"

    >     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     > <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>> wrote:

    >     >>     >

    >     >>     >> Igor, John-

    >     >>     >>

    >     >>     >> Please see in-line.

    >     >>     >>

    >     >>     >> From: "[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>>"

    >     >>     >> <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> Date: Monday, November 4, 2013 8:57 AM

    >     >>     >> To: zali <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>,

    >     >>     "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     >> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>"

    >     >>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     >> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> Cc: "[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>" <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     >> <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> Subject: RE: Comments about

    >     >>     >> draft-beeram-ccamp-network-assigned-upstream-label-00

    >     >>     >>

    >     >>     >> Zafar,

    >     >>     >>

    >     >>     >> 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.

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> 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

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> 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

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> *From:*Zafar Ali (zali) [mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>]

    >     >>     >> *Sent:* Monday, November 04, 2013 1:51 AM

    >     >>     >> *To:* John E Drake; Igor Bryskin

    >     >>     >> *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>

    >     >>     >> *Subject:* Re: Comments about

    >     >>     >> draft-beeram-ccamp-network-assigned-upstream-label-00

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> Hi John:

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> Please see in-line.

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> Thanks

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> Regards … Zafar

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> *From: *"[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>"

    >     >>     >> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> *Date: *Sunday, November 3, 2013 11:57 AM

    >     >>     >> *To: *zali <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>,

    >     >>     >> "[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>>"

    >     >>     >> <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> *Cc: *"[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>" <[e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     >> <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>>

    >     >>     >> *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

    >     >>     >>

    >     >>     >>

    >     >>     >>

    >     >>     >> *From:*[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>

    >     >>     >> [mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>]

    >     >>     *On Behalf Of *Zafar Ali (zali)

    >     >>     >> *Sent:* Sunday, November 03, 2013 8:12 AM

    >     >>     >> *To:* [e-mail]<mailto:[e-mail]>

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>

    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >>     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>>>

    >     >>     >> *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>>

    >     >>     >> *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/".

    >     >>     >>

    >     >>     >> 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

    >     >>     >>

    >     >>     >

    >     >>     >

    >     >>     > _______________________________________________

    >     >>     > CCAMP mailing list

    >     >>     > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>



    >     >>     > https://www.ietf.org/mailman/listinfo/ccamp

    >     >>     >

    >     >>

    >     >>     _______________________________________________

    >     >>     CCAMP mailing list



    >     >>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>



    >     <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>>

    >     >>     https://www.ietf.org/mailman/listinfo/ccamp

    >     >>

    >     >>

    >     >>

    >     >>

    >     >> _______________________________________________

    >     >> CCAMP mailing list

    >     >> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    <mailto:[e-mail] <mailto:[e-mail]><mailto:[e-mail]>>

    >     >> https://www.ietf.org/mailman/listinfo/ccamp

    >     >

    >     >_______________________________________________

    >     >CCAMP mailing list

    >     >[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >https://www.ietf.org/mailman/listinfo/ccamp

    >     >_______________________________________________

    >     >CCAMP mailing list

    >     >[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> <mailto:[e-mail]

    <mailto:[e-mail]><mailto:[e-mail]>>

    >     >https://www.ietf.org/mailman/listinfo/ccamp

    >

    >

    >

    >

    > _______________________________________________

    > CCAMP mailing list

    > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

    > https://www.ietf.org/mailman/listinfo/ccamp

    >









_______________________________________________

CCAMP mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ccamp