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
> 
> 
> 
>