Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19

[Leeyoung <[e-mail]>]

Hi Lou,

Please see my comments in-line. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, March 19, 2013 11:44 AM
To: Leeyoung
Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); [e-mail]
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.  

YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized Label Request parameters to indicate client/tributary layer of the LSP at the source/sink.
I was not clear on what you meant "trib side resources." If you meant "trib side resources" are LSP encoding type, Switching Type and G-PID (which are covered by RFC 3471/4328), I believe RFC 3471/4328 are sufficient; if not could you elaborate? 

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.

YOUNG>> Here you seemed to allude the need for advertizing the Source/Destination tributary resource information using IGP. In general, OSPF does not advertise the trib-side information, does it? I believe signaling check on the tributary resource info on LSP level is good enough per RFC 3471/4328. Please correct me if my understanding is wrong. 


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.

YOUNG>> This point is carried from the above discussion. G-PID has been specified to cover all GMPLS related technologies. 

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

YOUNG>> Actually G-PID is advertised as part of the Node information: <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]
   [<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. 

- Doesn't it make sense to simplify the add/drop G-PID identification by
adding <ClientSignalList> somewhere under (generic) <LinkInfo>?

YOUNG>> I think you meant doing this at the source/destination. Again I am not sure if we really need to advertise tributary client signal as link TLV. We have signaling mechanism to verify this. 

Thanks,
Lou

> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Monday, March 18, 2013 8:07 AM
> To: Leeyoung; CCAMP
> Cc: Margaria, Cyril (NSN - DE/Munich); [e-mail]
> 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:[e-mail]] 
>> Sent: Thursday, March 14, 2013 5:53 PM
>> To: Leeyoung; CCAMP; [e-mail]
>> 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:[e-mail]]
>>> Sent: Wednesday, March 13, 2013 9:33 PM
>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa-
>>> [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Margaria, Cyril (NSN - DE/Munich)
>>> Sent: Wednesday, March 13, 2013 8:54 AM
>>> To: CCAMP; [e-mail]
>>> 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:[e-mail]
>>> Phone: [phone]
>>> Fax:   [phone]
>>> ----------------------------------------------------------------
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
>