Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
Lou Berger <lberger@labn.net> Tue, 07 May 2013 13:52 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 84E5F21F8C69 for <ccamp@ietfa.amsl.com>; Tue, 7 May 2013 06:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.591
X-Spam-Level:
X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 OEOv+dEu4etV for <ccamp@ietfa.amsl.com>; Tue, 7 May 2013 06:52:21 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id BD8A321F8BE4 for <ccamp@ietf.org>; Tue, 7 May 2013 06:52:20 -0700 (PDT)
Received: (qmail 30890 invoked by uid 0); 7 May 2013 13:51:53 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 7 May 2013 13:51:53 -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=wI1sY7uU8VEmvZXDi2JObNVMondgutubjk3XgBhiiOs=; b=lviHvPUXqhRgf5dbbaBCi/D0PE4y5LZTqjMGLYC9w7ju5Qs/gCPxQWGdQTZsZF2UQoslp6WNbbfv4GrH26Ymowe1ND8hh47Glr2CgfUTWU+SolrkW66Z4HgD0IQE6/YI;
Received: from box313.bluehost.com ([69.89.31.113]:55884 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UZiJ7-00055F-Dd; Tue, 07 May 2013 07:51:53 -0600
Message-ID: <518906F8.50507@labn.net>
Date: Tue, 07 May 2013 09:51:52 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>
References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
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 <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org>
Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
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, 07 May 2013 13:52:28 -0000
[oops, found this in my outbox -- sorry about the delay] Young, I think this discussion primarily comes down to the intent of mentioning drop ports in several places in Section 6 of the info document. Is the scope of this text aimed at just regen ports or any drop (regen &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on 4/4, I understood it to refer to the advertisement of information for any drop port. so: > Did I misunderstand the intent of mentioning drop ports in several > places in Section 6 of the info document? If the intended scope is just regen, this needs to be made clear in the documents. Furthermore, as the same (G-PID compatibility identification) issue exists with the egress, why wouldn't the same solution be used for both? Much thanks, Lou On 4/24/2013 12:17 PM, Leeyoung wrote: > Hi Lou, > > I think the main point is if we need to advertise add/drop > (tributary) ports in generic context? You said in the previous > email: > > "I agree that that is how it is normally done, but WSON seems to be changing this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces." > > These elements above are part of regeneration elements that > constitute a WSON lightpath which begins the line side of ingress and > ends the line side of egress. See the diagram below: > > ---- ---- > | |<------------ -------------->| | > ---- | | ---- > -------- > | REG | > -------- > There is a clear use case for this for WSON as REG's are integral > part of a WSON lightpath which can cause an incompatibility/blocking > issue of the path. Drop/Add ports here in REG element may have > wavelength restriction and that is why this is an additional > constraint to look at. > > Advertising tributary ports in general context is a different matter > to me. Not sure if there is a clear use case that can be justified to > support advertising tributary ports in general context. Even if there > is, I don't think that is part of the scope of the generic encoding. > > > Regards, > Young > > > > > > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, April 04, 2013 5:06 PM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > Young, > Please see below. > > On 3/27/2013 1:59 PM, Leeyoung wrote: >> Hi Lou, >> >> Please see my comments in-line. >> >> Thanks. >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, March 19, 2013 11:44 AM >> To: Leeyoung >> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); >> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> >> Young, >> See below. >> On 3/18/2013 1:02 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> The encoding is a part of the Resource Block >> >> Understood, but my comment was more on the definition of >> <ClientSignalList>/<client-signal-list> encoding. >> >>> (that includes Regenerators and Wavelength converters) which is a WSON specific entity. >> >> So I agree that the need for transit nodes to have detailed encoding >> and adaptation information to support 3R and certain other types of >> switching is (at least to my understanding) specific to WSON. >> > > Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized > Y> Label Request parameters to indicate client/tributary layer of the > Y> LSP at the source/sink. > Y> > Y> I was not clear on what you meant "trib side resources." If you meant > Y> "trib side resources" are LSP encoding type, Switching Type and G-PID > Y> (which are covered by RFC 3471/4328), I believe RFC 3471/4328 are > Y> sufficient; if not could you elaborate? > > trib side = add/drop port at ingress/egress > > resources = attributes related to data that port can transport > >> >> But unless I misunderstand the WSON info draft, this same information >> can be advertised in support of the trib side resources (i.e., at the >> source/destination for add/drop) and this is a generic requirement >> shared with other technologies. >> > > y> YOUNG>> Here you seemed to allude the need for advertizing the > y> Source/Destination tributary resource information using IGP. In > y> general, OSPF does not advertise the trib-side information, does it? > y> I believe signaling check on the tributary resource info on LSP level > y> is good enough per RFC 3471/4328. Please correct me if my > y> understanding is wrong. > > > I agree that that is how it is normally done, but WSON seems to be changing this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces. > > Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document? > >> >> So this lead me to ask about changing the G-PID list encoding to be >> defined in the generic drafts (to facilitate PID advertisement for >> non-WSON technologies.) Perhaps just having a generic encoding for a >> G-PID list won't be of much value, but I suspect that we'll end up >> needing it for other technologies too. >> > > Y> YOUNG>> This point is carried from the above discussion. G-PID has > Y> been specified to cover all GMPLS related technologies. > > Agreed that this is a derivative point and can wait until the above is clarified. > >> -- For what it's worth I am having some trouble understanding how >> G-PID is advertised for add/drop. As far as I can tell, you have a >> <LinkInfo> per add/drop port, mapped to <ResourcePool>, to a >> <ResourceBlockInfo> and infer output G-PID from the <InputConstraints>. >> At least that's how I'm reading the info draft. > > Y> YOUNG>> Actually G-PID is advertised as part of the Node > Y> information: <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] > Y> [<ResourcePool>] > > Got that. That's what I was referring to when I said " mapped to <ResourcePool>" >> >> Look at the diagram below from info draft: >> >> I1 +-------------+ +-------------+ E1 >> ----->| | +--------+ | |-----> >> I2 | +------+ Rb #1 +-------+ | E2 >> ----->| | +--------+ | |-----> >> | | | | >> | Resource | +--------+ | Resource | >> | Pool +------+ +-------+ Pool | >> | | + Rb #2 + | | >> | Input +------+ +-------| Output | >> | Connection | +--------+ | Connection | >> | Matrix | . | Matrix | >> | | . | | >> | | . | | >> IN | | +--------+ | | EM >> ----->| +------+ Rb #P +-------+ |-----> >> | | +--------+ | | >> +-------------+ ^ ^ +-------------+ >> | | >> | | >> | | >> | | >> >> Input wavelength Output wavelength >> constraints for constraints for >> each resource each resource >> >> Figure 1 Schematic diagram of resource pool model. >> >> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is >> part of link information and advertised as link-TLV; however Resource >> Blocks and its internal connectivity is not modeled as node property >> as they are internal to Resource Pool. >> >> <ResourcePool> ::= <ResourceBlockInfo>... >> [<ResourceAccessibility>...] [<ResourceWaveConstraints>...] >> [<RBPoolState>] >> >> We modeled how RB's are accessible via matrices (input/ouput), if >> there are wavelength limitations and if RB's are available. All of >> these are modeled as the node property. >> >> And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. >> >> <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints> >> [<ProcessingCapabilities>] <OutputConstraints>)* >> >> Where >> <InputConstraints> ::= <SharedInput> [<OpticalInterfaceClassList>] >> [<ClientSignalList>] >> >> >> >> I was delaying asking if a couple of related questions until the above >> was resolved, but perhaps it makes sense to ask them now: >> - Shouldn't <ClientSignalList> also be allowed under <OutputConstraints>? >> >> YOUNG>> It is implied. <ClientSignalList> is checked in <InputContraints> and <OutputConstraints> has obviously the same property. We can add this comment to clarify. >> > > So there is/will never (be) a case where the <OutputConstraints> differ from the <InputContraints>? As you say, this certainly should be made explicit. > >> - Doesn't it make sense to simplify the add/drop G-PID identification >> by adding <ClientSignalList> somewhere under (generic) <LinkInfo>? >> > y> YOUNG>> I think you meant doing this at the source/destination. > sure, but aren't add/drop always at source/destination? (I guess you can come up with a case where they aren't, but this isn't the norm...) > > Y> Again > y> I am not sure if we really need to advertise tributary client signal > y> as link TLV. We have signaling mechanism to verify this. > > As you say, this point is covered above. > >> Thanks, >> Lou >> >>> >>> Regards, >>> Young >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Monday, March 18, 2013 8:07 AM >>> To: Leeyoung; CCAMP >>> Cc: Margaria, Cyril (NSN - DE/Munich); >>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> Young/All, >>> >>> Some of the discussions last week (on 709 and dimitri's) got me >>> thinking more about the inclusion of G-PID on the wson specific >>> encoding. As G-PID and other client/input information is not >>> technology specific, and it looks like there's a likely a need for a >>> general solution, shouldn't the G-PID (and other 'client/input') >>> information be in draft-ietf-ccamp-general-constraint-encode? >>> >>> Thoughts? >>> >>> Lou >>> >>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>> Thanks. >>>> >>>> Young >>>> >>>> -----Original Message----- >>>> From: Margaria, Cyril (NSN - DE/Munich) >>>> [mailto:cyril.margaria@nsn.com] >>>> Sent: Thursday, March 14, 2013 5:53 PM >>>> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> >>>> Hi, >>>> >>>> Thanks for the quick feedback. As this introduce a dependency with >>>> the GPID, the text should indicate that the number of bit rate MUST match the number of GPID. >>>> >>>> Other than that I think this is acceptable >>>> >>>> >>>> >>>> Best regards / Mit freundlichen Grüßen Cyril Margaria >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa- >>>>> wson-encode@tools.ietf.org >>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Hi Cyril, >>>>> >>>>> Thanks for your comment. >>>>> >>>>> This refers to the "Input Bit Rate" of the associated client Signal >>>>> Type in the RB. >>>>> Below is a new section 5.4 that defines Input Bit Rate List Sub-Sub- >>>>> TLV. We removed "range" from this Sub-Sub-TLV. >>>>> >>>>> Let me know if this is acceptable. >>>>> >>>>> Thanks. >>>>> Young >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>> >>>>> This sub-sub-TLV contains a list of bit rate of each input client >>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>> Type := Input Bit Rate List >>>>> Value := IEEE 32-bit IEEE Floating Point >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #1 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> : : >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #N | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>>> Of Margaria, Cyril (NSN - DE/Munich) >>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Dear Authors, >>>>> >>>>> I have the following comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Section 5.1 Resource Block Information Sub-TLV >>>>> >>>>> The sub-TLV format defines the "Input Bit Rate Range List Sub-Sub-TLV >>>>> (opt)" >>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it was >>>>> present in the previous version. >>>>> >>>>> I think the section should be re-added. >>>>> >>>>> >>>>> Mit freundlichen Grüßen / Best Regards >>>>> Cyril Margaria >>>>> >>>>> Nokia Siemens Networks Optical GmbH >>>>> St.Martin-Str. 76 >>>>> D-81541 München >>>>> Germany >>>>> mailto:cyril.margaria@nsn.com >>>>> Phone: +49-89-5159-16934 >>>>> Fax: +49-89-5159-44-16934 >>>>> ---------------------------------------------------------------- >>>>> Nokia Siemens Networks Optical GmbH >>>>> Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz >>>>> Sitz der Gesellschaft: München / Registered office: Munich >>>>> Registergericht: München / Commercial registry: Munich, HRB 197143 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > >
- [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-enc… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Leeyoung
- Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson… Lou Berger