Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

From: Rajan Rao <[email-masked]>
Date: Wed, 13 Oct 2010 14:39:33 -0700

Hi,

The following draft has been submitted. Please review. Comments are appreciated.

https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/

thanks
Authors

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 2:30 PM
To: Rajan Rao
Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan
Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository.

Filename:	 draft-ashok-ccamp-gmpls-ospf-g709
Revision:	 01
Title:		 OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks
Creation_date:	 2010-10-12
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
As OTN network capabilities continue to evolve, there is an increased
need to support GMPLS control for the same. [RFC4328] introduced
GMPLS signaling extensions for supporting the early version of G.709
[G.709-v1]. The basic routing considerations from signaling
perspective is also specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and
[GSUP.43] have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling
support for optimal service aggregation.  

This document describes OSPF protocol extensions to support
Generalized MPLS (GMPLS) control for routing services over the
standardized OTU/ODU containers in support of ODU based TDM
switching. Routing support for Optical Channel Layer switching
(Lambda switching) is not covered in this document.

The IETF Secretariat.

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 14 Oct 2010 10:44:30 -0400

Hi Rajan,

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It
would be helpful to understand if your draft is asking for similar
extensions or different functionality.

Thanks,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rajan Rao
Sent: Wednesday, October 13, 2010 2:40 PM
To: [email-masked]
Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted:
draft-ashok-ccamp-gmpls-ospf-g709-01

Hi,

The following draft has been submitted. Please review. Comments are
appreciated.

thanks
Authors

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 2:30 PM
To: Rajan Rao
Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan
Subject: New Version Notification for
draft-ashok-ccamp-gmpls-ospf-g709-01 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been
successfully submitted by Rajan Rao and posted to the IETF repository.

Filename:	 draft-ashok-ccamp-gmpls-ospf-g709
Revision:	 01
Title:		 OSPF TE Extensions for Generalized MPLS (GMPLS) Control
of G.709 Optical Transport Networks
Creation_date:	 2010-10-12
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:

The IETF Secretariat.

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

---

From: Rajan Rao <[email-masked]>
Date: Fri, 15 Oct 2010 10:12:51 -0700

Lyndon,

Yes, we are aware of the existing draft. There are some fundamental differences in the model we have proposed from the existing draft. The key differences are the following:
 
1) This draft extends existing ISCD  Vs. defining a new one 
    - addresses backward compatibility issues (RFC 4202)

2) ODU containers are advertised instead of #TSs
     - simple path computation

3) Path computing node doesn't need to know per link and/or per ODU layer TS granularity
     - again, simple & straight forward path computation  

Thanks
Rajan

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Thursday, October 14, 2010 7:45 AM
To: Rajan Rao; [email-masked]
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

Hi,

thanks
Authors

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 2:30 PM
To: Rajan Rao
Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan
Subject: New Version Notification for

Abstract:

The IETF Secretariat.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 22 Oct 2010 15:48:36 +0200

Hi Rajan,

Just a couple of comments on backward compatibility and bandwidth advertisement.

- Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues.
Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It states that:

      "Encoding of Max LSP Bandwidth is as follows:
       Max LSP Bandwidth = Unreserved-TS-Count x TS-Nominal-Rate"

Moreover it states:

      "If the interface does not support ODU-flex service, 
      this value should be coded as zero".

But advertising max LSP bandwidth = 0 means discarding such link in the path computation process.

- Bandwidth advertisement: in the -04 version of our draft the bandwidth is advertised as follows:

    - Unreserved bandwidth for fixed container in number of containers
    - Unreserved bandwidth for oduflex in Bytes/sec
    - Max LSP bandwidth in Bytes/sec.

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

BR

The authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: venerdì 15 ottobre 2010 19.13
To: Ong, Lyndon; [email-masked]
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Lyndon,

Thanks
Rajan

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Thursday, October 14, 2010 7:45 AM
To: Rajan Rao; [email-masked]
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Rajan,

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

Thanks,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: Wednesday, October 13, 2010 2:40 PM
To: [email-masked]
Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted:

Hi,

thanks
Authors

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Wednesday, October 13, 2010 2:30 PM
To: Rajan Rao
Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan
Subject: New Version Notification for

Abstract:

The IETF Secretariat.

---

From: Rajan Rao <[email-masked]>
Date: Mon, 25 Oct 2010 16:13:16 -0700

Daniele,

Please see response inline, within { }.

Thanks

Rajan

-----Original Message-----

From: Daniele Ceccarelli [mailto:[email-masked]]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; [email-masked]

Hi Rajan,

[Rajan]  {

Agree there is no ODU advertisement defined. The need to address backwards compatibility depends on the following:

 1) are there RFC-4328 based deployments?

 2) If so, what do they use for BW advertisement?

Our fair guess is that ISCD is used for this as per RFC 4202/4203.

There are 2 ways to address the compatibility issue - either support or don't support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please refer to attached slides for details.

}

[Rajan]  {

The unit here is in Bytes/sec. The description above (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertising node.

}

Moreover it states:

[Rajan] {

Good question & very valid. I think you are bringing up a scenario where ODUflex is not supported but backward compatibility is required.

What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

}

[Rajan] {

We believe advertising the number of containers is the right approach. This is exactly the proposal we have in our draft. Good to see that you have moved away from TS approach which had serious limitations.

}

[Rajan] {

 The ODUflex uses bytes/sec in our draft.  There is no disagreement here.

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 26 Oct 2010 20:10:32 +0800

Hi Rajan,

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications.

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth. Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function to understand that it can support ODU0 LSP. Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. Fourth, it can not differentiate termination and swiching capability for your darft.

I am trying to recall more reasons why we need to use a new sub-TLV rather than the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~

Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: Rajan Rao 
  To: Daniele Ceccarelli 
  Cc: Ong, Lyndon ; [email-masked] 
  Sent: Tuesday, October 26, 2010 7:13 AM
  Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

  Daniele,

  Thanks

  Rajan

  -----Original Message-----

  To: Rajan Rao

  Hi Rajan,

   

  [Rajan]  { 

  }

  [Rajan]  { 

  }

  Moreover it states:

  [Rajan] {

  }

  [Rajan] {

  }

  [Rajan] {

  } 

  BR

  The authors

  -----Original Message-----

  Lyndon,

  Thanks

  Rajan

  -----Original Message-----

  Hi Rajan,

  Thanks,

  Lyndon

  -----Original Message-----

  To: [email-masked]

  Hi,

  thanks

  Authors

  -----Original Message-----

  To: Rajan Rao

   

  Revision:   01

  Number_of_pages: 20

  Abstract:

   

  The IETF Secretariat.

  CCAMP mailing list

  [email-masked]

  CCAMP mailing list

  [email-masked]

------------------------------------------------------------------------------

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 26 Oct 2010 14:28:12 +0200

Hi all,

we concur with all Fatai pointed out with one more addon : the change in the semantic of Minimum LSP BW open also the door to the question of which "Nominal " OPU Tributary Slot should be chose in case of bundling .

Best Regards

Sergio and Pietro

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 Fatai Zhang
Inviato: martedì 26 ottobre 2010 14.11
A: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; [email-masked]
Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Rajan,

Best Regards

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Cc: Ong, Lyndon; [email-masked]<mailto:[email-masked]>

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

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

---

From: Rajan Rao <[email-masked]>
Date: Tue, 26 Oct 2010 12:14:55 -0700

Fatai,

Please see response inline, within { }

Thanks
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Tuesday, October 26, 2010 5:11 AM
To: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; [email-masked]
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Rajan,

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth.
{Rajan] {
Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:
 With  backward compatibility option, the ODUflex goes in to a separate sub-TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't become zero.

Please clarify if you have a different case in mind.
}

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function to understand that it can support ODU0 LSP.
[Rajan] {
No, we have not changed the meaning of "Minimum LSP BW".   Please elaborate on what is messed.
Following RFC 4202/4201 meaning, the example you have listed works as follows:

MinLSP-BW = ODU1  ( G.709-v1 supports 2.5G)
MaxLSP-BW = ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

If you are computing path for an ODU0 connection, the rule would be

Odu0-LSP-BW >= MinLSP-BW && <= MaxLSP-BW

The computation fails for the above.   Where is it messed? Please provide a concrete example.
}

Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective.
[Rajan] {
The whole idea is to stay with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original GMPLS model.
}

Fourth, it can not differentiate termination and swiching capability for your darft.
 [Rajan] {
We do not see a need to advertise this info.  We need to understand the use cases requiring this.  Are T/S bits addressing HW limitations?
}

I am trying to recall more reasons why we need to use a new sub-TLV rather than the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~
 [Rajan] {
Please list the justifications for changing original GMPLS model.
}
Best Regards

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Ashok Kunjidhapatham <[email-masked]>
Date: Wed, 27 Oct 2010 03:57:14 -0700

Hi Sergio,

For bundle case, the OPU TS rate of the component link/odu container used for encoding Max-Lsp-Bw should be coded in Min-Lsp-Bw.  Basically Min-Lsp-Bw and Max-Lsp-Bw pertain to the same component link.

Thanks,
Ashok

From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, October 26, 2010 5:58 PM
To: Fatai Zhang; Rajan Rao
Cc: Ong, Lyndon; [email-masked]
Subject: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi all,

Best Regards

Sergio and Pietro

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

Hi Rajan,

Best Regards

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 28 Oct 2010 10:30:30 +0200

Hello all,

some considerations.

1) Draft Ashok states that

                                                 Max LSP Bandwidth

      Number of OPU TSs =      -------------------------

                                                  Min LSP Bandwidth

This means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.
So it can have only two values 1.25 and 2.5 Gbit/s.
The min LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)

With the above relationship it seems that a NE that supporting ODU1 and higher rate containers
and exporting interfaces with TS size = 1.25 Gbit/s should always declare a Min LSP Bandwidth = to 1.25Gbit/s
that is not corresponding to a supported switching capability.

This behavior is absolutely independent from the fact that ODU-flex is supported or not.

2)      Snip:

"Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:
 With  backward compatibility option, the ODUflex goes in to a separate sub-TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't become zero."

We would like first to observe that the ashok draft does not report this specific behavior. Secondary
we would make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently
when the ODU-flex capacity is exhausted.
If you think to a bundle link with ODU-flex capacity, then when
UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain way whereas when the ODU-flex capacity is exhausted the
ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is different.
we do not see a reason that motivates the introduction of this kind of complication in routing.

3)      Snip:

The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only
reference for requirements that have to be supported. Moreover, as required by CCAMP chair an example of the difference in efficiency between the original IETF format
and the new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.

4)      Differentiation between termination and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator
to engineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix.
Of course this can be overcome with very costly muxponder boards that by the way could have limitations related to which containers can be terminated and which can be
only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing)
in order to operate the network. As a consequence the routing specification must provide the means to allow manage the current technology indicating clearly which are the capabilities of each interface in terms of terminations and switching.

Pietro & Sergio

============================================
Pietro Vittorio Grandi
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: martedì 26 ottobre 2010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Oct 2010 08:26:18 -0400

Pietro,

I have a general comment, not on the specific drafts being discussed: I 
read your main and am left with the impression that you think that we 
need not make any attempt to leverage, to the maximum extent possible, 
what is already present in GMPLS.  I don't believe this is the case, nor 
what the WG has agreed to.

As has been said before, by the WG charter, the chairs and others, it is 
the mandate of CCAMP to developed "common" solutions wherever possible, 
not technology specific ones.  As we covered in Maastrict, see 
http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , the WG 
is still in the earlier stages of defining a GMPLS-based solution for OTN.

It seems to me, that this thread is really part of the "how information 
is to be communicated" discussion identified in slide 3 (of 
ccamp-28.htm).  Such discussions are an important step in the 
standardization cycle, and it's good that discussions on reuse are 
underway and continue.

But, please keep in mind that once there is agreement on requirements 
and information to be communicated,  we can then decided how to 
communicate the information and agree on how we "Maximizing reuse of 
existing mechanisms".  Maximizing reuse is an important optimization and 
generalization step in the CCAMP standardization cycle.  (as has been 
done before for each of technologies supported by GMPLS.)

The WG has not yet decided on how existing mechanisms are to be reused 
and what technology-specific objects are to be introduced. So please 
don't cut short any discussion on re-use.

Much thanks,
Lou

PS Again, this is not an endorsement of any specific draft or proposal.

On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote:
> 3) Snip:
>
> Thirdly, it can not support priority flexibility, so it is not efficient
> from the routing scalability perspective.
>
> [Rajan] {
>
> The whole idea is to stay with the GMPLS architecture already in place.
> The technology specific extensions should go into SCSI. This has been
> done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do
> not see a reason to deviation from the original GMPLS model.
>
> }
>
> The original idea for GMPLS has been already discussed in the frame work
> document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only
>
> reference for requirements that have to be supported. Moreover, as
> required by CCAMP chair an example of the difference in efficiency
> between the original IETF format
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 28 Oct 2010 15:02:23 +0200

Hi Lou,

I can take the action to answer your e-mail since I shared with him the content of Pietro's mail.
It seems to me our intention was exactly in the opposite direction of what you interpreted. 
We do not touch "how to communicate" but we just referenced requirements and information needed to accomplish them. 
We did not discuss about the format to communicate priority flexibility but just remind requirement for that and why the need to have it was already discussed and contained in two regular document one dealing with requirement and the other one related to information to be communicated (not how) . 
This seems completely in line with the path indicated in the slides your referenced. 
It was not absolutely in our intention jump directly to " decide on how existing mechanisms are to be reused 
and what technology-specific objects are to be introduced" 

On the other hand I think it is correct to highlight when some drafts trying to propose format without taking into account requirement already discussed.

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: giovedì 28 ottobre 2010 14.26
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: Rajan Rao; [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]
Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Pietro,

Much thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 28 Oct 2010 15:53:13 +0200

Hello Lou,

I concur with Sergio's answer.

Pietro

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: giovedì 28 ottobre 2010 14.26
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: Rajan Rao; [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Pietro,

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Oct 2010 14:43:25 -0400

Sergio,
	I think talking solutions is just fine.  I was really reacting to "The 
framework is the only reference for requirements that have to be 
supported".  It's not clear to me that the framework is (a) fully agreed 
upon, or (b) that it captures, or should even capture, all CCAMP 
requirements.  It certainly should capture all technology-specific 
requirements.  (Also, if the requirements end-up reading "don't use 
common mechanisms" then I personally think something is probably broken 
from a CCAMP perspective.)

If you feel a point has been previously covered on the list, you 
certainly can take advantage of the list archive and point to where the 
point was discussed.

Lou

---

From: Rajan Rao <[email-masked]>
Date: Thu, 28 Oct 2010 12:35:53 -0700

Pietro,

Starting a separate chain for Termination and Switching flags.  These flags are very confusing and seems H/W centric.  We will address your other questions in a separate email.

The framework doc has this requirement in section 5.3 & I think this has led to T/S flags.
"Support for differentiating between link multiplexing capacity and
      link rate capacity"

Our interpretation of the above requirement is as follows. Please correct/expand if this is not the case:

1.       A given ODU service can consume full ODUk or an ODUj based on line rate "k".

2.       In case of ODUj, it can be anywhere in the muxing hierarchy depending on the mux layers supported on the link.

3.       The routing extensions should allow path computation on Te-links with varying muxing hierarchy.

Since we are all agreeing on advertising #ODUs,  the above requirement is automatically taken care. This is because,  when we advertise ODU0, ODU1, ODU2 bandwidth for an OTU3 link it does mean that interface is capable of terminating ODU3, ODU2 and ODU1.  We do not see a need to explicitly convey this ("Termination") information in LSAs.

Questions:

1.       Where is the need to advertise Termination for the above?

2.       By advertising #ODUs, we are saying it is switchable & any HO-ODUs are definitely terminate-able.  If so, where is the need to advertise "Switching" flag?

Thanks
Rajan

From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:[email-masked]]
Sent: Thursday, October 28, 2010 1:31 AM
To: Rajan Rao
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hello all,

some considerations.

                                                 Max LSP Bandwidth

                                                  Min LSP Bandwidth

2)    Snip:

3)    Snip:

Pietro & Sergio

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: John E Drake <[email-masked]>
Date: Thu, 28 Oct 2010 14:53:02 -0700

Pietro,

These fields were not in the predecessor to this I-D, so I am a bit curious why they were added?

With the new bandwidth allocation TLV, I thought we are only advertising  the client service types available on a given TE link, and not on any of the underlying hardware details.  So in that context, what is the purpose of these fields?   E.g., switching is more or less by definition.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: Thursday, October 28, 2010 12:36 PM
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags

Pietro,

Questions:

Thanks
Rajan

Hello all,

some considerations.

                                                 Max LSP Bandwidth

                                                  Min LSP Bandwidth

2)  Snip:

3)  Snip:

Pietro & Sergio

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Rajan Rao <[email-masked]>
Date: Thu, 28 Oct 2010 17:45:11 -0700

Pietro, et al

Please see response inline

Thanks
Rajan

Hello all,

some considerations.

                                                 Max LSP Bandwidth

                                                  Min LSP Bandwidth

This means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.
So it can have only two values 1.25 and 2.5 Gbit/s.
[Rajan] {
Yes. This is correct.  But the exact value is nominal rate depending on the ODU layer involved.
}
The min LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)
[Rajan] {
 We have only 2 TS variants defined for (Switching-Capability=TDM &&  Encoding=ODUk ). Not sure what the comment is about.
}

With the above relationship it seems that a NE that supporting ODU1 and higher rate containers
and exporting interfaces with TS size = 1.25 Gbit/s should always declare a Min LSP Bandwidth = to 1.25Gbit/s
that is not corresponding to a supported switching capability.
[Rajan] {
This is not true.  A link which is G.709-v1 based will advertise Min-LSP-BW=2.5G (ODU1 rate) not 1.25G (ODU0 rate). Please ref to ODU0 example in the previous chain.
}

2)    Snip:

[Rajan] {
The ODUflex confusion may be due to lack of details from us.  In the ppt sent earlier we mentioned about how to handle backward compatibility & ODUflex.  The minor modifications are captured in our draft-02 version (section 5.4.2).  Please review and let us know if there are still any issues.
http://www.infinera.com/rfc/draft-ashok-ccamp-gmpls-ospf-g709-02.txt

}

3)    Snip:

The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only
reference for requirements that have to be supported. Moreover, as required by CCAMP chair an example of the difference in efficiency between the original IETF format
and the new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.
[Rajan] {
We have shown in our draft that we can take care of OTN extensions in SCSI.  It doesn't make sense to have two ISCDs (ISCD+BA) for the same switching type (=TDM). Unnecessary.
}

 Responded in a separate chain on why we do not need T/S flags.
}

Pietro & Sergio

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 29 Oct 2010 10:13:22 +0200

Hello Rao,

see in line.

Pietro

________________________________
From: Rajan Rao [mailto:[email-masked]]
Sent: giovedì 28 ottobre 2010 21.36
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]; Fatai Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags

Pietro,

[[PG]]  It is no so. A  line card can terminate e.g. an OTU-3 and not terminate ODU-2, ODU-1 and ODU-0

[[PG]] Moreover the assumption you make are not even valid for muxponder boards. Just make an example of a muxponder board that demuxes ODU3-ODU2-ODU1.

These kind of boards would cost less if engineered in such a way that ODU-3 (and may be also ODU2) cannot be passed to the matrix.

Questions:

2.       By advertising #ODUs, we are saying it is switchable & any HO-ODUs are definitely terminate-able.

[[PG]] I'll answer with an example: suppose that in a bundle link there are both OTU-3 and OTU-4.
In this case part of the ODU-3 resources are only switchable (the one carried by ODU-4) and part are terminated or switchable (the ODU-3 resources carried by the OTU-3).

If advertising does not distinguish between terminated and switchable resources a misuse is possible due to the fact that on end points the matrix is able to switch one layer

and not two.

Suppose that on an endpoint there is  the need to switch an ODU-2 path carried by an ODU-3 path. This is possible if the ODU-3 path is terminated on a line card, the ODU 2 is extracted on the line card and sent to matrix for switching.

When setting up the ODU-3 path that will  carry the ODU-2 path, care must be taken to ensure that on the end node of the ODU-3 path  an ODU-3 that is terminated

is used.  If a non terminated ODU-3 is used, like ODU3- carried by an OTU-4, what happens is that the line card terminates the ODU-4 and is not able to extract the ODU-2 that is not directly visible because transported in an ODU-3.

 If so, where is the need to advertise "Switching" flag?

[[PG]] Please see before.

Thanks
Rajan

Hello all,

some considerations.

                                                 Max LSP Bandwidth

                                                  Min LSP Bandwidth

2)      Snip:

3)      Snip:

Pietro & Sergio

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 29 Oct 2010 11:20:07 +0200

Hello
in line and in RED to differentiate from previous statements..

Pietro

________________________________
From: Rajan Rao [mailto:[email-masked]]
Sent: venerdì 29 ottobre 2010 2.45
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Fatai Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve); Biao Lu; Ashok Kunjidhapatham
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Pietro, et al

Thanks
Rajan

Hello all,

some considerations.

                                                 Max LSP Bandwidth

                                                  Min LSP Bandwidth

This means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.
So it can have only two values 1.25 and 2.5 Gbit/s.
[Rajan] {
Yes. This is correct.  But the exact value is nominal rate depending on the ODU layer involved.
}
The min LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)
[Rajan] {
 We have only 2 TS variants defined for (Switching-Capability=TDM &&  Encoding=ODUk ). Not sure what the comment is about.
}
[[PG]] The comment is about the fact that Min LSP bandwidth by RFC4202 has to report the bandwidth associated to a switchable container.
By G.709 Tributary Slots  are not switchable containers, they are just a way to partition bandwidth available on a link in such a way
to have max flexibility.  Their scope is limited to the link and are never sent to the matrix. While nominal speed of the Tributary slots is dependent from the server (e.g. ODU-3 TS has different size from ODU-2 TS), the ODU speed is always the same independently from the server.  This has to be the reference for min LSP.
}

With the above relationship it seems that a NE that supporting ODU1 and higher rate containers
and exporting interfaces with TS size = 1.25 Gbit/s should always declare a Min LSP Bandwidth = to 1.25Gbit/s
that is not corresponding to a supported switching capability.
[Rajan] {
This is not true.  A link which is G.709-v1 based will advertise Min-LSP-BW=2.5G (ODU1 rate) not 1.25G (ODU0 rate). Please ref to ODU0 example in the previous chain.
[[PG]] I do not understand why you say so. The draft does not report that the relation is limited to G.709v1 interfaces. What I say happens
always when a matrix does not support ODU0 switching.  Again, the tributary slot size  by G.709 definition is not switched in matrix, and it has not to be considered as the equivalent of the ODU-1/ODU0.
}

2)      Snip:

[Rajan] {

}

3)      Snip:

[[PG]] This is the reason why we have created an "agnostic" format .

[[PG]] Responded in a separate chain on why this is needed.

Pietro & Sergio

Fatai,

Thanks
Rajan

Hi Rajan,

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: Daniele Ceccarelli<mailto:[email-masked]>
Cc: Ong, Lyndon<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 26, 2010 7:13 AM
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Daniele,

Thanks

Rajan

-----Original Message-----

To: Rajan Rao

Hi Rajan,

[Rajan]  {

}

[Rajan]  {

}

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

}

BR

The authors

-----Original Message-----

Lyndon,

Thanks

Rajan

-----Original Message-----

Hi Rajan,

Thanks,

Lyndon

-----Original Message-----

To: [email-masked]

Hi,

thanks

Authors

-----Original Message-----

To: Rajan Rao

Revision:   01

Number_of_pages: 20

Abstract:

The IETF Secretariat.

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 29 Oct 2010 13:57:41 +0200

Hi Lou,

PMFJI but I think it is worth making a clarification.

We all know and believe that each solution must meet *both* framework requirements (technology specific ones) and CCAMP requirements (tecnohology agnostic,reuse, scalability etc). The requirements defined in the framework ID obviously do not address point (b) " it captures, or should even capture, all CCAMP requirements" but absolutely do not aim at suggesting not to use common mechanisms.

On the other hand since the framework draft can be surely improved, it just has to represent a basic starting point for the information model analysis. Any proposed technology specific format should be at least aligned with the framework content. I believe this was the intention that Pietro wanted to explain.

Than the framework requirements are analyzed in the info model draft against the CCAMP requirements. Such ID tries to explains what can be reused, what needs to be extended and what should be replaced. RFC4202/3 could be potentially extended to meet also all the framework requirements, but with evident scalability and efficiency issues (an example is carried out in Section 5 of http://tools.ietf.org/id/draft-bccdg-ccamp-gmpls-ospf-agnostic-00.txt, where non technology specific requirements, like for example priority advertisement, are considered). This is why an alternative solution is being discussed. 

Best Regards,

Daniele

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: giovedì 28 ottobre 2010 20.43
To: BELOTTI, SERGIO (SERGIO)
Cc: Rajan Rao; [email-masked]; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; [email-masked]; Daniele Ceccarelli; Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: R: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Sergio,
	I think talking solutions is just fine.  I was really reacting to "The framework is the only reference for requirements that have to be supported".  It's not clear to me that the framework is (a) fully agreed upon, or (b) that it captures, or should even capture, all CCAMP requirements.  It certainly should capture all technology-specific requirements.  (Also, if the requirements end-up reading "don't use common mechanisms" then I personally think something is probably broken from a CCAMP perspective.)

If you feel a point has been previously covered on the list, you certainly can take advantage of the list archive and point to where the point was discussed.

Lou

On 10/28/2010 9:02 AM, BELOTTI, SERGIO (SERGIO) wrote:
> It was not absolutely in our intention jump directly to " decide on 
> how existing mechanisms are to be reused and what technology-specific objects are to be introduced"
>
> I have a general comment, not on the specific drafts being discussed: 
> I read your main and am left with the impression that you think that 
> we need not make any attempt to leverage, to the maximum extent 
> possible, what is already present in GMPLS.  I don't believe this is 
> the case, nor what the WG has agreed to.
>
> As has been said before, by the WG charter, the chairs and others, it 
> is the mandate of CCAMP to developed "common" solutions wherever 
> possible, not technology specific ones.  As we covered in Maastrict, 
> see http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , 
> the WG is still in the earlier stages of defining a GMPLS-based solution for OTN.
>
> It seems to me, that this thread is really part of the "how 
> information is to be communicated" discussion identified in slide 3 
> (of ccamp-28.htm).  Such discussions are an important step in the 
> existing mechanisms".  Maximizing reuse is an important optimization 
> and generalization step in the CCAMP standardization cycle.  (as has 
> been done before for each of technologies supported by GMPLS.)
>
>> Thirdly, it can not support priority flexibility, so it is not 
>> efficient from the routing scalability perspective.
>>
>> [Rajan] {
>>
>> done successfully for SONET/SDH case (Ref to examples in RFC 4202). 
>> Do not see a reason to deviation from the original GMPLS model.
>>
>> }
>>
>> The original idea for GMPLS has been already discussed in the frame 
>> work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework 
>> is the only
>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Oct 2010 11:36:32 -0400

Daniele,
	I think we're in agreement here.  Discussion of ALL solutions at this 
point seems just right to me too.  I don't think we've reach the point 
of throwing out any specific encoding formats and this was really my 
point.  Again, my comments are general comments, and should not be taken 
as supporting or endorsing any specific proposal.

Thanks,
Lou