Subject: [CCAMP] Flexi-grid issue 2

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 13 Nov 2011 01:34:21 -0000

Hi,

Second email on the differences between the label formats defined in
http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sun, 13 Nov 2011 08:38:08 +0100

Hi Adrian,

Hottest issue. The choice of putting the m parameter into the label seems to better fit with label definition, but on the other side, thinking of traffic parameters, they indicate the amount of resources requested, and the m parameter indeed indicates right that.

Both solutions seem to be acceptable. Further considerations might be needed.

Thanks and BR 
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: domenica 13 novembre 2011 2.34
To: [email-masked]
Subject: [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-lambda-label
and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

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?

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

---

From: Ramon Casellas <[email-masked]>
Date: Sun, 13 Nov 2011 11:51:28 +0100

On 11/13/2011 02:34 AM, Adrian Farrel wrote:

> 1st issue:
============ 
> should we use a new value for the Grid field or should we continue to use the
> value that indicates DWDM.

I don't have a strong opinion on this. As discussed in private mails, it is true that ITU-T sticks to DWDM, but IMHO with the main purpose of defining a nominal set of frequencies and allowing management of frequency slots / ranges. If the grid codepoint space remains purely within GMPLS, without necessarily mapping to "1" and "2" from ITU, a new value could clearly mean "flexi" as opposed to (if defined in the future) a fixed grid with 6.25 GHz spacing. In any case, it remains a X-bit (32, 64, ?) label, and it is possible to obtain the nominal central frequency for both. The "spectrum switched" nature as opposed to "wavelength switched" nature of the LSP can be deduced from a higher context. I'm fine either way.

> 2nd issue
============
> is a full description of the channel, and AFAICS for flexi-grid this includes
My personal preference, although I understand both Fatai's and Yao's view on this, is also that the m parameter is part of the label, it is part of the definition of the switchable entity, simplifies upstream processing and has the "nice to have" feature of WSON and other SC that an ERO with explicit label control captures the cross-connects. However, Fatai's view of m as that the "amount of resource to be reserved" with regard to a total "capacity" (optical spectrum) and as such is part of the sender descriptor / flow descriptor / flowspec is also valid. It also has the practical advantage that it remains 32-bits, implementations may have relied in common data types (uint32_t) to encode LSC labels. In the past, we considered a u32 label following LSC labels where m was encoded in the WSON "identifier" field for SSON

Thanks
Ramon
--

---

From: Rajan Rao <[email-masked]>
Date: Mon, 14 Nov 2011 02:06:51 +0000

Hi,

The other thing we need to consider is OEO possibilities and use of values other than 12.5GHz as base granularity in future. 

Putting 'm' in traffic param does allow modifications by intermediate nodes if we were to address the above possibilities. Having it in the label seems like the right approach.

BTW,  there is another draft on the same topic:

draft-hussain-ccamp-super-channel-label-02.txt

thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Saturday, November 12, 2011 11:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Flexi-grid issue 2

Hi Adrian,

Thanks and BR 
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: domenica 13 novembre 2011 2.34
To: [email-masked]
Subject: [CCAMP] Flexi-grid issue 2

Hi,

   

Thanks,
Adrian

---

From: Zhangfatai <[email-masked]>
Date: Mon, 14 Nov 2011 02:20:12 +0000

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,

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Nov 2011 02:54:35 -0000

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

> From: Zhangfatai [mailto:[email-masked]]
> Sent: 14 November 2011 02:20
> 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.
> 
> and
http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 14 Nov 2011 04:13:33 +0100

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Adrian Farrel
> Sent: Monday, November 14, 2011 10:55 AM
> To: 'Zhangfatai'; [email-masked]
> 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
> 
> > 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
> > 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
> > 发件人: [email-masked] [[email-masked]] 代表 Adrian
> Farrel
> > [[email-masked]]
> > 发送时间: 2011年11月13日 9:34
> > 到: [email-masked]
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-
> lambd
> > a-label
> > and
> > This issue is more complicated than the first issue. This question
> has
> > two
> > sub-points:
> > draft-zhang is a more comprehensive document that draft-farrkingel
> > because it aims to cover a number of significant signaling parameters
> for RSVP-TE.
> > 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?
> >
> > 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
> >

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 15 Nov 2011 00:50:14 +0100

probably worth to remind that current wson signaling draft
(draft-ietf-ccamp-wson-signaling) does not extend traffic parameters but
needs an additional tlv (still TBD) to carry wson information required
for xc programming.

Well, still a live document and looks probably time to review that
choice but this is the current status.

Cheers
G

---

From: [email-masked]
Date: Tue, 15 Nov 2011 09:54:46 +0800

Some additional information

According to the description in RFC2210 section 2:

"Information generated at each sender describing the data traffic 
generated by that sender (the Sender TSpec). This information is carried 
from the sender to intermediate network elements and the receiver(s) by 
RSVP, but is never modified by intermediate elements within the network. 
This information is carried in RSVP SENDER_TSPEC objects".

But if the O-E-O scenario should be considered in flexible grid scenario, 
the "m" value may be changed. My personal opinion is that it MUST be 
considered.

Just my two cents, I do not think it is a good idea to put "m" in the 
SENDER_TSPEC object, which is not backward compatible; even that it may be 
carried except in the label object, it should be treated in another way or 
like Giovanni said ,an additional TLV.

Best,

Fei

Giovanni Martinelli <[email-masked]> 
发件人:  [email-masked]
2011-11-15 07:50

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [CCAMP] Flexi-grid issue 2

Cheers
G

> You are, of course, right that issues like interface ID and component 
interface
>> Do you agree that "m" should also be put into Traffic Parameters 
object, which
>> Talking about the Label definition from RFC3471, the Label defined in 
[draft-
>> We know that the reciveing node cannot program its cross connect 
correctly by
Farrel

>> draft-zhang is a more comprehensive document that draft-farrkingel 
because it
>> So, what information do we need to carry in a label to satisfy that? I 
think
>> is a full description of the channel, and AFAICS for flexi-grid this 
includes