Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00
Lou Berger <lberger@labn.net> Tue, 05 November 2013 19:22 UTC
Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2112711E81C4 for <ccamp@ietfa.amsl.com>; Tue, 5 Nov 2013 11:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.417
X-Spam-Level:
X-Spam-Status: No, score=-97.417 tagged_above=-999 required=5 tests=[AWL=-4.073, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTbr0H85gCmA for <ccamp@ietfa.amsl.com>; Tue, 5 Nov 2013 11:22:14 -0800 (PST)
Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 154DA11E80E2 for <ccamp@ietf.org>; Tue, 5 Nov 2013 11:21:54 -0800 (PST)
Received: (qmail 5524 invoked by uid 0); 5 Nov 2013 19:21:25 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 5 Nov 2013 19:21:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Xujg/dhYSyQ2FMVX/3QOH2mQfWllhXakKH4SZgJ6Sio=; b=pb1mA7s25DELF/XhRNNesmgSaT+akYrG1zpE8gZuY0lc2pX32dxKSXYwriPWdUghXVLAt7fxaHPHN1IDRhfn0hmUUDb2YSaRzq6PXkYE5Z02SjgGQtJqIUwpaMGMdRG9;
Received: from box313.bluehost.com ([69.89.31.113]:46435 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1VdmBo-00016J-PX; Tue, 05 Nov 2013 12:21:25 -0700
Message-ID: <52794534.3030804@labn.net>
Date: Tue, 05 Nov 2013 14:21:24 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Igor Bryskin <IBryskin@advaoptical.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
References: <F82A4B6D50F9464B8EBA55651F541CF85CA89932@SZXEMA504-MBS.china.huawei.com> <CE9DDCED.81368%zali@cisco.com> <CA+YzgTumNUY_bUWVr1RCMFsx3wwt-p0eOe-RDUjX1f0x_0peXw@mail.gmail.com> <52790CAD.80003@labn.net> <CA+YzgTt9d1Q=ek=J=Cmk+gb4r4NfcHEtpWe0PAfA2CcxBB7aug@mail.gmail.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A192C9FBB@atl-srv-mail10.atl.advaoptical.com> <52791CB8.4000706@labn.net> <CDAC6F6F5401B245A2C68D0CF8AFDF0A192CA09E@atl-srv-mail10.atl.advaoptical.com>
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A192CA09E@atl-srv-mail10.atl.advaoptical.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] 答复: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 19:22:19 -0000
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:lberger@labn.net] > Sent: Tuesday, November 05, 2013 11:29 AM > To: Igor Bryskin; Vishnu Pavan Beeram > Cc: ccamp@ietf.org > 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:*ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On >> Behalf Of *Vishnu Pavan Beeram >> *Sent:* Tuesday, November 05, 2013 10:50 AM >> *To:* Lou Berger >> *Cc:* ccamp@ietf.org >> *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 <lberger@labn.net >> <mailto:lberger@labn.net>> 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) <zali@cisco.com >> <mailto:zali@cisco.com> >> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com>>> 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 <zhangfatai@huawei.com >> <mailto:zhangfatai@huawei.com> <mailto:zhangfatai@huawei.com >> <mailto:zhangfatai@huawei.com>>> >> > Date: Monday, November 4, 2013 7:38 PM >> >> > To: "julien.meuric@orange.com >> <mailto:julien.meuric@orange.com> <mailto:julien.meuric@orange.com >> <mailto:julien.meuric@orange.com>>" >> > <julien.meuric@orange.com <mailto:julien.meuric@orange.com> >> <mailto:julien.meuric@orange.com >> <mailto:julien.meuric@orange.com>>>, Vishnu >> > Pavan >> >> > Beeram <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com> >> <mailto:vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>> >> > Cc: "ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>" <ccamp@ietf.org >> <mailto:ccamp@ietf.org> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> >> > 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 >> > > >> > >________________________________________ >> >> > >发件人: ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org>> >> > [ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org> >> <mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>>] 代 >> 表 Julien >> > Meuric >> > >[julien.meuric@orange.com <mailto:julien.meuric@orange.com> >> <mailto:julien.meuric@orange.com >> <mailto:julien.meuric@orange.com>>] >> >> > >发送时间: 2013年11月5日 10:35 >> > >收件人: Vishnu Pavan Beeram >> >> > >抄送: ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> >> > >主题: 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 >> <lberger@labn.net <mailto:lberger@labn.net> >> > <mailto:lberger@labn.net <mailto:lberger@labn.net>> >> >> > >> <mailto:lberger@labn.net <mailto:lberger@labn.net> >> <mailto:lberger@labn.net <mailto:lberger@labn.net>>>> 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)" >> > <zali@cisco.com <mailto:zali@cisco.com> <mailto:zali@cisco.com >> <mailto:zali@cisco.com>> >> > >> <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>> >> > >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>>>> wrote: >> > >> > >> > >> >> Igor, John- >> > >> >> >> > >> >> Please see in-line. >> > >> >> >> > >> >> From: "IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>>>" >> > >> >> <IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>>>> >> > >> >> Date: Monday, November 4, 2013 8:57 AM >> > >> >> To: zali <zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>> >> >> > >> <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>>>>, >> > >> "jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>> >> > >> >> <mailto:jdrake@juniper.net >> <mailto:jdrake@juniper.net> <mailto:jdrake@juniper.net >> <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>>>" >> > >> <jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>> >> > >> >> <mailto:jdrake@juniper.net >> <mailto:jdrake@juniper.net> <mailto:jdrake@juniper.net >> <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>>>> >> > >> >> Cc: "ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>>" <ccamp@ietf.org >> <mailto:ccamp@ietf.org> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> > >> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>>> >> > >> >> 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:zali@cisco.com >> <mailto:zali@cisco.com> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> > >> <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>>] >> > >> >> *Sent:* Monday, November 04, 2013 1:51 AM >> > >> >> *To:* John E Drake; Igor Bryskin >> > >> >> *Cc:* ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>> >> > >> >> *Subject:* Re: Comments about >> > >> >> draft-beeram-ccamp-network-assigned-upstream-label-00 >> > >> >> >> > >> >> >> > >> >> >> > >> >> Hi John: >> > >> >> >> > >> >> >> > >> >> >> > >> >> Please see in-line. >> > >> >> >> > >> >> >> > >> >> >> > >> >> Thanks >> > >> >> >> > >> >> >> > >> >> >> > >> >> Regards … Zafar >> > >> >> >> > >> >> >> > >> >> >> > >> >> *From: *"jdrake@juniper.net >> <mailto:jdrake@juniper.net> <mailto:jdrake@juniper.net >> <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>> >> > >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>>>" >> > >> >> <jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>> >> > >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>> >> >> > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net> >> <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>>>> >> > >> >> *Date: *Sunday, November 3, 2013 11:57 AM >> > >> >> *To: *zali <zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>> >> >> > >> <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>> >> >> > <mailto:zali@cisco.com <mailto:zali@cisco.com> >> <mailto:zali@cisco.com <mailto:zali@cisco.com>>>>>, >> > >> >> "IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>> >> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>>>" >> > >> >> <IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>>>> >> > >> >> *Cc: *"ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>>" <ccamp@ietf.org >> <mailto:ccamp@ietf.org> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> > >> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>>> >> > >> >> *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:*ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> > <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org>> <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> > <mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>>> >> > >> <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> >> > <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org>> <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> >> > <mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>>>> >> > >> >> [mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> > <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org>> <mailto:ccamp-bounces@ietf.org >> <mailto:ccamp-bounces@ietf.org> >> > <mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>>>] >> > >> *On Behalf Of *Zafar Ali (zali) >> > >> >> *Sent:* Sunday, November 03, 2013 8:12 AM >> > >> >> *To:* IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>> >> > >> <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com> >> >> > <mailto:IBryskin@advaoptical.com >> <mailto:IBryskin@advaoptical.com>>>> >> > >> >> *Cc:* ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>> >> >> > >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>> >> >> > <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org> >> <mailto:ccamp@ietf.org <mailto:ccamp@ietf.org>>>> >> > >> >> *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 >> > >> > CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org>> >> >> > <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org>>> >> >> > >> > https://www.ietf.org/mailman/listinfo/ccamp >> > >> > >> > >> >> > >> _______________________________________________ >> > >> CCAMP mailing list >> >> > >> CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org>> >> <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> >> > <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org>>> >> > >> https://www.ietf.org/mailman/listinfo/ccamp >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> CCAMP mailing list >> > >> CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> <mailto:CCAMP@ietf.org <mailto:CCAMP@ietf.org>> >> > >> https://www.ietf.org/mailman/listinfo/ccamp >> > > >> > >_______________________________________________ >> > >CCAMP mailing list >> > >CCAMP@ietf.org <mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org >> <mailto:CCAMP@ietf.org>> >> > >https://www.ietf.org/mailman/listinfo/ccamp >> > >_______________________________________________ >> > >CCAMP mailing list >> > >CCAMP@ietf.org <mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org >> <mailto:CCAMP@ietf.org>> >> > >https://www.ietf.org/mailman/listinfo/ccamp >> > >> > >> > >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org <mailto:CCAMP@ietf.org> >> > https://www.ietf.org/mailman/listinfo/ccamp >> > >> >> >>
- [CCAMP] Comments about draft-beeram-ccamp-network… Zafar Ali (zali)
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… John E Drake
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Igor Bryskin
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Zafar Ali (zali)
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… John E Drake
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Igor Bryskin
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Zafar Ali (zali)
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… John E Drake
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Lou Berger
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Igor Bryskin
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Vishnu Pavan Beeram
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Julien Meuric
- [CCAMP] 答复: Comments about draft-beeram-ccamp-net… Fatai Zhang
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Lou Berger
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Zafar Ali (zali)
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Vishnu Pavan Beeram
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Vishnu Pavan Beeram
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Lou Berger
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Vishnu Pavan Beeram
- Re: [CCAMP] Comments about draft-beeram-ccamp-net… Igor Bryskin
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Igor Bryskin
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Lou Berger
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Igor Bryskin
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Lou Berger
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Igor Bryskin
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Lou Berger
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Igor Bryskin
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Lou Berger
- [CCAMP] 答复: 答复: Comments about draft-beeram-ccamp… Fatai Zhang
- Re: [CCAMP] 答复: Comments about draft-beeram-ccamp… Igor Bryskin
- Re: [CCAMP] 答复: 答复: Comments about draft-beeram-c… Dieter Beller
- Re: [CCAMP] 答复: 答复: Comments about draft-beeram-c… Zafar Ali (zali)
- Re: [CCAMP] 答复: 答复: Comments about draft-beeram-c… Rajan Rao
- Re: [CCAMP] 答复: 答复: Comments about draft-beeram-c… Igor Bryskin
- [CCAMP] 答复: 答复: 答复: Comments about draft-beeram-c… Fatai Zhang