Re: [CCAMP] R: OSPF OTN drafts merged

[Igor Bryskin <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, July 19, 2011 3:28 AM
To: Lou Berger; Daniele Ceccarelli
Cc: 'CCAMP'; [e-mail]
Subject: [CCAMP] R: OSPF OTN drafts merged

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: [phone]
[e-mail]



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

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

Lou

On 7/18/2011 6:27 AM, Daniele Ceccarelli wrote:
> 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:[e-mail]]
> Sent: venerdì 15 luglio 2011 18.04
> To: Daniele Ceccarelli
> Cc: [e-mail]; 'CCAMP'; [e-mail]
> 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:
>> 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:[e-mail]]
>> Sent: giovedì 14 luglio 2011 18.27
>> To: [e-mail]
>> Cc: Daniele Ceccarelli; 'CCAMP'; [e-mail]
>> Subject: Re: [CCAMP] OSPF OTN drafts merged
>>
>>> 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, [e-mail] wrote:
>>>
>>> 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
>>>
>>>
>>> *Daniele Ceccarelli <[e-mail]>*
>>>
>>> 2011-07-12 下午 06:25
>>>
>>>
>>> 收件人
>>>     "[e-mail]" <[e-mail]>
>>> 抄送
>>>     'CCAMP' <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "'BELOTTI, SERGIO (SERGIO)'"
>>> <[e-mail]>, Fatai Zhang
>>> <[e-mail]>
>>> 主题
>>>     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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>> *From:* [e-mail] [mailto:[e-mail]] *
>>> Sent:* giovedì 7 luglio 2011 16.25*
>>> To:* Daniele Ceccarelli*
>>> Cc:* 'CCAMP'; [e-mail]; [e-mail]*
>>> Subject:* RE: RE: [CCAMP] OSPF OTN drafts merged
>>>
>>>
>>> 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
>>>
>>>
>>> *Daniele Ceccarelli <[e-mail]>*
>>>
>>> 2011-07-07 下午 09:40
>>>
>>>
>>> 收件人
>>>     "[e-mail]" <[e-mail]>
>>> 抄送
>>>     'CCAMP' <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>> 主题
>>>     RE: RE: [CCAMP] OSPF OTN drafts merged
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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:* [e-mail] [mailto:[e-mail]] *
>>> Sent:* giovedì 7 luglio 2011 15.33*
>>> To:* Daniele Ceccarelli*
>>> Cc:* 'CCAMP'; [e-mail]; [e-mail]*
>>> Subject:* RE: RE: [CCAMP] OSPF OTN drafts merged
>>>
>>>
>>> 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
>>>
>>> *Daniele Ceccarelli <[e-mail]>*
>>>
>>> 2011-07-07 下午 09:18
>>>
>>>
>>> 收件人
>>>     "[e-mail]" <[e-mail]>
>>> 抄送
>>>     'CCAMP' <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>> 主题
>>>     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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>> *
>>> From:* [e-mail] [mailto:[e-mail]] *
>>> Sent:* giovedì 7 luglio 2011 13.01*
>>> To:* Daniele Ceccarelli*
>>> Cc:* 'CCAMP'; [e-mail]; [e-mail]*
>>> 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
>>> *Daniele Ceccarelli <[e-mail]>*
>>>
>>> 2011-07-07 下午 06:14
>>>
>>>
>>> 收件人
>>>     "[e-mail]" <[e-mail]>
>>> 抄送
>>>     'CCAMP' <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>> 主题
>>>     RE: [CCAMP] OSPF OTN drafts merged
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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:* [e-mail] [mailto:[e-mail]] *
>>> Sent:* mercoledì 6 luglio 2011 13.37*
>>> To:* Daniele Ceccarelli*
>>> Cc:* 'CCAMP'; [e-mail]; [e-mail]*
>>> 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
>>> *Daniele Ceccarelli <[e-mail]>*
>>> 发件人:  [e-mail]
>>>
>>> 2011-06-27 下午 09:28
>>>
>>>
>>> 收件人
>>>     'CCAMP' <[e-mail]>
>>> 抄送
>>>     "[e-mail]" <[e-mail]>
>>> 主题
>>>     [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.
>>> t
>>> xt_
>>>
>>> Comments and feedback are appreciated
>>>
>>> Thanks,
>>> The authors
>>>
>>>
>>> *
>>>
>>> DANIELE CECCARELLI
>>> System & Technology - DU IP & Broadband*
>>>
>>> Via L.Calda, 5
>>> Genova, Italy
>>> Phone [phone]
>>> Mobile [phone]
>>> [e-mail]_
>>> __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>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp