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

From: Lou Berger <[email-masked]>
Date: Thu, 04 Apr 2013 18:06:14 -0400

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:[email-masked]] 
> Sent: Tuesday, March 19, 2013 11:44 AM
> To: Leeyoung
> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); [email-masked]
> 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:[email-masked]] 
>> Sent: Monday, March 18, 2013 8:07 AM
>> To: Leeyoung; CCAMP
>> Cc: Margaria, Cyril (NSN - DE/Munich); [email-masked]
>> 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:[email-masked]] 
>>> Sent: Thursday, March 14, 2013 5:53 PM
>>> To: Leeyoung; CCAMP; [email-masked]
>>> 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:[email-masked]]
>>>> Sent: Wednesday, March 13, 2013 9:33 PM
>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa-
>>>> [email-masked]
>>>> 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: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of Margaria, Cyril (NSN - DE/Munich)
>>>> Sent: Wednesday, March 13, 2013 8:54 AM
>>>> To: CCAMP; [email-masked]
>>>> 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:[email-masked]
>>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>> _______________________________________________
>>> CCAMP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
> 
>

---

From: Leeyoung <[email-masked]>
Date: Wed, 24 Apr 2013 16:17:11 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, April 04, 2013 5:06 PM
To: Leeyoung
Cc: CCAMP; [email-masked]
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:
> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); 
> [email-masked]
> So I agree that the need for transit nodes to have detailed encoding 
> and adaptation information to support 3R and certain other types of 

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

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?

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

Got that.  That's what I was referring to when I said " mapped to <ResourcePool>"
>       I1   +-------------+                       +-------------+ E1

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

>> Cc: Margaria, Cyril (NSN - DE/Munich); 
>> [email-masked]
>> 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
>>
>>> 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.
>>>
>>> Best regards / Mit freundlichen Grüßen Cyril Margaria
>>>
>>>