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

[Lou Berger <[e-mail]>]

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

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