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

From: Rajan Rao <[email-masked]>
Date: Mon, 1 Nov 2010 10:26:55 -0700

Pietro,

On Minimum-LSP-BW:    You are correct. We fully agree on setting the BW value to lowest switchable container.   There is no issue in doing so as ODUflex BW advertisement is moved to SCSI. We will clarify this in the draft. Thanks for the correction.

On Termination/Switching:    We are not able to understand the need.  It will be helpful if you could show couple of use cases with diagrams.
Is this trying to address switch blocking scenarios?

Thanks
Rajan

From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:[email-masked]]
Sent: Friday, October 29, 2010 2:20 AM
To: Rajan Rao
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

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

Pietro

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

Please see response inline

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.

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

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.

[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:
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
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.
}
[[PG]] This is the reason why we have created an "agnostic" format .

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.
[Rajan] {
 Responded in a separate chain on why we do not need T/S flags.
}

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

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,

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,

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

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]<mailto:[email-masked]>

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

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.

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

}

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"

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

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

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

}

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

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

}

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

[Rajan] {

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

}

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,

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,

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.

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.

_______________________________________________

CCAMP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ccamp

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

---

From: [email-masked]
Date: Mon, 8 Nov 2010 18:49:01 +0800

Hi Pietro,

For your following statement, please refer to the liaison from ITU-T Q12. 
Operator do need the multi stage multiplexing. It focuses on how you 
provide the multi stage multiplexing capability in low cost. 
I don't agree that any routing extension drafts can force operator to use 
multi-stage multiplexing. But you have to provide a method to represent 
the multi-stage capability based on the deployed network.
Termination and switching capabilities could not be understood. I don't 
see any text in draft-ceccarelli-ccamp-gmpls-ospf-g709-04. Could you give 
any example about how to use it?
 
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. 

Xihua Fu

"GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
<[email-masked]> 
发件人:  [email-masked]
2010-10-28 下午 04:30

收件人
Rajan Rao <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, Snigdho Bardalai 
<[email-masked]>, "Ong, Lyndon" <[email-masked]>, Khuzema 
Pithewan <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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
 
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:
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
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
 
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
 
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: 
 
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. 
{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.

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)

 
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 
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: 
 
Daniele,

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]
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: 
 
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.

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

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

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

But advertising max LSP bandwidth = 0 means discarding such link in the 
path computation process.
 
[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.
 
}
 
- Bandwidth advertisement: in the -04 version of our draft the bandwidth 
is advertised as follows:

[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.
 
}
 
Advertising the unreserved bandwidth in number of containers is the most 
suitable way for fixed containers (ODUk) but doesn't work with ODUflex.
 
[Rajan] {

} 
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,
 
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:

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

 
Abstract:

 
 
The IETF Secretariat.

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Mon, 8 Nov 2010 12:15:36 +0100

Hello Fu Xihua,

the intention of the statement was not to say that multi-stage multiplexing has not to be dealt by the routing solution draft.
On the contrary the intention was to say that any operator has to be allowed to engineer its own network
keeping into account current technology limitations without the need to introduce multi-stage multiplexing
where it is not needed.
With this respect a routing solution must offer the possibility to engineer a network that  is free from multi-stage multiplexing as
well as a network that uses multi-stage multiplexing where needed.
At the end of the day this will leave to any operator a full freedom on how to engineer its own network.
We believe with this respect that advertising termination and switching capabilities is part of the solution to the problem
allowing us to deal at least with current technology limitations. As far as multi-stage multiplexing is concerned, you will notice
that currently all drafts contain only placeholders.
This is mainly due to the fact that ITU-T has not yet fully understood how to manage multi-stage multiplexing from a networking point of view.
Given the complexity of multi-stage multiplexing having a clear understanding of limitations and cases of usage can help in simplifying a lot
also IETF modeling.

About information on termination and switching capabilities you should refer to draft draft-bccg-ccamp-otn-ospf-info-model.
An example of usage will also be showed in our presentation to IETF.

Pietro & Sergio

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: lunedì 8 novembre 2010 11.49
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: [email-masked]; [email-masked]; [email-masked]; Khuzema Pithewan; Ong, Lyndon; Rajan Rao; Snigdho Bardalai
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Pietro,

For your following statement, please refer to the liaison from ITU-T Q12. Operator do need the multi stage multiplexing. It focuses on how you provide the multi stage multiplexing capability in low cost.
I don't agree that any routing extension drafts can force operator to use multi-stage multiplexing. But you have to provide a method to represent the multi-stage capability based on the deployed network.
Termination and switching capabilities could not be understood. I don't see any text in draft-ceccarelli-ccamp-gmpls-ospf-g709-04. Could you give any example about how to use it?

Xihua Fu

"GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
发件人:  [email-masked]

2010-10-28 下午 04:30

收件人

抄送

"[email-masked]" <[email-masked]>, Snigdho Bardalai <[email-masked]>, "Ong, Lyndon" <[email-masked]>, Khuzema Pithewan <[email-masked]>, "[email-masked]" <[email-masked]>

主题

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:

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

3)      Snip:

Pietro & Sergio

Fatai,

Thanks
Rajan

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.

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:

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-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, October 22, 2010 6:49 AM
To: Rajan Rao
Cc: Ong, Lyndon; [email-masked]<mailto:[email-masked]>
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Rajan,

[Rajan]  {

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

Moreover it states:

[Rajan] {

}

[Rajan] {

}

[Rajan] {

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

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.

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

---

From: [email-masked]
Date: Mon, 8 Nov 2010 19:35:47 +0800

Hi Pietro,

We should not say "ITU-T has not yet fully understood how to manage 
multi-stage multiplexing from a networking point of view".
Multi-stage multiplexing is not a common use case and requirement. It 
always happens within "Gateway node" (I know we don't like this 
terminology).
So I hope any clarification from your presentation. 

Xihua Fu

2010-11-08 下午 07:15

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
Khuzema Pithewan <[email-masked]>, "Ong, Lyndon" 
<[email-masked]>, Rajan Rao <[email-masked]>, Snigdho Bardalai 
<[email-masked]>, "BELOTTI, SERGIO (SERGIO)" 
<[email-masked]>, Daniele Ceccarelli 
<[email-masked]>, "Varma, Eve L (Eve)" 
<[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO 
VITTORIO)" <[email-masked]>
主题
RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: 
draft-ashok-ccamp-gmpls-ospf-g709-01

Hello Fu Xihua,
 
the intention of the statement was not to say that multi-stage 
multiplexing has not to be dealt by the routing solution draft.
On the contrary the intention was to say that any operator has to be 
allowed to engineer its own network 
keeping into account current technology limitations without the need to 
introduce multi-stage multiplexing
where it is not needed. 
With this respect a routing solution must offer the possibility to 
engineer a network that  is free from multi-stage multiplexing as
well as a network that uses multi-stage multiplexing where needed. 
At the end of the day this will leave to any operator a full freedom on 
how to engineer its own network.
We believe with this respect that advertising termination and switching 
capabilities is part of the solution to the problem
allowing us to deal at least with current technology limitations. As far 
as multi-stage multiplexing is concerned, you will notice
that currently all drafts contain only placeholders. 
This is mainly due to the fact that ITU-T has not yet fully understood how 
to manage multi-stage multiplexing from a networking point of view.
Given the complexity of multi-stage multiplexing having a clear 
understanding of limitations and cases of usage can help in simplifying a 
lot
also IETF modeling.
 
About information on termination and switching capabilities you should 
refer to draft draft-bccg-ccamp-otn-ospf-info-model.
An example of usage will also be showed in our presentation to IETF.
 
Pietro & Sergio

From: [email-masked] [mailto:[email-masked]] 
Sent: lunedì 8 novembre 2010 11.49
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: [email-masked]; [email-masked]; [email-masked]; Khuzema 
Pithewan; Ong, Lyndon; Rajan Rao; Snigdho Bardalai
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: 
draft-ashok-ccamp-gmpls-ospf-g709-01

Hi Pietro, 

Xihua Fu 

收件人

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 
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: 
  
Daniele, 

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] 
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: 
  
Hi Rajan, 

[Rajan]  { 

  
  
} 

  
[Rajan]  { 

Moreover it states: 

  
[Rajan] { 

} 

  
[Rajan] { 
  
} 

[Rajan] { 

} 
BR 
  
The authors 
  
-----Original Message----- 
  
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: 
  
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.