Re: [CCAMP] R: OSPF OTN drafts merged

[John E Drake <[e-mail]>]

Igor,

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

Thanks,

John

Sent from my iPhone


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Igor Bryskin
> Sent: Tuesday, July 19, 2011 8:11 AM
> To: BELOTTI, SERGIO (SERGIO); Lou Berger; Daniele Ceccarelli
> Cc: 'CCAMP'; [e-mail]
> 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
> -----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
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp