Subject: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 11 Mar 2012 21:23:21 -0000

Hi CCAMP,

<individual participant>

Well, it seems like in the period between Taipei and Paris we had a full and
frank exchange of views, a period of silence, and a desperate flurry of I-D
posting.

My personal view is that it is really important to learn to walk before we try
to run. IMHO, the simple concept of a flexi-grid label is very forward-looking.
I may be wrong, but I don't expect substantial deployment of G.694.1 rev2 in the
next 12 months. In view of this, it seems slightly early to be discussing the
control plane, and significantly premature to be talking about control plane for
sophisticated wavelength combination and modification strategies. If people are
putting this function into production equipment then I am happy to be told I am
wrong.

This extends to the concept of "super channels" as discussed in
draft-hussain-ccamp-super-channel-label. What I see here is a combination of two
things:
- wavebands
- virtual concatenation
I don't oppose this work (although I do note that we have prior art on wavebands
and virtual concatenation that should be considered), and I am sure it is
modelling something that is within the architecture and concepts advanced in the
ITU-T (although not, as yet, included in the Q6/15 work), but I question whether
there is urgent deployment need for a this function in a GMPLS control plane.

So my preference is to throttle back the discussions (and drafts) for the great
and clever things you are all dreaming up, and see whether we can get the
foundations right. For me, the most basic building block is the label. Next
would come the signaling parameters. I am going to make the rash assertion that
early deployments if/when they happen will involve coherent nodes and so the
need for routing capability exchanges is lower down the priority list.
Similarly, the use of LMP to discover/confirm link capabilities may be getting
ahead of ourselves.

None of this means that people shouldn't stop thinking and inventing. And
sharing ideas through I-Ds is a great way to go forward. It's just that I think
WG time (read: my time :-) is better spent starting with the simple pieces.

And that leads me to the revision of this I-D.

The changes in this version are quite small:
- Add reference to G.671 for the definition of DWDM and CWDM
- Add a quote from G.694.1 rev (draftv6) to section 2 to explain
  that implementations are not required to support every possible
  slot or wavelength that flexigrid can define.
- Update acknowledgements
- Update the reference to Q6/15's work for the revision they
   produced in December.

I have done nothing to address the discussions on the two points for discussion
we took out of Taipei. I didn't see any convergence on ideas other than what the
I-D already says. The issues were:

1. Should we use a new value for the Grid field or should we continue to use the
value that indicates DWDM? My take-away from the discussion was that:
- It was not a deal-breaker to go either way
- "Purists" prefer to use the same DWDM value because there is no
  actual change to the grid in use.
- Some implementers find using a distinct value to be "helpful" in
  selecting a different code path for flexigrid
The I-D used a different value, and this revision continues with that approach.

2. Where do we carry the "m" value and the traffic parameters? From this
discussion I took away:
- traffic parameters do not belong in a label
- some people think "m" is a traffic parameter
- some people think "m" defines a "switching thing"
- there is agreement that the "switching things" are what the label is for.
This I-D takes the view that "m" is part of the definition of what is being
switched and is essential for the switch cross-connect to be programmed. Thus,
it is part of the label.
I would acknowledge that the value of "m" influences the bandwidth of the LSP,
but I would claim that an Path request asks for b/w in the traffic parameters
and the label returned provides the value of "m" to be programmed into the XC.
If it is necessary (perhaps a question for
draft-zhang-ccamp-flexible-grid-rsvp-te-ext) to also specify "m" (or a range of
acceptable values of "m") as part of the Path request, then it would seem
pragmatic to put it in the traffic parameters. 

Lastly Q6/15 does not appear to have addressed explicit guard bands in the
latest draft of G.694.1rev2. That is, the guard band remains implicit as it is
in the non-flexible DWDM grid. It might be appropriate to ask Q6/15 (through a
liaison) what their plans are, but developing control plane approaches for the
management of guard bands seems to be getting ahead of the ITU-T's data plane
work which I don't think CCAMP should do.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 12 Mar 2012 12:34:15 -0000

Hi Fatai,

[snip]

> Let me focus on Adrian's two points:
>
> (1) Should we use a new value for the Grid field or should we
> continue to use the value that indicates DWDM?
>
> This has been discussed deeply in the last SG15 plenary meeting
> and the meeting denied using a new value for the Grid field.
> DWDM channel spacing encoding has been updated in G.697.1,
> "flexible grid" has been introduced for CS. 
>
> Please check the last SG15 plenary meeting and G.697.1 for detail.
>
> Therefore, to make it consistent with ITU-T recommendations and
> avoid confusion, we should continue to use the value that indicates
> DWDM.

It seems to me that what the ITU-T has determined is that the grid used for
static and flexi is the same. I agree with this.

However, we are talking about the control plane. The control plane does not
require to have a one-to-one mapping of field values so long as a mapping can be
generated.

I find it perfectly easy to map:
1 = 694.1 grid used for static spacing
3 = 694.1 grid used for flexible spacing
Same grid. Different usage.

I fail to see how adding information in the control plane can be a bad thing. 
The main (only?) reason you give is that there may be "confusion". Personally, I
am not confused by this mapping.

Is there a stronger reason to use one value for both purposes?

> (2)Where do we carry the "m" value and the traffic parameters?
>
> I want to clarify this question from signaling and routing perspective.
>
> ------from signaling perspective:
>
> As we discussed in Taipei, you also agreed that "m" might reasonably
> be in the traffic parameters.

Yes. I agree that it might reasonably be there.
I do not agree that it might *exclusively* be there.
That is, I can see it as an important part of the label *and* an important part
of the traffic parameters.

> Meanwhile, we also saw a few experts agreed to have "m" in the traffic
> parameters, because it indicates b/w or capacity.

Yup. Experts and others agreed this.

> The argument is: does it need to carry "m" in the label?

Disagree that this is the argument :-)
"Need" is soooo subjective.

The problem with the word "need" is that, so long as you can get the information
from somewhere (we could encode it in a new TLV of the Admin Status object!) we
do not need to put it anywhere.

I prefer to ask is it useful/convenient/expedient/logical?

> At Taipei meeting, you pointed out what is label in RFC3471:
>
>  "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. "
>
> You also admitted that only the "label" information is not sufficient,
> and then you pointed out that "interface ID and component
> interface ID are also necessary for XC programming".  

You make it sound like I was being tortured by the inquisition!

> Some experts also raised that traffic parameters should also be
> considered. 

Those pesky experts, again.

> Therefore, from your understanding and my understanding, it 
> seems that the label defined in
> [draft-zhang-ccamp-flexible-grid-rsvp-te-ext] is sufficient for
> XC programming.

Yes. But I agree.
And similarly you agree that the label defined in
draft-farrkingel-ccamp-flexigrid-lambda-label is sufficient.

I don't find that you are advancing the discussion in any way. We both know that
so long as all the information is present somewhere in the signaling message, we
can programme the XC. 

I suppose I am baffled as to why this topic should be the subject of such hot
debate!

> ------from routing perspective:
>
> The label defined in [draft-zhang-ccamp-flexible-grid-rsvp-te-ext] is 32 bits
and it is
> consistent with RFC6205, however, the label defined in
> [draft-farrkingel-ccamp-flexigrid-lambda-label] has 64 bits ("m" is there),
ie., twice
> length as the first one.
>
> Let's see how this label in [draft-farrkingel-ccamp-flexigrid-lambda-label] is
> used in routing.

"is used" is probably a bit extreme.
"could be used" or "has been suggested in one draft"

I don't think it is valuable to back-form from an individual draft of OSPF
extensions to "the way it will be done". Or should I assume that you support the
content of draft-wangl-ccamp-ospf-ext-constraint-flexi-grid except for the label
format? :-)

Frankly, I don't think *anyone* understands routing in a variable flexigrid
environment, and I stand by my previous claim that initial deployments (*if*
they ever happen) will be within sub-networks of coherent nodes such that there
will be no requirement to perform "clever" functions.

> In [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01], it says:
> =========================================
> The value of m in start/end label in meaningless on the label set,
> however, in order to keep the integrity of labels and avoid
> misunderstanding, it is set to default value: m = (slot width
> granularity)/12.5GHz.
> ==========================================
>
> 32 additional bits space is used to carry meaningless information!  People
> can image how many labels are distributed in the routing. What scalable
> issue it is!
>
> Do you think if it is a real scalability issue for routing? I think the answer

> is definitely “Yes”.
>
> Consequently, my conclusion is: 
>
> "m" should not be carried in the generalized label either from signaling
> or routing perspective.

That is interesting.
What you are saying is that the slot width supported by a switch for a specific
wavelength will not form part of the routing decision.

> Thanks

You are very welcome.
Adrian

---

From: Iftekhar Hussain <[email-masked]>
Date: Tue, 13 Mar 2012 20:55:22 +0000

Adrian,

Please see few comments in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, March 11, 2012 2:23 PM
To: 'CCAMP'
Cc: [email-masked]
Subject: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi CCAMP,

<individual participant>

Well, it seems like in the period between Taipei and Paris we had a full and frank exchange of views, a period of silence, and a desperate flurry of I-D posting.

My personal view is that it is really important to learn to walk before we try to run. IMHO, the simple concept of a flexi-grid label is very forward-looking.
I may be wrong, but I don't expect substantial deployment of G.694.1 rev2 in the next 12 months. In view of this, it seems slightly early to be discussing the control plane, and significantly premature to be talking about control plane for sophisticated wavelength combination and modification strategies. If people are putting this function into production equipment then I am happy to be told I am wrong.

[Iftekhar] While it is hard to precisely predict whether and to what extent flexgrid based products will get deployed in the next 12 months nevertheless  I would respectfully disagree with the assertion that flexgrid related control plane work is that far ahead of reality. There are many major  component as well as system vendors who are in the process of supporting this functionality in the "real" deployable products.  

This extends to the concept of "super channels" as discussed in draft-hussain-ccamp-super-channel-label. What I see here is a combination of two
things:
- wavebands
- virtual concatenation
I don't oppose this work (although I do note that we have prior art on wavebands and virtual concatenation that should be considered), and I am sure it is modelling something that is within the architecture and concepts advanced in the ITU-T (although not, as yet, included in the Q6/15 work), but I question whether there is urgent deployment need for a this function in a GMPLS control plane.

[Iftekhar] A super-channel is not necessarily confined to a virtual concatenation concept at the protocol layer only.  Clearly it is possible to form super-channels by closely packing multiple carriers to support real customers need to deploy spectrally efficient optical connections with data rates beyond 100Gbps (e.g., 1 Tbps). Glad to hear that you don't oppose this work.  We are very open to discuss and explore the reuse of existing art. 

So my preference is to throttle back the discussions (and drafts) for the great and clever things you are all dreaming up, and see whether we can get the foundations right. For me, the most basic building block is the label. Next would come the signaling parameters. I am going to make the rash assertion that early deployments if/when they happen will involve coherent nodes and so the need for routing capability exchanges is lower down the priority list.

[Iftekhar] Again I would disagree with this assertion. Let us get a reality check here. So do you mean coherent nodes are not real  and also too far in the future? There are already adequate number of 40G/100G coherent deployed systems with fast ramp up expected soon.

Regards,
Iftekhar

Similarly, the use of LMP to discover/confirm link capabilities may be getting ahead of ourselves.

None of this means that people shouldn't stop thinking and inventing. And sharing ideas through I-Ds is a great way to go forward. It's just that I think WG time (read: my time :-) is better spent starting with the simple pieces.

I have done nothing to address the discussions on the two points for discussion we took out of Taipei. I didn't see any convergence on ideas other than what the I-D already says. The issues were:

1. Should we use a new value for the Grid field or should we continue to use the value that indicates DWDM? My take-away from the discussion was that:
- It was not a deal-breaker to go either way
- "Purists" prefer to use the same DWDM value because there is no
  actual change to the grid in use.
- Some implementers find using a distinct value to be "helpful" in
  selecting a different code path for flexigrid The I-D used a different value, and this revision continues with that approach.

2. Where do we carry the "m" value and the traffic parameters? From this discussion I took away:
- traffic parameters do not belong in a label
- some people think "m" is a traffic parameter
- some people think "m" defines a "switching thing"
- there is agreement that the "switching things" are what the label is for.
This I-D takes the view that "m" is part of the definition of what is being switched and is essential for the switch cross-connect to be programmed. Thus, it is part of the label.
I would acknowledge that the value of "m" influences the bandwidth of the LSP, but I would claim that an Path request asks for b/w in the traffic parameters and the label returned provides the value of "m" to be programmed into the XC.
If it is necessary (perhaps a question for
draft-zhang-ccamp-flexible-grid-rsvp-te-ext) to also specify "m" (or a range of acceptable values of "m") as part of the Path request, then it would seem pragmatic to put it in the traffic parameters. 

Lastly Q6/15 does not appear to have addressed explicit guard bands in the latest draft of G.694.1rev2. That is, the guard band remains implicit as it is in the non-flexible DWDM grid. It might be appropriate to ask Q6/15 (through a
liaison) what their plans are, but developing control plane approaches for the management of guard bands seems to be getting ahead of the ITU-T's data plane work which I don't think CCAMP should do.

Cheers,
Adrian

---

From: Rajan Rao <[email-masked]>
Date: Tue, 13 Mar 2012 20:55:50 +0000

Adrian, et al

Fully agree on getting the foundation right.   There were comments during Taipei meeting to  list Flex-Grid requirements and use cases.   May be we should start with these. 

Some of us have made an attempt to list the requirements etc in this doc: http://datatracker.ietf.org/doc/draft-syed-ccamp-flexgrid-framework-ext/

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Sunday, March 11, 2012 2:23 PM
To: 'CCAMP'
Cc: [email-masked]
Subject: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi CCAMP,

<individual participant>

Cheers,
Adrian

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Mar 2012 11:16:14 -0000

Hi Iftekhar,

[snip]

>> would come the signaling parameters. I am going to make the rash assertion
>> that early deployments if/when they happen will involve coherent nodes
>> and so the need for routing capability exchanges is lower down the priority
>> list.
> 
> [Iftekhar] Again I would disagree with this assertion. Let us get a reality
check
> here. So do you mean coherent nodes are not real  and also too far in the
future?
> There are already adequate number of 40G/100G coherent deployed systems
> with fast ramp up expected soon.

I have read and re-read my text to try to see where you got your
misunderstanding of my assertion, but I can't find it.

Maybe you have understood "coherent" in the optical sense?

I meant that initial deployments of flex-grid systems will form sub-networks of
nodes from the same vendor or (exceptionally) from vendors with very close
cooperation agreements. Thus, the ability to exchange information in the routing
protocols about the flexi-grid capabilities of nodes in the network is less
pressing than other functions.

Cheers,
Adrian

---

From: Iftekhar Hussain <[email-masked]>
Date: Thu, 15 Mar 2012 18:27:45 +0000

Hi Adrian,

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 4:16 AM
To: Iftekhar Hussain; 'CCAMP'
Cc: [email-masked]; Marco Sosa; Abinder Dhillon; Rajan Rao
Subject: RE: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi Iftekhar,

[snip]

>> So my preference is to throttle back the discussions (and drafts) for 
>> the
great
>> and clever things you are all dreaming up, and see whether we can get 
>> the foundations right. For me, the most basic building block is the 
>> label. Next would come the signaling parameters. I am going to make 
>> the rash assertion that early deployments if/when they happen will 
>> involve coherent nodes and so the need for routing capability 
>> exchanges is lower down the priority list.
> 
check
future?
> There are already adequate number of 40G/100G coherent deployed 
> systems with fast ramp up expected soon.

I have read and re-read my text to try to see where you got your misunderstanding of my assertion, but I can't find it.

[Iftekhar] Yes that is correct. Obviously the context of this discussion is mainly about coherent optical systems (i.e., Super-Channels, Modulation formats, FEC types etc) and their support on FlexGrid networks. 

Cheers,
Iftekhar

I meant that initial deployments of flex-grid systems will form sub-networks of nodes from the same vendor or (exceptionally) from vendors with very close cooperation agreements. Thus, the ability to exchange information in the routing protocols about the flexi-grid capabilities of nodes in the network is less pressing than other functions.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 17 Mar 2012 10:15:16 -0000

[snip]

> >> I am going to make
> > So do you mean coherent nodes are not real  and also too far in
> > the future? There are already adequate number of 40G/100G
> > coherent deployed systems with fast ramp up expected soon.
> 
> [Iftekhar] Yes that is correct. Obviously the context of this discussion is
mainly
> about coherent optical systems (i.e., Super-Channels, Modulation formats, FEC
> types etc) and their support on FlexGrid networks.

Excellent. So with that misunderstanding sorted out, what do you think of my
assertion rephrased as...
 
> protocols about the flexi-grid capabilities of nodes in the network is less
pressing
> than other functions.
 
Cheers,
Adrian

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 19 Mar 2012 16:36:17 +0000

Please see comments in-line.

[snip]

mainly
> about coherent optical systems (i.e., Super-Channels, Modulation 
> formats, FEC types etc) and their support on FlexGrid networks.

Excellent. So with that misunderstanding sorted out, what do you think of my assertion rephrased as...
 
> I meant that initial deployments of flex-grid systems will form 
> sub-networks
of
> nodes from the same vendor or (exceptionally) from vendors with very 
> close cooperation agreements. Thus, the ability to exchange 
> information in the
routing
pressing
> than other functions.

[Iftekhar] I think this argument(s) equally applies to fixed-grid network case - yet protocol extensions encompassing all aspects of solution (label, routing, signaling parameters) either have been defined or in progress. In that respect, flex-grid capabilities are extensions of the fixed-grid capabilities - this should allow protocol extensions to enable system solution covering all aspects. Certainly, label definition for flex-grid is a very important component, this does not mean the other aspects including routing and signaling extensions are any less important. I think rather than taking a piecemeal approach we should look at a system approach. Perhaps the right place to start is to agree on set of requirements . In parallel, define common set of terms (i.e. framework)  to avoid confusion. Then concentrate in provide holistic solution including label, routing, and signaling.

Regards,
Iftekhar

---

From: Fatai.Zhang <[email-masked]>
Date: Wed, 21 Mar 2012 07:51:42 +0000

Agree. 

We should investigate how to use and process the label efficiently that is being made in the environment of signaling and routing.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iftekhar Hussain
Sent: 2012年3月20日 0:36
To: [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

[snip]

mainly

of
routing
pressing

Regards,
Iftekhar

---

From: Iftekhar Hussain <[email-masked]>
Date: Thu, 22 Mar 2012 01:59:10 +0000

Hi, Fatai,

I am not clear what you mean. Can you please clarify what you are agreeing to and what environment are you taking about?   Do you mean we should continue with extensions submissions without defining the requirements or you mean just focus on "select" portion of the problem?

Regards,
Iftekhar
-----Original Message-----
From: Fatai.Zhang [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2012 12:52 AM
To: Iftekhar Hussain; [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: RE: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Agree. 

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iftekhar Hussain
Sent: 2012年3月20日 0:36
To: [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

[snip]

mainly

of
routing
pressing

Regards,
Iftekhar

---

From: Fatai.Zhang <[email-masked]>
Date: Thu, 22 Mar 2012 02:17:45 +0000

Hi Iftekhar,

I meant that we should focus on FWK/requirement first, and then provide holistic solution including routing and signaling.

Moreover, I think it is not appropriate to design the label format isolatedly without considering how to process the label in the environment of signaling and routing.

Thanks
 
Fatai

-----Original Message-----
From: Iftekhar Hussain [mailto:[email-masked]] 
Sent: 2012年3月22日 9:59
To: Fatai.Zhang; [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: RE: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi, Fatai,

Regards,
Iftekhar
-----Original Message-----
From: Fatai.Zhang [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2012 12:52 AM
To: Iftekhar Hussain; [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: RE: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Agree. 

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iftekhar Hussain
Sent: 2012年3月20日 0:36
To: [email-masked]; 'CCAMP'
Cc: Mike VanLeeuwen; Marco Sosa; Abinder Dhillon; [email-masked]; Biao Lu
Subject: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

[snip]

mainly

of
routing
pressing

Regards,
Iftekhar