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

[Fatai Zhang <[e-mail]>]

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] [[e-mail]] 代表 Lou Berger [[e-mail]]
发送时间: 2013年11月6日 6:47
收件人: Igor Bryskin; Vishnu Pavan Beeram
抄送: [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]
> 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]
>> 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
>>>     >
>>>
>>>
>>>
>
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp