Subject: Re: [CCAMP] OSPF OTN drafts merged

From: [email-masked]
Date: Tue, 5 Jul 2011 16:25:56 +0800

Hi  Daniele,

Thank you for your hard work in OTN routing.
A few comments.
1. In the "Abstract" section, you wrote "... in support of both sub-lambda 
and lambda level  routing granularity."  I don’t think this document is 
related to lambda level routing.
2. In the 5.2 section, ODUflex could have switching capability. S bits 
should be 1.
3. In the 5.3 section, you should value the T and S bit. If ODU4 have both 
switching and termination capability, you may give two blocks to describe 
it.
4. In the 5.4 section, it is also suggested you should value T and S bit, 
otherwise these example could not clearly reflect the SCSI encoding.
5. In the 5.5 section,  ODU0 should be mapped into ODU3, then ODU4. 

Xihua Fu

Daniele Ceccarelli <[email-masked]> 
发件人:  [email-masked]
2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
[CCAMP] OSPF OTN drafts merged

Hi CCAMPers,
 
As promised during the IETF meeting in Prague the authors of the two 
competing drafts on OSPF-TE routing extensions for OTN have been working 
together and a merged document has been produced.
 
You can find the merged ID at the following link:
 
http://tools.ietf.org/id/draft-ceccarelli-ccamp-gmpls-ospf-g709-06.txt 
 
Comments and feedback are appreciated
 
Thanks,
The authors

DANIELE CECCARELLI 
System & Technology - DU IP & Broadband 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750
[email-masked]
www.ericsson.com 

This Communication is Confidential. We only send and receive email on the 
basis of the term set out at www.ericsson.com/email_disclaimer 
 
 _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Wed, 6 Jul 2011 19:36:49 +0800

Hi Daniele,

One more comment.
In section "4.  ISCD format extensions",  it write:
"The MAX LSP bandwidth field is used accordingly to RFC4204: i.e. 0 <=
  Max LSP Bandwidth <= ODUk/OTUk and intermediate values are those on
  the branch of OTN switching hierarchy supported by the interface.
  E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP
  Bandwidth for some priorities, ODU3 for others, ODU2 for some others 
etc. 
"
In my understanding, there is no any standardized principle about how to 
value this unit.
It doesn't make any sense to path computation entity. It has to rely on 
SCSI information.
Is that right?

Xihua

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

 

Thanks,
The authors

DANIELE CECCARELLI 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Jul 2011 11:40:54 +0200

Hi Xihua,

thanks for your review.

Please find answers inline.

BR
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: martedì 5 luglio 2011 10.26
To: Daniele Ceccarelli
Cc: 'CCAMP'
Subject: Re: [CCAMP] OSPF OTN drafts merged

Hi  Daniele,

Thank you for your hard work in OTN routing.
A few comments.
1. In the "Abstract" section, you wrote "... in support of both sub-lambda and lambda level  routing granularity."  I don’t think this document is related to lambda level routing.
[DC] - Lambda stands for the bottom most ODU layer, while sub lambdas are the lower order ODUs muxed in it. If for example an OTU3 link is being advertised with ODU2 and ODU0 capabilities, the ODU3 is the lambda, while ODU0 and ODU2 the sub lambdas.
2. In the 5.2 section, ODUflex could have switching capability. S bits should be 1.
[DC] - In section 5.2 T and S bits are not taken into account, they could be 0 or 1. The example just wants to show the utilization of the F bit.
3. In the 5.3 section, you should value the T and S bit. If ODU4 have both switching and termination capability, you may give two blocks to describe it.
4. In the 5.4 section, it is also suggested you should value T and S bit, otherwise these example could not clearly reflect the SCSI encoding.
[DC] - Also section 5.3 and 5.4 don't aim at explaining the utilization of the T and S bits. Their explanation is limited to section 5.1 and no more discussed in the following examples as other features are being shown. If you think it might be worth, we could add a further example, maybe quite complicated, so to try and summarize everything into a single example.
5. In the 5.5 section,  ODU0 should be mapped into ODU3, then ODU4.
[DC] - You're right, it's a typo, i'll fix it.
Xihua Fu

2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

As promised during the IETF meeting in Prague the authors of the two competing drafts on OSPF-TE routing extensions for OTN have been working together and a merged document has been produced.

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

<http://www.ericsson.com/>

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Jul 2011 12:14:48 +0200

Hi Xihua,

for sure RFC4204 is not correct, given that it is about LMP :-)

The draft defines a guideline on how to fill those fields. RFC 4203 states that:

   Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in
   the IEEE floating point format [IEEE<http://tools.ietf.org/html/rfc4203#ref-IEEE>], with priority 0 first and
   priority 7 last.  The units are bytes (not bits!) per second.

and the MAX LSP field must be filled accordingly. Given that the OTN has a complex hierarchy, the max LSP bandwidth is equal to the "biggest" available container of the hierarchy. Moreover at different priorities can correspond different MAX LSP bandwidth availabilities.

You're rigth when saying that this information is not enough for the PCE and the SCSI must be used.

Thanks,
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: mercoledì 6 luglio 2011 13.37
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; [email-masked]
Subject: Re: [CCAMP] OSPF OTN drafts merged

Hi Daniele,

One more comment.
In section "4.  ISCD format extensions",  it write:
"The MAX LSP bandwidth field is used accordingly to RFC4204: i.e. 0 <=
  Max LSP Bandwidth <= ODUk/OTUk and intermediate values are those on
  the branch of OTN switching hierarchy supported by the interface.
  E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP
  Bandwidth for some priorities, ODU3 for others, ODU2 for some others etc.
"
In my understanding, there is no any standardized principle about how to value this unit.
It doesn't make any sense to path computation entity. It has to rely on SCSI information.
Is that right?

Xihua

2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: [email-masked]
Date: Thu, 7 Jul 2011 19:00:35 +0800

HiDaniele,

Thank you for your clarification.
We know how Maximum LSP Bandwidth is standardized except this draft. 
If it doesn't make any sense to path computation, it doesn't matter with 
how to standardize it in this draft.

Xihua

2011-07-07 下午 06:14

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [CCAMP] OSPF OTN drafts merged

Hi Xihua,

The draft defines a guideline on how to fill those fields. RFC 4203 states 
that:
 
   Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in
   the IEEE floating point format [IEEE], with priority 0 first and
   priority 7 last.  The units are bytes (not bits!) per second.
 
and the MAX LSP field must be filled accordingly. Given that the OTN has a 
complex hierarchy, the max LSP bandwidth is equal to the "biggest" 
available container of the hierarchy. Moreover at different priorities can 
correspond different MAX LSP bandwidth availabilities.
 
You're rigth when saying that this information is not enough for the PCE 
and the SCSI must be used.
 
Thanks,
Daniele

Hi Daniele, 

One more comment. 

Xihua 

收件人
'CCAMP' <[email-masked]> 
抄送

Hi CCAMPers, 

  

Thanks, 
The authors 

DANIELE CECCARELLI 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Jul 2011 15:18:47 +0200

Hi Xihua,

in the end this message is an ISCD, so we must keep the same format and same values. The MAX LSP bandwidth is present and must be filled as defined in RFC4203 (as written in the draft). Given that RFC 4203 just says few words on "how to fill" that field, we just added few words to say it explicitely.
What's your suggestion?

Thanks
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: giovedì 7 luglio 2011 13.01
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; [email-masked]
Subject: Re: RE: [CCAMP] OSPF OTN drafts merged

HiDaniele,

Thank you for your clarification.
We know how Maximum LSP Bandwidth is standardized except this draft.
If it doesn't make any sense to path computation, it doesn't matter with how to standardize it in this draft.

Xihua

2011-07-07 下午 06:14

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [CCAMP] OSPF OTN drafts merged

Hi Xihua,

Thanks,
Daniele

Hi Daniele,

One more comment.

Xihua

2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: [email-masked]
Date: Thu, 7 Jul 2011 21:32:38 +0800

Hi Daniele,

How about adding following sentence into draft?

"If Encoding Type is G.709 ODUk (Digital Path) , information in MAX LSP 
bandwidth block is not enough for the patch computation. The SCSI must be 
used. Implementation must not rely on MAX LSP bandwidth block"

Xihua

2011-07-07 下午 09:18

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: RE: [CCAMP] OSPF OTN drafts merged

Hi Xihua,
 
in the end this message is an ISCD, so we must keep the same format and 
same values. The MAX LSP bandwidth is present and must be filled as 
defined in RFC4203 (as written in the draft). Given that RFC 4203 just 
says few words on "how to fill" that field, we just added few words to say 
it explicitely.
What's your suggestion?
 
Thanks
Daniele

HiDaniele, 

Xihua 

收件人

Hi Xihua, 

  

  
Thanks, 
Daniele 

Hi Daniele, 

One more comment. 

" 

Xihua 

收件人
'CCAMP' <[email-masked]> 
抄送

Hi CCAMPers, 

 

Thanks, 
The authors 

DANIELE CECCARELLI 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Jul 2011 15:40:18 +0200

Xihua,

given that the SCSI is mandatory and not optional, the info in the MAX LSP bandwdith fields is implicitely not enough for the path computation :-)

Thanks
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: giovedì 7 luglio 2011 15.33
To: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]; [email-masked]
Subject: RE: RE: [CCAMP] OSPF OTN drafts merged

Hi Daniele,

"If Encoding Type is G.709 ODUk (Digital Path) , information in MAX LSP bandwidth block is not enough for the patch computation. The SCSI must be used. Implementation must not rely on MAX LSP bandwidth block"

Xihua

2011-07-07 下午 09:18

收件人

Hi Xihua,

Thanks
Daniele

HiDaniele,

Xihua

2011-07-07 下午 06:14

收件人

Hi Xihua,

Thanks,
Daniele

Hi Daniele,

One more comment.

Xihua

2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: [email-masked]
Date: Thu, 7 Jul 2011 22:24:57 +0800

Hi Daniele,

One more question.
"
   The ISCD includes a variable number of SCSI TLVs as described in the
   following sections.  A single ISCD TLV MAY be used for the
   advertisement of unbundled or bundled links also with different
   server layers.  A different SCSI TLV MUST be used for each different
   muxing hierarchy (muxing tree in the following examples).
"
There two links among A, B and C. One link #1 supports ODU0-ODU2-ODU3. 
Another link #2 supports ODU0-ODU2-ODU4.
                             0/2/4                   4/2/0
                                     |                           B       | 
 
o---------------o  X  o--------------o  X  o--------------o  X 
o----------------o
                          A       o--------------o  X  o--------------o C  
 
                                     |                       |
                              0/2/3                   3/2/0

Although we could bundle them together, there must be two SCSIs to 
represent different hierarchy. What benefit I could see is there is just 
one block for Max LSP bandwidth, SC, ET and so on.

Another usecase is that if we create two ODU 2 FA-LSP over link #1 and 
link #2 and make them as a TE Link, we could bundle them together based on 
the current OSPF extension in this draft.
In my opion, we could use one SCSI to represent ODU2 bundle link.

Xihua 

2011-07-07 下午 09:40

收件人

Xihua,
 
given that the SCSI is mandatory and not optional, the info in the MAX LSP 
bandwdith fields is implicitely not enough for the path computation :-)
 
Thanks
Daniele

Hi Daniele, 

Xihua 

收件人

Hi Xihua, 

Thanks 
Daniele 

HiDaniele, 

Xihua 

收件人

Hi Xihua, 

 

 
Thanks, 
Daniele 

Hi Daniele, 

One more comment. 

Xihua 

收件人
'CCAMP' <[email-masked]> 
抄送

Hi CCAMPers, 

Thanks, 
The authors 

DANIELE CECCARELLI 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 12 Jul 2011 12:25:11 +0200

Hi Xihua,

the case you are considering is a quite a simple scenario and there would be no issue in having the two hierarchies adverties into the same SCSI, but there are some "unlucky" cases in which bundling component links with dissimilar hierarchies could cause ambiguities.
Let's try to analize one of them. Suppose to have the following hierarchies supported (quite similar to the one present in the -06 version of the draft)

Component Link#1      Component Link#2
         ODU0                  ODU0
          |                     |
         ODU3                  ODU3
          |                     |
         ODU4                  ODU4

We said that the advertisement of intermediate layers bandwidth is required in order to know how many FA can be set up. In this case, the advertisement of both
ODU0->ODU3->ODU4 and
ODU3->ODU4
available bandwidth is performed so to know how many ODU3 FA can be setup. In the case above it is possible to advertise the 2 component links into the same SCSI.
On the other side, if you have to bundle the 3 component links in the following, there could be an ambiguity:

Component Link#1      Component Link#2     Component Link#3
         ODU0                  ODU0
          |                     |                  ODU3
         ODU3                  ODU3                 |
          |                     |                  ODU4
         ODU4                  ODU4

Merging all the component links into the same SCSI would cause this type of advertisement:

ODU0->ODU3->ODU4 and
ODU3->ODU4

But in this case it is not possible to know how many ODU3->ODU4 are availalbe for ODU3 FA set up (i.e. belonging to the ODU0->ODU3->ODU4 hierarchy) and how many simple ODU3 cannot be used for ODU0 transport (i.e. belonging to ODU3->ODU4 hierarchy).

This issue *does not* prevent to perform the bundling of the three component links and can be simply solved advertising component links #1 and #2 into an SCSI and component link #3 in a different one (all inside the same ISCD).

By the way thaks a lot for the question, this clarification will be introduced into the next version of the draft.

BR
Daniele

Sent: giovedì 7 luglio 2011 16.25

Hi Daniele,

One more question.
"
   The ISCD includes a variable number of SCSI TLVs as described in the
   following sections.  A single ISCD TLV MAY be used for the
   advertisement of unbundled or bundled links also with different
   server layers.  A different SCSI TLV MUST be used for each different
   muxing hierarchy (muxing tree in the following examples).
"
There two links among A, B and C. One link #1 supports ODU0-ODU2-ODU3. Another link #2 supports ODU0-ODU2-ODU4.
                             0/2/4                                                           4/2/0
                                     |                           B                            |
o---------------o  X  o--------------o  X  o--------------o  X  o----------------o
                          A       o--------------o  X  o--------------o    C
                                     |                                                           |
                              0/2/3                                                          3/2/0

Although we could bundle them together, there must be two SCSIs to represent different hierarchy. What benefit I could see is there is just one block for Max LSP bandwidth, SC, ET and so on.

Another usecase is that if we create two ODU 2 FA-LSP over link #1 and link #2 and make them as a TE Link, we could bundle them together based on the current OSPF extension in this draft.
In my opion, we could use one SCSI to represent ODU2 bundle link.

Xihua

2011-07-07 下午 09:40

收件人

Xihua,

Thanks
Daniele

Hi Daniele,

Xihua

2011-07-07 下午 09:18

收件人

Hi Xihua,

Thanks
Daniele

HiDaniele,

Xihua

2011-07-07 下午 06:14

收件人

Hi Xihua,

Thanks,
Daniele

Hi Daniele,

One more comment.

Xihua

2011-06-27 下午 09:28

收件人
'CCAMP' <[email-masked]>
抄送

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Sidd Aanand <[email-masked]>
Date: Tue, 12 Jul 2011 07:42:22 -0400

Danielle,

Regarding the MAX LSP BW field in the ISCD: While this may not be enough information to compute a path, it might be useful in pruning the tree. That is, the path computation algorithm can have the multiplexing hierarchy details and in addition store the MAX LSP BW at each priority and discard those links that have max-lsp-bw less than the bw that I am looking for.

In other words, this represents the maximum bandwidth an LSP can have on this link. This will be the maximum of all maximums in the hierarchy, right?

Thanks,
Sidd

2011-07-07 下午 09:40

收件人

抄送

主题

Xihua,

Thanks
Daniele

Hi Daniele,

Xihua

2011-07-07 下午 09:18

收件人

抄送

主题

Hi Xihua,

Thanks
Daniele

HiDaniele,

Xihua

2011-07-07 下午 06:14

收件人

抄送

主题

Hi Xihua,

Thanks,
Daniele

Hi Daniele,

One more comment.

Xihua

2011-06-27 下午 09:28

收件人

'CCAMP' <[email-masked]>

抄送

主题

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 12 Jul 2011 14:06:42 +0200

Hi Sidd,

that's correct. For sure the MAX LSP BW can be used for pruning the tree, so to apply the path computation algorithm just to the pruned tree.

Thanks,
Daniele

________________________________
From: Sidd Aanand [mailto:[email-masked]]
Sent: martedì 12 luglio 2011 13.42
To: Daniele Ceccarelli; [email-masked]
Cc: 'CCAMP'; [email-masked]
Subject: RE: [CCAMP] OSPF OTN drafts merged

Danielle,

Thanks,
Sidd

2011-07-07 下午 09:40

收件人

抄送

主题

Xihua,

Thanks
Daniele

Hi Daniele,

Xihua

2011-07-07 下午 09:18

收件人

抄送

主题

Hi Xihua,

Thanks
Daniele

HiDaniele,

Xihua

2011-07-07 下午 06:14

收件人

抄送

主题

Hi Xihua,

Thanks,
Daniele

Hi Daniele,

One more comment.

Xihua

2011-06-27 下午 09:28

收件人

'CCAMP' <[email-masked]>

抄送

主题

Hi CCAMPers,

Thanks,
The authors

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: [email-masked]
Date: Wed, 13 Jul 2011 10:36:50 +0800

Hi Daniele,

Thank you for your clarification.
I can catch the purpose of separate SCSIs for dissimilar hierarchies when 
they are bundled together.
This draft states "A single ISCD TLV MAY be used for the advertisement of 
unbundled or bundled links also with different server layers."
I think the description in this draft is accurate.
So we could bundle 0/2/3 and 0/2/4 together and use two separate SCSIs to 
represent two hierarchies.
What I am curious is after we build two ODU2 FA-LSPs over different 
hierarchies (i.e., server layers ODU3 and ODU4) and bundle both of ODU2 
FAs together, we can use only one SCSI to represent it.
Based on draft-ietf-mpls-explicit-resource-control-bundle-10, when an ODU0 
is going to over bundle link of ODU2 FA, we may have a requirement to 
explicit select a component link (i.e., ODU2 FA) which is over ODU4 server 
layer. But there isn't enough information for this requirement.

Xihua Fu

2011-07-12 下午 06:25

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, "'BELOTTI, SERGIO (SERGIO)'" 
<[email-masked]>, Fatai Zhang <[email-masked]>
主题
RE: RE: [CCAMP] OSPF OTN drafts merged

Hi Xihua,
 
the case you are considering is a quite a simple scenario and there would 
be no issue in having the two hierarchies adverties into the same SCSI, 
but there are some "unlucky" cases in which bundling component links with 
dissimilar hierarchies could cause ambiguities.
Let's try to analize one of them. Suppose to have the following 
hierarchies supported (quite similar to the one present in the -06 version 
of the draft)
Component Link#1      Component Link#2 
         ODU0                  ODU0 
          |                     | 
         ODU3                  ODU3 
          |                     | 
         ODU4                  ODU4
We said that the advertisement of intermediate layers bandwidth is 
required in order to know how many FA can be set up. In this case, the 
advertisement of both 
ODU0->ODU3->ODU4 and 
ODU3->ODU4 
available bandwidth is performed so to know how many ODU3 FA can be setup. 
In the case above it is possible to advertise the 2 component links into 
the same SCSI.
On the other side, if you have to bundle the 3 component links in the 
following, there could be an ambiguity:
Component Link#1      Component Link#2     Component Link#3
         ODU0                  ODU0 
          |                     |                  ODU3
         ODU3                  ODU3                 |
          |                     |                  ODU4
         ODU4                  ODU4
Merging all the component links into the same SCSI would cause this type 
of advertisement:
 
ODU0->ODU3->ODU4 and 
ODU3->ODU4 
 
But in this case it is not possible to know how many ODU3->ODU4 are 
availalbe for ODU3 FA set up (i.e. belonging to the ODU0->ODU3->ODU4 
hierarchy) and how many simple ODU3 cannot be used for ODU0 transport 
(i.e. belonging to ODU3->ODU4 hierarchy).
 
This issue *does not* prevent to perform the bundling of the three 
component links and can be simply solved advertising component links #1 
and #2 into an SCSI and component link #3 in a different one (all inside 
the same ISCD).
 
By the way thaks a lot for the question, this clarification will be 
introduced into the next version of the draft.
 
BR 
Daniele

Hi Daniele, 

One more question. 
" 

                                     |                       | 
                              0/2/3                   3/2/0 

Xihua 

收件人

Xihua, 

Thanks 
Daniele 

Hi Daniele, 

Xihua 

收件人

Hi Xihua, 

Thanks 
Daniele 

HiDaniele, 

Xihua 

收件人

Hi Xihua, 

Thanks, 
Daniele 

Hi Daniele, 

One more comment. 

Xihua 

收件人
'CCAMP' <[email-masked]> 
抄送

Hi CCAMPers, 

Thanks, 
The authors 

DANIELE CECCARELLI 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Sidd Aanand <[email-masked]>
Date: Thu, 14 Jul 2011 04:04:22 -0400

Hello Authors,

A few questions regarding the latest draft:

1.       The MAX LSP BW that's advertised in the ISCD part (the one that we discussed could be used for pruning purposes): This is really the MAX AVAILABLE LSP BW, right? In other words, as links are added/deleted from the TE-link or as LSPs are created/deleted on the TE link, this field would get updated, right?

2.       In the examples, the T/S bits are not marked. Suggest that add the T/S bit values in each example for the sake of clarity. More importantly, we'd like to ensure our understanding is correct for this particular example: ODU1->ODU2->ODU3. For ODU1, we'd have S=1, T=0. For ODU2, do we set both the T/S bits to 1? Same question for ODU3.

3.       In most examples and in particular in Ex. 5.4, when a ODU2->ODU3->ODU4, we are not sure how we would get the num-odus as 10?  Since there are only two ODU3s on ODU4 and each ODU3 can accommodate 4 ODU2s, shouldn't it be 8 ODUs? It is understandable the num-odus will be 10 when ODU2 is stacked on top of ODU4 directly.

4.       In case of link bundling (ex 5.5), why do we need  a separate SCSI for Component Link #3? Can we not have it as another TLV under the same SCSI. We couldn't understand the benefit of having another SCSI for it. It'd be great if you can provide explanation for that.

5.       In Section 3 of the draft, we seem to be using the term ODU-k TE link to describe what is really a OTU-k TE-link. The previous draft used the term OTU-k TE link. So I am not sure why we have changed it. In any case, it doesn't seem to have much bearing on rest of the document.

Thanks,
Sidd

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 14 Jul 2011 12:36:03 +0200

Hi Sidd,

thanks for the careful review. Please find answers to your questions inline.

BR
Daniele

________________________________
From: Sidd Aanand [mailto:[email-masked]]
Sent: giovedì 14 luglio 2011 10.04
To: Daniele Ceccarelli
Cc: 'CCAMP'
Subject: Questions about the merged OSPF OTN draft.

Hello Authors,

[DC] Right.

[DC] There is an example dedicated to each topic, i would prefer not to focus on T/S bits on different example. Maybe it is worth exanding example 5.1 for a more detailed and exhaustive analysis of the T/S bits utilization. With respect to the example as it is now, the ODU1->ODU2->ODU3 hierarchy as it is now does not tell you much about termination and switching capabilities. For sure ODU2 and ODU3 must be AT LEAST terminated in order to extract the ODU2 from the ODU3 and the ODU1 from the ODU2, but then the ODU3 and ODU2 could be also switched or not and the ODU1 could be S only, T only or both (it is not specified). We'll add some text to the example and have a more complex hierarchy so to have a more exhaustive example.

[DC] what you say is correct, indeed there is a mistake :-)

This is correct as ODU2 is directly muxed into the ODU4

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (BW-fix)      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |F|T|S|   Res   |1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |                   Padding                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODUk at Prio 0 =10    |    Unres ODUk at Prio 3 =10   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

while this isn't correct

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (BW-fix)      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 2   |F|T|S|   Res   |1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |             Padding           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODUk at Prio 0 =10    |    Unres ODUk at Prio 3 =10   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the correct value is 8.

[DC] This point was raised by Xihua in these days, this is the reason:

there are some "unlucky" cases in which bundling component links with dissimilar hierarchies could cause ambiguities.
Let's try to analize one of them. Suppose to have the following hierarchies supported (quite similar to the one present in the -06 version of the draft)

ODU0->ODU3->ODU4 and
ODU3->ODU4

5.       In Section 3 of the draft, we seem to be using the term ODU-k TE link to describe what is really a OTU-k TE-link. The previous draft used the term OTU-k TE link. So I am not sure why we have changed it. In any case, it doesn't seem to have much bearing on rest of the document.
 [DC] Yes, terminology needs to be uniformed
Thanks,
Sidd

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Jul 2011 09:27:07 -0700

> we may have a requirement
> to explicit select a component link (i.e., ODU2 FA) which is over ODU4
> server layer.

Xihua,
	Why would one care how the ODU2 FA is transported (ODU3 vs ODU4) in
this case?

Lou

On 7/12/2011 7:36 PM, [email-masked] wrote:
> I can catch the purpose of separate SCSIs for dissimilar hierarchies
> when they are bundled together.
> This draft states "A single ISCD TLV MAY be used for the advertisement
> of unbundled or bundled links also with different server layers."
> So we could bundle 0/2/3 and 0/2/4 together and use two separate SCSIs
> to represent two hierarchies.
> Based on draft-ietf-mpls-explicit-resource-control-bundle-10, when an
> ODU0 is going to over bundle link of ODU2 FA, we may have a requirement
> to explicit select a component link (i.e., ODU2 FA) which is over ODU4
> server layer. But there isn't enough information for this requirement.
> 
> Xihua Fu
> 
> 
> *Daniele Ceccarelli <[email-masked]>*
> 
> 2011-07-12 下午 06:25
> 
> 	
> 收件人
> the case you are considering is a quite a simple scenario and there
> would be no issue in having the two hierarchies adverties into the same
> SCSI, but there are some "unlucky" cases in which bundling component
> links with dissimilar hierarchies could cause ambiguities.
> hierarchies supported (quite similar to the one present in the -06
> version of the draft)
> available bandwidth is performed so to know how many ODU3 FA can be
> setup. In the case above it is possible to advertise the 2 component
> links into the same SCSI.
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* giovedì 7 luglio 2011 16.25*
> To:* Daniele Ceccarelli*
> Cc:* 'CCAMP'; [email-masked]; [email-masked]*
> Subject:* RE: RE: [CCAMP] OSPF OTN drafts merged
> 
> 
> Hi Daniele,
> 
> One more question.
> "
>                             0/2/4                                      
>                     4/2/0
>                                     |                           B      
>                      |    
>                                     |                                  
>                         |
>                              0/2/3                                      
>                    3/2/0
> link #2 and make them as a TE Link, we could bundle them together based
> on the current OSPF extension in this draft.
> *Daniele Ceccarelli <[email-masked]>*
> 
> 2011-07-07 下午 09:40
> 
> 	
> 收件人
> given that the SCSI is mandatory and not optional, the info in the MAX
> LSP bandwdith fields is implicitely not enough for the path computation :-)
>  
> Thanks
> Daniele
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* giovedì 7 luglio 2011 15.33*
> To:* Daniele Ceccarelli*
> Cc:* 'CCAMP'; [email-masked]; [email-masked]*
> Subject:* RE: RE: [CCAMP] OSPF OTN drafts merged
> 
> 
> Hi Daniele,
> 
> bandwidth block is not enough for the patch computation. The SCSI must
> be used. Implementation must not rely on MAX LSP bandwidth block"
> 
> Xihua
> 
> *Daniele Ceccarelli <[email-masked]>*
> 
> 2011-07-07 下午 09:18
> 
> 	
> 收件人
> says few words on "how to fill" that field, we just added few words to
> say it explicitely.
> What's your suggestion?
> 
> Thanks
> Daniele
> 
> 
> ------------------------------------------------------------------------
> *
> From:* [email-masked] [mailto:[email-masked]] *
> Sent:* giovedì 7 luglio 2011 13.01*
> To:* Daniele Ceccarelli*
> Cc:* 'CCAMP'; [email-masked]; [email-masked]*
> Subject:* Re: RE: [CCAMP] OSPF OTN drafts merged
> 
> 
> HiDaniele,
> 
> *Daniele Ceccarelli <[email-masked]>*
> 
> 2011-07-07 下午 06:14
> 
> 	
> 收件人
> the IEEE floating point format [_IEEE_
> <http://tools.ietf.org/html/rfc4203#ref-IEEE>], with priority 0 first and
> and the MAX LSP field must be filled accordingly. Given that the OTN has
> a complex hierarchy, the max LSP bandwidth is equal to the "biggest"
> available container of the hierarchy. Moreover at different priorities
> can correspond different MAX LSP bandwidth availabilities.
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* mercoledì 6 luglio 2011 13.37*
> To:* Daniele Ceccarelli*
> Cc:* 'CCAMP'; [email-masked]; [email-masked]*
> Subject:* Re: [CCAMP] OSPF OTN drafts merged
> 
> 
> Hi Daniele,
> 
> One more comment.
> *Daniele Ceccarelli <[email-masked]>*
> You can find the merged ID at the following link: _
> 
> __http://tools.ietf.org/id/draft-ceccarelli-ccamp-gmpls-ospf-g709-06.txt_
> 
> *
> System & Technology - DU IP & Broadband*
> 
> Via L.Calda, 5
> Genova, Italy
> Phone +390106002512
> Mobile +393346725750
> [email-masked]
> __www.ericsson.com_ _
> 
> 
> _ <http://www.ericsson.com/>
> 
> This Communication is Confidential. We only send and receive email on
> the basis of the term set out at _www.ericsson.com/email_disclaimer_
> <http://www.ericsson.com/email_disclaimer>
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 15 Jul 2011 09:54:07 +0200

Xihua, Lou,

For sure this is not one of the key requirements that would prevent the network from correctly working, but the capability of being able to choose the server layer might be an attractive feature. If I were an operator and I had to set up a 10Gb LSP (i.e. ODU2) I would prefer to use a 40Gb lambda (ODU3/OTU3) rather than a 100Gb one (ODU4/OTU4), so that I would be able to accept a future connection request of 100Gbps through the ODU4 link.
This could be achieved in two ways:
1. Explicitly choosing the component link via the signaling
2. Having an "algorithm" on the intermediates nodes so that the choice of the component link is local but "starts" from the smallest available server.

I don't know if this requirement needs to be added or not. Your opinion?

BR
Daniele

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: giovedì 14 luglio 2011 18.27
To: [email-masked]
Cc: Daniele Ceccarelli; 'CCAMP'; [email-masked]
Subject: Re: [CCAMP] OSPF OTN drafts merged

> to explicit select a component link (i.e., ODU2 FA) which is over ODU4 

Xihua,
	Why would one care how the ODU2 FA is transported (ODU3 vs ODU4) in this case?

Lou

On 7/12/2011 7:36 PM, [email-masked] wrote:
> hierarchies (i.e., server layers ODU3 and ODU4) and bundle both of 
> ODU2 FAs together, we can use only one SCSI to represent it.
> ODU0 is going to over bundle link of ODU2 FA, we may have a 
> requirement to explicit select a component link (i.e., ODU2 FA) which 
> is over ODU4 server layer. But there isn't enough information for this requirement.
> 
> Xihua Fu
> 
> 
> would be no issue in having the two hierarchies adverties into the 
> same SCSI, but there are some "unlucky" cases in which bundling 
> component links with dissimilar hierarchies could cause ambiguities.
> component links and can be simply solved advertising component links 
> #1 and #2 into an SCSI and component link #3 in a different one (all 
> inside the same ISCD).
>  
> represent different hierarchy. What benefit I could see is there is 
> just one block for Max LSP bandwidth, SC, ET and so on.
> 
> link #2 and make them as a TE Link, we could bundle them together 
> based on the current OSPF extension in this draft.
> "If Encoding Type is G.709 ODUk (Digital Path) , information in MAX 
> LSP bandwidth block is not enough for the patch computation. The SCSI 
> must be used. Implementation must not rely on MAX LSP bandwidth block"
> 
> Xihua
> 
> in the end this message is an ISCD, so we must keep the same format 
> and same values. The MAX LSP bandwidth is present and must be filled 
> as defined in RFC4203 (as written in the draft). Given that RFC 4203 
> just says few words on "how to fill" that field, we just added few 
> words to say it explicitely.
> What's your suggestion?
> 
> Thanks
> Daniele
> 
> 
> If it doesn't make any sense to path computation, it doesn't matter 
> with how to standardize it in this draft.
> 
> Xihua
> <http://tools.ietf.org/html/rfc4203#ref-IEEE>], with priority 0 first 
> and priority 7 last.  The units are bytes (not bits!) per second.
> 
> and the MAX LSP field must be filled accordingly. Given that the OTN 
> has a complex hierarchy, the max LSP bandwidth is equal to the "biggest"
> competing drafts on OSPF-TE routing extensions for OTN have been 
> working together and a merged document has been produced.
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Jul 2011 09:04:08 -0700

Daniele,
	Perhaps I misunderstood Xihua.  I thought the case he was discussing
already had the ODU2 FAs established (i.e., underlying allocation has
already taken place.)

Lou

---

From: [email-masked]
Date: Sat, 16 Jul 2011 18:12:02 +0800

Hi Lou,

You are watching the discussion very carefully.
You are right. In this case, ODU0 LSP shouldn't care how ODU2 FA is 
transported over ODU3 or ODU4.

Xihua

Lou Berger <[email-masked]> 
2011-07-16 上午 12:04

收件人
Daniele Ceccarelli <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, 'CCAMP' <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] OSPF OTN drafts merged

Daniele,
                 Perhaps I misunderstood Xihua.  I thought the case he was 
discussing
already had the ODU2 FAs established (i.e., underlying allocation has
already taken place.)

Lou

On 7/15/2011 12:54 AM, Daniele Ceccarelli wrote:
> Xihua, Lou,
> 
> For sure this is not one of the key requirements that would prevent the 
network from correctly working, but the capability of being able to choose 
the server layer might be an attractive feature. If I were an operator and 
I had to set up a 10Gb LSP (i.e. ODU2) I would prefer to use a 40Gb lambda 
(ODU3/OTU3) rather than a 100Gb one (ODU4/OTU4), so that I would be able 
to accept a future connection request of 100Gbps through the ODU4 link.
> 2. Having an "algorithm" on the intermediates nodes so that the choice 
of the component link is local but "starts" from the smallest available 
server.
etc.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 18 Jul 2011 12:27:28 +0200

Lou,

Indeed it is worth distinguishing between the two cases. 

When the FA is already created it is automatically the less expensive path, so I agree that there is no difference between a server layer or another.
On the other side, in case the FA has not been created yet, the server layer issue should be addressed in my opinion.

Thanks
Daniele

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: venerdì 15 luglio 2011 18.04
To: Daniele Ceccarelli
Cc: [email-masked]; 'CCAMP'; [email-masked]
Subject: Re: [CCAMP] OSPF OTN drafts merged

Daniele,
	Perhaps I misunderstood Xihua.  I thought the case he was discussing already had the ODU2 FAs established (i.e., underlying allocation has already taken place.)

Lou

On 7/15/2011 12:54 AM, Daniele Ceccarelli wrote:
> 1. Explicitly choosing the component link via the signaling 2. Having 
> an "algorithm" on the intermediates nodes so that the choice of the component link is local but "starts" from the smallest available server.
> 
>> to explicit select a component link (i.e., ODU2 FA) which is over 
>> ODU4 server layer.
> 
> Xihua,
>> This draft states "A single ISCD TLV MAY be used for the 
>> advertisement of unbundled or bundled links also with different server layers."
>> So we could bundle 0/2/3 and 0/2/4 together and use two separate 
>> SCSIs to represent two hierarchies.
>> required in order to know how many FA can be set up. In this case, 
>> the advertisement of both
>> ODU0->ODU3->ODU4 and
>> ODU3->ODU4
>> ---------------------------------------------------------------------
>> -
>> --
>> Another usecase is that if we create two ODU 2 FA-LSP over link #1 
>> and link #2 and make them as a TE Link, we could bundle them together 
>> given that the SCSI is mandatory and not optional, the info in the 
>> MAX LSP bandwdith fields is implicitely not enough for the path 
>> computation :-)
>>  
>> Thanks
>> Daniele
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------------------------------------------------------------
>> -
>> --
>> *
>> available container of the hierarchy. Moreover at different 
>> priorities can correspond different MAX LSP bandwidth availabilities.
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> "The MAX LSP bandwidth field is used accordingly to RFC4204: i.e. 0 
>> <= Max LSP Bandwidth <= ODUk/OTUk and intermediate values are those 
>> on the branch of OTN switching hierarchy supported by the interface.
>> __http://tools.ietf.org/id/draft-ceccarelli-ccamp-gmpls-ospf-g709-06.
>> t
>> xt_
>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Jul 2011 12:32:25 -0400

Daniele,
	It sounds like both cases are part of standard standard hierarchy issues...

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 19 Jul 2011 09:27:50 +0200

Lou , Daniele,

I'm not sure the fact FA is already created put it as best choice: if you have two links , 1 OTU3 and 1 OTU2 , even if ODU3 LSP is already provided and advertised as H-LSP, if you need to carry a 10G service, usage of 40 G link is not the correct policy .
For me, in any case, the requirement raised by Daniele remain to be considered independently from FA already created or not .

BR
sergio

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: lunedì 18 luglio 2011 18.32
A: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Oggetto: Re: [CCAMP] OSPF OTN drafts merged

Daniele,

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 19 Jul 2011 12:27:55 +0200

Hi Sergio,

you're right. I would be better if the requirement is considered in both cases.

Thanks,
Daniele

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: martedì 19 luglio 2011 9.28
To: Lou Berger; Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Subject: R: [CCAMP] OSPF OTN drafts merged

Lou , Daniele,

BR
sergio

SERGIO BELOTTI

ALCATEL-LUCENT

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: lunedì 18 luglio 2011 18.32
A: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Oggetto: Re: [CCAMP] OSPF OTN drafts merged

Daniele,

Lou

On 7/18/2011 6:27 AM, Daniele Ceccarelli wrote:
> discussing already had the ODU2 FAs established (i.e., underlying
> allocation has already taken place.)
>
> Lou
>
>>> Based on draft-ietf-mpls-explicit-resource-control-bundle-10, when
>>> an ODU0 is going to over bundle link of ODU2 FA, we may have a
>>> requirement to explicit select a component link (i.e., ODU2 FA)
>>> which is over ODU4 server layer. But there isn't enough information for this requirement.
>>>
>>> Xihua Fu
>>>
>>>
>>> On the other side, if you have to bundle the 3 component links in
>>> the following, there could be an ambiguity:
>>> hierarchy) and how many simple ODU3 cannot be used for ODU0
>>> transport (i.e. belonging to ODU3->ODU4 hierarchy).
>>>
>>> and link #2 and make them as a TE Link, we could bundle them
>>> together based on the current OSPF extension in this draft.
>>> LSP bandwidth block is not enough for the patch computation. The
>>> SCSI must be used. Implementation must not rely on MAX LSP bandwidth block"
>>>
>>> Xihua
>>>
>>> Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields
>>> in the IEEE floating point format [_IEEE_
>>> <http://tools.ietf.org/html/rfc4203#ref-IEEE>], with priority 0
>>> first and priority 7 last.  The units are bytes (not bits!) per second.
>>>
>>> This Communication is Confidential. We only send and receive email
>>> on the basis of the term set out at
>>> _www.ericsson.com/email_disclaimer_

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 19 Jul 2011 15:11:29 +0000

Sergio,
I completely agree with you. FA should be (IMO) indistinguishable from any "physical" link as far as path computation is concerned. 

Cheers,
Igor
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, July 19, 2011 3:28 AM
To: Lou Berger; Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Subject: [CCAMP] R: OSPF OTN drafts merged

Lou , Daniele,

BR
sergio

SERGIO BELOTTI

ALCATEL-LUCENT

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: lunedì 18 luglio 2011 18.32
A: Daniele Ceccarelli
Cc: 'CCAMP'; [email-masked]
Oggetto: Re: [CCAMP] OSPF OTN drafts merged

Daniele,

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 19 Jul 2011 08:34:22 -0700

Igor,

I agree with you.  (This is disturbing 8->.)

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Igor Bryskin
> Sent: Tuesday, July 19, 2011 8:11 AM
> To: BELOTTI, SERGIO (SERGIO); Lou Berger; Daniele Ceccarelli
> Subject: Re: [CCAMP] R: OSPF OTN drafts merged
>
> Sergio,
> I completely agree with you. FA should be (IMO) indistinguishable from
> any "physical" link as far as path computation is concerned.
>
> Cheers,
> Igor
> I'm not sure the fact FA is already created put it as best choice: if
> you have two links , 1 OTU3 and 1 OTU2 , even if ODU3 LSP is already
> provided and advertised as H-LSP, if you need to carry a 10G service,
> usage of 40 G link is not the correct policy .
>
>
> For me, in any case, the requirement raised by Daniele remain to be
> considered independently from FA already created or not .
>
> BR
> sergio
>
> SERGIO BELOTTI
>
> ALCATEL-LUCENT
> > When the FA is already created it is automatically the less expensive
> path, so I agree that there is no difference between a server layer or
> another.
> > On the other side, in case the FA has not been created yet, the
> server layer issue should be addressed in my opinion.
> >
> > Thanks
> > Daniele
> >
> >> For sure this is not one of the key requirements that would prevent
> the network from correctly working, but the capability of being able to
> choose the server layer might be an attractive feature. If I were an
> operator and I had to set up a 10Gb LSP (i.e. ODU2) I would prefer to
> use a 40Gb lambda (ODU3/OTU3) rather than a 100Gb one (ODU4/OTU4), so
> that I would be able to accept a future connection request of 100Gbps
> through the ODU4 link.
> >> an "algorithm" on the intermediates nodes so that the choice of the
> component link is local but "starts" from the smallest available
> server.
> >>
> server layers."
> an
> which
> >>> availalbe for ODU3 FA set up (i.e. belonging to the ODU0->ODU3-
> >ODU4
> transport
> >>>                          A       o--------------o  X  o------------
> --o
> >>>  C
> >>>                                     |
> >>>                         |
> >>>                              0/2/3
> >>>                    3/2/0
> >>>
> together
> SCSI
> first
> >>> You're rigth when saying that this information is not enough for
> the
> >>> PCE and the SCSI must be used.
> >>>
> >>> Thanks,
> >>> Daniele
> >>>
> >>> In my understanding, there is no any standardized principle about
> how
> >>> to value this unit.
> >>> It doesn't make any sense to path computation entity. It has to
> rely
> >>> on SCSI information.
> >>> Is that right?
> >>>
> >>> Xihua