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

["Zafar Ali (zali)" <[e-mail]>]

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]>
Date: Monday, November 4, 2013 7:38 PM
To: "[e-mail]" <[e-mail]>, Vishnu Pavan
Beeram <[e-mail]>
Cc: "[e-mail]" <[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] [[e-mail]] 代表 Julien Meuric
>[[e-mail]]
>发送时间: 2013年11月5日 10:35
>收件人: Vishnu Pavan Beeram
>抄送: [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]>> 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]>>> wrote:
>>     >
>>     >> Igor, John-
>>     >>
>>     >> Please see in-line.
>>     >>
>>     >> From: "[e-mail]
>>     <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>>"
>>     >> <[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]>>>,
>>     "[e-mail] <mailto:[e-mail]>
>>     >> <mailto:[e-mail] <mailto:[e-mail]>>"
>>     <[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: 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]>]
>>     >> *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]>>
>>     >> *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]>>"
>>     >> <[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]>>>,
>>     >> "[e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>"
>>     >> <[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: *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]>]
>>     *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]>>
>>     >> *Cc:* [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]>
>>     > 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
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp