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

[Lou Berger <[e-mail]>]

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

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.

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

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

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