Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
Leeyoung <leeyoung@huawei.com> Wed, 24 April 2013 16:17 UTC
Return-Path: <leeyoung@huawei.com>
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 C3F4A21F8F0F for <ccamp@ietfa.amsl.com>; Wed, 24 Apr 2013 09:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HPX69T5SYTUe for <ccamp@ietfa.amsl.com>; Wed, 24 Apr 2013 09:17:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 86F3021F9026 for <ccamp@ietf.org>; Wed, 24 Apr 2013 09:17:24 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASD64795; Wed, 24 Apr 2013 16:17:17 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 17:16:46 +0100
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 17:17:17 +0100
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 24 Apr 2013 09:17:12 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
Thread-Index: AQHOMYCjjSbgAyDhM0mIOPaGuA1CEpjloTRA
Date: Wed, 24 Apr 2013 16:17:11 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.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>
In-Reply-To: <515DF956.1020305@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.198]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Wed, 24 Apr 2013 16:17:28 -0000
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