Subject: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

From: Snigdho Bardalai <[email-masked]>
Date: Tue, 6 Jul 2010 12:59:51 -0700

Hello,

I have a comment and a question on Section 3.1.2.1. This section describes the link-parameters that are required for OTN service routing purposes.

My comment is how are we going to advertise the low-order ODUj availability within a higher-order container. For example, consider an OTU3 link which has 16 time-slots of 2.5G granularity and then we establish an ODU2 service over the link. At this point in time the OTU3 link has 12 time-slots available for ODU2 services and up to 12+4 time-slots available for ODU1 services (4 ODU1s are contained over the ODU2). So it is obvious from this example that the number of time-slots available is different based on the signal-type (i.e. ODU1 and ODU2). How do we address this issue based on the approach specified in the draft?

My other question is why not simply advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent bandwidth in bytes/sec within a link? This approach seems to be more in-line with the general approach outlined in RFC-4202. Refer to section 3.4 in RFC 4202 for an example that shows multiple ISCDs being advertised per VC rate for an SDH link. The additional benefit is that the advertisement is TS size independent and hence will simplify the implementation.

Regards
Snigdho

---

From: Lou Berger <[email-masked]>
Date: Wed, 07 Jul 2010 11:37:07 -0400

Snigdho,
	I believe there has been some off-line discussion on how to better 
align the work with 4202.  Use of common approaches is of course one of 
the main objectives of *C*CAMP.  I look forward to hearing from the 
draft and discussion contributors on there progress on this point.

Lou

On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
> Hello,
>
> I have a comment and a question on Section 3.1.2.1. This section
> describes the link-parameters that are required for OTN service routing
> purposes.
>
> My comment is how are we going to advertise the low-order ODUj
> availability within a higher-order container. For example, consider an
> OTU3 link which has 16 time-slots of 2.5G granularity and then we
> establish an ODU2 service over the link. At this point in time the OTU3
> link has 12 time-slots available for ODU2 services and up to 12+4
> time-slots available for ODU1 services (4 ODU1s are contained over the
> ODU2). So it is obvious from this example that the number of time-slots
> available is different based on the signal-type (i.e. ODU1 and ODU2).
> How do we address this issue based on the approach specified in the draft?
>
> My other question is why not simply advertize the available number of
> ODU0, ODU1, ODU2, …, ODU4 container instances or the equivalent
> bandwidth in bytes/sec within a link? This approach seems to be more
> in-line with the general approach outlined in RFC-4202. Refer to section
> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
> advertised per VC rate for an SDH link. The additional benefit is that
> the advertisement is TS size independent and hence will simplify the
> implementation.
>
> Regards
>
> Snigdho
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Snigdho Bardalai <[email-masked]>
Date: Wed, 7 Jul 2010 08:43:46 -0700

Hi Lou

Thanks, I also would like to hear about the same.

Snigdho

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, July 07, 2010 8:37 AM
To: Snigdho Bardalai
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snigdho,

Lou

On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 08 Jul 2010 09:32:35 +0800

Hi Snigdho and Lou,

Yes, we have lots of off-line discussions among authors and other interested experts, and we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

The framework draft just tells you what information needed for control plane, no matter how you encode the routing information. For TDM networks, you know the resource is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

If you are trying to find how to encode the routing information, I think you need go to the routing drafts (info model and encoding).

If you look at the routing drafts (info model and encoding), you will find that one of your suggestions is adopted (i.e., simply advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances).

One more thing for your first comment:
If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing TE link (like RFC4206bis).

Best Regards
 
Fatai

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Thu, 8 Jul 2010 14:27:16 +0200

Just to add that the the new version of the info model draft is already available
 
http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-01.txt
 
while the -02 version of the encoding draft will be available in a couple of days.
 
Best regards
 
Daniele

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: giovedì 8 luglio 2010 3.33
To: Snigdho Bardalai; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Snigdho and Lou,

 

Best Regards
 
Fatai
 
----- Original Message ----- 
From: "Snigdho Bardalai" <[email-masked] <mailto:[email-masked]> >
To: "Lou Berger" <[email-masked] <mailto:[email-masked]> >
Cc: <[email-masked] <mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, July 07, 2010 11:43 PM
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp> 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp> 
>

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 08:10:17 -0700

Hi Fatai

I think we need to sort out the issues with the framework document before we can embark on any proposals to the problem. I am still not clear why do we have to deviate from the general approach that has been established in RFC 4202.

Additionally, I do not see any reason to advertise a new TE-link to represent the low-order ODUj bandwidth within the high-order containers. This is simply blowing up the solution to a very simple problem.

Regards
Snigdho

From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Snigdho and Lou,

Best Regards

Fatai

----- Original Message -----
From: "Snigdho Bardalai" <[email-masked]<mailto:[email-masked]>>
To: "Lou Berger" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 07, 2010 11:43 PM
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 8 Jul 2010 18:02:38 +0200

Hi Snigdho,

Framework draft is dealing with information needed form control plane prespective iin the OTN context , and list also requirements to be considered.(both form sugnaling and routing point of view)
Then we a draft with the aim to explain , starting from requirements described in the framework, how the present tools can accomplish or not these requirements.
And finally we have an encoding draft proposing a solution format.

It seems to me you're making question about encoding starting from requirements . As suggested by Fatai we probably discuss about the various points taking into consideration all the bunch of OTN CP work.

Best Regards

sergio

Sergio Belotti

System Architecture
Optics Division-Terrestrial Optics Unit
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Snigdho Bardalai
Inviato: giovedì 8 luglio 2010 17.10
A: Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Fatai

Regards
Snigdho

Hi Snigdho and Lou,

Best Regards

Fatai

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 09:12:28 -0700

Hi Sergio

Yes, I agree with the process you described and you are right I am questioning the routing requirements that are being laid out in the framework draft.

Regards
Snigdho

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 9:03 AM
To: Snigdho Bardalai
Cc: [email-masked]; [email-masked]; Fatai Zhang; Lou Berger
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Snigdho,

Best Regards

sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

Hi Fatai

Regards
Snigdho

Hi Snigdho and Lou,

Best Regards

Fatai

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 13:53:20 -0400

Snigdho,

Ø  I think we need to sort out the issues with the framework document before we can embark on any proposals to the problem. I am still not clear why do we have to deviate from the general approach that has been established in RFC 4202.

IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and it is highly desirable to adhere to the layer independent paradigm of advertising of TE links, and there is no reason to invent an OTN specific ISCD. The combination of Switching Capability and Encoding type of RFC4202 ISCD allows for specifying both multiplexing capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have another reserved 16 bits.

>Additionally, I do not see any reason to advertise a new TE-link to represent >the low-order ODUj bandwidth within the high-order containers. This is simply >blowing up the solution to a very simple problem.

IB>> Here I disagree. In order to give a user possibility to create OTN hierarchies and constrain LO connections to HO containers, one needs to advertise OTN links with different switchcaps.

Cheers,
Igor

Regards
Snigdho

Hi Snigdho and Lou,

Best Regards

Fatai

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 10:59:24 -0700

What do you mean by "different switchcaps"?

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Igor Bryskin
> Sent: Thursday, July 08, 2010 10:53 AM
> To: Snigdho Bardalai; Fatai Zhang; Lou Berger
> Ø  I think we need to sort out the issues with the framework document
> before we can embark on any proposals to the problem. I am still not clear
> why do we have to deviate from the general approach that has been
> established in RFC 4202.
> 
> 
> 
> IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and
> it is highly desirable to adhere to the layer independent paradigm of
> advertising of TE links, and there is no reason to invent an OTN specific
> ISCD. The combination of Switching Capability and Encoding type of RFC4202
> ISCD allows for specifying both multiplexing capabilities and OTN layer
> (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have
> another reserved 16 bits.
> 
> 
> 
> >Additionally, I do not see any reason to advertise a new TE-link to
> represent >the low-order ODUj bandwidth within the high-order containers.
> This is simply >blowing up the solution to a very simple problem.
> 
> 
> 
> IB>> Here I disagree. In order to give a user possibility to create OTN
> hierarchies and constrain LO connections to HO containers, one needs to
> advertise OTN links with different switchcaps.
> 
> 
> 
> Cheers,
> 
> Igor
> 
> 
> 
> Regards
> 
> Snigdho
> 
> 
> 
> Yes, we have lots of off-line discussions among authors and other
> interested experts, and we think the proposal described in "draft-
> ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible
> for OTN networks.
> 
> 
> 
> The framework draft just tells you what information needed for control
> plane, no matter how you encode the routing information. For TDM networks,
> you know the resource is allocated based on TS, so the available TS should
> be get or induced before creating cross-connect.
> 
> 
> 
> If you are trying to find how to encode the routing information, I think
> you need go to the routing drafts (info model and encoding).
> 
> 
> 
> If you look at the routing drafts (info model and encoding), you will find
> that one of your suggestions is adopted (i.e., simply advertize the
> available number of ODU0, ODU1, ODU2, ..., ODU4 container instances).
> 
> 
> 
> If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1,
> you have to advertise a new TE link or put this FA as a component link of
> an existing TE link (like RFC4206bis).
> 
> 
> 
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> Cc: <[email-masked] <mailto:[email-masked]> >; <draft-ietf-ccamp-gmpls-
> [email-masked] <mailto:draft-ietf-ccamp-gmpls-g709-
> [email-masked]> >
> 
> > Cc: [email-masked] <mailto:[email-masked]> ; draft-ietf-ccamp-gmpls-
> [email-masked] <mailto:draft-ietf-ccamp-gmpls-g709-
> [email-masked]>
> <https://www.ietf.org/mailman/listinfo/ccamp>
> <https://www.ietf.org/mailman/listinfo/ccamp>
> >

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 11:16:43 -0700

Igor,

Please see below.

Thanks,
Snigdho

From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 10:53 AM
To: Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snigdho,

IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and it is highly desirable to adhere to the layer independent paradigm of advertising of TE links, and there is no reason to invent an OTN specific ISCD. The combination of Switching Capability and Encoding type of RFC4202 ISCD allows for specifying both multiplexing capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have another reserved 16 bits.
[SCB]  I support your suggestion here.

IB>> Here I disagree. In order to give a user possibility to create OTN hierarchies and constrain LO connections to HO containers, one needs to advertise OTN links with different switchcaps.
[SCB] No disagreement with advertising the OTN link with different "switchcaps" but why do we need an FA?

Cheers,
Igor

Regards
Snigdho

Hi Snigdho and Lou,

Best Regards

Fatai

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:31:02 -0400

I think OTN links require more than one switchcaps: as many as the depth of the deepest possible OTN DP hierarchy, for example:

typedef enum
{
   LSPSwitchType_Unknown =0            /* Unknown */
   , LSPSwitchType_PSC_1 =1            /* PSC-1 */
   , LSPSwitchType_PSC_2 =2            /* PSC-2 */
   , LSPSwitchType_PSC_3 =3            /* PSC-3 */
   , LSPSwitchType_PSC_4 =4            /* PSC-4 */
   , LSPSwitchType_L2SC  =50           /* L2SC */
   , LSPSwitchType_TDM   =100          /* TDM */

/*****/
   , LSPSwitchType_OTN_LO=124   /* OTN low order */
   , LSPSwitchType_OTN_HO=125   /* OTN high order */
   , LSPSwitchType_OTN_SHO=126  /* OTN super high order */
/*****/
   , LSPSwitchType_LSC   =150          /* LSC */
   , LSPSwitchType_FSC   =200          /* FSC */
}e_LSPSwitchType;

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:34:37 -0400

We need FA because it is possible in GMPLS (and quite beneficial) to share the same routing instance between OTN layers

From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:17 PM
To: Igor Bryskin; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Please see below.

Thanks,
Snigdho

Snigdho,

Cheers,
Igor

Regards
Snigdho

Hi Snigdho and Lou,

Best Regards

Fatai

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 13:35:40 -0500

For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 in ODU4) - while this may be the worst case, it is the possible case too.

As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400G?) the depth of the hierarchy will grow.

This makes me wonder: wouldn't a generalized method be a better approach than just creating new SwitchingTypes -- especially since the signals supported within each of these is the same (e.g. an ODU1 over an ODU2 is the same as an ODU1 over an ODU3...)

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:40:19 -0400

There is a lot of swcaps available :=)
Separate swcaps provide an easy way to constrain connection to a desired level of hierarchy. 

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 11:43:30 -0700

Why not simply create switching capability descriptors per hierarchy (i.e. ODU0, ODU1,...)?

> Sent: Thursday, July 08, 2010 11:40 AM
> To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang;
> Lou Berger
> For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in
> ODU3 in ODU4) - while this may be the worst case, it is the possible
> case too.
> 
> As new signals/rates are added (e.g. ODU5 for "the next great speed" --
> 400G?) the depth of the hierarchy will grow.
> 
> This makes me wonder: wouldn't a generalized method be a better
> approach than just creating new SwitchingTypes -- especially since the
> signals supported within each of these is the same (e.g. an ODU1 over
> an ODU2 is the same as an ODU1 over an ODU3...)
> 
> Jonathan Sadler
> 
> I think OTN links require more than one switchcaps: as many as the
> depth of the deepest possible OTN DP hierarchy, for example:
> 
> typedef enum
> {
> > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > Snigdho,
> >
> >
> >
> >
> >
> > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> >
> >
> > Hi Snigdho and Lou,
> >
> >
> >
> > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> >
> >
> > > Hi Lou
> > >
> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> > >
> > > Snigdho,
> > >> How do we address this issue based on the approach specified in
> the
> > draft?
> > >>

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 13:45:33 -0500

How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals?

Since the switch-cap is end-to-end significant, there is no opportunity for changing it in the middle, but the specific relationship between the LSP and what it is being carried by can change.  For example, an ODU1 could start out on an OTU1, but at the next node (operated by the customer) be muxed into an ODU2 that goes into a carrier's edge-to-edge connection.  That carrier could in turn use a carriers-carrier service which muxes it into an ODU3.

At each point in this chain, the ODU1 has a different relationship to what is carrying it.  At the ODU1 over OTU1, it was an HO signal.  At the ODU1 over ODU2, it was a LO signal.  What is it at the ODU1 over ODU2 over ODU3?

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:45:41 -0400

Because the same signal (and connection) could be on a different hierarchy level.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:49:59 -0400

In the situation you describe the connection goes through more than one OTN layer. It is possible to route such connection by constraining path computation to more than layer (e.g. in case of restoration you may allow the connection to take any OTN link with sufficient bandwidth)

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 11:51:24 -0700

That means that the signal can be at different hierarchies over different OTN links along the route.

If that is the case how can you constraint a connection to a specific hierarchy end-to-end? I think all you can do is find an OTN link that can support the required signal-type.

> Sent: Thursday, July 08, 2010 11:46 AM
> To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang;
> Lou Berger
> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Igor Bryskin
> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > > before we can embark on any proposals to the problem. I am still
> not
> > clear
> > > IB>> Agree absolutely. GMPLS is inherently multi-layer control
> plane,
> > and
> > > hierarchies and constrain LO connections to HO containers, one
> needs
> > to
> > > If you look at the routing drafts (info model and encoding), you
> will
> > find
> > > >> establish an ODU2 service over the link. At this point in time
> the
> > OTU3
> > > >> time-slots available for ODU1 services (4 ODU1s are contained
> over
> > the
> > > >> ODU2). So it is obvious from this example that the number of
> time-
> > slots
> > > >> My other question is why not simply advertize the available
> number
> > of
> > > >> advertised per VC rate for an SDH link. The additional benefit
> is
> > that

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 11:51:22 -0700

Igor,

I suppose you could do that but it doesn't seem necessary.  I think the existing TDM ISC could be re-used:

Switching capability = TDM
Encoding = OTN
Max LSP BW (0-7) = max ODU rate at that priority
Min LSP BW = min ODU rate

(where rates are expressed in bytes per second)

There would be one or more of these advertised, such that every ODU rate currently supported by the advertising node is advertised either explicitly or implicitly, by being within the range covered by a Min/Max LSP BW pair.

Thanks,

John
> Sent: Thursday, July 08, 2010 11:36 AM
> For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3
> in ODU4) - while this may be the worst case, it is the possible case too.
> 
> This makes me wonder: wouldn't a generalized method be a better approach
> than just creating new SwitchingTypes -- especially since the signals
> supported within each of these is the same (e.g. an ODU1 over an ODU2 is
> the same as an ODU1 over an ODU3...)
> 
> Jonathan Sadler
> 
> I think OTN links require more than one switchcaps: as many as the depth
> of the deepest possible OTN DP hierarchy, for example:
> 
> typedef enum
> {

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 14:57:57 -0400

>If that is the case how can you constraint a connection to a >specific hierarchy end-to-end? 

You don't have to. You MAY constrain a connection to take, for example, only LO links. But you can also allow the connection to take either HO or LO links. Also, keep in mind that GMPLS allows to advertise OTN link to belong to more than one OTN layer.

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:51 PM
To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> > Behalf Of

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 13:57:20 -0500

The only way I can see that working is if the entity doing path computation knows about the equivalence of Switching Cap/Encapsulation Type/Signal Type tuples. That sounds like the path computation function has to know specific details about the technology...

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 15:01:58 -0400

This won't allow an easy way to constrain a connection to a desired level of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by different levels, and what if an operator wants to constrain the connection to a particular one?

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:51 PM
To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 15:05:37 -0400

All path computation needs to know is switchcap/encoding type combination the connection is allowed to take. This is the GMPLS universal multi-layer approach (not specific to OTN).

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:57 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 14:14:38 -0500

I'm not certain I agree this is "universal".  Consider an LSP with a loose ERO hop -- how does the intermediate GMPLS NE know what Switching Cap/Encoding Type to allow?  The LSP signaling only contains one Switching Cap/Encoding Type...

Again, it looks like that intermediate node has to understand specific details about the technology...

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:57 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 14:18:27 -0500

John,

I agree that a single Switching Cap/Encoding Type should be possible.  What needs to be considered is how the potential LSP hierarchy is announced -- especially when G.709 (2009) specific signals are being setup over G.709 (2003) intermediate nodes...

Jonathan Sadler

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 1:51 PM
To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 15:26:43 -0400

Agree, but we all know that ingress NE has more information than transit NEs. For instance, how a transit NE knows whether optical impairments need or need not to be considered in WDM layer path computation? This is a service specific policy and unless it is signaled is known only on the ingress NE,

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 3:15 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:57 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 14:32:00 -0500

I agree that for existing standards there are some constraints (e.g. impairments, latency) that cannot be handled by the intermediate node.

However, in this case, the introduction of multiple switching capabilities is creating this problem.  If a method exists that solves the need to show hierarchy supported but doesn't create this problem, I would expect it to be more desirable.

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:15 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:57 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 12:09:34 -0700

Igor,

You are arguing backwards from a capability that might or might not be needed.  I don't recall seeing this requirement in any of the CCAMP OTN documents to date.

I actually have the impression that the requirement is actually the opposite; viz, establish an LSP by whatever means.

Thanks,

John

> Sent: Thursday, July 08, 2010 12:02 PM
> To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou
> Berger
> This won't allow an easy way to constrain a connection to a desired level
> of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by
> different levels, and what if an operator wants to constrain the
> connection to a particular one?
> 
> There would be one or more of these advertised, such that every ODU rate
> currently supported by the advertising node is advertised either
> explicitly or implicitly, by being within the range covered by a Min/Max
> LSP BW pair.
> 
> Thanks,
> 
> John
> ODU3

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 15:42:35 -0400

> However, in this case, the introduction of multiple  switching capabilities is creating this problem.  If a method exists that solves the need to show hierarchy supported but doesn't create this pr…

IB>> I almost always compute entire explicit end-to-end paths in one place (ingress NE or remote PCE) even when explicit loose paths are specified. But in rear cases when I have to do distributed path computation, in OTN case I would simply assume that all OTN layers are allowed

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:32 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:15 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:57 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:46 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 15:49:14 -0400

John,

HO connections may make up a topology for LO connections. They may require different planning and created in different time frame. Ergo it is likely that an operator may want to route a service LO connection over topology he prepared rather than over any OTN capable links.

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 3:10 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 12:24:44 -0700

Jonathan,

I would have to see some examples.  What I proposed was simply a reduced version of what is in the OTN routing I-D.  It tried to advertise available bandwidth by ODUj, which I don't think is necessary.

Thanks,

John

> Sent: Thursday, July 08, 2010 12:18 PM
> To: John E Drake; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger
> I agree that a single Switching Cap/Encoding Type should be possible.
> What needs to be considered is how the potential LSP hierarchy is
> announced -- especially when G.709 (2009) specific signals are being setup
> over G.709 (2003) intermediate nodes...
> 
> Jonathan Sadler
>

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 13:07:19 -0700

Igor,

>From the I-D under discussion:

"While [G872-2001] considered the ODU as a set of layers in the same
 way as SDH has been modeled, recent ITU-T OTN architecture progress
 [G872-Am2] includes an agreement to model the ODU as a single layer
 network with the bit rate as a parameter of links and connections.
 This allows the links and nodes to be viewed in a single topology as
 a common set of resources that are available to provide ODUj
 connections independent of the value of j. Note that when the bit
 rate of ODUj is less than the server bit rate, ODUj connections are
 supported by HO-ODU (which has a one-to-one relationship with the
 OTU)."

"Therefore, this document only considers ODU layer for LO ODU connection request."

"GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor of TDM which can be used for ODU."

"Thus, for example, an ODU2 connection service request could be supported by: OTU2 links (here the connection service rate is the same as the link rate), a combination of OTU2 and OTU3 links, OTU3 links, etc."

Thanks,

John

> Sent: Thursday, July 08, 2010 12:49 PM
> HO connections may make up a topology for LO connections. They may require
> different planning and created in different time frame. Ergo it is likely
> that an operator may want to route a service LO connection over topology
> he prepared rather than over any OTN capable links.
>
> You are arguing backwards from a capability that might or might not be
> needed.  I don't recall seeing this requirement in any of the CCAMP OTN
> documents to date.
>
> I actually have the impression that the requirement is actually the
> opposite; viz, establish an LSP by whatever means.
>
> Thanks,
>
> John
>
> > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang;
> Lou
> > Berger
> approach
> depth
> > > Of
> > > > you have to advertise a new TE link or put this FA as a component
> link
> > > of
> > > > > align the work with 4202.  Use of common approaches is of course
> one
> > > of
> > > > >> availability within a higher-order container. For example,
> consider
> > > an

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 16:29:41 -0400

Jonathan,

According to ITU-T each layer must have a separate routing instance, hence ITU-T folks assume that it would be very awkward to model an OTN network as a multi-layer network.

IN GMPLS, however, we do not have such a limitation. it is OK to share a routing instance between several layers and we can take advantage of this. With the multi-layer approach I suggest one can do everything what is possible to do in a single-layer approach by constraining the routing to all OTN layers. However. It gives certain flexibility in building OTN hierarchies and constraining connections to desired levels of hierarchy, which is not obvious how can be done within a single layer.

Ypu wrote:

What if in the described scenario the operator wants to constrain or prefer for a given ODU2 connections usage of only OTU2 links rather than other possible combinations perhaps provisioned for different purposes?

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 4:07 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 13:43:39 -0700

Igor,

Even though I think you are making up requirements as you go, on behalf of service providers to whom you have never spoken, I think that the scheme I proposed would support what you are stipulating as a requirement without any trouble.

By controlling the values of min/max LSP bandwidth that are advertised, one can clearly see which links are ODU2, ODU3, etc., and route an LSP request along only those links with the required granularity.

Thanks,

John
> Sent: Thursday, July 08, 2010 1:30 PM
> According to ITU-T each layer must have a separate routing instance, hence
> ITU-T folks assume that it would be very awkward to model an OTN network
> as a multi-layer network.
>
> IN GMPLS, however, we do not have such a limitation. it is OK to share a
> routing instance between several layers and we can take advantage of this.
> With the multi-layer approach I suggest one can do everything what is
> possible to do in a single-layer approach by constraining the routing to
> all OTN layers. However. It gives certain flexibility in building OTN
> hierarchies and constraining connections to desired levels of hierarchy,
> which is not obvious how can be done within a single layer.
>
> Ypu wrote:
> "Thus, for example, an ODU2 connection service request could be supported
> by: OTU2 links (here the connection service rate is the same as the link
> rate), a combination of OTU2 and OTU3 links, OTU3 links, etc."
>
> What if in the described scenario the operator wants to constrain or
> prefer for a given ODU2 connections usage of only OTU2 links rather than
> other possible combinations perhaps provisioned for different purposes?
>
> Cheers,
> Igor
>
> "Thus, for example, an ODU2 connection service request could be supported
> by: OTU2 links (here the connection service rate is the same as the link
> rate), a combination of OTU2 and OTU3 links, OTU3 links, etc."
>
> Thanks,
>
> John
>
> > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang;
> Lou
> > Berger
> > > I suppose you could do that but it doesn't seem necessary.  I think
> the
> > > existing TDM ISC could be re-used:
> > >
> > > > As new signals/rates are added (e.g. ODU5 for "the next great speed"
> -
> > -
> > > > supported within each of these is the same (e.g. an ODU1 over an
> ODU2
> > is
> > > > > IB>> Here I disagree. In order to give a user possibility to
> create
> > > OTN
> > > > > you know the resource is allocated based on TS, so the available
> TS
> > > > should
> > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA
> for
> > > > ODU1,
> > > > > >> in-line with the general approach outlined in RFC-4202. Refer
> to
> > > > > section
> > > > > >> the advertisement is TS size independent and hence will
> simplify
> > > the
> > > > > >> implementation.
> > > > > >>
> > > > > >> Regards
> > > > > >>
> > > > > >> Snigdho
> > > > > >>
> > > > > >>
> > > > > >>

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 8 Jul 2010 16:14:06 -0500

Hi Igor,

I beg to differ with your characterization about the ITU-T's standards.

G.7715 (2002) and G.7715.1 (2003) recognize the benefit of having a single routing instance carrying information about multiple layers (see G.7715 Section 5.2).  What is required is link attribute information is defined per layer (see G.7715.1 section 9.5).  This allows variable adaptation (such as found in SONET/SDH) to have a single advertisement, but provide different attribute information for each layer (e.g. separate information for VT1.5/VC11, STS1/VC3, STS3c/VC4, STS12c/VC4-4c).  It also enables separate routing instances to be used per layer if the service provider/vendor chooses to do so.

The ITU-T has recently consented an amendment to G.8080 that defines a new construct - the transitional link.  A liaison about this has been sent by ITU-T to IETF (see https://datatracker.ietf.org/liaison/910/).

Transitional links enable the routing information being carried from different layers in a single instance to show the relationships where termination/adaptation points exist.  And it only works when a single routing instance is used to carry information about multiple layers.

If you're not familiar with the ITU-T's transitional link - think of it as information similar to the IACD defined in the MLN/MRN solution RFCs.  (There are some differences, but the intent is the same.)

This transitional link construct is certainly applicable to G.709 (2009) networks, and can show the relationship for how an ODU1 would be routed over various server layers (e.g. ODU1 over OTU1, ODU1 over ODU2 over OTU2, ODU1 over ODU2 over ODU3 over OTU3, ...).

Jonathan Sadler

P.S. I didn't write the quote you included in your email... but the situation you describe isn't specific to OTN -- it would exist for any multi-layer interaction. (e.g. lighting a lambda to satisfy a 2.5G demand).  Again, a technology agnostic solution would make more sense to me than one that is technology specific.

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:30 PM
To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan,

Ypu wrote:

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 4:07 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 17:19:38 -0400

John,

You wrote::

" Even though I think you are making up requirements as you go, on behalf of service providers to whom you have never spoken"

IB>> And how would you know that?

IB>> No, you can not do this. In the example you described "OTU2 links,
, a combination of OTU2 and OTU3 links, OTU3 links, etc." may advertise the same value of min/max LSP bandwidth currently available on the links after some resources are allocated. Besides, in a multi-layer GMPLS path computation I'd like to constrain a computation to particular layer(s) in a universal way (which is usually done by evaluating advertised switchcaps/encoding type) without making any layer or technology specific considerations.

Igor

Thanks,

John

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 17:34:53 -0400

Hi Jonathan,

Thanks for this information. My understanding of ITU-T standards is clearly outdated.
You wrote:
"Again, a technology agnostic solution would make more sense to me than one that is technology specific"

But this is exactly the point of my suggestion: constraining the routing to particular layer(s) just by looking at the the advertised switchcaps/encoding type pairs. How is that not a technology agnostic solution? In our multi-layer implementation we are using this approach to separate WDM, generic sub-lambda, OTN and Ethernet layers already.

Thanks,
Igor

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 5:14 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

Jonathan Sadler

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:30 PM
To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan,

Ypu wrote:

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 4:07 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2010 14:40:47 -0700

> Sent: Thursday, July 08, 2010 2:20 PM
> " Even though I think you are making up requirements as you go, on behalf
> of service providers to whom you have never spoken"
>
[JD]

Everything you have been mentioning as a requirement runs counter to what the existing OTN I-Ds, Jonathan's explanation of ITU modeling, etc. are saying, and I haven't seen anyone express any agreement with you.

>
> By controlling the values of min/max LSP bandwidth that are advertised,
> one can clearly see which links are ODU2, ODU3, etc., and route an LSP
> request along only those links with the required granularity.
>
> , a combination of OTU2 and OTU3 links, OTU3 links, etc." may advertise
> the same value of min/max LSP bandwidth currently available on the links
> after some resources are allocated. Besides, in a multi-layer GMPLS path
> computation I'd like to constrain a computation to particular layer(s) in
> a universal way (which is usually done by evaluating advertised
> switchcaps/encoding type) without making any layer or technology specific
> considerations.
[JD]

We will see.  I know this won't mean anything to you, but switching capability has a very specific meaning and it isn't network layer indicator.

> > "GMPLS Routing [RFC4202] defines Interface Switching Capability
> Descriptor
> > of TDM which can be used for ODU."
> >
> > > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai
> Zhang;
> > > Lou
> > > > Berger
> > > > > in ODU4) - while this may be the worst case, it is the possible
> case
> > > > too.
> > > > >
> > > > > > it is highly desirable to adhere to the layer independent
> paradigm
> > > of
> > > > > > ISCD. The combination of Switching Capability and Encoding type
> of
> > > > > RFC4202
> > > > > > ISCD allows for specifying both multiplexing capabilities and
> OTN
> > > > layer
> > > > > > >Additionally, I do not see any reason to advertise a new TE-
> link
> > to
> > > > > > If you are trying to find how to encode the routing information,
> I
> > > > think
> > > > > > Cc: <[email-masked] <mailto:[email-masked]> >; <draft-ietf-
> ccamp-
> > > > gmpls-
> > > > > > > the main objectives of *C*CAMP.  I look forward to hearing
> from
> > > the
> > > > > > >> describes the link-parameters that are required for OTN
> service
> > > > > routing
> > > > > > >> purposes.
> > > > > > >>
> > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and
> then
> > we
> > > > > > >> available is different based on the signal-type (i.e. ODU1
> and
> > > > ODU2).
> > > > > > >> bandwidth in bytes/sec within a link? This approach seems to
> be
> > > > more

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 8 Jul 2010 15:07:47 -0700

Igor,

It is not clear why are you requiring the constraint for a connection to take a specific level in the hierarchy end-to-end? Is it a hardware specific issue you are trying to address?

Snigdho

> Sent: Thursday, July 08, 2010 11:58 AM
> You don't have to. You MAY constrain a connection to take, for example,
> only LO links. But you can also allow the connection to take either HO
> or LO links. Also, keep in mind that GMPLS allows to advertise OTN link
> to belong to more than one OTN layer.
>
>
> If that is the case how can you constraint a connection to a specific
> hierarchy end-to-end? I think all you can do is find an OTN link that
> can support the required signal-type.
>
> > --
> > > link of
> > > one of
> > > consider an

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Jul 2010 18:15:54 -0400

No, just network policies and planning.

Cheers,
Igor

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 6:08 PM
To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Snigdho

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Fri, 9 Jul 2010 10:25:30 +0200

All,

We tried analize if the the ISCD was enough to meet ITU requirements, if it needed to be modified, replaced or whatever. The result of our analysis has been translated into an info-model draft:

http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-01.txt.

Each requirement has been considered and a reason why it can be addressed via RFC4202 or not has been given. Could you please send your comments about it? 

Many thanks and BR
The authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: venerdì 9 luglio 2010 0.16
To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 6:08 PM
To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Snigdho

> hierarchy end-to-end?
> You don't have to. You MAY constrain a connection to take, for 
> example, only LO links. But you can also allow the connection to take 
> either HO or LO links. Also, keep in mind that GMPLS allows to 
> advertise OTN link to belong to more than one OTN layer.
>
>
> > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai 
> > Zhang; Lou Berger
> > > There is a lot of swcaps available :=) Separate swcaps provide an 
> > > easy way to constrain connection to a desired level of hierarchy.
> > >
> > >    , LSPSwitchType_OTN_SHO=126  /* OTN super high order */ /*****/

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 9 Jul 2010 10:45:04 +0200

Hi Igor,

We are on the same page here, this is the reason in CH. 5.3 of the framework of the requirement 
-	Support for differentiating between link multiplexing capacity and link rate capacity

Best Regards

sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: giovedì 8 luglio 2010 21.49
A: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 3:10 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 9 Jul 2010 11:08:06 +0200

Hi Igor, Jonathan,

I tent to agree with Jonathan.
The nature of signals in the different possible chains in the OTN hierarchies is the same . My understanding of Switching Cap is that different Switching Cap would be linked to different technologies imply different switching capabilities  : we have not created different Switching Cap for VC4 or VC12 in SDH. 

Best Regards

sergio

Best Regards

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 09 Jul 2010 17:42:55 +0800

Hi Igor and all,

I think we are at the same line about the requrement of network policy and planning. For transport networks, the tunnels for transporting service usually should be planed under some policy. Therefore, we may need to differentiate full lambda LSP or sub lambda LSP when creating a connection. We would like to reflect the requirement much clearer in the FWK document.

However, to meet the requirment, I personally think that maybe we don't need to extend ISC type. For example, Lo ODU, Ho ODU, SHO ODU, they are relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level?

Another point is about why the existing ISCD is not competent. 

We all know the history of the GMPLS, which is inherited from MPLS.  In MPLS networks, we can only use floating point number to identify the bandwidth. However, for the TDM network, the resource is alloacted based on the TS, so it is very naturally to use TS (or per signal type) to encode the bandwidth. If we use the floating point number, the routing still need to convert the floating point to see how many TS or signal (ODUk) can be supported to create the connections. Secondly, if we use the existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min LSP bandwidth (ODU1), how to know whether it can support ODUflex; How to know if it can support ODU2 and ODU3 if the equipments may have some constraits. Thirdly, in TDM networks, it is not efficient for scalability issue if we use the existing ISCD, because it needs 32 bits to indicate the bandwidth (Actually, we only need much fewer bits to identify the signal type (e.g., ODUk)).

Hope this can clarify your concern.

Best Regards
 
Fatai
 
----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: "Snigdho Bardalai" <[email-masked]>; "Sadler, Jonathan B." <[email-masked]>; "John E Drake" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, July 09, 2010 6:15 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 6:08 PM
To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Snigdho

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Jul 2010 08:58:47 -0400

Sergio,

You wrote:

" My understanding of Switching Cap is that different Switching Cap would be linked to different technologies imply different switching capabilities

IB>> We do have PSC1-PSC4 for packet switching ( note, one per MPLS DP hierarchy level, I suggest the same for OTN). We have also agreed that a single L2SC is not enough for Ethernet technology, in fact, we need separate swicthcaps for STAG switching, EPL, EVPL, etc. 

"  : we have not created different Switching Cap for VC4 or VC12 in SDH". 

IB>> IMO this is the reason why GMPLS in TDM has never really taken off.

Igor

Best Regards

sergio

Best Regards

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Jul 2010 05:59:14 -0700

> Sent: Friday, July 09, 2010 2:43 AM
> To: Igor Bryskin; Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Lou
> Berger
> Cc: [email-masked]
> I think we are at the same line about the requrement of network policy and
> planning. For transport networks, the tunnels for transporting service
> usually should be planed under some policy. Therefore, we may need to
> differentiate full lambda LSP or sub lambda LSP when creating a
> connection. We would like to reflect the requirement much clearer in the
> FWK document.
>
> However, to meet the requirment, I personally think that maybe we don't
> need to extend ISC type. For example, Lo ODU, Ho ODU, SHO ODU, they are
> relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regard
> ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there
> is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2
> (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this
> case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level?
[JD]

I agree.  Switching capability is very different from network layer indicator.

> We all know the history of the GMPLS, which is inherited from MPLS.  In
> MPLS networks, we can only use floating point number to identify the
> bandwidth. However, for the TDM network, the resource is alloacted based
> on the TS, so it is very naturally to use TS (or per signal type) to
> encode the bandwidth.
[JD]

You seem to be ignoring the fact that for both SDH/SONET and lambda switching, floating point bytes per second is currently used.

> If we use the floating point number, the routing
> still need to convert the floating point to see how many TS or signal
> (ODUk) can be supported to create the connections.
[JD]

If bytes per second is used, there is no need to advertise TS.  Your reason for not using bytes per second boils down to you simply not liking it.

> Secondly, if we use the
> existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min
> LSP bandwidth (ODU1), how to know whether it can support ODUflex; How to
> know if it can support ODU2 and ODU3 if the equipments may have some
> constraits. Thirdly, in TDM networks, it is not efficient for scalability
> issue if we use the existing ISCD, because it needs 32 bits to indicate
> the bandwidth (Actually, we only need much fewer bits to identify the
> signal type (e.g., ODUk)).
[JD]

No one is advocating using the existing ISC, rather whatever is designed should be consistent with the rest of GMPLS.

In particular we should have bandwidth advertised in bytes per second, eight priority levels each with total unreserved bandwidth, a simple indication (such as a bit vector) of what switching granularities are currently supported, and ODU flex bandwidth by priority level.

> From: "Igor Bryskin" <[email-masked]
> <mailto:[email-masked]> >
> To: "Snigdho Bardalai" <[email-masked]
> <mailto:[email-masked]> >; "Sadler, Jonathan B."
> <[email-masked] <mailto:[email-masked]> >; "John
> E Drake" <[email-masked] <mailto:[email-masked]> >; "Fatai Zhang"
> <[email-masked] <mailto:[email-masked]> >; "Lou Berger"
> <[email-masked] <mailto:[email-masked]> >
> Cc: [email-masked] <mailto:[email-masked]> ; draft-ietf-ccamp-gmpls-g709-
> [email-masked] <mailto:draft-ietf-ccamp-gmpls-g709-
> It is not clear why are you requiring the constraint for a connection to
> take a specific level in the hierarchy end-to-end? Is it a hardware
> specific issue you are trying to address?
>
> Snigdho
>
> > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf
> > Of Igor Bryskin
> g709-
> > [email-masked] <mailto:[email-masked]>
> g709-
> > [email-masked] <mailto:[email-masked]>
> g709-
> > > [email-masked] <mailto:[email-masked]>
> g709-
> > > [email-masked] <mailto:[email-masked]>
> g709-
> > > > [email-masked] <mailto:[email-masked]>
> g709-
> > > > [email-masked] <mailto:[email-masked]>
> > > > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] On
> > > Behalf
> > > > Of Igor Bryskin
> g709-
> > > > [email-masked] <mailto:[email-masked]>
> g709-
> > > > [email-masked] <mailto:[email-masked]>
> > > > > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] On
> > > > Behalf Of
> > > > > Igor Bryskin
> > > > > Cc: [email-masked] <mailto:[email-masked]> ; draft-ietf-ccamp-
> gmpls-g709-
> > > > [email-masked] <mailto:[email-masked]>
> > > > > Cc: [email-masked] <mailto:[email-masked]> ; draft-ietf-ccamp-
> gmpls-g709-
> > > > [email-masked] <mailto:[email-masked]>
> > > > > From: "Snigdho Bardalai" <[email-masked]
> <mailto:[email-masked]>
> > > > > <mailto:[email-masked] <mailto:[email-masked]> > >
> > > > >
> > > > > To: "Lou Berger" <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]> > >
> > > > >
> > > > > Cc: <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]> > >; <draft-ietf-ccamp-
> > > > gmpls-
> > > > > [email-masked] <mailto:g709-
> [email-masked]>  <mailto:draft-ietf-ccamp-gmpls <mailto:draft-
> ietf-ccamp-gmpls> -
> > g709-
> > > > > [email-masked] <mailto:[email-masked]> > >
> > > > >
> > > > > > Cc: [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]> > ; draft-ietf-ccamp-
> > > > gmpls-
> > > > > [email-masked] <mailto:g709-
> [email-masked]>  <mailto:draft-ietf-ccamp-gmpls <mailto:draft-
> ietf-ccamp-gmpls> -
> > g709-
> > > > > [email-masked] <mailto:[email-masked]> >
> > > > > >> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]
> <mailto:[email-masked]> >
> > > > > <https://www.ietf.org/mailman/listinfo/ccamp
> <https://www.ietf.org/mailman/listinfo/ccamp> >
> > > > > > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]
> <mailto:[email-masked]> >
> > > > > <https://www.ietf.org/mailman/listinfo/ccamp
> <https://www.ietf.org/mailman/listinfo/ccamp> >
> > > > > >
> > > >

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 9 Jul 2010 15:27:33 +0200

Hi John,

See in line

Best Regards

sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 9 luglio 2010 14.59
A: Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Sadler, Jonathan B.; Lou Berger
Cc: [email-masked]
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

[JD]

[JD]

[SB] I do not want to answer on behalf of Fatai, but I do not think Fatai is ignoring that. He simply pointed out the fact using byte per second is not the best way to advertise fixed containers like SDH or OTN. In fact,to be practical,  I would be interested to see implementation of transport equipment implementing GMPLS (and restoration) using the byte per second for BW advertisement and not e.g. number of containers (VC12, VC3, or VC4 in case of SDH). So, theoretically you're right but practically a different semantic it would be better.

[JD]

[JD]

[SB] I think we are not too far here. We can discuss about the bytes per second, but for the rest I think our attempt in the routing OTN draft is to follow your basic suggestion. Please have a look also to the OTN routing draft. It would be very beneficial to have you comment/suggestion on that.

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 9 Jul 2010 15:27:39 +0200

Hi Igor,
        A quick one.

[dc] strange sentence for a thread where lots of people are struggling to have GMPLS on OTN that is TDM :-)

BTW I can give you a lot of examples of network where GMPLS is driving SDH and I'm pretty sure the other colleagues can do the same.

BR

D

 line

DIEGO CAVIGLIA 
Strategic Product Manager 

Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
[email-masked]
www.ericsson.com 

 Ericsson

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: venerdì 9 luglio 2010 14.59
To: BELOTTI, SERGIO (SERGIO); Sadler,Jonathan B.
Cc: [email-masked]; Snigdho Bardalai; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Sergio,

You wrote:

Igor

Best Regards

sergio

Best Regards

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 2:36 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, July 08, 2010 1:31 PM
To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

typedef enum
{

/*****/

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 1:59 PM
To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> <mailto:[email-masked]> >
>

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 9 Jul 2010 15:29:53 +0200

Hello John,
in line.

[JD]

[JD]

[[PG]]  I do not want to make any polemics here, but being in the transport since a lot of years, I had the occasion to see several implementations in field using the OIF format also for the I-NNI, and they are so many that I am not really sure that IETF ISCD format is in field for something different from MPLS.
The OIF format, I would recall, counts signal types. This is useful
in order to minimize crank-backs and is also more compact with respect to current IETF ISCD, giving more information too.

[JD]

[JD]

[[PG]] The encoding drafts fulfills requirements, may be you could read it and comment. Your comments will be welcome.

I would like to remark again that the bandwidth in bytes per second is not useful in any situation, while counting signal types for sure is.  So it is in my mind too simple to
say this just because of tradition and the subject should be fronted without any bias.

Pietro

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Jul 2010 10:09:13 -0400

Jonathan and all,

Let's consider OTN connections recovery. Let me know if the following makes sense to you.

1. Suppose an ODU0 connection is carried by ODU1 containers. IF you are sure that each of the ODU1 connections serving the containers is protected, you don't really need end-to-end protection for your ODU0 connection. (Note that this would be the case if a LO topology served by protected ODU1 connections is planned and provisioned, and our ODU0 connection is constrained to this topology.) Otherwise, you will have to provision some sort of end-to-end recovery for the ODU0 connection and correlate it with the recovery of the ODU1 connections should one or some of them happen to be protected as well. Generally speaking, end-to-end recovery of an OTN connection must be correlated with the recovery of all its containers, which in turn, should be correlated with the recovery of their containers, etc. How this correlation could be achieved when the connection can move at every hop freely and in an uncontrollable way within 5-level hierarchy is not immediately obvious for me. I am sure ITU folks have an answer, but in any case the configuration of such recovery correlation could be very confusing for the user. The things could be significantly simplified if:
a) HO topology is carefully planned and pre-provisioned;
b) HO connections are constrained to the HO topology;
c) LO topology is made of the HO connections;
d) LO connections are constrained to the LO topology;
etc.

2. Suppose, an ODU0 connection path can take either:
a) an OTU2;
b) an ODU1 mapped on to the same OTU2.

Path computer will see the two as separate TE links and may select one for the working path and another for the backup path, which, of course, would be wrong: as soon as the OTU2 goes down, so will both working and protection connections. Generally speaking, it would be quite a formidable task to select links for the working and backup paths sufficiently disjoint from each other under circumstances when each of the paths could be at any hop anywhere in the hierarchy. One way to solve this problem:
a) Prepare LO topology of HO mutually independent connections;
b) Constrain computation of the working and backup paths for a LO topology to the prepared topology.

Cheers,
Igor

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 5:14 PM
To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

Jonathan Sadler

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 3:30 PM
To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Jonathan,

Ypu wrote:

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 4:07 PM
To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Jul 2010 06:47:17 -0700

snipped
> No one is advocating using the existing ISC, rather whatever is designed
> should be consistent with the rest of GMPLS.
> 
> In particular we should have bandwidth advertised in bytes per second,
> eight priority levels each with total unreserved bandwidth, a simple
> indication (such as a bit vector) of what switching granularities are
> currently supported, and ODU flex bandwidth by priority level.
> 
> [SB] I think we are not too far here. We can discuss about the bytes per
> second, but for the rest I think our attempt in the routing OTN draft is
> to follow your basic suggestion. Please have a look also to the OTN
> routing draft. It would be very beneficial to have you comment/suggestion
> on that.
[JD] 

I will take a look at it.  My comments, above, are based on the version a month or so ago, and I gave Diego and Daniele comments on it.

---

From: <[email-masked]>
Date: Fri, 9 Jul 2010 15:27:06 +0100

Some observations in-line: 

Igor Bryskin wrote 09 July 2010 13:59
> 
> Sergio,
> 
> You wrote:
> 
> " My understanding of Switching Cap is that different 
> Switching Cap would be linked to different technologies imply 
> different switching capabilities
> 
> IB>> We do have PSC1-PSC4 for packet switching ( note, one 
> per MPLS DP hierarchy level,

NH=> Do you really mean client/server here (as this is the only proper
hierarchy case)?  I query you on this because right now there is a  DP
problem in MPLS-TP that is being consciously ignored wrt the
implications of the unnecessary carry-over of PWs and sublayering into
MPL-TP.  And one of the problems (its not the only one) is the potential
for misconnectivity between MPLS layers, MPLS sublayers and PW layers
when the LSP for each of these looks the same in the DP.  Not only must
we have a common method of (OAM) detection but this must contain a
proper SA of the layer network (or sublayers) in order for quick/correct
diagnosis of offending source.  

> I suggest the same for OTN). 

NH=> It's not a great idea to always blindly replicate the artificial
hierarchies that past co-cs mode technologies (like PDH and SDH) created
in the future.  The PDH hierarchy simply reflected the maturity of
silicon technology at the time.  SDH replicated this with an increased
step size and removed the async 'mux mountain' problem.  However, the
simple commercial reason for not replicating this fixed hierarchy
structure is that each layer network represents a set of DP/CP/MP
functions and stuff to configure/operate/etc...these are all costs and
things that can fail, ie more layers = less reliable.  What we really
need here is to minimise the number of layer networks between the
(external application interfacing) TOS layer network and the (EM wave
modulating) BOS layer network.  In other words, the future transport
network should be migrating to a digital wrapper approach with no fixed
hierarchy IMO.  

> We 
> have also agreed that a single L2SC is not enough for 
> Ethernet technology, in fact, we need separate swicthcaps for 
> STAG switching, EPL, EVPL, etc. 
> 

NH=> I don't agree with this.  Though I would separate signalling from
routing functions here....and wrt to latter distributed vs centralised
cases.  Real BOS transport networks must currently have very long
information transfer phases (set-up and tear-down phases are very much
smaller).  So the CP components are nowhere near as important as the MP
components...esp as the MP components have to be there anyway.  So this
is why IMO GMPLS has probably not been as successful as some hoped it
would be.

BTW - If one looks at the business case for trying to more rapidly
set-up/tear-down BOS layer network connections you quickly find that the
commercials do not figure for a useful GOS.....at least in today's
environment.  I got the traffic/maths group at BT labs to look at
analysing this topic many years ago in a very general sense (ie very
general calling/holding statistics).  Though I must add here that today
we do not have the truly massive external end-system application numbers
we would need nor do we have the short-enough holding times to warrant a
switched services case, eg like the PSTN say.  If we had this however
then would drive the GMPLS CP case. 

regards, Neil 

<snipped to end>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 13 Jul 2010 10:59:17 -0400

Hi Neil,

You response confuses me a bit. Would you agree that there are only two possible ways to model OTN hierarchies:
a) a multi-layer construct with a distinct layer per hierarchy level (this is my suggestion);
b) a single layer with several sub-layers (this is how I understand the ITU model).

You seem to disagree with me, which means that you agree with the latter. But this position contradicts IMO with a lot of things you have said in the context of MPLS-TP. On many occasions, for example, you have explained in great details how you hate the multi-sub-layering in MPLS, that there should be exactly one sub-layer per MPLS-TP layer, if one is stacking MPLS-TP links, one is stacking MPLS-TP layers (rather than sub-layers), that we shouldn't even need S-bit, etc.... Did I get this right? If so, how come that the same logic does not apply to OTN layering vs. OTN sub-layering? If anything, the logic should make a better sense for OTN due to its cs-co nature.

Further more, my suggestion to introduce several OTN related switching capabilities (specifically, 5: one per hierarchy level) has to do with how CP views an OTN hierarchy, regardless whether its each level is a true layer, sub-layer or something else. You can think of this as a suggestion for CP to control various OTN virtual topologies. This would give an operator an easy way to constrain a given connection, say, to use only OTUs and avoid using any ODU containers, or, on the contrary, to avoid using OTUs and use ODU containers, preferably smaller before larger ones. You can argue with the usefulness of such feature, but you can hardly argue with the fact that it takes nothing away from the current framework: the user can always constrain the connection path to *any* of the hierarchy levels, and in this case all OTN links will be considered as equal candidates in the path selection process.

What do you think? I am also interested to hear from the authors of "multi stage multiplexing configuration in G.709 network" documents.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 09, 2010 10:27 AM
To: Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

regards, Neil 

<snipped to end>

---

From: <[email-masked]>
Date: Tue, 13 Jul 2010 16:20:28 +0100

Hi Igor...... 
who wrote 13 July 2010 15:59
>
> Hi Neil,
> 
> You response confuses me a bit. Would you agree that there 
> are only two possible ways to model OTN hierarchies:

NH=> Yes, this is clean BUT I do have a problem with always blindly
following the PDH and SDH models.....as each layer = cost and less
reliability....the key obsrevation being to always strive to minimise
the number of layers networks TOS to BOS.  Ergo my remarks in my
original response below on the need to start thinking about a digital
wrapper approach at BOS....and I do know of one vendor who has started
to think about this point.

> understand the ITU model).

NH=> Not a great idea IMO.
> 
> You seem to disagree with me, which means that you agree with 
> the latter. 

NH=> Now I am confused!  The bit I was disagreeing with you on was the
reasons you suggested why a GMPLS CP for co-cs mode layer networks had
not really taken off.  IMO this has nothing to do with technical issues
(at least per se) but rather the real cost of providing 'BW on demand'
to client X from server Y to meet a given GOS for a given set of calling
rate demands and holding times.  I asked for this to be modelled a long
time ago at our labs (~10 years ago in fact) and the results stated what
you have confirmed, ie there is no commercial driver given the
population size of current applications that would demand this for a
viable (acceptable) GOS....indeed, they are few/no external (to any
network) applications today but simply client topology build cases, and
here there is no case at all IMO.  

> But this position contradicts IMO with a lot of 
> things you have said in the context of MPLS-TP. On many 
> occasions, for example, you have explained in great details 
> how you hate the multi-sub-layering in MPLS, that there 
> should be exactly one sub-layer per MPLS-TP layer, if one is 
> stacking MPLS-TP links, one is stacking MPLS-TP layers 
> (rather than sub-layers), that we shouldn't even need S-bit, 
> etc.... Did I get this right? If so, how come that the same 
> logic does not apply to OTN layering vs. OTN sub-layering? If 
> anything, the logic should make a better sense for OTN due to 
> its cs-co nature.

NH=> All I have said with sublayering in MPLS-TP, no need for PWs,  etc
still stands....they are just plainly obvious facts that anyone can
figure out.  I think you have simply misunderstood what I wrote as I
have noted above.
> 
> Further more, my suggestion to introduce several OTN related 
> switching capabilities (specifically, 5: one per hierarchy 
> level) has to do with how CP views an OTN hierarchy, 
> regardless whether its each level is a true layer, sub-layer 
> or something else. You can think of this as a suggestion for 
> CP to control various OTN virtual topologies. This would give 
> an operator an easy way to constrain a given connection, say, 
> to use only OTUs and avoid using any ODU containers, or, on 
> the contrary, to avoid using OTUs and use ODU containers, 
> preferably smaller before larger ones. You can argue with the 
> usefulness of such feature, but you can hardly argue with the 
> fact that it takes nothing away from the current framework: 
> the user can always constrain the connection path to *any* of 
> the hierarchy levels, and in this case all OTN links will be 
> considered as equal candidates in the path selection process.
> 
> What do you think?

NH=> I think the replication of the PDH/SDH hierarchy in OTN was a
mistake...for the reasons I gave above.

regards, Neil

 I am also interested to hear from the 
> authors of "multi stage multiplexing configuration in G.709 
> network" documents.
> 
> Cheers,
> Igor
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [CCAMP] Comment on 
> draft-ietf-ccamp-gmpls-g709-framework-01.txt
> 
> > " My understanding of Switching Cap is that different Switching Cap 
> > would be linked to different technologies imply different switching 
> > capabilities
> >

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 13 Jul 2010 11:34:09 -0400

Neil, 

> understand the ITU model).

You are saying that a) is clean but wasteful and b) is not a good idea,
So what is in your opinion a good model? Is it:

c) a single layer and no sub-layers?
But how OTN hierarchy fits in?

Thanks,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 11:20 AM
To: Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor...... 

regards, Neil

---

From: <[email-masked]>
Date: Tue, 13 Jul 2010 17:00:48 +0100

Hi Igor.. 
13 July 2010 16:34
 
> Neil, 
> 
> > a) a multi-layer construct with a distinct layer per 
> hierarchy level 
> > (this is my suggestion);
> You are saying that a) is clean but wasteful and b) is not a 
> good idea, So what is in your opinion a good model? Is it:
> 

NH=> I'm not sure you have followed what I said...so let me very briefly
recap one last time:

-	I very much believe each layer network should be a self
contained instance in the general case....this includes a routing
component for that (and only that) layer network

-	I believe sublayering is not required in a transport network
(and I'd also add to the 'not required' the somewhat even more
artificial case of TCM OAM here - noting carefully that there is no
technical necessity for E-NNIs in non-TOS layer networks, so this is no
justification for TCM at all)

-	the old PDH hierarchy came from silicon technology
break-points.....SDH replicated this basic idea.  

-	we always must have TOS and BOS layer networks present in all
networks cases, and to minimise cost and maximise reliability we should
reduce to the minimum any additional layers networks between the TOS and
BOS extremes.  So just blindly carrying on replicating what happened in
PDH/SDH is not a great idea....need to think out of the box a
bit....ergo the digital wrapper approach is good idea.  BTW Note
carefully that one guy's transport network (layer N say) is another
guy's service....and what this means is that we have to create layer
network N+1 (ie downwards) to carry the whole bit rate of the layer N
network in the payload of the layer N+1 traffic unit....and so we end-up
generating more and more layer networks towards the duct.  This approach
is not a sustainable.

-	Too late for OTN....it did a me-too on the SDH/PDH way of doing
things.

Is that clear now?  Hope so.

regards, Neil 
> > You response confuses me a bit. Would you agree that there are only 
> > two possible ways to model OTN hierarchies:
> > a) a multi-layer construct with a distinct layer per 
> hierarchy level 
> > (this is my suggestion);
> 
> NH=> Yes, this is clean BUT I do have a problem with always 
> blindly following the PDH and SDH models.....as each layer = 
> cost and less reliability....the key obsrevation being to 
> always strive to minimise the number of layers networks TOS 
> to BOS.  Ergo my remarks in my original response below on the 
> need to start thinking about a digital wrapper approach at 
> BOS....and I do know of one vendor who has started to think 
> about this point.
> 
>  
> > You seem to disagree with me, which means that you agree with the 
> > latter.
> 
> NH=> Now I am confused!  The bit I was disagreeing with you 
> on was the reasons you suggested why a GMPLS CP for co-cs 
> mode layer networks had not really taken off.  IMO this has 
> nothing to do with technical issues (at least per se) but 
> rather the real cost of providing 'BW on demand'
> to client X from server Y to meet a given GOS for a given set 
> of calling rate demands and holding times.  I asked for this 
> to be modelled a long time ago at our labs (~10 years ago in 
> fact) and the results stated what you have confirmed, ie 
> there is no commercial driver given the population size of 
> current applications that would demand this for a viable 
> (acceptable) GOS....indeed, they are few/no external (to any
> network) applications today but simply client topology build 
> cases, and here there is no case at all IMO.  
> 
> > But this position contradicts IMO with a lot of things you 
> have said 
> > in the context of MPLS-TP. On many occasions, for example, you have 
> > explained in great details how you hate the multi-sub-layering in 
> > MPLS, that there should be exactly one sub-layer per 
> MPLS-TP layer, if 
> > one is stacking MPLS-TP links, one is stacking MPLS-TP 
> layers (rather 
> > than sub-layers), that we shouldn't even need S-bit, 
> etc.... Did I get 
> > this right? If so, how come that the same logic does not 
> apply to OTN 
> > layering vs. OTN sub-layering? If anything, the logic should make a 
> > better sense for OTN due to its cs-co nature.
> 
> NH=> All I have said with sublayering in MPLS-TP, no need for 
> PWs,  etc still stands....they are just plainly obvious facts 
> that anyone can figure out.  I think you have simply 
> misunderstood what I wrote as I have noted above.
> > 
> > Further more, my suggestion to introduce several OTN 
> related switching 
> > capabilities (specifically, 5: one per hierarchy
> > level) has to do with how CP views an OTN hierarchy, regardless 
> > whether its each level is a true layer, sub-layer or 
> something else. 
> > You can think of this as a suggestion for CP to control various OTN 
> > virtual topologies. This would give an operator an easy way to 
> > constrain a given connection, say, to use only OTUs and avoid using 
> > any ODU containers, or, on the contrary, to avoid using 
> OTUs and use 
> > ODU containers, preferably smaller before larger ones. You 
> can argue 
> > with the usefulness of such feature, but you can hardly 
> argue with the 
> > the user can always constrain the connection path to *any* of the 
> > hierarchy levels, and in this case all OTN links will be 
> considered as 
> > equal candidates in the path selection process.
> > 
> > What do you think?
> 
> NH=> I think the replication of the PDH/SDH hierarchy in OTN 
> was a mistake...for the reasons I gave above.
> 
> regards, Neil
> 
> 
> network" 
> > documents.
> Switching Cap 
> > MPL-TP.  And one of the problems (its not the only one) is the 
> > potential for misconnectivity between MPLS layers, MPLS 
> sublayers and 
> > PW layers when the LSP for each of these looks the same in the DP.  
> > Not only must we have a common method of (OAM) detection 
> but this must 
> > contain a proper SA of the layer network (or sublayers) in 
> order for 
> > quick/correct diagnosis of offending source.
> > 
> > 
> > network should be migrating to a digital wrapper approach with no 
> > fixed hierarchy IMO.
> > 
> > 
> > > We
> > > have also agreed that a single L2SC is not enough for Ethernet 
> > > technology, in fact, we need separate swicthcaps for STAG 
> switching, 
> > > EPL, EVPL, etc.
> > > 
> > smaller).  So the CP components are nowhere near as 
> important as the 
> > MP components...esp as the MP components have to be there 
> anyway.  So 
> > this is why IMO GMPLS has probably not been as successful as some 
> > hoped it would be.
> > 
> > set-up/tear-down BOS layer network connections you quickly 
> find that 
> > the commercials do not figure for a useful GOS.....at least 
> in today's 
> > general calling/holding statistics).  Though I must add here that 
> > today we do not have the truly massive external end-system 
> application 
> > numbers we would need nor do we have the short-enough 
> holding times to 
> > warrant a switched services case, eg like the PSTN say.  If we had 
> > this however then would drive the GMPLS CP case.
> > 
> > regards, Neil
> > 
> > <snipped to end>
> > 
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 13 Jul 2010 12:28:05 -0400

No Neil, it is not clear, because you didn't answer my question which is:

If you and Y.800 folks model OTN today what in your opinion would be a correct model:
1) multi-layer with no sub-layering;
2) single layer with sub-layers;
3) single layer with no sub-layers;
4) something else, e.g. you mentioned digital wrapper approach

Can you give me a short answer: 1, 2, 3 or 4?

If 4, can you elaborate how this will work for OTN.

Thanks,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:01 PM
To: Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor.. 
13 July 2010 16:34

regards, Neil

---

From: <[email-masked]>
Date: Tue, 13 Jul 2010 17:33:37 +0100

Given OTN as-is, my view is 1.

BTW 4 will not work for OTN as-is...we would need a new approach.

regards, Neil 

> Sent: 13 July 2010 17:28
> To: Harrison,N,Neil,DKQ7 R; 
> [email-masked]; [email-masked]
> > > b) a single layer with several sub-layers (this is how I 
> understand 
> > > the ITU model).
> > 
> > You are saying that a) is clean but wasteful and b) is not a good 
> > idea, So what is in your opinion a good model? Is it:
> > 
> NH=> I'm not sure you have followed what I said...so let me 
> very briefly recap one last time:
> 
> contained instance in the general case....this includes a 
> routing component for that (and only that) layer network
> 
> (and I'd also add to the 'not required' the somewhat even 
> more artificial case of TCM OAM here - noting carefully that 
> there is no technical necessity for E-NNIs in non-TOS layer 
> networks, so this is no justification for TCM at all)
> 
> networks cases, and to minimise cost and maximise reliability 
> we should reduce to the minimum any additional layers 
> networks between the TOS and BOS extremes.  So just blindly 
> carrying on replicating what happened in PDH/SDH is not a 
> great idea....need to think out of the box a bit....ergo the 
> digital wrapper approach is good idea.  BTW Note carefully 
> that one guy's transport network (layer N say) is another 
> guy's service....and what this means is that we have to 
> create layer network N+1 (ie downwards) to carry the whole 
> bit rate of the layer N network in the payload of the layer 
> N+1 traffic unit....and so we end-up generating more and more 
> layer networks towards the duct.  This approach is not a sustainable.
> 
> > > b) a single layer with several sub-layers (this is how I 
> understand 
> > > the ITU model).
> > 
> on was the 
> > not really taken off.  IMO this has nothing to do with technical 
> > issues (at least per se) but rather the real cost of 
> providing 'BW on 
> > demand'
> > to client X from server Y to meet a given GOS for a given set of 
> > calling rate demands and holding times.  I asked for this to be 
> > modelled a long time ago at our labs (~10 years ago in
> there is no 
> > commercial driver given the population size of current applications 
> > that would demand this for a viable
> > network) applications today but simply client topology build cases, 
> > and here there is no case at all IMO.
> > 
> > NH=> All I have said with sublayering in MPLS-TP, no need for PWs,  
> > etc still stands....they are just plainly obvious facts that anyone 
> > can figure out.  I think you have simply misunderstood what 
> I wrote as 
> > I have noted above.
> > >

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 13 Jul 2010 12:45:42 -0400

Thank you. I take it that under circumstances you kind of agree with me.

I would want very much to talk to you in person. Any chance you could come to Maastricht?

Thanks for the very interesting discussion.
Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:34 PM
To: Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 13 Jul 2010 18:23:33 -0400

>    , LSPSwitchType_FSC   =200          /* FSC */

It would be better IMHO to keep the Switch Type as TDM and make the
Encoding Type OTN_LO, OTN_HO or OTN_SHO.

This would replace the 20006 OTN Encoding Type for G.709 Digital Path
layer and G.709 Optical Channel layer for 2009 OTN, which had in turn
replaced the Encoding Type of "Digital Wrapper" a long time ago.

Replacing the Encoding Type would insure that any LSR that did not
understand what the TS type meant did not try to multiplex its LO ODU
at TS granularity 2.5 onto a HO ODU that had alraedy commited to using
a 1.25 TS granularity for another LO ODU.

It could also be stated that if an LSR advertises OTN_LO, OTN_HO or
OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter
is for backward compatibility and should be ignored if OTN_LO, OTN_HO
or OTN_SHO is understood.  If the LSR commits to 1.25 TS granularity,
then the corresponding G.709 Digital Path FA can be withdrawn.

The Encoding type would be the lower encoding at each end of the LSP
regardless of what goes on in the middle since that determines what
can be wrapped inside it.

For example:

                        OTU3
              OTU2      ODUk=3 --------------
   OTU1       ODUk=2 -- ODUj=2
   ODUk=1 --- ODUj=1 --

This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even
though the ODUk=2 at the next hop could not directly contain an ODU0.
If the SHO Encoding Type is used, then it indicates that two levels of
multiplexing could be supported at that switch/LSR.

The nominal bytes/sec rates can still be provided.  RFC 4328 Switch
Types currently don't include an ODUj or ODUk distinction but if
Encoding Type indicated LO or HO, that may not be needed.  Along with
the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex,
and ODU2e, can be added.

btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear
how in an FA it can be indicated that either type is currently
available (NE capable of both and hasn't committed to either one yet).

BTW- Maybe I'm missing something but the number of messages on this
would indicate a huge controversy and I'm not getting it (other than a
strong preference to rely on bytes/sec or on enumerated type fields).

draft-bccg-ccamp-otn-g709-info-model-01 is nice work.  I'm not sure if
the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or
other intent.  Could someone (either draft) concisely summarize the
multiplexing restrictions in one place, including restrictions on
number of multiplexing layers at one LSR.  That might help.

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 14 Jul 2010 10:36:34 -0400

Curtis,

Thanks for your comment.

I agree that there should be multiple OTN specific encoding types introduced. But IMO they should indicate the link's mux capabilities rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link's role or roles IMO should be indicated with a separate switchcaps. I can give you several reasons:

1. Links with the same mux capabilities may have different roles;
2. Link may advertise several roles (e.g. HO and SHO) with different mux.capabilities per role;
3. Link's role and mux. capabilities can be advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is required);
4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?)
5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

For example:

                        OTU3

Curtis

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 15 Jul 2010 09:52:28 +0800

Hi Igor and all,

Thanks for all your comments.

I think role does not equal switching capability. The operators can define different roles depending on their policy and achieve the role through different methods. However, for OTN networks, the containers (e.g., ODUk) all have the same switching capablility (i.e., TDM switching) and I think we should reflect the natural characteristics of links in the routing. In addition, if we extend the ISC, it will make the encoding type lose its' own meaning(ie., ISC overrides encoding type).

According to the point 3, I don't know how to advertise the roles and muxing capabilities with the ISCD of RFC4202, could you clarify?

In addition, could you clarify my questions in another email (copied as follows):
====================================================================================================
For  Lo ODU, Ho ODU, SHO ODU, they are relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level?
===================================================================================================

Thanks
 
Fatai
 
----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

For example:

                        OTU3

Curtis

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 15 Jul 2010 14:18:46 +0200

Hi Curtis,

Regarding the note about draft-bccg-ccamp-otn-g709-info-model-01,thanks for your comment to consider it a nice work.
The original intent is to separate specific requirements into draft-ietf-ccamp-gmpls-g709-framework and in draft-bccg, to analyze routing impact of these requirements and how these requirements can match or not with the present tools. 

We put in both drafts placeholder for multi-stage multiplexing since the issue can have impact both at requirement level and protocol routing impact.
The discussion on this issue is still open also in ITU (SG15 Q12) and we are waiting a more defined situation to better specify requirements, possible constrains, and analyze those against actual IETF protocol tools.
This is surely our intention to update.

Best Regards 

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 15 Jul 2010 12:34:33 -0400

Fatai,
Please, see my answers in line.

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 9:52 PM
To: Igor Bryskin; [email-masked]
Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor and all,

IB>> When a GMPLS CP instance controls several layers, it views the network as a stack of topologies. Whether a given topology is real or virtual is of no importance.
The GMPLS ISCD link sub-tlv and, in particular, its switching capability field (confusing name as it is) is a good way to describe a layer in technology independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of topologies that could be easily separated in technology independent way should path computation be constrained to particular one or sub-stack of them.
I think a good way to identify an OTN (virtual) topology is via (infrastructure) ODU container role of ODUs comprising the topology. BTW IMO the role of an ODU container does not change hop-by-hop (as some people seem to believe). The role is only meaningful on the ODU terminating nodes and irrelevant on transit nodes. It is it's position in the hierarchy (but not role) that may change hop-by-hop. ODU's role is the level of topology it is provisioned for and it is the same for all ODUs that comprise the topology. For, example a user may provision a LO topology and constrain ODUs he sells to a set of clients to use the topology rather than any resources available on OTN network.
The bottom line: container's role is the same as the role of virtual topology the container is a part of and could be advertised as the corresponding link switchcap.

IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.)
     encoding type = mux. capabilities code

In addition, could you clarify my questions in another email (copied as follows):
====================================================================================================
For  Lo ODU, Ho ODU, SHO ODU, they are relative to each other.
IB>> I disagree. You define role == position in the hierarchy, which is a mistake IMO.

For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level?

IB>> As I mentioned earlier, ODU role is only important on the ODU terminating nodes (i.e. on either side of corresponding link). What happens on the ODU transit nodes and its place in the hierarchy on the transit nodes are of no importance. My LO container can be carried by somebody else's LO container and can carry my client's LO container. To some extent it is similar to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its path.

Cheers,
Igor

Thanks

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

For example:

                        OTU3

Curtis

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 19 Jul 2010 10:48:45 +0800

Hi Igor,

Thanks.
I understand what you said. Therefore, we have added some text to address the requirment in FWK document. However, we still don't think that we need to extend ISC to meet the requirment. The role of the ODU can be get from the routing information implicitly. In the [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of  "Full Lambda" is introduced.

A quick question on your statement: "the role of an ODU container does not change hop-by-hop (as some people seem to believe). The role is only meaningful on the ODU terminating nodes and irrelevant on transit nodes. It is it's position in the hierarchy (but not role) that may change hop-by-hop. "

For example, A(AI1)----(BI1)B(BI2)----(CI1)C,  Interfaces AI1 and CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role of Ho ODU level is requested,  according to your statement, this conneciton will be allowed to be created. However, it should not be allowed because the ISC is not consistent along the LSP. 

Please see the text from RFC3473:   "Nodes MUST verify that the type indicated in the Switching Type  parameter is supported on the corresponding incoming interface.  If  the type cannot be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication."

Best Regards
 
Fatai
 
----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, July 16, 2010 12:34 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 9:52 PM
To: Igor Bryskin; [email-masked]
Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor and all,

Cheers,
Igor

Thanks

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

For example:

                        OTU3

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 19 Jul 2010 09:39:34 -0400

Fatai,

Please, see my responses on-line.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Sunday, July 18, 2010 10:49 PM
To: Igor Bryskin; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

Thanks.

IB>> This is possible, however:
a) this requires OTN specific advertising and processing rules;
b) disallows topology separation in technology independent way

IB>> No, your understanding is not correct. A11 and C11 TE link ends will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path computation is constrained to the OTN_HO_SC topology, B11 and B12 TE links will be disallowed, and the resulting path (if any) will not go through B11 and B12. If one circumvents the path computation by providing the fully explicit path, the signaling should fail on node B for the same reason: inconsistency of required (signaled) and supported (by local interfaces) switchcap.

IB>> Indeed

Best Regards

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, July 16, 2010 12:34 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 9:52 PM
To: Igor Bryskin; [email-masked]
Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor and all,

Cheers,
Igor

Thanks

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

For example:

                        OTU3

Curtis

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Mon, 19 Jul 2010 16:31:27 +0200

Hi Igor,

I didn't understand if you're proposing to (a) send an ISCD per role (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type.

In case (a) you're still missing a lot of information. For each role you would advertise just the unreserved bandwidth but you wouldn't know if such bandwidth is available for a certain type of ODUj LSP (e.g. 15 Gbps available on 3 component links: you advertise 45 Gbps available but no ODU3 can be set up on such TE link).

In case (b) the number of ISCDs would cause serious scalability issues and the requirement of being able to bundle component links together wouldn't be satisfied.

Cheers,
Daniele 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: lunedì 19 luglio 2010 15.40
To: Fatai Zhang; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Sunday, July 18, 2010 10:49 PM
To: Igor Bryskin; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

Thanks.

Best Regards

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, July 16, 2010 12:34 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 9:52 PM
To: Igor Bryskin; [email-masked]
Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor and all,

Cheers,
Igor

Thanks

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

1. Links with the same mux capabilities may have different roles; 2. Link may advertise several roles (e.g. HO and SHO) with different mux.capabilities per role; 3. Link's role and mux. capabilities can be advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is required); 4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?) 5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

>    , LSPSwitchType_FSC   =200          /* FSC */

It would be better IMHO to keep the Switch Type as TDM and make the Encoding Type OTN_LO, OTN_HO or OTN_SHO.

This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced the Encoding Type of "Digital Wrapper" a long time ago.

Replacing the Encoding Type would insure that any LSR that did not understand what the TS type meant did not try to multiplex its LO ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granularity for another LO ODU.

It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter is for backward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is understood.  If the LSR commits to 1.25 TS granularity, then the corresponding G.709 Digital Path FA can be withdrawn.

The Encoding type would be the lower encoding at each end of the LSP regardless of what goes on in the middle since that determines what can be wrapped inside it.

For example:

                        OTU3

This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even though the ODUk=2 at the next hop could not directly contain an ODU0.
If the SHO Encoding Type is used, then it indicates that two levels of multiplexing could be supported at that switch/LSR.

The nominal bytes/sec rates can still be provided.  RFC 4328 Switch Types currently don't include an ODUj or ODUk distinction but if Encoding Type indicated LO or HO, that may not be needed.  Along with the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added.

btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how in an FA it can be indicated that either type is currently available (NE capable of both and hasn't committed to either one yet).

BTW- Maybe I'm missing something but the number of messages on this would indicate a huge controversy and I'm not getting it (other than a strong preference to rely on bytes/sec or on enumerated type fields).

draft-bccg-ccamp-otn-g709-info-model-01 is nice work.  I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent.  Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR.  That might help.

Curtis

> Cc: [email-masked]; 
> > Behalf Of Igor Bryskin
> > Cc: [email-masked]; 
> > Subject: Re: [CCAMP] Comment on 
> > Ø  I think we need to sort out the issues with the framework 
> > document before we can embark on any proposals to the problem. I am 
> > still not clear why do we have to deviate from the general approach 
> > that has been established in RFC 4202.
> >
> >
> >
> > IB>> plane, and
> > it is highly desirable to adhere to the layer independent paradigm 
> > of advertising of TE links, and there is no reason to invent an OTN 
> > specific ISCD. The combination of Switching Capability and Encoding 
> > type of RFC4202 ISCD allows for specifying both multiplexing 
> > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if 
> > this not sufficient, you have another reserved 16 bits.
> >
> >
> >
> > IB>> Here I disagree. In order to give a user possibility to create 
> > IB>> OTN
> > hierarchies and constrain LO connections to HO containers, one needs 
> > to advertise OTN links with different switchcaps.
> >
> >
> >
> > Cheers,
> >
> > Igor
> >
> >
> >
> > Regards
> >
> > Snigdho
> >
> >
> >
> > Cc: [email-masked]; 
> > Subject: Re: [CCAMP] Comment on 
> > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more 
> > feasible for OTN networks.
> >
> >
> >
> > The framework draft just tells you what information needed for 
> > control plane, no matter how you encode the routing information. For 
> > TDM networks, you know the resource is allocated based on TS, so the 
> > available TS should be get or induced before creating cross-connect.
> >
> >
> >
> > If you are trying to find how to encode the routing information, I 
> > think you need go to the routing drafts (info model and encoding).
> >
> >
> >
> > will find that one of your suggestions is adopted (i.e., simply 
> > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances).
> >
> >
> >
> > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for 
> > ODU1, you have to advertise a new TE link or put this FA as a 
> > component link of an existing TE link (like RFC4206bis).
> >
> >
> >
> >
> >
> >
> > Best Regards
> >
> > Fatai
> >
> >
> > Cc: <[email-masked] <mailto:[email-masked]> >; 
> > <draft-ietf-ccamp-gmpls- [email-masked] 
> > <mailto:draft-ietf-ccamp-gmpls-g709-
> > Subject: Re: [CCAMP] Comment on 
> > > Subject: Re: [CCAMP] Comment on 
> > > one of the main objectives of *C*CAMP.  I look forward to hearing 
> > > from the draft and discussion contributors on there progress on this point.
> > >
> > > Lou
> > >
> > >> describes the link-parameters that are required for OTN service 
> > >> routing purposes.
> > >>
> > >> the OTU3 link has 12 time-slots available for ODU2 services and 
> > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are 
> > >> contained over the ODU2). So it is obvious from this example that 
> > >> the number of time-slots available is different based on the signal-type (i.e. ODU1 and ODU2).
> > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the 
> > >> equivalent bandwidth in bytes/sec within a link? This approach 
> > >> seems to be more in-line with the general approach outlined in 
> > >> RFC-4202. Refer to
> > section
> > >> advertised per VC rate for an SDH link. The additional benefit is 
> > >> that the advertisement is TS size independent and hence will 
> > >> simplify the implementation.
> > >>
> > >> Regards
> > >>
> > >> Snigdho
> > >>
> > >>
> > >>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 19 Jul 2010 10:42:58 -0400

Daniele,

Please, see in line.

Cheers,
Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, July 19, 2010 10:31 AM
To: Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

IB>> in ISCD:
switchCap = role;
encodeType = muxCap & signal type;
We also have 16 reserved bits which can use for OTN specific info in case we need it.

IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will provide a lot of flexibility: you can specify different things (e.g. available bandwidth) for the same link in different roles.

Cheers,
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: lunedì 19 luglio 2010 15.40
To: Fatai Zhang; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Sunday, July 18, 2010 10:49 PM
To: Igor Bryskin; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

Thanks.

Best Regards

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, July 16, 2010 12:34 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Fatai,

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 9:52 PM
To: Igor Bryskin; [email-masked]
Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor and all,

Cheers,
Igor

Thanks

Fatai

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou Berger" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 2010 10:36 PM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis,

Thanks for your comment.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 6:24 PM
To: Igor Bryskin
Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

For example:

                        OTU3

Curtis

---

From: Snigdho Bardalai <[email-masked]>
Date: Mon, 19 Jul 2010 08:30:44 -0700

Igor

Please see inline.

Regards
Snigdho

> Sent: Monday, July 19, 2010 7:43 AM
> To: Daniele Ceccarelli; Fatai Zhang; [email-masked]
> I didn't understand if you're proposing to (a) send an ISCD per role
> (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type.
>
> IB>> in ISCD:
> switchCap = role;
[SCB] I am yet to clearly understand what the role of "role" is, but agree with your observation on the encode-type and the 16 reserved-bits to further classify the switching information.
>
> In case (a) you're still missing a lot of information. For each role
> you would advertise just the unreserved bandwidth but you wouldn't know
> if such bandwidth is available for a certain type of ODUj LSP (e.g. 15
> Gbps available on 3 component links: you advertise 45 Gbps available
> but no ODU3 can be set up on such TE link).
>
> In case (b) the number of ISCDs would cause serious scalability issues
> and the requirement of being able to bundle component links together
> wouldn't be satisfied.
>
> IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will
> provide a lot of flexibility: you can specify different things (e.g.
> available bandwidth) for the same link in different roles.
[SCB] Are you saying the ISCD as defined today with minor extensions (i.e. to further classify the information) will be sufficient?
> I understand what you said. Therefore, we have added some text to
> address the requirment in FWK document. However, we still don't think
> that we need to extend ISC to meet the requirment. The role of the ODU
> can be get from the routing information implicitly. In the [draft-
> ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of  "Full Lambda" is
> introduced.
>
> A quick question on your statement: "the role of an ODU container does
> not change hop-by-hop (as some people seem to believe). The role is
> only meaningful on the ODU terminating nodes and irrelevant on transit
> nodes. It is it's position in the hierarchy (but not role) that may
> change hop-by-hop. "
>
> For example, A(AI1)----(BI1)B(BI2)----(CI1)C,  Interfaces AI1 and CI1
> can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support
> Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role
> of Ho ODU level is requested,  according to your statement, this
> conneciton will be allowed to be created. However, it should not be
> allowed because the ISC is not consistent along the LSP.
>
> IB>> No, your understanding is not correct. A11 and C11 TE link ends
> will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11
> and B12 - only with a single ISCD: OTN_LO_SC. If the path computation
> is constrained to the OTN_HO_SC topology, B11 and B12 TE links will be
> disallowed, and the resulting path (if any) will not go through B11 and
> B12. If one circumvents the path computation by providing the fully
> explicit path, the signaling should fail on node B for the same reason:
> inconsistency of required (signaled) and supported (by local
> interfaces) switchcap.
>
> Please see the text from RFC3473:   "Nodes MUST verify that the type
> indicated in the Switching Type  parameter is supported on the
> corresponding incoming interface.  If  the type cannot be supported,
> the node MUST generate a PathErr message with a "Routing
> problem/Switching Type" indication."
> IB>> Indeed
>
>
>
>
> Best Regards
>
> Fatai
>
> Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai"
> <[email-masked]>; "Lou Berger" <[email-masked]>;
> <[email-masked]>; <draft-ietf-ccamp-gmpls-g709-
> Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; draft-
> [email-masked]
> I think role does not equal switching capability. The operators can
> define different roles depending on their policy and achieve the role
> through different methods. However, for OTN networks, the containers
> (e.g., ODUk) all have the same switching capablility (i.e., TDM
> switching) and I think we should reflect the natural characteristics of
> links in the routing. In addition, if we extend the ISC, it will make
> the encoding type lose its' own meaning(ie., ISC overrides encoding
> type).
>
> IB>> When a GMPLS CP instance controls several layers, it views the
> network as a stack of topologies. Whether a given topology is real or
> virtual is of no importance.
> The GMPLS ISCD link sub-tlv and, in particular, its switching
> capability field (confusing name as it is) is a good way to describe a
> layer in technology independent way, so that, say, MPLS-TP->OTN_LO-
> >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of
> topologies that could be easily separated in technology independent way
> should path computation be constrained to particular one or sub-stack
> of them.
> I think a good way to identify an OTN (virtual) topology is via
> (infrastructure) ODU container role of ODUs comprising the topology.
> BTW IMO the role of an ODU container does not change hop-by-hop (as
> some people seem to believe). The role is only meaningful on the ODU
> terminating nodes and irrelevant on transit nodes. It is it's position
> in the hierarchy (but not role) that may change hop-by-hop. ODU's role
> is the level of topology it is provisioned for and it is the same for
> all ODUs that comprise the topology. For, example a user may provision
> a LO topology and constrain ODUs he sells to a set of clients to use
> the topology rather than any resources available on OTN network.
> The bottom line: container's role is the same as the role of virtual
> topology the container is a part of and could be advertised as the
> corresponding link switchcap.
>
> According to the point 3, I don't know how to advertise the roles and
> muxing capabilities with the ISCD of RFC4202, could you clarify?
>
> For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho
> OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link
> supporting ODU2 switching, which can be used as Lo ODU2 (service over
> ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how
> to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level?
>
> IB>> As I mentioned earlier, ODU role is only important on the ODU
> terminating nodes (i.e. on either side of corresponding link). What
> happens on the ODU transit nodes and its place in the hierarchy on the
> transit nodes are of no importance. My LO container can be carried by
> somebody else's LO container and can carry my client's LO container. To
> some extent it is similar to MPLS LSP role: LSP always has a role (e.g.
> PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its
> path.
>
> Cheers,
> Igor
>
> Cc: "John E Drake" <[email-masked]>; "Snigdho Bardalai"
> <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Lou
> Berger" <[email-masked]>; <[email-masked]>; <draft-ietf-ccamp-gmpls-
> [email-masked]>
> I agree that there should be multiple OTN specific encoding types
> introduced. But IMO they should indicate the link's mux capabilities
> rather than the link's role (i.e. level in the OTN hierarchy: LO, HO,
> SHO, etc.). The link's role or roles IMO should be indicated with a
> separate switchcaps. I can give you several reasons:
>
> 1. Links with the same mux capabilities may have different roles; 2.
> Link may advertise several roles (e.g. HO and SHO) with different
> mux.capabilities per role; 3. Link's role and mux. capabilities can be
> advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is
> required); 4. The combination of swicthcaps and encoding type will look
> to CP as a separate layer, which is exactly how ITU models OTN
> hierarchies in all aspects but routing (!?) 5. If the operator would
> want to constrain the routing of OTN connections to pre-configured
> topology with a specific role (e.g. constrain all ODUs it sells to the
> clients to one or more pre-configured LO topologies), this would be
> possible to do in a technology independent way. Suppose an instance of
> GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN
> links will be no different from the separation of WDM links from OTUs.
>
> Cheers,
> Igor
>
> Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger;
> [email-masked]; [email-masked]
> regardless of what goes on in the middle since that determines what can
> be wrapped inside it.
>
> For example:
>
>                         OTU3

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 19 Jul 2010 11:45:42 -0400

[SCB] Are you saying the ISCD as defined today with minor extensions (i.e. to further classify the information) will be sufficient

That's exactly what I've been
trying to say all along.

Cheers,
Igor

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Monday, July 19, 2010 11:31 AM
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor

Please see inline.

Regards
Snigdho

---

From: Snigdho Bardalai <[email-masked]>
Date: Mon, 19 Jul 2010 08:47:30 -0700

Understood...

Regards
Snigdho

> Sent: Monday, July 19, 2010 8:46 AM
> To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; [email-masked]
> Cc: [email-masked]
> [SCB] Are you saying the ISCD as defined today with minor extensions
> (i.e. to further classify the information) will be sufficient
>
> [SCB] I am yet to clearly understand what the role of "role" is, but
> agree with your observation on the encode-type and the 16 reserved-bits
> to further classify the switching information.
> >
> [SCB] Are you saying the ISCD as defined today with minor extensions
> (i.e. to further classify the information) will be sufficient?
> >
> > Cheers,
> > Daniele
> >
> > Of Fatai Zhang
> > In addition, could you clarify my questions in another email (copied
> as
> > follows):
> >
> > IB>> I disagree. You define role == position in the hierarchy, which
> is
> > a mistake IMO.
> >
> can

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Tue, 20 Jul 2010 10:31:40 +0200

Igor, one more question.

What about the unreserved bandwidth? 
If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap & signal type) you also need to advertise the unreserved bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending the unreserved bandwidth TLV so to create a corrispondence between the couples (ISCD-unreserved bandwidth subTLV).

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]] 
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

> agree with your observation on the encode-type and the 16 
> reserved-bits to further classify the switching information.
> >
> > address the requirment in FWK document. However, we still don't 
> > think that we need to extend ISC to meet the requirment. The role of 
> > the
> ODU
> > For example, A(AI1)----(BI1)B(BI2)----(CI1)C,  Interfaces AI1 and 
> > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only
> support
> > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while 
> > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path 
> > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE 
> > links will
> be
> > define different roles depending on their policy and achieve the 
> > role through different methods. However, for OTN networks, the 
> > containers (e.g., ODUk) all have the same switching capablility 
> > (i.e., TDM
> > links in the routing. In addition, if we extend the ISC, it will 
> > make the encoding type lose its' own meaning(ie., ISC overrides 
> > encoding type).
> >
> > network as a stack of topologies. Whether a given topology is real 
> > or virtual is of no importance.
> > should path computation be constrained to particular one or 
> > sub-stack of them.
> > is the level of topology it is provisioned for and it is the same 
> > for all ODUs that comprise the topology. For, example a user may
> provision
> > According to the point 3, I don't know how to advertise the roles 
> > and muxing capabilities with the ISCD of RFC4202, could you clarify?
> >
> ======================================================================
> =
> > =============================
> > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as 
> > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3
> link
> > transit nodes are of no importance. My LO container can be carried 
> > by somebody else's LO container and can carry my client's LO container.
> To
> ======================================================================
> =
> > ============================
> >
> >
> >
> > Thanks
> >
> > Fatai
> >
> > <[email-masked]>; "Fatai Zhang" <[email-masked]>; 
> > "Lou Berger" <[email-masked]>; <[email-masked]>; 
> > <draft-ietf-ccamp-
> gmpls-
> > rather than the link's role (i.e. level in the OTN hierarchy: LO, 
> > HO, SHO, etc.). The link's role or roles IMO should be indicated 
> > with a separate switchcaps. I can give you several reasons:
> >
> > This would replace the 20006 OTN Encoding Type for G.709 Digital 
> > Path layer and G.709 Optical Channel layer for 2009 OTN, which had 
> > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago.
> >
> > understand what the TS type meant did not try to multiplex its LO 
> > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to
> using
> > is for backward compatibility and should be ignored if OTN_LO, 
> > OTN_HO or OTN_SHO is understood.  If the LSR commits to 1.25 TS 
> > granularity, then the corresponding G.709 Digital Path FA can be withdrawn.
> >
> > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex 
> > even though the ODUk=2 at the next hop could not directly contain an ODU0.
> > Encoding Type indicated LO or HO, that may not be needed.  Along 
> > with the new Encoding Type new Signal Types for ODU0, ODU4, and 
> > ODU-flex, and ODU2e, can be added.
> >
> > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, 
> > or other intent.  Could someone (either draft) concisely summarize 
> > the multiplexing restrictions in one place, including restrictions 
> > on number of multiplexing layers at one LSR.  That might help.
> >
> > Curtis
> >
> >
> > > > >Additionally, I do not see any reason to advertise a new 
> > > > >TE-link
> > to
> > > > Yes, we have lots of off-line discussions among authors and 
> > > > other interested experts, and we think the proposal described in
> "draft-
> > > > > from the draft and discussion contributors on there progress 
> > > > > on
> > this point.
> > > > >
> > > > > Lou
> > > > >
> > > > >> My comment is how are we going to advertise the low-order 
> > > > >> ODUj availability within a higher-order container. For 
> > > > >> example, consider an
> > > > >> establish an ODU2 service over the link. At this point in 
> > > > >> time the OTU3 link has 12 time-slots available for ODU2 
> > > > >> services
> and
> > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s 
> > > > >> are contained over the ODU2). So it is obvious from this 
> > > > >> example
> > that
> > > > >> equivalent bandwidth in bytes/sec within a link? This 
> > > > >> approach seems to be more in-line with the general approach 
> > > > >> outlined in RFC-4202. Refer to
> > > > section
> > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs 
> > > > >> being advertised per VC rate for an SDH link. The additional 
> > > > >> benefit
> > is

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 10:15:36 -0400

In line

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:32 AM
To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, one more question.

IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per role per (muxCap & signal type) per priority level. However, total unreserved bandwidth IMO is OK to share between roles unless you see a compelling reason to the contrary (which I don't)

Igor

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 10:52:25 -0400

> Thanks.

Sorry to jump in but I think I understand Igor's objection (and
Snigdho's objection, and the reason this thread is going on).

> can be get from the routing information implicitly. In the
> [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full
> Lambda" is introduced.
>  

I think the objection, which would be a very valid one, is that the
ingress has no way to know apriori that a path is infeasible.  Each
crankback delays convergence.  Crankback should only occur if another
ingress has reserved resources before signaling was completed, not
because inadequate routing information is provided in quiescent state.

Curtis

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Tue, 20 Jul 2010 16:57:27 +0200

Igor,

The need for unreserved resources advertised per signal type is the concurrent path computation. I'll answer quoting a section from the info-model draft, please have a look in particular to the example:

   " Unreserved resources need to be advertised per priority and per
   signal type in order to allow the correct functioning of the
   restoration process.  [RFC4203] only allows advertising unreserved
   resources per priority, this leads not to know how many LSPs of a
   specific signal type can be restored.  As example it is possible to
   consider the scenario depicted in the following figure.

                  +------+ component link 1 +------+
                  |      +------------------+      |
                  |      | component link 2 |      |
                  |  N1  +------------------+  N2  |
                  |      | component link 3 |      |
                  |      +------------------+      |
                  +------+                  +---+--+
                  
   Suppose to have a TE link comprising 3 ODU3 component links with
   32TSs available on the first one, 24TSs on the second, 24TSs on the
   third and supporting ODU2 and ODU3 signal types.  The node would
   advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX
   LSP bandwidth equal to 32 TSs.  In case of restoration the network
   could try to restore 2 ODU3 (64TSs) in such TE-link while only a
   single ODU3 can be set up and a crank-back would be originated.  In
   more complex network scenarios the number of crank-backs can be much
   higher."

In other words, advertising the number of availble resources per signal type does not avoid the possibility of cranck-back but decreases it as much as possible. For sure a good routing prevents from crank-backs caused by the restoration of LSP originating on the same Ingress. The cranck-backs due to the concurrent restoration of LSPs originating on different ingress nodes cannot be avoided.

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: martedì 20 luglio 2010 16.16
To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

In line

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:32 AM
To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, one more question.

IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per 
IB>> role per (muxCap & signal type) per priority level. However, total 
IB>> unreserved bandwidth IMO is OK to share between roles unless you 
IB>> see a compelling reason to the contrary (which I don't)

Igor

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Tue, 20 Jul 2010 17:02:36 +0200

Hi Curtis,

Thanks for jumping in :-)

You got the point.

I hope my last mail can further clarify it.

BR
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: martedì 20 luglio 2010 16.52
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> Thanks.

Sorry to jump in but I think I understand Igor's objection (and Snigdho's objection, and the reason this thread is going on).

> problem/Switching Type" indication."

I think the objection, which would be a very valid one, is that the ingress has no way to know apriori that a path is infeasible.  Each crankback delays convergence.  Crankback should only occur if another ingress has reserved resources before signaling was completed, not because inadequate routing information is provided in quiescent state.

Curtis

> <[email-masked]>; 
> <[email-masked]>
> Cc: John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]; 
> ============================== For  Lo ODU, Ho ODU, SHO ODU, they are 
> relative to each other.
> Berger" <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> required); 4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?) 5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs.
>  
> Cheers,
> Igor
>  
> In message 
> <[email-masked]
> cal.com>
> Igor Bryskin writes:
> >

---

From: Snigdho Bardalai <[email-masked]>
Date: Tue, 20 Jul 2010 08:10:04 -0700

Curtis, very well put...the issue gets amplified with the inverse-multiplexing use-cases.

Thanks,
Snigdho

> Sent: Tuesday, July 20, 2010 7:52 AM
> To: Fatai Zhang
> Cc: Igor Bryskin; [email-masked]; John E Drake; Snigdho Bardalai; Lou
> Berger; [email-masked]
> framework-01.txt
> framework-01.txt
> as follows):
> is a mistake IMO.
> framework-01.txt
> > 3. Link's role and mux. capabilities can be advertised with ISCDs as
> defined in RFC4202 (no OTN-style ISCD is required);
> > 4. The combination of swicthcaps and encoding type will look to CP as
> a separate layer, which is exactly how ITU models OTN hierarchies in
> all aspects but routing (!?)
> > 5. If the operator would want to constrain the routing of OTN
> connections to pre-configured topology with a specific role (e.g.
> constrain all ODUs it sells to the clients to one or more pre-
> configured LO topologies), this would be possible to do in a technology
> independent way. Suppose an instance of GMPLS CP manages WDM and OTN
> NEs. Then separation of LO from HO OTN links will be no different from
> the separation of WDM links from OTUs.
> >
> > Cheers,
> > Igor
> >
> framework-01.txt
> framework-01.txt
> document
> not clear
> plane, and
> paradigm of
> of RFC4202
> create OTN
> needs to
> control
> TS should
> I think
> will find
> for ODU1,
> service routing
> the OTU3
> over the
> time-slots
> > > > >> How do we address this issue based on the approach specified
> in the
> > > > draft?
> > > > >>
> number of
> be more
> is that

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 11:21:13 -0400

It is a valid point, but the suggested solution is way too expensive. All you need is a way to say how the advertised unreserved bandwidth is partitioned between ISCDs in case the TE link advertisement contains several of them. One cheap way of doing so is to allocate 3-4 bits out of the ISCD sub-TLV reserved bits to indicate the fraction of total unreserved bandwidth associated with the ISCD. Another way is to use swicthcap specific extension.
BTW: this is not an OTN specific issue, rather more general: any time when a TE link advertises more than one ISCD (which is perfectly Ok according to 4203) you'll have the same problem.

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 10:57 AM
To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 16.16
To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

In line

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:32 AM
To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, one more question.

Igor

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

> draft-
> in

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 11:27:10 -0400

Curtis,

I agree with your concerns about cranbacks. I never liked solutions that rely on crankbacks. But what I was saying is that path computation in the described example will be able to figure that the path is not feasible, hence the ingress node will know that without signaling failure.

Cheers and hope to see you in Maastricht.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 10:52 AM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]; John E Drake; Snigdho Bardalai; Lou Berger; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Curtis

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 08:54:03 -0700

Igor,

Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs is actually a non-issue.

Unreserved bandwidth by priority has always been advertised using the MPLS sub-TLV.  My point has been that we have never had a requirement (including SDH/SONET) in the past to advertise unreserved bandwidth by signal type, so what is special about OTN?

A further point would be that if we do decide that it is necessary to advertise unreserved bandwidth by signal type, it should be done in a general way and not in an OTN specific manner.  (And in fact, the arguments that unreserved bandwidth by signal type needs to be advertised, such as the latest e-mail from Curtis, are not OTN specific.)

Thanks,

John

> Sent: Tuesday, July 20, 2010 8:21 AM
> It is a valid point, but the suggested solution is way too expensive.
> All you need is a way to say how the advertised unreserved bandwidth is
> partitioned between ISCDs in case the TE link advertisement contains
> several of them. One cheap way of doing so is to allocate 3-4 bits out
> of the ISCD sub-TLV reserved bits to indicate the fraction of total
> unreserved bandwidth associated with the ISCD. Another way is to use
> swicthcap specific extension.
> BTW: this is not an OTN specific issue, rather more general: any time
> when a TE link advertises more than one ISCD (which is perfectly Ok
> according to 4203) you'll have the same problem.
>
> Igor
>
> The need for unreserved resources advertised per signal type is the
> concurrent path computation. I'll answer quoting a section from the
> info-model draft, please have a look in particular to the example:
>
>
> In other words, advertising the number of availble resources per signal
> type does not avoid the possibility of cranck-back but decreases it as
> much as possible. For sure a good routing prevents from crank-backs
> caused by the restoration of LSP originating on the same Ingress. The
> cranck-backs due to the concurrent restoration of LSPs originating on
> different ingress nodes cannot be avoided.
>
> BR
> Daniele
>
>
> If you're advertising the max lsp bandwidth by 1 ISCD per role per
> (muxCap & signal type) you also need to advertise the unreserved
> bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This
> also implies extending the unreserved bandwidth TLV so to create a
> corrispondence between the couples (ISCD-unreserved bandwidth subTLV).
>
> > > We also have 16 reserved bits which can use for OTN specific info
> in
> > > case we need it.
> > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of  "Full
> Lambda"
> > is
> > > introduced.
> > >
> > > switching) and I think we should reflect the natural
> characteristics
> > of
> > > capability field (confusing name as it is) is a good way to
> describe
> > a
> 2.
> > > would indicate a huge controversy and I'm not getting it (other
> than
> > a
> > > > > document before we can embark on any proposals to the problem.
> I
> > am
> > > > > control plane, no matter how you encode the routing
> information.
> > > For
> > > > > TDM networks, you know the resource is allocated based on TS,
> so
> > > the

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 20 Jul 2010 18:16:01 +0200

Igor,

You jump right now at the solution ! There is a problem of spatial allocation and we tried to solve it suggesting a format.
This cannot be the best one but at least before saying it is too expensive , the comparison has to be made with one can address the issue as well. This is not the case for the present RFC 4202/4203 as you admit proposing a modification. We are open to discuss the "best way" to solve different issues we depicted in the info draft.

On the other hand you pointed out correctly that this is not an OTN specific issue: in fact in SDH we have the same problem and btw a similar approach of what proposed by us is proposed also in the draft-ong-gmpls-ason-routing-exper-02.

I realized from someone in this thread (not from you) this was due just to ignorance and misunderstanding of RFC 4202/4203 bandwidth advertisement for SDH . Anyway it is a fact that the alternative format is used in many implementations "in field" for SDH control plane.

I think could be a good point try to have at the end one single format that can accomplish issues coming from different TDM technologies.

Once that we have a common understanding of requirements and issues nothing prevent to progress the format in the best way.

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: martedì 20 luglio 2010 17.21
A: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 10:57 AM
To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 16.16
To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

In line

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:32 AM
To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, one more question.

Igor

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 12:16:17 -0400

John,

I totally agree with you. It is absolutely non OTN specific. However if a TE link advertises more than one ISCD (with each ISCD containing only max lsp bandwidth per priority), it is necessary to indicate how the total link unreserved bandwidth is partitioned between several ISCDs. What I am suggesting is instead of advertising the unreserved bandwidth multiple times (one per ISCD), indicate how the bandwidth is split between the ISCDs: e.g ISCD1 75%, ISCD2 25%.

Igor.

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 11:54 AM
To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: Snigdho Bardalai <[email-masked]>
Date: Tue, 20 Jul 2010 09:21:53 -0700

Igor,

Would you not need percentage per priority per signal-type?

Regards
Snigdho

On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin <[email-masked]>wrote:

> John,
>
> I totally agree with you. It is absolutely non OTN specific. However if a
> TE link advertises more than one ISCD (with each ISCD containing only max
> lsp bandwidth per priority), it is necessary to indicate how the total link
> unreserved bandwidth is partitioned between several ISCDs. What I am
> suggesting is instead of advertising the unreserved bandwidth multiple times
> (one per ISCD), indicate how the bandwidth is split between the ISCDs: e.g
> ISCD1 75%, ISCD2 25%.
>
> Igor.
>
> Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of
> partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs is
> actually a non-issue.
>
> Unreserved bandwidth by priority has always been advertised using the MPLS
> sub-TLV.  My point has been that we have never had a requirement (including
> SDH/SONET) in the past to advertise unreserved bandwidth by signal type, so
> what is special about OTN?
>
> A further point would be that if we do decide that it is necessary to
> advertise unreserved bandwidth by signal type, it should be done in a
> general way and not in an OTN specific manner.  (And in fact, the arguments
> that unreserved bandwidth by signal type needs to be advertised, such as the
> latest e-mail from Curtis, are not OTN specific.)
>
> Thanks,
>
> John
>

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 09:56:29 -0700

Igor,

You seem to have missed the first point in my email, regarding what is actually advertised.

Wrt your proposed solution, it won't work because there is no constraint requiring different ISC TLVs to use a common bandwidth pool.  Further, if they did share a common bandwidth pool, then at any point in time the unreserved bandwidth is available to all of them.

Thanks,

John

> Sent: Tuesday, July 20, 2010 9:16 AM
> To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang;
> [email-masked]
> Cc: [email-masked]
> I totally agree with you. It is absolutely non OTN specific. However if
> a TE link advertises more than one ISCD (with each ISCD containing only
> max lsp bandwidth per priority), it is necessary to indicate how the
> total link unreserved bandwidth is partitioned between several ISCDs.
> What I am suggesting is instead of advertising the unreserved bandwidth
> multiple times (one per ISCD), indicate how the bandwidth is split
> between the ISCDs: e.g ISCD1 75%, ISCD2 25%.
>
> Igor.
>
> Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue
> of partitioning unreserved bandwidth across multiple advertised TDM ISC
> TLVs is actually a non-issue.
>
> Unreserved bandwidth by priority has always been advertised using the
> MPLS sub-TLV.  My point has been that we have never had a requirement
> (including SDH/SONET) in the past to advertise unreserved bandwidth by
> signal type, so what is special about OTN?
>
> general way and not in an OTN specific manner.  (And in fact, the
> arguments that unreserved bandwidth by signal type needs to be
> advertised, such as the latest e-mail from Curtis, are not OTN
> specific.)
>
> Thanks,
>
> John
>
> > > > you would advertise just the unreserved bandwidth but you
> wouldn't
> > > know
> > > > if such bandwidth is available for a certain type of ODUj LSP
> (e.g.
> > > 15
> [draft-
> > > > disallowed, and the resulting path (if any) will not go through
> B11
> > > and
> > > > layer in technology independent way, so that, say, MPLS-TP-
> >OTN_LO-
> > > > topologies that could be easily separated in technology
> independent
> > > way
> > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this
> case,
> > > how
> > > > happens on the ODU transit nodes and its place in the hierarchy
> on
> > > the
> > > > mux.capabilities per role; 3. Link's role and mux. capabilities
> can
> > > be
> > > > required); 4. The combination of swicthcaps and encoding type
> will
> > > look
> > > > topology with a specific role (e.g. constrain all ODUs it sells
> to
> > > the
> > > > possible to do in a technology independent way. Suppose an
> instance
> > > of
> > > > in turn replaced the Encoding Type of "Digital Wrapper" a long
> time
> > ago.
> > > >
> > > > If the SHO Encoding Type is used, then it indicates that two
> levels
> > > of
> > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work.  I'm not
> sure
> > > if
> > > > > > of advertising of TE links, and there is no reason to invent
> an
> > > OTN
> > > > > > >> the number of time-slots available is different based on
> the
> > > > signal-type (i.e. ODU1 and ODU2).
> > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances
> or
> > > the

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 10:01:15 -0700

Curtis,

Unless you are proposing to issue a new advertisement every time an LSP is activated or deactivated, which has issues of its own, you will be dealing with thresholding so what is being advertised is only an approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is between 0 ODUj and 10 ODUj), so you will never know with certainty whether a given LSP can be activated until you try to activate it.

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 10:04:00 -0700

Snipped....

> 
> I realized from someone in this thread (not from you) this was due just
> to ignorance and misunderstanding of RFC 4202/4203 bandwidth
> advertisement for SDH . Anyway it is a fact that the alternative format
> is used in many implementations "in field" for SDH control plane.
> 

JD:  As the person to whom I believe you are referring, I would suggest that you actually read RFC 4202 and 4206.

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 10:13:09 -0700

>From RFC 4202:

   For a simple (unbundled) link the Maximum LSP Bandwidth at priority p
   is defined as the maximum bandwidth an LSP at priority p could
   reserve.  Maximum LSP Bandwidth for a bundled link is defined in
   [LINK-BUNDLE].

   The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP
   could reserve.

   Typical values for the Minimum LSP Bandwidth and for the Maximum LSP
   Bandwidth are enumerated in [GMPLS-SIG].

   On an interface having Standard SDH multiplexing, an LSP at priority
   p could reserve any bandwidth allowed by the branch of the SDH
   hierarchy, with the leaf and the root of the branch being defined by
   the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority
   p.

   On an interface having Arbitrary SDH multiplexing, an LSP at priority
   p could reserve any bandwidth between the Minimum LSP Bandwidth and
   the Maximum LSP Bandwidth at priority p, provided that the bandwidth
   reserved by the LSP is a multiple of the Minimum LSP Bandwidth.

>From RFC 4201:

3.10.  Maximum LSP Bandwidth

   The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
   For an unbundled link, the Maximum Bandwidth is defined in
   [GMPLS-ROUTING].  The Maximum LSP Bandwidth of a bundled link at
   priority p is defined to be the maximum of the Maximum LSP Bandwidth
   at priority p of all of its component links.

> From: John E Drake
> Sent: Tuesday, July 20, 2010 10:04 AM
> To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin
> Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-
> framework-01.txt
> 
> Snipped....
> 
> >
> JD:  As the person to whom I believe you are referring, I would suggest
> that you actually read RFC 4202 and 4206.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 14:01:53 -0400

John,

You seem to have missed the first point in my email, regarding what is actually advertised.
IB>> I always do :=) On the other hand you seem not to get about everything that I am saying.

Wrt your proposed solution, it won't work because there is no constraint requiring different ISC TLVs to use a common bandwidth pool.

IB>> If a TE link advertising contains, say, 2 ISCDs, and a single unreserved bandwidth sub-TLV, how would you interpret this advertising other than the two sharing the common pool?

 Further, if they did share a common bandwidth pool, then at any point in time the unreserved bandwidth is available to all of them.

IB>> What if the user preference/policy is to partition the common pool in a certain way so that the bandwidth fragmentation (as Snigdho correctly pointed out) could be avoided?

Thanks,

John

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 14:16:22 -0400

Sergio,

I am not jumping at the solution because the solution exists for a long time already.

I'd like to make it abundantly clear. All I am saying, have been saying and still stand by is that for the routing in the OTN space we don't need anything outside of RFC 4203. All we have to do:
1) define a bunch of OTN switchcaps (one per role);
2) define a bunch of encoding types (on per mux. caps & signal type).

One thing worth of considering is enhancing 4203 to indicate how the advertised pool of unreserved bandwidth is split between several ISCDs, but this is not an OTN specific issue.

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 12:16 PM
To: Igor Bryskin
Cc: [email-masked]; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: martedì 20 luglio 2010 17.21
A: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 10:57 AM
To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 16.16
To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

In line

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:32 AM
To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, one more question.

Igor

Thanks
Daniele

-----Original Message-----
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: lunedì 19 luglio 2010 17.48
To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Understood...

Regards
Snigdho

---

From: Snigdho Bardalai <[email-masked]>
Date: Tue, 20 Jul 2010 08:47:42 -0700

Generally speaking - unreserved bandwidth per signal-type is desirable to address potential fragmentation of bandwidth across component links in a bundle.

Regards
Snigdho

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 14:20:42 -0400

John,

The point is that from ISCD you can not figure out how *many* LSPs matching the ISCD you can accommodate on the link. Such information is important in case of con-current routing (e.g. restoration after link failure).

Igor

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 11:26:59 -0700

> Sent: Tuesday, July 20, 2010 11:02 AM
> Wrt your proposed solution, it won't work because there is no
> constraint requiring different ISC TLVs to use a common bandwidth pool.
>
> IB>> If a TE link advertising contains, say, 2 ISCDs, and a single
> unreserved bandwidth sub-TLV, how would you interpret this advertising
> other than the two sharing the common pool?

JD:  The advertisement of the two ISCDs is independent and dynamic, and if the independent bandwidth pool for one of them became depleted, it would be withdrawn.

The advertised unreserved bandwidth is computed by a node according to some unspecified function.  This actually points out another problem with putting much credence in the advertised unreserved bandwidth; viz, there are not even guidelines, let alone rules, for what is advertised.

In your example, if the two ISCDs used independent bandwidth pools, the advertised unreserved bandwidth could equally well be the min, max, sum, or some other function of the unreserved bandwidth in the two pools.

>
>  Further, if they did share a common bandwidth pool, then at any point
> in time the unreserved bandwidth is available to all of them.
>
> IB>> What if the user preference/policy is to partition the common pool
> in a certain way so that the bandwidth fragmentation (as Snigdho
> correctly pointed out) could be avoided?

JD:  As always, you argue backwards from your proposed solution to a perceived requirement.

As I explained above, today's encodings already cover this case, unless one wants to attempt to improve the accuracy of the advertised unreserved bandwidth.  This is the point for which I have yet to be convinced, for reasons that I pointed out in my email to Curtis.

(In your example above, the common bandwidth pool is partitioned between the two ISCDs and then each is managed independently.)

In order to do this and to allow any combination of shared and independent bandwidth pools between advertised ISCDs, I think a generalization of the scheme being proposed for OTN should be used.

> > > All you need is a way to say how the advertised unreserved
> bandwidth
> > is
> > > > > think that we need to extend ISC to meet the requirment. The
> role
> > > of
> > > > > the
> > > > ODU
> > > > > A quick question on your statement: "the role of an ODU
> container
> > > > does
> > > > > not change hop-by-hop (as some people seem to believe). The
> role
> > is
> > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with
> the
> > > > role
> > > > > conneciton will be allowed to be created. However, it should
> not
> > be
> > > > > computation is constrained to the OTN_HO_SC topology, B11 and
> B12
> > > TE
> > > > > links will
> > > > be
> > > > > some people seem to believe). The role is only meaningful on
> the
> > > ODU
> > > > > in the hierarchy (but not role) that may change hop-by-hop.
> ODU's
> > > > role
> > > > > a LO topology and constrain ODUs he sells to a set of clients
> to
> > > use
> > > > > supporting ODU2 switching, which can be used as Lo ODU2
> (service
> > > > > over
> > > > > some extent it is similar to MPLS LSP role: LSP always has a
> role
> > > > (e.g.
> > > > > clients to one or more pre-configured LO topologies), this
> would
> > be
> > > > > links will be no different from the separation of WDM links
> from
> > > > OTUs.
> > > > >
> > > > > Cheers,
> > > > > Igor
> > > > >
> > > > > > I think OTN links require more than one switchcaps: as many
> as
> > > the
> > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy
> commited
> > > to
> > > > using
> > > > > It could also be stated that if an LSR advertises OTN_LO,
> OTN_HO
> > or
> > > > > granularity, then the corresponding G.709 Digital Path FA can
> be
> > > withdrawn.
> > > > >
> > > > > The Encoding type would be the lower encoding at each end of
> the
> > > LSP
> > > > > even though the ODUk=2 at the next hop could not directly
> contain
> > > an ODU0.
> > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm
> not
> > > > clear
> > > > > available (NE capable of both and hasn't committed to either
> one
> > > > yet).
> > > > >
> > > > > > > From: [email-masked] [mailto:ccamp-
> [email-masked]]
> > On
> > > > > > > Behalf Of Igor Bryskin
> > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link,
> and,
> > > if
> > > > > > > represent >the low-order ODUj bandwidth within the high-
> order
> > > > > containers.
> > > > > > > other interested experts, and we think the proposal
> described
> > > in
> > > > "draft-
> > > > > > > available TS should be get or induced before creating
> cross-
> > > > > connect.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If you look at the routing drafts (info model and
> encoding),
> > > you
> > > > > > > advertize the available number of ODU0, ODU1, ODU2, ...,
> ODU4
> > > > > container instances).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links)
> as
> > FA
> > > > for
> > > > > > > [email-masked] <mailto:draft-ietf-ccamp-
> gmpls-
> > > > g709-
> > > > > > > > I believe there has been some off-line discussion on how
> to
> > > > > better

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 11:38:06 -0700

Igor,

The unreserved bandwidth advertised in the MPLS sub-TLV is there to provide a hint, nothing more, and you seemed quite happy with this in the e-mail you sent to Sergio.  So why do you now perceive it to be an issue?

It's not clear to me that advertising unreserved bandwidth by signal type actually provides the improvement in accuracy that people claim for it, and it does come with a cost, more bandwidth and more message processing.

However, if that's what folks want, then it should be done in a general, rather than an OTN specific, manner.

Thanks,

John

> Sent: Tuesday, July 20, 2010 11:21 AM
> To: John E Drake; BELOTTI, SERGIO (SERGIO)
> The point is that from ISCD you can not figure out how *many* LSPs
> matching the ISCD you can accommodate on the link. Such information is
> important in case of con-current routing (e.g. restoration after link
> failure).
> 
> Igor
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 14:51:00 -0400

IB>> ... unless you have a policy that *administratively* partitions the pool in certain way. In such case allocation requests for one ISDC will fail even when the bandwidth is still available. For example, LO and HO ODU2s may share the same pool, but the operator may want that 75% of the pool to be available for HO and 25% for LO.

The advertised unreserved bandwidth is computed by a node according to some unspecified function.  This actually points out another problem with putting much credence in the advertised unreserved bandwidth; viz, there are not even guidelines, let alone rules, for what is advertised.
IB>> No problem here. It is a simple matter of local discovery and policy (e.g. via configuration)

In your example, if the two ISCDs used independent bandwidth pools, the advertised unreserved bandwidth could equally well be the min, max, sum, or some other function of the unreserved bandwidth in the two pools.
IB>> I never said independent. It is shared but administratively partitioned.

IB>> But why is it OTN matter? It is a generic issue of several ISCDs advertised for a single link.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 14:57:02 -0400

In message <[email-masked]>
Igor Bryskin writes:
>  
> It is a valid point, but the suggested solution is way too
> expensive. All you need is a way to say how the advertised unreserved
> bandwidth is partitioned between ISCDs in case the TE link
> advertisement contains several of them. One cheap way of doing so is
> to allocate 3-4 bits out of the ISCD sub-TLV reserved bits to indicate
> the fraction of total unreserved bandwidth associated with the
> ISCD. Another way is to use swicthcap specific extension.  BTW: this
> is not an OTN specific issue, rather more general: any time when a TE
> link advertises more than one ISCD (which is perfectly Ok according to
> 4203) you'll have the same problem.
>  
> Igor

Igor,

Perhaps at the meeting we can try to agree as to whether minimizing
unecessary crankback is a goal or not.  It has always been a goal in
the past.

Also when a link advertises more than one ISCD it means it can accept
a reservation (ie: LSP) using any of them.  That is what I get out of
the examples in RFC4202.  The examples are LSC+TDM, OXC+TDM, PWC+LSR,
TDM+LSR.  For example, in TDM+LSR, it should be possible to set up a
TDM LSP from an adjacent TDM only LSR or a PSC LSP from a PSC only
LSR, or either type from an adjacent TDM+LSR device.  Do you interpret
this differently?

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 15:02:06 -0400

John,

>The unreserved bandwidth advertised in the MPLS sub-TLV is there to provide a hint, > nothing more, and you seemed quite happy with this in the e-mail you sent to >Sergio.  So why do you now perceive it to be an issue?

IB>> Because there are cases when you need to know how many LSPs of certain type can be placed on a link. 4203 needs an enhancement to allow for this IMO.

>It's not clear to me that advertising unreserved bandwidth by signal type actually >provides the improvement in accuracy that people claim for it, and it does come with >a cost, more bandwidth and more message processing.

IB>> From my personal experience the overhead is negligible.  

>However, if that's what folks want, then it should be done in a general, rather than >an OTN specific, manner.

IB>> Exactly my point.

Thanks,

John

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 15:03:26 -0400

In message <[email-masked]>
Igor Bryskin writes:
>  
> Curtis,
>  
> I agree with your concerns about cranbacks. I never liked solutions
> that rely on crankbacks. But what I was saying is that path
> computation in the described example will be able to figure that the
> path is not feasible, hence the ingress node will know that without
> signaling failure.
>  

Igor,

I don't follow that.  Are you claiming that the PathErr is
significantly different from crankback?  Or did I miss something about
the example?

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 15:10:29 -0400

Curtis,

IB>> I don't understand why do you keep bringing up crankbacks. None of what I have said so far in this discussion will cause a crankback, quite to the contrary.

IB>> Correct. In the context of OTN if a link advertises two ISDCs: OTN_HO and OTN_LO, it means it is willing to accept the setup of ODUs for any of the two roles.

Igor

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 15:17:02 -0400

Curtis,

Igor,

IB>> Curtis, I don't follow you either. When did I mention either crankback or pathErr? I was saying that not feasible paths should be failed by path computation. The advertising based solely on 4203 has everything to achieve that.

Igor

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 15:29:11 -0400

In message <[email-masked]>
Igor Bryskin writes:
>  
> John,
>  
> I totally agree with you. It is absolutely non OTN specific. However
> if a TE link advertises more than one ISCD (with each ISCD containing
> only max lsp bandwidth per priority), it is necessary to indicate how
> the total link unreserved bandwidth is partitioned between several
> ISCDs. What I am suggesting is instead of advertising the unreserved
> bandwidth multiple times (one per ISCD), indicate how the bandwidth is
> split between the ISCDs: e.g ISCD1 75%, ISCD2 25%.
>  
> Igor.

Igor,

If there are two ISCs and nothing reserved, then there is one FA.  One
ISC is always lower in the hierarchy than the other.  Consider the
TDM+LSR example in RFC4202 and assume the exact advertisement is
TDM+PSC-4.  If a 1Gb/s PSC-3 LSP from far away is created on a STM64
and uses an STM16 worth of bandwidth, then the original FA has 75%
reservable and there is a new PSC-4 only FA with 2.5G and 1.5G
reservable.  The new PSC-4 FA can take more PSC-3 but not more TDM.
The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity.  The
far away LSR would advertise a PSC-3 FA.

The same should apply to the above example if an STM16 was added from
a far away LSR.  A new FA would be created at STM16 advertised by the
new TDM LSP ingress.  The old FA would now have 75% remaining for
either TDM or PSC-4.

Of course with 75% remaining it may not be possible to create a 5 Gb/s
PSC LSP if it is not possible to link bundle two PSC-4 each over a
STM16, but that brings us into the realm of discussing multipath (or
pointing out that maxlsp can be set to 2.5G and avoid it).

BTW- I am wondering what TDM capable LSR in the field actually do if
this is not what they do.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 15:32:34 -0400

In message <[email-masked]>
> Would you not need percentage per priority per signal-type?

You would if you wanted to be able to preempt LSPs, therefore you do.
I take it that was a rhetorical question for which you knew the answer
already but I fell for it and answered.  :-)

Curtis

> On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin <[email-masked]>wro=
> te:
>  
> > John,
> >
> > lsp bandwidth per priority), it is necessary to indicate how the total li=
> nk
> > suggesting is instead of advertising the unreserved bandwidth multiple ti=
> mes
> > (one per ISCD), indicate how the bandwidth is split between the ISCDs: e.=
> g
> > ISCD1 75%, ISCD2 25%.
> >
> > Igor.
> >
> > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue o=
> f
> > partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs=
>  is
> > actually a non-issue.
> >
> > Unreserved bandwidth by priority has always been advertised using the MPL=
> S
> > sub-TLV.  My point has been that we have never had a requirement (includi=
> ng
> > SDH/SONET) in the past to advertise unreserved bandwidth by signal type, =
> so
> > general way and not in an OTN specific manner.  (And in fact, the argumen=
> ts
> > that unreserved bandwidth by signal type needs to be advertised, such as =
> the
> > > Sent: marted=EC 20 luglio 2010 16.16
> > > Sent: luned=EC 19 luglio 2010 17.48
> > > > > switchCap =3D role;
> > > > > encodeType =3D muxCap & signal type;
> > > > > Sent: luned=EC 19 luglio 2010 15.40
> > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.)
> > > > >      encoding type =3D mux. capabilities code
> > > > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > =3D
> > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D
> > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy,
> > > which
> > > > is
> > > > > a mistake IMO.
> > > > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > =3D
> > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D
> > > > >
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Fatai
> > > > >
> > > > > >    LSPSwitchType_Unknown =3D0            /* Unknown */
> > > > > >    , LSPSwitchType_PSC_1 =3D1            /* PSC-1 */
> > > > > >    , LSPSwitchType_PSC_2 =3D2            /* PSC-2 */
> > > > > >    , LSPSwitchType_PSC_3 =3D3            /* PSC-3 */
> > > > > >    , LSPSwitchType_PSC_4 =3D4            /* PSC-4 */
> > > > > >    , LSPSwitchType_L2SC  =3D50           /* L2SC */
> > > > > >    , LSPSwitchType_TDM   =3D100          /* TDM */
> > > > > >
> > > > > > /*****/
> > > > > >    , LSPSwitchType_OTN_LO=3D124   /* OTN low order */
> > > > > >    , LSPSwitchType_OTN_HO=3D125   /* OTN high order */
> > > > > >    , LSPSwitchType_OTN_SHO=3D126  /* OTN super high order */
> > > /*****/
> > > > > >    , LSPSwitchType_LSC   =3D150          /* LSC */
> > > > > >    , LSPSwitchType_FSC   =3D200          /* FSC */
> > > > > > }e_LSPSwitchType;
> > > > >
> > > > >
> > > > >               OTU2      ODUk=3D3 --------------
> > > > >    OTU1       ODUk=3D2 -- ODUj=3D2
> > > > >    ODUk=3D1 --- ODUj=3D1 --
> > > > >
> > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df=
> lex
> > > > > even though the ODUk=3D2 at the next hop could not directly contain
> > > an ODU0.
> > > > > > > =D8  I think we need to sort out the issues with the framework

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 15:39:37 -0400

In message <[email-masked]>
John E Drake writes:
>  
> Curtis,
>  
> Unless you are proposing to issue a new advertisement every time an
> LSP is activated or deactivated, which has issues of its own, you will
> be dealing with thresholding so what is being advertised is only an
> approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is
> between 0 ODUj and 10 ODUj), so you will never know with certainty
> whether a given LSP can be activated until you try to activate it.
>  
> Thanks,
>  
> John

John,

When you create a new LSP you must deduct from the existing FA and
create an FA for the new LSP.  The endpoints of the new LSP may not be
the same as the endpoints of the old FA, more likely it is just a hop
along the way.

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 15:44:11 -0400

Curtis,

When a link advertises two ISCDs it means that it is immediately ready to accept an LSP of any type. Hence the TDM+PSC-4 advertisement (albeit allowed) does not make any practical sense to me. You need, first, create a TDM LSP, advertise it as an FA and use FA as a link (which is likely to be a different link, because, for example, it will have a different remote end) for PSC-4 LSP. However, if an OTN link advertises two IDSCc - OTN_LO and OTN_HO - it is quite a different ball game. It will mean that the link could participate in the two topologies immediately.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 3:29 PM
To: Igor Bryskin
Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Curtis

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 13:17:32 -0700

> Sent: Tuesday, July 20, 2010 12:40 PM
> To: John E Drake
> Cc: [email-masked]; Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Lou
> Berger; [email-masked]

JD:  I agree with what you wrote, above, but I am not sure what it has to do with my e-mail.

The question we have been discussing is whether an intermediate node should be advertising the total unreserved bandwidth or unreserved bandwidth by service category for each of its links.  I thought your e-mail indicated support for the latter position.

What I was trying to point out was that unless an intermediate node issues a new advertisement every it activates or deactivates an LSP across its links, the state of its links in its last advertisement may be very different from its current state, and that hence an ingress node does not have a reliable indication of that state.

The example I used was that what was advertised for a given link was 5 ODUj, even though the current unreserved bandwidth for ODUj is anywhere in the range 0 ODUj to 10 ODUj.

I.e., advertising unreserved bandwidth by service category gives a false sense of security wrt the distributed awareness of the current state of the network.

> > > > that we need to extend ISC to meet the requirment. The role of
> the
> > > ODU
> CI1
> characteristics of
> make
> describe a
> by
> "Lou
> HO,
> > > > 2. Link may advertise several roles (e.g. HO and SHO) with
> different
> > > mux.capabilities per role;
> Path
> even
> with
> > > > > > advertising of TE links, and there is no reason to invent an
> OTN
> > > specific
> > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient,
> you
> > > have
> other
> > > > > > plane, no matter how you encode the routing information. For
> TDM
> > > networks,
> > > > > > that one of your suggestions is adopted (i.e., simply
> advertize
> > > the
> ODUj
> > > > > > >> link has 12 time-slots available for ODU2 services and up
> to
> > > 12+4
> being

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 16:26:04 -0400

Curtis,
Igor,

Curtis

IB>> The question is not rhetorical. Keep in mind that this information is only needed for concurrent path computations performed on the same node. For example, a link has failed and *all* LSPs going through the link are originated on the same NE, and the NE is trying to reroute all of them concurrently. I don't think you will want to preempt other connections knowing that it may not help, because at the same time other NEs (terminating other LSPs going over the failed link) may do the same thing.
If you use preemption in this case your restoration will do more harm than good.

In all other case the info does not help much. I think it is Ok to say that ISDCs share the common pool in, say, 60% to 40% ratio and extrapolate the ratio for all priority levels. I say it is overkill to partition the unreserved bandwidth pool on per priority level. However, if you insist on such partitioning then 4203 allows you to expand the IDSC sub-TLV and you can specify the unreserved bandwidth per priority level for every ISCD.

Igor

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 13:28:04 -0700

Igor,

It is quite possible for a node to concurrently switch both PSC and TDM LSPs.  (Or TDM and Lambda LSPs.)  That is why the TLV is called ISCD and why multiple of them may be advertised for all of that node's links.

Thanks,

John

> Sent: Tuesday, July 20, 2010 12:44 PM
> To: [email-masked]
> Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang;
> [email-masked]
> When a link advertises two ISCDs it means that it is immediately ready
> to accept an LSP of any type. Hence the TDM+PSC-4 advertisement (albeit
> allowed) does not make any practical sense to me. You need, first,
> create a TDM LSP, advertise it as an FA and use FA as a link (which is
> likely to be a different link, because, for example, it will have a
> different remote end) for PSC-4 LSP. However, if an OTN link advertises
> two IDSCc - OTN_LO and OTN_HO - it is quite a different ball game. It
> will mean that the link could participate in the two topologies
> immediately.
>
> Igor
>
> > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the
> issue of partitioning unreserved bandwidth across multiple advertised
> TDM ISC TLVs is actually a non-issue.
> >
> expensive.
> bandwidth is
> role is
> not be
> would be
> OTN_HO or
> [email-masked]] On
> > > > > > > of advertising of TE links, and there is no reason to
> invent an
> > > > OTN
> as FA
> > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container
> instances or
> > > > the

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 13:35:26 -0700

Snipped...

> IDSC sub-TLV and you can specify the unreserved bandwidth per priority
> level for every ISCD.

JD:  Igor, what part of my quote from RFC 4202 did you not understand?  You do not advertise unreserved bandwidth in the ISCD TLV.  In particular, for TDM, what is advertised is the max and min bandwidth allowed for a single LSP.  It was designed to produce a compact representation by taking advantage of the SDH/SONET hierarchy.

Advertising a separate ISCD for each supported rate is allowed but wasteful.

> > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai
> Zhang;
> > > [email-masked]
> > > Cc: [email-masked]
> issue o=
> argumen=
> > > > > > I didn't understand if you're proposing to (a) send an ISCD
> per
> > > > role
> > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per
> signal
> > > > type.
> > > > > >
> > > > > > IB>> in ISCD:
> > > > > > switchCap =3D role;
> > > > > > In case (a) you're still missing a lot of information. For
> each
> > > > role
> > > > > > In case (b) the number of ISCDs would cause serious
> scalability
> > > > > issues
> > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several
> ISDCs
> > > > will
> > > > > > provide a lot of flexibility: you can specify different
> things
> > > > (e.g.
> > > > > > only meaningful on the ODU terminating nodes and irrelevant
> on
> > > > > transit
> > > > > > IB>> No, your understanding is not correct. A11 and C11 TE
> link
> > > > ends
> > > > > > disallowed, and the resulting path (if any) will not go
> through B11
> > > > > and
> > > > > > explicit path, the signaling should fail on node B for the
> same
> > > > > reason:
> > > > > > Please see the text from RFC3473:   "Nodes MUST verify that
> the
> > > > type
> > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is
> a
> > > > OTU3
> > > > > link
> > > > > > happens on the ODU transit nodes and its place in the
> hierarchy on
> > > > > the
> > > > > > mux.capabilities per role; 3. Link's role and mux.
> capabilities can
> > > > > be
> > > > > > hierarchies in all aspects but routing (!?) 5. If the
> operator
> > > > would
> > > > > > topology with a specific role (e.g. constrain all ODUs it
> sells to
> > > > > the
> > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-
> srv-
> > > > > > exgen.atl.advaoptical.com>
> > > > > > Igor Bryskin writes:
> > > > > > >
> > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a
> long time
> > > > ago.
> > > > > >
> > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then
> the
> > > > > latter
> > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work.  I'm
> not sure
> > > > > if
> > > > > > > > still not clear why do we have to deviate from the
> general
> > > > > approach
> > > > > > > > specific ISCD. The combination of Switching Capability
> and
> > > > > Encoding
> > > > > > > > > I believe there has been some off-line discussion on
> how to
> > > > > > better
> > > > > > > > > align the work with 4202.  Use of common approaches is
> of
> > > > > course
> > > > > > > > > one of the main objectives of *C*CAMP.  I look forward
> to
> > > > > hearing
> > > > > > > > >> I have a comment and a question on Section 3.1.2.1.
> This
> > > > > section
> > > > > > > > >> the number of time-slots available is different based
> on the

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 16:54:23 -0400

John,

> It is quite possible for a node to concurrently switch both PSC and TDM LSPs.  (Or > TDM and Lambda LSPs.)  That is why the TLV is called ISCD and why multiple of them > may be advertised for all of that node's links.

IB>> It is possible from the RFC4203 point of view. What I am saying is that it is not practical to advertise for the same link both TDM and PSC ISCDs. It is only possible when:
a) TDM topology and PSC topology are congruent (at least partially);
b) TDM topology and PSC topology share the same address space;
c) TDM and PSC share the same routing instance.

Igor

Thanks,

John

> [email-masked]; [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jul 2010 13:59:55 -0700

Dear John,
> What I was trying to point out was that unless an intermediate node issues a new advertisement every it activates or deactivates an LSP across its links, the state of its links in its last advertis…

I think that this is the case, certain lagging behind between
allocated BW and knowledge of it in the ingress or any other node in
the network, in general and not unique to this scenario.

Regards,
Greg

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 17:02:25 -0400

John,

Do you understand the quote from RFC4203:
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Switching Capability-specific information              |
   |                  (variable)                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You can use the last field for OTN switchcap to advertise unresolved bandwidth available for the ISCD on per priority level.

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 14:04:52 -0700

> Sent: Tuesday, July 20, 2010 1:54 PM
> To: John E Drake; [email-masked]
> > It is quite possible for a node to concurrently switch both PSC and
> TDM LSPs.  (Or > TDM and Lambda LSPs.)  That is why the TLV is called
> ISCD and why multiple of them > may be advertised for all of that
> node's links.
> 
> IB>> It is possible from the RFC4203 point of view. What I am saying is
> that it is not practical to advertise for the same link both TDM and
> PSC ISCDs. It is only possible when:

JD: Correct.

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 14:09:42 -0700

Igor,

I was describing SDH/SONET not OTN, I have no idea what you mean by "last field", and I have no idea what you mean by "unresolved bandwidth".

John

> Sent: Tuesday, July 20, 2010 2:02 PM
> To: John E Drake; [email-masked]; Snigdho Bardalai
> You can use the last field for OTN switchcap to advertise unresolved
> bandwidth available for the ISCD on per priority level.
>
> Igor
>
> JD:  Igor, what part of my quote from RFC 4202 did you not understand?
> You do not advertise unreserved bandwidth in the ISCD TLV.  In
> particular, for TDM, what is advertised is the max and min bandwidth
> allowed for a single LSP.  It was designed to produce a compact
> representation by taking advantage of the SDH/SONET hierarchy.
>
> > > > SDH/SONET) in the past to advertise unreserved bandwidth by
> signal
> > type, =
> > > so
> > > > A further point would be that if we do decide that it is
> necessary
> > to
> > > > advertise unreserved bandwidth by signal type, it should be done
> in
> > a
> > > > > unreserved bandwidth associated with the ISCD. Another way is
> to
> > use
> > > > > BTW: this is not an OTN specific issue, rather more general:
> any
> > time
> > > > > when a TE link advertises more than one ISCD (which is
> perfectly
> > Ok
> > > > >    " Unreserved resources need to be advertised per priority
> and
> > per
> > > > >    advertise a TE link unreserved bandwidth equal to 80 TSs and
> a
> > MAX
> > > > >    could try to restore 2 ODU3 (64TSs) in such TE-link while
> only
> > a
> > > > > In other words, advertising the number of availble resources
> per
> > signal
> > > > > type does not avoid the possibility of cranck-back but
> decreases
> > it as
> > > > > caused by the restoration of LSP originating on the same
> Ingress.
> > The
> > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD,
> correct?
> > This
> > > > > also implies extending the unreserved bandwidth TLV so to
> create
> > a
> > > > > IB>> Agree that max lsp bandwidth should be advertised by 1
> ISCD
> > per
> > > > > IB>> role per (muxCap & signal type) per priority level.
> However,
> > total
> > > > > IB>> unreserved bandwidth IMO is OK to share between roles
> unless
> > you
> > > > > > > We also have 16 reserved bits which can use for OTN
> specific
> > info
> > > > > in
> > > > > > > case we need it.
> > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C,  Interfaces
> AI1
> > and
> > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2
> can
> > only
> > > > > > support
> > > > > > > B12. If one circumvents the path computation by providing
> the
> > fully
> > > > > > > define different roles depending on their policy and
> achieve
> > the
> > > > > > > network as a stack of topologies. Whether a given topology
> is
> > real
> > > > > > > BTW IMO the role of an ODU container does not change hop-
> by-
> > hop (as
> > > > > > > terminating nodes and irrelevant on transit nodes. It is
> it's
> > > > > > position
> > > > > > > is the level of topology it is provisioned for and it is
> the
> > same
> > > > > > > for all ODUs that comprise the topology. For, example a
> user
> > may
> > > > > > provision
> > > > > > > The bottom line: container's role is the same as the role
> of
> > > > > virtual
> > > > > > > In addition, could you clarify my questions in another
> email
> > > > > (copied
> > > > > > as
> > > > > > > follows):
> > > > > > >
> > > > > >
> > > > >
> >
> > > > > > > by somebody else's LO container and can carry my client's
> LO
> > > > > container.
> > > > > > To
> > > > > > > rather than the link's role (i.e. level in the OTN
> hierarchy:
> > LO,
> > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO
> from
> > HO OTN
> > > > > > > OTN_HO or OTN_SHO is understood.  If the LSR commits to
> 1.25
> > TS
> > > > > > > The nominal bytes/sec rates can still be provided.  RFC
> 4328
> > Switch
> > > > > > > Types currently don't include an ODUj or ODUk distinction
> but
> > if
> > > > > > > strong preference to rely on bytes/sec or on enumerated
> type
> > > > > fields).
> > > > > > >
> > > > > > > > > This is simply >blowing up the solution to a very
> simple
> > > > > problem.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > IB>> Here I disagree. In order to give a user
> possibility
> > to
> > > > > > create
> > > > > > > > > IB>> OTN
> > > > > > > > > TDM networks, you know the resource is allocated based
> on
> > TS,
> > > > > so
> > > > > > > the
> > > > > > > > > will find that one of your suggestions is adopted
> (i.e.,
> > simply
> > > > > > > > > ODU1, you have to advertise a new TE link or put this
> FA
> > as a
> > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G
> granularity
> > and
> > > > > > > > > >> then
> > > > > > > we
> > > > > > > > > >> establish an ODU2 service over the link. At this
> point
> > in

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jul 2010 17:19:35 -0400

John,

What I meant to say is that for OTN link advertisements it is possible to use "|        Switching Capability-specific information" for advertisement of unreserved bandwidth on per priority level available for the ISCD, if we decide to make such information available (which I don't think we should).

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 5:10 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

John

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 14:28:10 -0700

Igor,

My apologies, that is certainly a true statement.  But again, if we decide to do advertise unreserved bandwidth by service category it shouldn't be just for OTN, which sort of argues for a new TLV.  I have been using the term 'service category' as a generic term.  In the OTN context it probably means bandwidth granularity, but in other contexts probably different things.

Thanks,

John

> Sent: Tuesday, July 20, 2010 2:20 PM
> What I meant to say is that for OTN link advertisements it is possible
> to use "|        Switching Capability-specific information" for
> advertisement of unreserved bandwidth on per priority level available
> for the ISCD, if we decide to make such information available (which I
> don't think we should).
>
> Igor
>
> I was describing SDH/SONET not OTN, I have no idea what you mean by
> "last field", and I have no idea what you mean by "unresolved
> bandwidth".
>
> John
>
> > > > > TE link advertises more than one ISCD (with each ISCD
> containing
> > > only max
> > > > > lsp bandwidth per priority), it is necessary to indicate how
> the
> > > total li=
> > > > nk
> > > > > unreserved bandwidth is partitioned between several ISCDs. What
> I
> > > am
> > > > > partitioning unreserved bandwidth across multiple advertised
> TDM
> > > ISC TLVs=
> > > >  is
> > > > > actually a non-issue.
> > > > >
> > > > > Unreserved bandwidth by priority has always been advertised
> using
> > > the MPL=
> > > > S
> > > > > sub-TLV.  My point has been that we have never had a
> requirement
> > > (includi=
> > > > ng
> > > > > that unreserved bandwidth by signal type needs to be
> advertised,
> > > such as =
> > > > the
> > > > > > The need for unreserved resources advertised per signal type
> is
> > > the
> > > > > > concurrent path computation. I'll answer quoting a section
> from
> > > the
> > > > > >    resources per priority, this leads not to know how many
> LSPs
> > > of a
> > > > > >    Suppose to have a TE link comprising 3 ODU3 component
> links
> > > with
> > > > > >    32TSs available on the first one, 24TSs on the second,
> 24TSs
> > > on the
> > > > > >    more complex network scenarios the number of crank-backs
> can
> > > be much
> > > > > >    higher."
> > > > > >
> > > > > > much as possible. For sure a good routing prevents from
> crank-
> > > backs
> > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per
> role
> > > per
> > > > > > > [SCB] I am yet to clearly understand what the role of
> "role"
> > > is, but
> > > > > > > > Gbps available on 3 component links: you advertise 45
> Gbps
> > > > > > available
> > > > > > > > and the requirement of being able to bundle component
> links
> > > > > > together
> > > > > > > > wouldn't be satisfied.
> > > > > > > >
> > > > > > > > b) disallows topology separation in technology
> independent
> > > way
> > > > > > > >
> > > > > > > > nodes. It is it's position in the hierarchy (but not
> role)
> > > that may
> > > > > > > > change hop-by-hop. "
> > > > > > > >
> > > > > > > > of Ho ODU level is requested,  according to your
> statement,
> > > this
> > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and
> OIN_LO_SC,
> > > while
> > > > > > > > indicated in the Switching Type  parameter is supported
> on
> > > the
> > > > > > > > role through different methods. However, for OTN
> networks,
> > > the
> > > > > > > > links in the routing. In addition, if we extend the ISC,
> it
> > > will
> > > > > > > > I think a good way to identify an OTN (virtual) topology
> is
> > > via
> > > > > > > > (infrastructure) ODU container role of ODUs comprising
> the
> > > > > > topology.
> > > > > > > > topology the container is a part of and could be
> advertised
> > > as the
> > > > > > > > According to the point 3, I don't know how to advertise
> the
> > > roles
> > > > > > > > and muxing capabilities with the ISCD of RFC4202, could
> you
> > > > > > clarify?
> > > > > > > >
> > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2
> or
> > > ODU3 as
> > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if
> there
> > is
> > > a
> > > > > > OTU3
> > > > > > > link
> > > > > > > > IB>> As I mentioned earlier, ODU role is only important
> on
> > > the ODU
> > > > > > > > transit nodes are of no importance. My LO container can
> be
> > > carried
> > > > > > > > some extent it is similar to MPLS LSP role: LSP always
> has
> > a
> > > role
> > > > > > > (e.g.
> > > > > > > > I agree that there should be multiple OTN specific
> encoding
> > > types
> > > > > > > > 1. Links with the same mux capabilities may have
> different
> > > roles;
> > > > > > 2.
> > > > > > > > to CP as a separate layer, which is exactly how ITU
> models
> > > OTN
> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-
> > > srv-
> > > > > > > > >    , LSPSwitchType_OTN_SHO=3D126  /* OTN super high
> order
> > > */
> > > > > > /*****/
> > > > > > > > It would be better IMHO to keep the Switch Type as TDM
> and
> > > make the
> > > > > > > > Replacing the Encoding Type would insure that any LSR
> that
> > > did not
> > > > > > > > understand what the TS type meant did not try to
> multiplex
> > > its LO
> > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0
> or
> > > ODUj=3Df=
> > > > lex
> > > > > > > > even though the ODUk=3D2 at the next hop could not
> directly
> > > contain
> > > > > > an ODU0.
> > > > > > > > with the new Encoding Type new Signal Types for ODU0,
> ODU4,
> > > and
> > > > > > > > BTW- Maybe I'm missing something but the number of
> messages
> > > on this
> > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-
> layer
> > > control
> > > > > > > > > > IB>> plane, and
> > > > > > > > > > Yes, we have lots of off-line discussions among
> authors
> > > and
> > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding]
> draft
> > > is more
> > > > > > > > > > think you need go to the routing drafts (info model
> and
> > > > > > > encoding).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >> describes the link-parameters that are required
> for
> > > OTN
> > > > > > > service
> > > > > > > > > > >> routing purposes.
> > > > > > > > > > >>
> > > > > > > > > > >> My comment is how are we going to advertise the
> low-
> > > order
> > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services
> (4
> > > ODU1s
> > > > > > > > > > >> are contained over the ODU2). So it is obvious
> from
> > > this
> > > > > > > > > > >> example
> > > > > > > > that

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Jul 2010 14:22:37 -0700

Igor,

In the same way that RFC 3471 describes the GMPLS signaling functions and RFC 3473 describes the RSVP encodings, RFC 4202 describes the GMPLS routing functions and RFC 4203 describes the OSPF encodings (and has normative references to RFC 4202).  The fact that RFC 4203 contains no description of min or max bandwidth should have been a clue to check the normative references, as opposed to just deciding that you know what they mean.

Thanks,

John

> Sent: Tuesday, July 20, 2010 2:10 PM
> To: 'Igor Bryskin'; [email-masked]; Snigdho Bardalai

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 19:36:18 -0400

> important in case of con-current routing (e.g. restoration after link

Igor, Sergio,

  RFC 4203 (in 1.  Introduction)

   The TE LSA, which is an opaque LSA with area flooding scope
   [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet
   and has one or more nested sub-TLVs for extensibility.  The
   top-level TLV can take one of two values (1) Router Address or (2)
   Link.  In this document, we enhance the sub-TLVs for the Link TLV
   in support of GMPLS.  Specifically, we add the following sub-TLVs
   to the Link TLV:

[OSPF-TE] above is RFC 3630.

  RFC 3630 (in 2.4.2.  Link TLV)

   The following sub-TLVs of the Link TLV are defined:

      1 - Link type (1 octet)
      2 - Link ID (4 octets)
      3 - Local interface IP address (4 octets)
      4 - Remote interface IP address (4 octets)
      5 - Traffic engineering metric (4 octets)
      6 - Maximum bandwidth (4 octets)
      7 - Maximum reservable bandwidth (4 octets)
      8 - Unreserved bandwidth (32 octets)
      9 - Administrative group (4 octets)

If you read on you find:

   The Maximum Reservable Bandwidth sub-TLV specifies the maximum
   bandwidth that may be reserved on this link, in this direction, in
   IEEE floating point format.  Note that this may be greater than the
   maximum bandwidth (in which case the link may be oversubscribed).

and

   The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
   not yet reserved at each of the eight priority levels in IEEE
   floating point format.  The values correspond to the bandwidth that
   can be reserved with a setup priority of 0 through 7, arranged in
   increasing order with priority 0 occurring at the start of the sub-
   TLV, and priority 7 at the end of the sub-TLV.  [...]

So the totals per link and per priority level are already there in the
base spec before the RFC 4203 *extensions* to RFC 3630 were added.

That is how you figure out how many ODU0 you can add to your existing
ODU2, and so on.

[BTW- Lets please not talk about "ignorance and misunderstanding".
This is not simple obvious stuff and maybe none of us individually
knows everything about everything.  Myself (all too obviously
sometimes) included.]

Curtis

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Wed, 21 Jul 2010 09:49:16 +0200

Igor,

In other words it could be possible to define 3 Switching Cap (LO, HO and SHO) and put what we defined in the encoding draft into the Switching Capability-specific information of the ISCD.

Something like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----Switching Capability-specific information
   |0|1|2|3|4|5|6|7|  T  |         |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P3                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P5                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P6                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P7                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                            ...                              ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P3                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P5                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P6                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P7                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I still don't understand why we need partitioning the network in three layers while just Sublamba and Full lambda distinction is enough (distinction supported advertising different signal types for full lambdas and sublambdas.

Personally i still prefer advertising these pieces of information as a separate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this could be a valid solution too.

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

> > > > IB>> However,
> > > > IB>> unless
> > > > > > encodeType =3D muxCap & signal type; We also have 16 
> > > > > > reserved bits which can use for OTN specific
> info
> > > > in
> > > > > > case we need it.
> > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the 
> > > > > > path computation is constrained to the OTN_HO_SC topology, 
> > > > > > B11 and
> B12
> > > > TE
> > > > > > links will
> > > > > be
> > > > > > The GMPLS ISCD link sub-tlv and, in particular, its 
> > > > > > switching capability field (confusing name as it is) is a 
> > > > > > good way to
> > > > describe
> > > > > a
> > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, 
> > > > > > IB>> etc.)
> 3
> D=3D=
> 3
> D=3D=
> > > > > > > > >Additionally, I do not see any reason to advertise a 
> > > > > > > > >new TE-link
> > > > > > to
> > > > > > > > IB>> possibility
> > > > > > > > >> ODUj availability within a higher-order container. 
> > > > > > > > >> For example, consider an

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Wed, 21 Jul 2010 10:29:03 +0200

Hi Curtis,

You're perfectly right, the tools for Maximum Reservable Bandwidth and Unreserved Bandwidth are already there, but they lack of distinguishing how such bandiwdth is distributed over the various signal types supported by the advertised link.
Estending both of them plus the ISCD could be a bigger effort and bandwidth consuming solution than introducing all the required information into a single sub-TLV.

Cheers
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: mercoledì 21 luglio 2010 1.36
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

So the totals per link and per priority level are already there in the base spec before the RFC 4203 *extensions* to RFC 3630 were added.

That is how you figure out how many ODU0 you can add to your existing ODU2, and so on.

[BTW- Lets please not talk about "ignorance and misunderstanding".
This is not simple obvious stuff and maybe none of us individually knows everything about everything.  Myself (all too obviously
sometimes) included.]

Curtis

> Subject: RE: [CCAMP] R: Comment on 
> > JD:  As the person to whom I believe you are referring, I would 
> > suggest that you actually read RFC 4202 and 4206.

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 21 Jul 2010 11:45:10 +0200

Hi Curtis,

Thanks for your comment.
As pointed out by Daniele you're right but the missing information here is the real spatial allocation that raised in importance above all in case of link bundling unless you constrain the capability in 1 component link per TE-link, that would reduce value of this very important feature for scalability.

About the last part 

I'm completely agree with you.
I know all that is not simple and obvious stuff for everyone. 
My only two cents is just to highlight it is not always possible justify that different solution for SDH control plane with respect what defined in RFC 4202/4203 are deployed, with a bad reading of these RFCs.

Best Regards

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] 
Inviato: mercoledì 21 luglio 2010 1.36
A: Igor Bryskin
Cc: John E Drake; BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

Curtis

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 21 Jul 2010 08:21:06 -0400

I support this, I think this would be very helpful for TDM technology in general.

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 1:29 AM
To: [email-masked]; Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Curtis,

Cheers
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: mercoledì 21 luglio 2010 1.36
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

Curtis

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 21 Jul 2010 08:29:43 -0400

I support this as well, of course.  Whether this is a technology-specific extension of the ISCD format or a separate sub-TLV is a detail, however as Daniele points out many of the same considerations apply to both OTN and SONET/SDH.

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 09:15:04 -0400

Curtis,

I agree with all you said. The question is that if a single TE LINK TLV contains several ISCDs sub-TLVs and a single "Maximum Reservable Bandwidth" sub-TLV, how the available bandwidth can be partitioned between ISCDs, so that a path computer making use of the TE LINK TLV could figure out how many LSPs of each type (associated with each ISCD) could be placed on the link. Again, this information is not needed when paths are computed for one service at a time, but useful for con-current path computations when several LSPs are (re-)placed at the same time (e.g. in case of restoration after a failure of a link carrying multiple LSPs).

Cheers,
Igor

P.S. [BTW- Lets please not talk about "ignorance and misunderstanding".
This is not simple obvious stuff and maybe none of us individually
knows everything about everything.  Myself (all too obviously
sometimes) included.]

I never do that.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2010 7:36 PM
To: Igor Bryskin
Cc: John E Drake; BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 09:34:58 -0400

Lyndon,

This is not TDM or OTN specific problem. I can build hierarchical topologies using Ethernet STAG switching. If a link can participate in several such topologies it will contain several IDSCs in the advertising, so the problem is the same: how the available bandwidth is partitioned between IDSCs?

Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 8:21 AM
To: Daniele Ceccarelli; [email-masked]; Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 1:29 AM
To: [email-masked]; Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Curtis,

Cheers
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: mercoledì 21 luglio 2010 1.36
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

Curtis

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 21 Jul 2010 09:43:53 -0400

Hi Igor,

Well, I did not say that it was specific to TDM, only that it does occur in TDM.  You point out that hierarchical topologies can be built in packet as well, which sounds reasonable.

I do think that some aspects, like supporting multiple signal types (i.e., minimum reserveable bandwidth quanta) may be specific to TDM.

Cheers,

Lyndon

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 6:35 AM
To: Ong, Lyndon; Daniele Ceccarelli; [email-masked]
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon,

Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 8:21 AM
To: Daniele Ceccarelli; [email-masked]; Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 1:29 AM
To: [email-masked]; Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Curtis,

Cheers
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: mercoledì 21 luglio 2010 1.36
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor, Sergio,

      1 - Link type (1 octet)
      2 - Link ID (4 octets)

If you read on you find:

and

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 09:51:05 -0400

We need to discuss this face to face. The biggest disagreements with Daniele are:
1) I don't believe that flat routing model of a multi-layer OTN network is correct.
2) I think each OTN role defines a separate topology of OTN links, and there is a need to be able to constrain the routing of a given OTN connection to one or more (but not necessarily all) such topologies;
3) There is an issue in the current definitions of GMPLS OSPF extensions (RFC 4203), which does allow to specify multiple ISCDs but does not guide as to how the available bandwidth on the link is partitioned between ISCDs. This is a generic issue and should be resolved in a generic way;
4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE and routing in OTN networks. Unless we see strong reasons to the contrary we should not invent such machinery.

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Jul 2010 07:42:43 -0700

> Sent: Wednesday, July 21, 2010 6:51 AM
> To: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked];
> Snigdho Bardalai

JD:  Disagree

> 2) I think each OTN role defines a separate topology of OTN links, and
> there is a need to be able to constrain the routing of a given OTN
> connection to one or more (but not necessarily all) such topologies;

JD:  Disagree

> 3) There is an issue in the current definitions of GMPLS OSPF
> extensions (RFC 4203), which does allow to specify multiple ISCDs but
> does not guide as to how the available bandwidth on the link is
> partitioned between ISCDs. This is a generic issue and should be
> resolved in a generic way;

JD:  Partitioning is the wrong model.  If we go this route we should advertise a separate bandwidth for each.  This is the most flexible and general model.

> 4) Other than (3) we don't need any OTN or TDM specific CP machinery
> for TE and routing in OTN networks. Unless we see strong reasons to the
> contrary we should not invent such machinery.

JD:  Agree

> I support this as well, of course.  Whether this is a technology-
> specific extension of the ISCD format or a separate sub-TLV is a
> detail, however as Daniele points out many of the same considerations
> apply to both OTN and SONET/SDH.
>
> Lyndon
>
>
>
> In other words it could be possible to define 3 Switching Cap (LO, HO
> and SHO) and put what we defined in the encoding draft into the
> Switching Capability-specific information of the ISCD.
>
> Something like this:
>
>     0                   1                   2                   3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
> ---Switching Capability-specific information
> I still don't understand why we need partitioning the network in three
> layers while just Sublamba and Full lambda distinction is enough
> (distinction supported advertising different signal types for full
> lambdas and sublambdas.
>
> Personally i still prefer advertising these pieces of information as a
> separate sub-TLV (called OTN-ISCD subTLV in the draft but easily
> estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft-
> ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this
> could be a valid solution too.
>
> BR
> Daniele
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 21 Jul 2010 16:58:39 +0200

Igor,

For point 1) and 2) I do not think we are so far.
You're proposing a three-layer approach , we are aligned with what ITU is proposing but we also have different roles in the network (lambda and sub-lambda) and than needs for constrains and policy in the network.
The fact to have three switching capability to characterize the different roles in the same technology it seems to me a little against the concept of switching capability itself.
You could say that for packet there is already 4 PSC SC defined. But here we are in TDM , we have not label stacking capability.

For point 3) and 4) , I do not discuss about the generality or not of the issue, but surely you cannot negate that the problem of spatial allocation is raised as soon as SDH CP has been implemented . Then the same problem come in for OTN , and your intention to cope the issue in a generic way with modifications of RFC 4203 is a good intention, but take also into account that also our proposed format can be generic as soon as you change the signal types supported.

You're right we need to discuss face to face but my perception is that we ca be less far than you believe.

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Jul 2010 07:37:11 -0700

Igor,

The normal case is that the advertised unreserved bandwidth is available to *all* of the advertised ISCDs.  That is why it was designed the way it was.

If we want to advertise unreserved bandwidth by service category, then that is what we should do, rather than trying to carve up unreserved bandwidth with percentages.  It doesn't fit the normal case and enforces a rigid structure.

Thanks,

John 

> Sent: Wednesday, July 21, 2010 6:15 AM
> To: [email-masked]
> I agree with all you said. The question is that if a single TE LINK TLV
> contains several ISCDs sub-TLVs and a single "Maximum Reservable
> Bandwidth" sub-TLV, how the available bandwidth can be partitioned
> between ISCDs, so that a path computer making use of the TE LINK TLV
> could figure out how many LSPs of each type (associated with each ISCD)
> could be placed on the link. Again, this information is not needed when
> paths are computed for one service at a time, but useful for con-
> current path computations when several LSPs are (re-)placed at the same
> time (e.g. in case of restoration after a failure of a link carrying
> multiple LSPs).
> 
> Cheers,
> Igor
> 
> > > > I realized from someone in this thread (not from you) this was
> due
> > > just
> suggest

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 11:33:51 -0400

I agree. All I am saying is that there is a need for a technology independent enhancement to 4203 to address the issue of concurrent path computations. 

Igor 

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 10:37 AM
To: Igor Bryskin; [email-masked]
Cc: BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt 

Igor,

Thanks,

John

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 11:40:54 -0400

> IB>> Curtis, I don't follow you either. When did I mention either crankback or pathErr? I was saying that not feasible paths should be failed by path computation. The advertising based solely on 42…

I'm not sure who wrote this since your style of "quoting" does not
make it clear.  I thought I was responding to a comment from you.

> > problem/Switching Type" indication."

In any case, we are in agreement that crankback should be avoided.

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 12:02:23 -0400

Hi Sergio,

I'd like to run with you the following logic.

1. Suppose an operator after some planning decides to provision an infrastructure ODU and use it as a link. Why would he do so?  One reason that I can think of is because he wants to build a virtual topology for a set of clients (with possibly himself as one from the set). The purpose of this topology, generally speaking,  is:
a)      To be non-congruent with underlying topology (virtual or OTU/OCh). For example, to interconnect nodes that do not have a common OTU/OCh link;
b)      To constrain said set of clients to resources of the topology (rather than, for example, to use OTU/OCh links directly).
The question is how the operator can constrain the routing of the ODUs for the clients from the set to the prepared for this purpose virtual topology within the flat ITU routing model?

2. Would you agree that the only reason why a TE link advertises an attribute is to be able to constrain a path computation based on the attribute? Your definitions of the OTN encoding types, for example, are:
"     ....
      o 8 - Lambda (Photonic)
      o 12 - G.709 ODUk (Digital Path)
      ....
"

which will give the operator an ability to route an OTN connection either straight over OTUs or over infrastructure ODUs with no regard to the roles assigned to the links. Do you believe this would be flexible enough for the operator?

3. What is it you can achieve with the suggested OTN routing that can not be achieved using multiple 4203 ISCDs?

Thanks,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 10:59 AM
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 12:21:43 -0400

In message <[email-masked]>
Igor Bryskin writes:
> to accept an LSP of any type. Hence the TDM+PSC-4 advertisement
> (albeit allowed) does not make any practical sense to me. You need,
> first, create a TDM LSP, advertise it as an FA and use FA as a link
> (which is likely to be a different link, because, for example, it will
> have a different remote end) for PSC-4 LSP. However, if an OTN link
> advertises two IDSCc - OTN_LO and OTN_HO - it is quite a different
> ball game. It will mean that the link could participate in the two
> topologies immediately.
>  
> Igor

TDM+LSR is the title of one of the examples in RFC 4202.  In RFC 4202
the set of ICSD is:

      Interface Switching Capability Descriptor:
         Interface Switching Capability = TDM [Standard SDH]
         Encoding = SDH
         Min LSP Bandwidth = VC-3
         Max LSP Bandwidth[p] = STM-64, for all p

      Interface Switching Capability Descriptor:
         Interface Switching Capability = PSC-1
         Encoding = SDH
         Max LSP Bandwidth[p] = 10 Gbps, for all p

Does RFC 4202 make sense?  If so, I changed from PSC-1 as listed in
RFC 4202 to PSC-4 and changed the description of it from TDM+LSR to
TDM+PSC-4.  If is still an FA and an FA in this case implies that a
STM-64 exists and at each termination point PSC LSP can be created as
well as TDM LSP.

Given that please reread and see if the rest of the example I gave
makes any sense.  It is the same as your OTN_HO+OTN_LO example and
given as an illustration using something familiar (PSC and TDM have
been deployed for a while now and *should* be familiar to someone).

BTW - I see exactly what you are doing by defining OTN_LO, OTN_HO, and
OTN_SHO but I'm not certain that all constraints of OTN are covered.
Maybe they are.  RFC 3630 gives the means to indicate how many
connections can be made in the base Link TLV.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 12:45:39 -0400

> JD: I agree with what you wrote, above, but I am not sure what it has

Apparently I am a master at irrelevant comments.  :-)

> The question we have been discussing is whether an intermediate node
> should be advertising the total unreserved bandwidth or unreserved
> bandwidth by service category for each of its links.  I thought your
> e-mail indicated support for the latter position.

Let me summarize:

  RFC 4203:

    Max Bandwidth is the total BW irrespective of what is reserved.

    Max LSP is the biggest LSP that can be created.

    Min LSP if provided is the smallest LSP and an LSP must be an
    integer multiple of min LSP.

  RFC 3630:

    Link TLV Unreserved Bandwidth has the remaining unreserved
    bandwidth per priority type.

RFC 4203 extends RFC 3630 and therefore the is no "unreserved
bandwidth" specified in RFC 4203.

In RFC 4202:

   [...] This document enhances the routing extensions [ISIS-TE],
   [OSPF-TE] required to support MPLS Traffic Engineering (TE).

   [ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say
   how to associate TE properties to regular (packet-switched) links.
   This document extends the set of TE properties, and also says how to
   associate TE properties with non-packet-switched links such as links
   between Optical Cross-Connects (OXCs).  [LSP-HIER] says how to
   associate TE properties with links formed by Label Switched Paths.

Note [OSPF-TE] == RFC 3630, [ISIS-TE]  == RFC 3784.

In RFC 4203:

   In this section, we define the enhancements to the Traffic
   Engineering (TE) properties of GMPLS TE links that can be announced
   in OSPF TE LSAs.  The TE LSA, which is an opaque LSA with area
   flooding scope [OSPF-TE], has only one top-level Type/Length/Value
   (TLV) triplet and has one or more nested sub-TLVs for
   extensibility.  The top-level TLV can take one of two values (1)
   Router Address or (2) Link.  In this document, we enhance the
   sub-TLVs for the Link TLV in support of GMPLS.  Specifically, we
   add the following sub-TLVs to the Link TLV:

   Sub-TLV Type      Length    Name
             11           8    Link Local/Remote Identifiers
             14           4    Link Protection Type
             15    variable    Interface Switching Capability
             Descriptor
             16    variable    Shared Risk Link Group

Note that none of the Link TLV sub-TLVs in RFC 3630 are obsoleted or
superceded.

> What I was trying to point out was that unless an intermediate node
> issues a new advertisement every it activates or deactivates an LSP
> across its links, the state of its links in its last advertisement may
> be very different from its current state, and that hence an ingress
> node does not have a reliable indication of that state.

Yes.  reservable bw must be updated.

> The example I used was that what was advertised for a given link was 5
> ODUj, even though the current unreserved bandwidth for ODUj is
> anywhere in the range 0 ODUj to 10 ODUj.

The reservable bandwidth would indicate that half of the capacity was
still available.  The min LSP bw indicates which ODUj you are dealing
with.

> I.e., advertising unreserved bandwidth by service category gives a
> false sense of security wrt the distributed awareness of the current
> state of the network.

The reservable bandwidth is in bytes/sec which we both agree on.  That
way any nominal multiple of min LSP could be used.  A slight sticky
point is that ODU payloads are not exact integer multiples due to OH
which is why I stated nominal multiples.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 13:51:20 -0400

In message <[email-masked]>
Igor Bryskin writes:
> IB>> The question is not rhetorical. Keep in mind that this
> information is only needed for concurrent path computations performed
> on the same node. For example, a link has failed and *all* LSPs going
> through the link are originated on the same NE, and the NE is trying
> to reroute all of them concurrently. I don't think you will want to
> preempt other connections knowing that it may not help, because at the
> same time other NEs (terminating other LSPs going over the failed
> link) may do the same thing.  If you use preemption in this case your
> restoration will do more harm than good.
>  
> In all other case the info does not help much. I think it is Ok to say
> that ISDCs share the common pool in, say, 60% to 40% ratio and
> extrapolate the ratio for all priority levels. I say it is overkill to
> partition the unreserved bandwidth pool on per priority
> level. However, if you insist on such partitioning then 4203 allows
> you to expand the IDSC sub-TLV and you can specify the unreserved
> bandwidth per priority level for every ISCD.
>  
> Igor

OK ... so if priority 0-7 in RFC 3630 Link TLV unreserve BW and in RFC
4203 are not for preemption, what exactly are they for?

If a priority 4 OTN_HO contains one smaller priority 5 OTN_LO how are
the reservable bandwidth per priority in the Link TLV expressed?

If a priority 4 OTN_LO won't fit, does the priority 5 OTN_LO block it,
or does it get preempted?

I think you need two FA in this case and priority would drive
preemption, but I'd be willing to read why it should be otherwise.

As I understand it, the FA for a priority N LSP should have BW for
priority zero to N-1 set to zero.  This is because you can't put a
priority 1 LSP into a priority 3 LSP, otherwise the priority 1 LSP
could effectively get preempted by a priority 2 LSP.  This means that
the examples above need two FA or need percentage per priority per
signal-type as Snigdho pointed out.

If OTN_LO OTN_HO, and OTN_SHO are ISCs, rather than use TDM as the
ISC, then you need Max LSP Bandwidth per priority level for each of
OTN_LO OTN_HO, and OTN_SHO plus the Switching Capability-specific
information given in the ISCD must be given individually for each.

OTOH, if just OTN is the ISC, then OTN_LO OTN_HO, and OTN_SHO can be
part of the Switching Capability-specific information in the ISCD.
This to me makes more sense.  Really the issue is how to express the
OTN specific constraints and IMHO that should be in the "Switching
Capability-specific information".  It is also architecturally cleaner
to provide only Sub-TLVs in the Switching Capability-specific
information and to define only one new ISC.

Curtis

> [...trimmed...]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 14:08:27 -0400

In message <[email-masked]>
Igor Bryskin writes:
>  
> IB>> It is possible from the RFC4203 point of view. What I am saying
> is that it is not practical to advertise for the same link both TDM
> and PSC ISCDs. It is only possible when:

That is essentially the peer model, which is in fact possible.

Curtis

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 22 Jul 2010 02:14:42 +0800

Hi John,

snipped....

[Fatai] Yes, agree. The solution for the issue is based on the assumption (i.e., extending ISC types).

Thanks

Fatai Zhang

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28973234
Fax: +86-755-28972935

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 14:28:41 -0400

Curtis,

IB>> That's what people thought when they were 10 years younger :=)
I would like to talk to somebody who has ever seen such configuration outside of an interop demo.
Igor

Curtis

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 22 Jul 2010 03:44:39 +0800

Hi Igor,

Thanks very much. I support your suggestions.

I would like to put a few items following your items to be discussed.

(5) Discuss or clarify the original meaning of Swithcing Capability to see if switching capability is equal to role.
(6) Discuss if three layers or roles are competent for more than three layers networks (at least 5 layers (ODUj(j=0/flex, 1,2,3,4...)). We know the higher layer ODUk can provide virtual topology for the lower layer ODUj (j<k). In addtion, do you think if it is semi-flat routing model for your proposal? 
(7) Discuss what should be extended to RFC4203 to carry accurate routing informaiton. If it needs major changes on ISCD even though it looks like the original ISCD of RFC4203, why we can not take a step forward to make it more reasonable.

Thanks
Fatai Zhang

----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Cc: <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Ong, Lyndon" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; "John E Drake" <[email-masked]>; <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Varma, Eve L (Eve)" <[email-masked]>; "Fatai Zhang" <[email-masked]>
Sent: Thursday, July 22, 2010 12:02 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Sergio,

Thanks,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 10:59 AM
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 16:00:00 -0400

In message <[email-masked]>
"Daniele Ceccarelli" writes:
>  
> Hi Curtis,
>  
> You're perfectly right, the tools for Maximum Reservable Bandwidth and
> Unreserved Bandwidth are already there, but they lack of
> distinguishing how such bandiwdth is distributed over the various
> signal types supported by the advertised link.  Estending both of them
> plus the ISCD could be a bigger effort and bandwidth consuming
> solution than introducing all the required information into a single
> sub-TLV.
>  
> Cheers
> Daniele

Daniele,

The only situation in which a new LSP was set up and a new FA was not
needed would be the case where the endpoints exactly the same.

If a ODU1 is set up inside an ODU3, the remaining reservable BW is
(nominal) ODU3-ODU1.  Since it is not possible to create 3.75 ODU2,
only 3 ODU2, there is no issue.

The new FA would be max-bandwidth of ODU1 and may be max-lsp-bw of
either ODU0 or ODU1 depending on whether a HO ODU1 LSP was created.

For the odd case where the new ODU1 LSP has the same end points as the
old ODU3 LSP, creating an additional FA that might otherwise not be
needed is not a big deal.

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 16:01:33 -0400

Fatai,

Please see in line.

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 3:45 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve)
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Igor,

IB>> Excellent, thanks

IB>> instance of GMPLS managing multiple layers views network as a stack of topologies with distinct swicthcap (which is the topology ID). My suggestion for the OTN is to associate each virtual topology with the role, hence for OTN swicthcap = role 

(6) Discuss if three layers or roles are competent for more than three layers networks (at least 5 layers (ODUj(j=0/flex, 1,2,3,4...)). We know the higher layer ODUk can provide virtual topology for the lower layer ODUj (j<k).

IB>> It should be 5, of course; 3 was an example

 In addtion, do you think if it is semi-flat routing model for your proposal? 

IB>> If I understand you correctly, by semi-flat you mean some TE links advertise more than 1 role. In this case, yes

IB>> Exactly, it should be a generic minor enhancement specific neither to OTN nor TDM.

Igor

Thanks
Fatai Zhang

----- Original Message ----- 
From: "Igor Bryskin" <[email-masked]>
To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Cc: <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Ong, Lyndon" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; "John E Drake" <[email-masked]>; <[email-masked]>; "Snigdho Bardalai" <[email-masked]>; "Varma, Eve L (Eve)" <[email-masked]>; "Fatai Zhang" <[email-masked]>
Sent: Thursday, July 22, 2010 12:02 AM
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Sergio,

Thanks,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 10:59 AM
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 21 Jul 2010 16:04:31 -0400

Curtis,

Could not agree more :=)

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 4:00 PM
To: Daniele Ceccarelli
Cc: [email-masked]; Igor Bryskin; [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt 

Daniele,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 16:24:51 -0400

In message <[email-masked]>
"BELOTTI, SERGIO (SERGIO)" writes:
>  
> Hi Curtis,
>  
> Thanks for your comment.
> As pointed out by Daniele you're right but the missing information
> here is the real spatial allocation that raised in importance above
> all in case of link bundling unless you constrain the capability in 1
> component link per TE-link, that would reduce value of this very
> important feature for scalability.

Maybe I'm missing something (again).  If so, please point out what I
missed.

In link bundling the min LSP BW is the smallest LSP or TDM container
supported.  Any multiple of the min LSP is allowed.  The max LSP BW is
the largest LSP that can be accommodated (per priority).  The max
reservable BW (not max LSP bw) is the total size of the bundle,
ignoring any reservations, and the reservable BW (in the Link TLV in
RFC 3630) indicates how much capacity is still left.

For bundles as per RFC 4201:

    The Maximum LSP Bandwidth takes the place of the Maximum
    Bandwidth.  For an unbundled link, the Maximum Bandwidth is
    defined in [GMPLS-ROUTING].  The Maximum LSP Bandwidth of a
    bundled link at priority p is defined to be the maximum of the
    Maximum LSP Bandwidth at priority p of all of its component links.
    The details of how Maximum LSP Bandwidth is carried in IS-IS is
    given in [GMPLS-ISIS].  The details of how Maximum LSP Bandwidth
    is carried in OSPF is given in [GMPLS-OSPF].

This is consistent with RFC 4203 "Max LSP Bandwidth at priority N"
being reported in the ISCD.

  3.8.  Unreserved Bandwidth

    The unreserved bandwidth of a bundled link at priority p is the
    sum of the unreserved bandwidths at priority p of all the
    component links associated with the bundled link.

This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined
in RFC 3630.

That seems to me to completely cover link bundling with no constraints
on its capability and no need for one TE-link (FA) per compoent link.

> My only two cents is just to highlight it is not always possible
> justify that different solution for SDH control plane with respect
> what defined in RFC 4202/4203 are deployed, with a bad reading of
> these RFCs.

We are defining new OTN functionality so software will need to
change.  If prior SONET implementations didn't get it right that is no
reason to not get it right in defining the OTN extensions.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 17:02:30 -0400

In message <[email-masked]>
Igor Bryskin writes:
>  
> Curtis,
>  
> I agree with all you said. The question is that if a single TE LINK
> TLV contains several ISCDs sub-TLVs and a single "Maximum Reservable
> could figure out how many LSPs of each type (associated with each
> ISCD) could be placed on the link. Again, this information is not
> needed when paths are computed for one service at a time, but useful
> for con-current path computations when several LSPs are (re-)placed at
> the same time (e.g. in case of restoration after a failure of a link
> carrying multiple LSPs).

I've been trying to point out that this is not an issue.

The case where an LSP is inside another LSP with identical endpoints
on both layers is rare and it is questionable what purpose that
serves.  In that case an additional FA is needed for the newer
contained LSP.

The more common case is where one or more of the end point of the
contained LSP extended beyond the endpoints of the containing LSP.  In
that case you always need another FA since the end points differ.

The bandwidth for all containers is reduced by the same amount.  The
inability to create a fractional ODUj allows the fractional part of
the unreserved bandwidth to do no harm.  There is no constraint that
unreserved bandwidth must be a multiple of the min-lsp-bw of any of
the ISCDs.

> knows everything about everything.  Myself (all too obviously

Yes.  I agree.  You don't.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 17:37:45 -0400

Igor,

A current solution would be to use ML/MT extensions.  A GMPLS E-NNI
could also solve this problem if designed to isolate clients and
resources in this manner.

No hacking of RFC 4203 is needed.  No (new) warts need to be added.

Curtis

In message <[email-masked]>
Igor Bryskin writes:

Hi Sergio,

Thanks,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 10:59 AM
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Jul 2010 17:55:56 -0400

> outside of an interop demo.

The same could be said of almost any two ISC types in the GMPLS
hierarchy, not just PSC and TDM.

We could also go off on the topic of interoperability among GMPLS
implementations.  Of the limited deployment of GMPLS that is not PSC,
there is very little deployment that is mixed vendor.

In any case, this was based on the example given in RFC 4202.  If it
is nothing more than an acedemic example, that is irrelevant to the
discussion of how RFC 3630, 4201, 4202, 4203 were intended to work.

Curtis

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 22 Jul 2010 08:50:57 -0400

Curtis,

Please, see my comments in line.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, July 21, 2010 4:25 PM
To: BELOTTI, SERGIO (SERGIO)
Cc: Snigdho Bardalai; [email-masked]; Igor Bryskin
Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> important feature for scalability.

Maybe I'm missing something (again).  If so, please point out what I missed.

In link bundling the min LSP BW is the smallest LSP or TDM container supported.  Any multiple of the min LSP is allowed.  The max LSP BW is the largest LSP that can be accommodated (per priority).  The max reservable BW (not max LSP bw) is the total size of the bundle, ignoring any reservations, and the reservable BW (in the Link TLV in RFC 3630) indicates how much capacity is still left.

This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined in RFC 3630.

That seems to me to completely cover link bundling with no constraints on its capability and no need for one TE-link (FA) per compoent link.

IB>> Correct as long as components share the same termination points. Generally speaking, when an infrastructure ODU is provisioned, it has more than 1 hope, hehence needs to be advertised as a separate FA TE link.

> what defined in RFC 4202/4203 are deployed, with a bad reading of 

We are defining new OTN functionality so software will need to change.  If prior SONET implementations didn't get it right that is no reason to not get it right in defining the OTN extensions.

IB>> agreed 100%. Also, CP architecture and protocols are the center part of IETF CCAMP charter, and we have all rights questioning ITU solutions wrt CP.

Igor 

Curtis

> Sergio Belotti
>  
> System Architecture
> Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT
>  
> +39 039 6863033
> +39 039 6863590
>  
>  
> Oggetto: Re: [CCAMP] R: Comment on 
> <[email-masked]
> cal.com>
> Igor Bryskin writes:
> >  
> > John,
> >  
> > matching the ISCD you can accommodate on the link. Such information 
> > is important in case of con-current routing (e.g. restoration after 
> > link failure).
> >  
> > Igor
>  
> Igor, Sergio,
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 22 Jul 2010 09:24:22 -0400

Curtis,

The same OTN TE link can play several roles (e.g. LO ODU2 and HO ODU2). Although, the two roles will share the same physical resources, operator may have a policy saying that the resources are divided between the roles (e.g. 50%-50% or 75%-25%). Therefore, I believe some enhancement to 4203 will be needed.

Otherwise, I agree.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, July 21, 2010 5:38 PM
To: Igor Bryskin
Cc: Varma, Eve L (Eve); [email-masked]; Snigdho Bardalai; Ong, Lyndon
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Curtis

Hi Sergio,

Thanks,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 10:59 AM
To: Igor Bryskin
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Cheers

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Igor Bryskin
Inviato: mercoledì 21 luglio 2010 15.51
A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [email-masked]; Snigdho Bardalai
Cc: [email-masked]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Something like this:

    0                   1                   2                   3

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [email-masked]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [email-masked]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 22 Jul 2010 15:29:55 +0200

Hi Curtis,

SB> You cannot deduce form this advertisement how many LSP (ODU connections) of MAX LSP BW you can setup since you have not the information on how the unreserved BW is allocate on the different component link and you can have the impression to be able to setup a number of connection that instead is not possible due to fragmentation of the usage of the BW in the different component link. 
If the TE is per- component link this obviously not happen losing the scalability of bundling construct.
You told me you have read the info draft for G.709, there is an example for that.

change. 

SB> Surely, possibly taking into account previous TDM experience.

 If prior SONET implementations didn't get it right that is no
reason to not get it right in defining the OTN extensions.

SB> Probably you misunderstood the sense of my wording: it is not the implementation that did not right but the implementation of CP SDH will try to overcome lack in the reference standard document.
I agree with you trying to avoid this can happen also for OTN.

Best regards

sergio

Curtis

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 08:07:16 -0700

Snipped...

>     Max Bandwidth is the total BW irrespective of what is reserved.

JD:  I didn't see that in 4203.  As I explained to Igor, it is probably better to use 4202 rather than 4203 as it contains the explanation of the fields.

>     integer multiple of min LSP.

JD: For PSC I don't think there is any relationship other than >= between max and min.  For TDM standard SDH/SONET, max and min describe a branch of the SDH/SONET hierarchy and an LSP of any rate defined on that branch may be established.  For TDM arbitrary SDH/SONET,  an LSP of rate N * min up to a value of max may be established.

> Yes.  reservable bw must be updated.

JD:  Unreserved?

> still available.  The min LSP bw indicates which ODUj you are dealing

JD:  Right, but my point was that the actual unreserved bandwidth could actually be less than 5 ODUj, so the establishment of a 5 ODUj LSP would fail even though it was in conformance with what was advertised.

> which is why I stated nominal multiples.

JD:  According to Snigdho what is actually allowed is exact integer multiples.  I.e., it would be possible to establish 84 ODU0 LSPs on an ODU4, but only 80 are actually allowed.

> > > > > Cc: Igor Bryskin; [email-masked]; John E Drake; Snigdho
> Bardalai;
> > > Lou
> > > > > Berger; [email-masked]
> > > > > > nodes. It is it's position in the hierarchy (but not role)
> that
> > > may
> > > > > > change hop-by-hop. "
> > > > > >
> > > > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can
> only
> > > > > support
> > > > > > I think role does not equal switching capability. The
> operators
> > > can
> > > > > > IB>> When a GMPLS CP instance controls several layers, it
> views
> > > the
> sub-
> > > stack
> > > > > > IB>> I disagree. You define role == position in the
> hierarchy,
> > > which
> > > > > is a mistake IMO.
> > > > > >
> > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or
> ODU3
> > > as Ho
> > > > > OTN Level or Lo OTN Level? Another example is, if there is a
> OTU3
> > > link
> > > > > > IB>> As I mentioned earlier, ODU role is only important on
> the
> > > ODU
> > > > > Berger" <[email-masked]>; <[email-masked]>; <draft-ietf-
> ccamp-
> > > gmpls-
> > > > > > 3. Link's role and mux. capabilities can be advertised with
> ISCDs
> > > as
> > > > > > 4. The combination of swicthcaps and encoding type will look
> to
> > > CP as
> > > > > a separate layer, which is exactly how ITU models OTN
> hierarchies
> > > in
> > > > > independent way. Suppose an instance of GMPLS CP manages WDM
> and
> > > OTN
> > > > > NEs. Then separation of LO from HO OTN links will be no
> different
> > > from
> > > > > > It would be better IMHO to keep the Switch Type as TDM and
> make
> > > the
> > > > > > layer and G.709 Optical Channel layer for 2009 OTN, which had
> in
> > > turn
> > > > > > Replacing the Encoding Type would insure that any LSR that
> did
> > > not
> > > > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited
> to
> > > > > using
> > > > > > regardless of what goes on in the middle since that
> determines
> > > what
> > > > > > though the ODUk=2 at the next hop could not directly contain
> an
> > > ODU0.
> > > > > > the new Encoding Type new Signal Types for ODU0, ODU4, and
> ODU-
> > > flex,
> > > > > > and ODU2e, can be added.
> > > > > >
> > > > > > BTW- Maybe I'm missing something but the number of messages
> on
> > > this
> > > > > > other intent.  Could someone (either draft) concisely
> summarize
> > > the
> > > > > > > > before we can embark on any proposals to the problem. I
> am
> > > still
> > > > > not clear
> > > > > > > > why do we have to deviate from the general approach that
> has
> > > been
> > > > > > > > established in RFC 4202.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ISCD. The combination of Switching Capability and
> Encoding
> > > type
> > > > > of RFC4202
> TE-
> > > > > > > > hierarchies and constrain LO connections to HO
> containers,
> > > one
> > > > > needs to
> > > > > > > > interested experts, and we think the proposal described
> in
> > > > > "draft-
> > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft
> is
> > > more
> > > > > feasible
> > > > > > > > for OTN networks.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The framework draft just tells you what information
> needed
> > > for
> > > > > control
> > > > > > > > > Cc: [email-masked] <mailto:[email-masked]> ; draft-
> ietf-
> > > ccamp-
> > > > > gmpls-
> > > > > course one of
> > > > > > > > > draft and discussion contributors on there progress on
> this
> > > > > point.
> > > > > > > > >
> > > > > > > > > Lou
> > > > > > > > >
> > > > > > > > >> ODU2). So it is obvious from this example that the
> number
> > > of
> > > > > time-slots
> > > > > > > > >> bandwidth in bytes/sec within a link? This approach
> seems
> > > to
> > > > > be more
> > > > > > > > >> in-line with the general approach outlined in RFC-
> 4202.
> > > Refer
> > > > > to
> > > > > > > > section

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 08:23:37 -0700

Curtis,

As I said last week, I think the existing RFC 4202/4203 design works just fine for unbundled links.

For bundled links, due to bin packing, it is asserted that if one advertised unreserved bandwidth by what I have been calling service type (which in the OTN case equates to ODUj client rate), one can get a more accurate understanding of the state of the bundled link wrt the number of LSPs that could be established at each of the ODUj client rates available at the time of advertisement.

So, I think there are two questions.  1) Do we want to advertise unreserved bandwidth by service type, and if so, do we want to advertise it for all links or only for bundled links?

Thanks,

John  

> Sent: Wednesday, July 21, 2010 1:25 PM
> Cc: [email-masked]; Daniele Ceccarelli; [email-masked]; Snigdho
> Bardalai; Igor Bryskin; John E Drake
> Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-
> framework-01.txt
> 
> 
> Bandwidth.
> > > > > advertisement for SDH . Anyway it is a fact that the
> alternative
> > > > format

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 09:19:22 -0700

Igor,

There is no reason to define multiple ISCD values for OTN networks in order to constrain the path of a given LSP to only certain links.  The right way to do this is link colors (nee Administrative Groups, defined in RFC 3630), which is what it was designed to do.

I know this is a radical thought but why don't we use ISCD for what it was designed to do?

Thanks,

John

> Sent: Wednesday, July 21, 2010 2:38 PM
> To: Igor Bryskin
> Cc: BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai; Ong,
> Lyndon; Daniele Ceccarelli; John E Drake; [email-masked]; Snigdho
> Bardalai; Varma, Eve L (Eve); Fatai Zhang
> 1. Suppose an operator after some planning decides to provision an
> infrastructure ODU and use it as a link. Why would he do so?  One
> reason that I can think of is because he wants to build a virtual
> topology for a set of clients (with possibly himself as one from the
> set). The purpose of this topology, generally speaking,  is:
> a)      To be non-congruent with underlying topology (virtual or
> OTU/OCh). For example, to interconnect nodes that do not have a common
> OTU/OCh link;
> b)      To constrain said set of clients to resources of the topology
> (rather than, for example, to use OTU/OCh links directly).
> The question is how the operator can constrain the routing of the ODUs
> for the clients from the set to the prepared for this purpose virtual
> topology within the flat ITU routing model?
>
> 2. Would you agree that the only reason why a TE link advertises an
> attribute is to be able to constrain a path computation based on the
> attribute? Your definitions of the OTN encoding types, for example,
> are:
> "     ....
>       o 8 - Lambda (Photonic)
> which will give the operator an ability to route an OTN connection
> either straight over OTUs or over infrastructure ODUs with no regard to
> the roles assigned to the links. Do you believe this would be flexible
> enough for the operator?
>
> 3. What is it you can achieve with the suggested OTN routing that can
> not be achieved using multiple 4203 ISCDs?
>
> Thanks,
> Igor
>
>
> Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli;
> John E Drake; [email-masked]; Snigdho Bardalai; Varma, Eve L (Eve);
> Fatai Zhang
> You're proposing a three-layer approach , we are aligned with what ITU
> is proposing but we also have different roles in the network (lambda
> and sub-lambda) and than needs for constrains and policy in the
> network.
> The fact to have three switching capability to characterize the
> different roles in the same technology it seems to me a little against
> the concept of switching capability itself.
> You could say that for packet there is already 4 PSC SC defined. But
> here we are in TDM , we have not label stacking capability.
>
> For point 3) and 4) , I do not discuss about the generality or not of
> the issue, but surely you cannot negate that the problem of spatial
> allocation is raised as soon as SDH CP has been implemented . Then the
> same problem come in for OTN , and your intention to cope the issue in
> a generic way with modifications of RFC 4203 is a good intention, but
> take also into account that also our proposed format can be generic as
> soon as you change the signal types supported.
>
> > operators can
> > views the
> > determines what
> > containers, one
> > needed for

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 22 Jul 2010 13:12:37 -0400

John,

One reason is that ISCD allows for advertising of available LSP bandwidth per priority level, which could change for the same OTN link depending on role. Coloring won't allow to do so. Also, ISCD encoding type allows for encoding the signal type, mux. capabilities, etc. without introduction of OTN specific sub-TLVs. We want to help operator to provision  topologies, ID them and provide a simple way to constrain a given LSP to be routed within a topology.  ISCD gives you a simple way to do so in a technology independent way, so that constraining LSP to belong, say, OTN_LO or OTN_HO topology will not be different from constraining LSP to belong to, say, ETH_EVPL layer.

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 22, 2010 12:19 PM
To: [email-masked]; Igor Bryskin
Cc: BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 10:21:01 -0700

Hi,

I have a suggestion.

Why don't we allow a node to optionally advertise the unreserved bandwidth for each of the component links in a bundle?  This is a general, non-OTN, solution to this specific problem and it is backwards compatible.

Thanks,

John 

> Sent: Thursday, July 22, 2010 8:24 AM
> To: [email-masked]'; BELOTTI, SERGIO (SERGIO)
> Cc: Daniele Ceccarelli; [email-masked]; Snigdho Bardalai; Igor Bryskin
> Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-
> framework-01.txt
> 
> Curtis,
> 
> For bundled links, due to bin packing, it is asserted that if one
> advertised unreserved bandwidth by what I have been calling service
> type (which in the OTN case equates to ODUj client rate), one can get a
> more accurate understanding of the state of the bundled link wrt the
> number of LSPs that could be established at each of the ODUj client
> rates available at the time of advertisement.
> 
> So, I think there are two questions.  1) Do we want to advertise
> unreserved bandwidth by service type, and if so, do we want to
> advertise it for all links or only for bundled links?
> 
> Thanks,
> 
> John
> 
> <[email-masked]
> > m.alcatel-lucent.com>
> > > >    Typical values for the Minimum LSP Bandwidth and for the
> Maximum
> > LSP
> > > >    p could reserve any bandwidth between the Minimum LSP
> Bandwidth
> > and

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 22 Jul 2010 10:27:34 -0700

John

That is an alternative but because the size of the LSA grows with number of components you could potentially have to limit the size of a bundle or be ready to grow the LSA (in theory there is no limit)

Regards
Snigdho

> Sent: Thursday, July 22, 2010 10:21 AM
> To: John E Drake; [email-masked]; BELOTTI, SERGIO (SERGIO)
> Why don't we allow a node to optionally advertise the unreserved
> bandwidth for each of the component links in a bundle?  This is a
> general, non-OTN, solution to this specific problem and it is backwards
> compatible.
> 
> Thanks,
> 
> John
> 
> > > > all in case of link bundling unless you constrain the capability
> in
> > 1
> > > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); [email-masked];
> Snigdho
> > > Bardalai
> > > > > important in case of con-current routing (e.g. restoration
> after
> > > link
> > > > > failure).
> > > > >
> > > > > Igor
> > > >
> > > > Igor, Sergio,
> > > >
> > > >    bandwidth that may be reserved on this link, in this
> direction,
> > in
> > > >    IEEE floating point format.  Note that this may be greater
> than
> > > the
> > > > So the totals per link and per priority level are already there
> in
> > > the
> > > > >    reserve.  Maximum LSP Bandwidth for a bundled link is
> defined
> > in
> > > > >    [LINK-BUNDLE].
> > > > >
> > > > >    [GMPLS-ROUTING].  The Maximum LSP Bandwidth of a bundled
> link
> > at

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 10:30:42 -0700

Igor,

This sounds like arm waving to me.  To put things in perspective, let's remember that you are the only person that is claiming that an operator wants any of this.  I have seen nothing to date in I-Ds pertaining to OTN that has said any of this is needed.  It is also completely contrary to the ITU modeling work for OTN, which uses a single flat network.  (Of which you were, until recently, completely unaware.)

As a general rule, what should be advertised in the TE database is the type of client signals that can be placed on a given link and not its server characteristics, which are more or less totally irrelevant.

John

> Sent: Thursday, July 22, 2010 10:13 AM
> Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai
> Zhang
> One reason is that ISCD allows for advertising of available LSP
> bandwidth per priority level, which could change for the same OTN link
> depending on role. Coloring won't allow to do so. Also, ISCD encoding
> type allows for encoding the signal type, mux. capabilities, etc.
> without introduction of OTN specific sub-TLVs. We want to help operator
> to provision  topologies, ID them and provide a simple way to constrain
> a given LSP to be routed within a topology.  ISCD gives you a simple
> way to do so in a technology independent way, so that constraining LSP
> to belong, say, OTN_LO or OTN_HO topology will not be different from
> constraining LSP to belong to, say, ETH_EVPL layer.
>
> Igor
>
> Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai
> Zhang
> There is no reason to define multiple ISCD values for OTN networks in
> order to constrain the path of a given LSP to only certain links.  The
> right way to do this is link colors (nee Administrative Groups, defined
> in RFC 3630), which is what it was designed to do.
>
> > You're right we need to discuss face to face but my perception is
> that
> > we ca be less far than you believe.
> >
> > Cheers
> >
> > Sergio
> >
> > Sergio Belotti
> >
> > System Architecture
> > Da: [email-masked] [mailto:[email-masked]] Per conto
> di
> > Igor Bryskin
> > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > 1) I don't believe that flat routing model of a multi-layer OTN
> network
> > is correct.
> > Of Daniele Ceccarelli
> >    ...                            ...
> ...

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 10:34:35 -0700

Snigdho,

I am sure there will be some details to work out, but it solves the specific problem at hand in a general way that is consistent with the way MPLS/GMPLS works.  It is just adding detail in a specific case where more detail may be useful.

Thanks,

John

> Sent: Thursday, July 22, 2010 10:28 AM
> Cc: Daniele Ceccarelli; [email-masked]; Igor Bryskin
> That is an alternative but because the size of the LSA grows with
> number of components you could potentially have to limit the size of a
> bundle or be ready to grow the LSA (in theory there is no limit)
> 
> Regards
> Snigdho
> 
> > > As I said last week, I think the existing RFC 4202/4203 design
> works
> > > just fine for unbundled links.
> > >
> > > type (which in the OTN case equates to ODUj client rate), one can
> get
> > a
> > > > Maybe I'm missing something (again).  If so, please point out
> what
> > I
> > > > missed.
> > > >
> > > > supported.  Any multiple of the min LSP is allowed.  The max LSP
> BW
> > > is
> > > > change.  If prior SONET implementations didn't get it right that
> is
> > > no
> > > > >    top-level TLV can take one of two values (1) Router Address
> or
> > > (2)
> > > > >    Link.  In this document, we enhance the sub-TLVs for the
> Link
> > > TLV
> > > > >    in support of GMPLS.  Specifically, we add the following
> sub-
> > > TLVs
> > > > >    to the Link TLV:
> > > > >
> > > > >    floating point format.  The values correspond to the
> bandwidth
> > > > that
> > > > >    can be reserved with a setup priority of 0 through 7,
> arranged
> > > in
> > > > >    increasing order with priority 0 occurring at the start of
> the
> > > > sub-
> > > > > >    The Minimum LSP Bandwidth specifies the minimum bandwidth
> an
> > > LSP
> > > > > >    could reserve.
> > > > > >
> > > > > >    On an interface having Standard SDH multiplexing, an LSP
> at
> > > > priority
> > > > > >    On an interface having Arbitrary SDH multiplexing, an LSP
> at
> > > > priority
> > > > > > > > I realized from someone in this thread (not from you)
> this
> > > was
> > > > due
> > > > > > > just
> > > > > > > > is used in many implementations "in field" for SDH
> control
> > > > plane.
> > > > > > > >
> > > > > > >

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 22 Jul 2010 14:12:22 -0400

John,

Things like in your last email you have said already several times in this discussion alone. I noticed that you do that every time when you run out of technical arguments (which in your case haven't changed a bit in 10 years since early GMPLS years).
Outside of technical arguments I do not care what you say. So why don't you stop wasting your time and wait for several days until the f2f meeting with the authors of the OTN work and CCAMP WG chair? You see, we have started this discussion long time before you joined it, and the fact that it is still alive tells me that some people do care and get things which you may not.

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, July 22, 2010 1:31 PM
To: Igor Bryskin; [email-masked]
Cc: BELOTTI, SERGIO (SERGIO); [email-masked]; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

John

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 11:44:56 -0700

Igor,

Since when do questions about the legitimacy of requirements become non-technical arguments?

Do you have any documentation that substantiates your assertions regarding what carriers what need in order to deploy OTN networks?  I haven't seen anything to date to support you, and as I said the OTU, which should have a pretty good understanding of OTN and carrier requirements, is going in a technical direction completely opposite to yours.  You are right that I have raised these points more than once.

What you failed to mention is that you have never answered them.

Regarding your comment about technical arguments, you have not actually made a detailed technical proposal yourself.  To date your technical proposal amounts to "let's use multiple switching capabilities as it is a perfect solution".  To what problem has also never crisply been answered.

I would reiterate that arm waving seems to characterize your activities to date on all of these points.

It might be useful for you to try to put together a detailed technical proposal, along with a description of the problem or problems it solves, an explanation of why it is so much better than other proposals ('practically perfect' doesn't count), and some justification that this problem or problems are of interest to anyone other than yourself.

I also noticed that you didn't respond to my last paragraph.

John

> Sent: Thursday, July 22, 2010 11:12 AM
> Things like in your last email you have said already several times in
> this discussion alone. I noticed that you do that every time when you
> run out of technical arguments (which in your case haven't changed a
> bit in 10 years since early GMPLS years).
> Outside of technical arguments I do not care what you say. So why don't
> you stop wasting your time and wait for several days until the f2f
> meeting with the authors of the OTN work and CCAMP WG chair? You see,
> we have started this discussion long time before you joined it, and the
> fact that it is still alive tells me that some people do care and get
> things which you may not.
>
> Cheers,
> Igor
>
> This sounds like arm waving to me.  To put things in perspective, let's
> remember that you are the only person that is claiming that an operator
> wants any of this.  I have seen nothing to date in I-Ds pertaining to
> OTN that has said any of this is needed.  It is also completely
> contrary to the ITU modeling work for OTN, which uses a single flat
> network.  (Of which you were, until recently, completely unaware.)
>
> As a general rule, what should be advertised in the TE database is the
> type of client signals that can be placed on a given link and not its
> server characteristics, which are more or less totally irrelevant.
>
> John
>
> > I know this is a radical thought but why don't we use ISCD for what
> it
> > was designed to do?
> >
> > Thanks,
> >
> > John
> >
> > > either straight over OTUs or over infrastructure ODUs with no
> regard
> > to
> > > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > 01.txt
> > >
> > > Igor,
> > >
> > > We need to discuss this face to face. The biggest disagreements
> with
> > > Daniele are:
> > > To: Daniele Ceccarelli; Igor Bryskin; John E Drake;
> [email-masked];
> > > Snigdho Bardalai
> > >    |
> |
> > >    |
> |
> > > Personally i still prefer advertising these pieces of information
> as
> > a
> > >    |                  (variable)
> |
> > > > > > (one per ISCD), indicate how the bandwidth is split between
> the
> > > > ISCDs: e.=
> > > > > g
> > > > > > ISCD1 75%, ISCD2 25%.
> > > > > >
> > > > > > Igor.
> > > > > >
> > > > > > > several of them. One cheap way of doing so is to allocate
> 3-4
> > > > bits out
> > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction
> of
> > > > total
> > > > > > >    third and supporting ODU2 and ODU3 signal types.  The
> node
> > > > would
> > > > > > >    LSP bandwidth equal to 32 TSs.  In case of restoration
> the
> > > > network
> > > > > > > corrispondence between the couples (ISCD-unreserved
> bandwidth
> > > > subTLV).
> > > > > > >
> > > > > > > > > if such bandwidth is available for a certain type of
> ODUj
> > > > > > > > > LSP
> > > > (e.g.
> > > > > > > > 15
> > > > > > > > > I understand what you said. Therefore, we have added
> some
> > > > text to
> > > > > > > > > address the requirment in FWK document. However, we
> still
> > > > don't
> > > > > > > > > think that we need to extend ISC to meet the
> requirment.
> > > The
> > > > role
> > > > > > > of
> > > > > > > > > the
> > > > > > > > ODU
> > > > > > > > > a) this requires OTN specific advertising and
> processing
> > > > rules;
> > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection
> ODU2
> > > > > > > > > with
> > > > the
> > > > > > > > role
> > > > > > > > > corresponding incoming interface.  If  the type cannot
> be
> > > > > > > supported,
> > > > > > > > > layer in technology independent way, so that, say,
> MPLS-
> > TP-
> > > > >OTN_LO-
> > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as
> a
> > > > stack of
> > > > > > > > > should path computation be constrained to particular
> one
> > or
> > > > > > > > > sub-stack of them.
> > > > > > > > > some people seem to believe). The role is only
> meaningful
> > > on
> > > > the
> > > > > > > ODU
> > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS
> stack
> > > > along its
> > > > > > > > > path.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Igor
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > >
> >
> > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-
> style
> > > > ISCD is
> > > > > > > > > required); 4. The combination of swicthcaps and
> encoding
> > > > > > > > > type
> > > > will
> > > > > > > > look
> > > > > > > > > want to constrain the routing of OTN connections to
> pre-
> > > > configured
> > > > > > > > > > I think OTN links require more than one switchcaps:
> as
> > > > > > > > > > many
> > > > as
> > > > > > > the
> > > > > > > > > This would replace the 20006 OTN Encoding Type for
> G.709
> > > > Digital
> > > > > > > > > Path layer and G.709 Optical Channel layer for 2009
> OTN,
> > > > which had
> > > > > > > > > granularity, then the corresponding G.709 Digital Path
> FA
> > > > > > > > > can
> > > > be
> > > > > > > withdrawn.
> > > > > > > > >
> > > > > > > > > The Encoding type would be the lower encoding at each
> end
> > > of
> > > > the
> > > > > > > LSP
> > > > > > > > > If the SHO Encoding Type is used, then it indicates
> that
> > > two
> > > > levels
> > > > > > > > of
> > > > > > > > > Encoding Type indicated LO or HO, that may not be
> needed.
> > > > Along
> > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition
> but
> > > I'm
> > > > not
> > > > > > > > clear
> > > > > > > > > would indicate a huge controversy and I'm not getting
> it
> > > > (other
> > > > > > > than
> > > > > > > > a
> > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-
> g709-
> > > > framework,
> > > > > > > > > or other intent.  Could someone (either draft)
> concisely
> > > > summarize
> > > > > > > > > on number of multiplexing layers at one LSR.  That
> might
> > > > help.
> > > > > > > > >
> > > > > > > > > Curtis
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > =D8  I think we need to sort out the issues with
> the
> > > > framework
> > > > > > > > > > > document before we can embark on any proposals to
> the
> > > > problem.
> > > > > > > I
> > > > > > > > am
> > > > > > > > > > > > align the work with 4202.  Use of common
> approaches
> > > is
> > > > of
> > > > > > > > course
> > > > > > > > > > > > from the draft and discussion contributors on
> there
> > > > progress
> > > > > > > > > > > > on
> > > > > > > > > this point.
> > > > > > > > > > > >
> > > > > > > > > > > > Lou
> > > > > > > > > > > >
> > > > > > > > > > > >> time the OTU3 link has 12 time-slots available
> for
> > > > ODU2
> > > > > > > > > > > >> services
> > > > > > > > and
> > > > > > > > > > > >> How do we address this issue based on the
> approach
> > > > specified
> > > > > > > > in
> > > > > > > > > > > >> the
> > > > > > > > > > > draft?
> > > > > > > > > > > >>
> > > > > > > > > > > >> My other question is why not simply advertize
> the
> > > > available
> > > > > > > > > > > >> approach seems to be more in-line with the
> general
> > > > approach
> > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows
> multiple
> > > > ISCDs
> > > > > > > > > > > >> being advertised per VC rate for an SDH link.
> The
> > > > additional
> > > > > > > > > > > >> benefit
> > > > > > > > > is
> > > > > > > > > > > >> that the advertisement is TS size independent
> and
> > > > hence will

---

From: John E Drake <[email-masked]>
Date: Thu, 22 Jul 2010 12:20:06 -0700

Igor,

I have a quick technical question.  Functionally, in what way is a separate ISCD value for each ODU container rate, which is what I think you are proposing, any different than a single ISCD value with link colors used to represent the ODU container rate?

John

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 26 Jul 2010 12:20:20 -0400

John,

That is worse.  What we are arguing about is whether we can reduce the
number of ICSD.  If we reduce to one ICSD per advertisement and have
one advertisement per component link, we have increased the number of
ICSD in total if number of components is >> number of switching types.

Curtis