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

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Mar 2013 13:53:59 +0000

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

---

From: Leeyoung <[email-masked]>
Date: Wed, 13 Mar 2013 20:32:31 +0000

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,

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 14 Mar 2013 22:53:26 +0000

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

> 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.
> 
> Below is a new section 5.4 that defines Input Bit Rate List Sub-Sub-
> TLV. We removed "range" from this 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.

---

From: Leeyoung <[email-masked]>
Date: Fri, 15 Mar 2013 09:35:40 +0000

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,

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Mar 2013 09:06:48 -0400

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

---

From: Leeyoung <[email-masked]>
Date: Mon, 18 Mar 2013 17:02:16 +0000

Hi Lou,

The encoding is a part of the Resource Block (that includes Regenerators and Wavelength converters) which is a WSON specific entity.

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,

Thoughts?

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Mar 2013 12:43:49 -0400

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

---

From: Leeyoung <[email-masked]>
Date: Wed, 27 Mar 2013 20:59:47 +0000

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.

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. 

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

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

YOUNG>> It is implied. <ClientSignalList> is checked in <InputContraints> and <OutputConstraints> has obviously the same property. We can add this comment to clarify. 

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