Subject: Re: [CCAMP] Flexi-grid issue 2

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 14 Nov 2011 04:27:45 +0100

Hi Cyril and all,

Having the same parameter in two place can often be the recipe for a disaster, in case there is the need to have an end-to-end parameter plus an hop-by-hop one we might consider having two different parameters.

Now the question is:is this possible? I mean, is it possible that a given slot width is asked from end to end but link by link the request can be satisfied with different slot width? If the answer is no, I think putting m in the traffic params could be enough, if the answer is no I think two values might be needed, one in the traffic parameters and the other in the label.

Maybe it is worth adding this question to the list Adrian asked for? Unless someone already has a question.

Thanks 
Daniele

*** E-mail via DME powered by mobile broadband ***

--Original message---
Sender: "[email-masked]" <[email-masked]>
Sent time: 13/nov/2011 22:13
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [CCAMP] Flexi-grid issue 2

Hi, 

It seems to me that m should be in the traffic parameters because it describes the capacity.
Regarding the label, if I understand correctly RFC4606 (and recent OTN work)  the label alone is not the only 
information (also when adding the interface information) is not enough, the traffic parameters are also used.

Having the "m" additionally in the label seems also to be considered, it seems possible that the "m" might be influenced by the switching element and change hop-by-hop.

My 2 cents.

Best regards / Mit freundlichen Grüßen
Cyril Margaria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Adrian Farrel
> Sent: Monday, November 14, 2011 10:55 AM
> To: 'Zhangfatai'; [email-masked]
> Subject: Re: [CCAMP] Flexi-grid issue 2
> 
> Hi,
> 
> I've not spent a lot of time looking at the traffic parameters, but
> yes. It seems to me that part of requesting the LSP could include
> specifying a number of parameters related to capacity and construction.
> That would mean that "m" might reasonably be in the traffic parameters
> (or maybe there would be a choice of values of m) and the final chosen
> value of m would then be placed in the label.
> 
> You are, of course, right that issues like interface ID and component
> interface ID are also necessary for XC programming.
> 
> A
> 
> > -----Original Message-----
> > From: Zhangfatai [mailto:[email-masked]]
> > Sent: 14 November 2011 02:20
> > To: [email-masked]; [email-masked]
> > Subject: 答复: [CCAMP] Flexi-grid issue 2
> >
> > Hi Adrian,
> >
> > Do you agree that "m" should also be put into Traffic Parameters
> > object, which indicates how much resource should be reserved before
> we
> > decide whethere we should put "m" in the Label?
> >
> > Talking about the Label definition from RFC3471, the Label defined in
> > [draft- zhang] contains "enough information" to allow the receiving
> > node to program
> its
> > cross connect, ie., nothing is missed from my understanding.
> >
> > We know that the reciveing node cannot program its cross connect
> > correctly by using only the information contained in the "Label",
> > because it also needs to
> get
> > some other information (e.g., TE link or component link information)
> > from
> other
> > RSVP objects such as ERO or RSVP-HOP.
> >
> > Please correct me if I have any misunderstanding.
> >
> > Fatai
> >
> > Thanks
> >
> >
> > ________________________________________
> > 发件人: [email-masked] [[email-masked]] 代表 Adrian
> Farrel
> > [[email-masked]]
> > 发送时间: 2011年11月13日 9:34
> > 到: [email-masked]
> > 主题: [CCAMP] Flexi-grid issue 2
> >
> > Hi,
> >
> > Second email on the differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-
> lambd
> > a-label
> > and
> http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-
> te-ext
> >
> > This issue is more complicated than the first issue. This question
> has
> > two
> > sub-points:
> > a. where do we carry the flexi-grid m parameter?
> > b. where do we carry traffic parameters for flexi-grid?
> >
> > draft-zhang is a more comprehensive document that draft-farrkingel
> > because it aims to cover a number of significant signaling parameters
> for RSVP-TE.
> > draft-farrkingel only attempts to define a label structure.
> >
> > Thus, the question we need to resolve is not where to carry the
> > traffic parameters for flexi-grid, but what constitutes a label in
> flexi-grid?
> >
> > Maybe we should start this with the question: what is a label? RFC
> 3471 says:
> >
> >    A generalized label contains enough information to allow the
> receiving
> >    node to program its cross connect, regardless of the type of this
> >    cross connect, such that the ingress segments of the path are
> >    properly joined.
> >
> > So, what information do we need to carry in a label to satisfy that?
> I
> > think
> it
> > is a full description of the channel, and AFAICS for flexi-grid this
> > includes the m parameter.
> >
> > Thanks,
> > Adrian
> >
> > _______________________________________________
> > 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: Daniele Ceccarelli <[email-masked]>
Date: Mon, 14 Nov 2011 04:30:47 +0100

Errata corrige

Hi Cyril and all,

Now the question is:is this possible? I mean, is it possible that a given slot width is asked from end to end but link by link the request can be satisfied with different slot width? If the answer is no, I think putting m in the traffic params could be enough, if the answer is YES I think two values might be needed, one in the traffic parameters and the other in the label.

Thanks 
Daniele

--Original message---

Hi, 

My 2 cents.