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

[Igor Bryskin <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, November 05, 2013 11:29 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [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]
> *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]>> 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]>>> 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]>>>
>     >     Date: Monday, November 4, 2013 7:38 PM
> 
>     >     To: "[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>"
>     >     <[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]>>>
>     >     Cc: "[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>" <[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]>>
>     >     [[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>] 代
>     表 Julien
>     >     Meuric
>     >     >[[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]>>
> 
>     >     >主题: 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]>>>> 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]>>>>> 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]>>>>"
>     >     >>     >> <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>> <mailto:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>     >     >>     <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]>>>>>,
>     >     >>     "[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >>     >> <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]>>>>>
>     >     >>     >> 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]>>>>" <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     >>     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >>     >> <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]>>>]
>     >     >>     >> *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]>>>>
>     >     >>     >> *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]>>>>"
>     >     >>     >> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >>     <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]>>>>>,
>     >     >>     >> "[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>> <mailto:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
> 
>     >     >>     <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]>>>>>
>     >     >>     >> *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]>>>>" <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     >>     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >>     >> <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]>>>]
>     >     >>     *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]>>>>
>     >     >>     >> *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]>>>>
>     >     >>     >> *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]>>>
> 
>     >     >>     > 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]>>>
>     >     >>     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]> <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
>     >
> 
>  
>