Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Jul 2014 13:54:16 +0100

> It is clear from your response that composite label portion is way beyond the
ITU
> data plane definition as of today. 

I'm sorry I have given you that impression. Sorrier still if the text in the I-D
leaves you with that impression.

It was my intention that this document defined a label that could be used for
the limited form of concatenated slot that is currently defined by the ITU-T.
It was also my intention that the document clearly and unequivocally states that
the label is not for any undefined (by the ITU-T) data plane constructs.
However, I wanted to ensure that the defined label is forward compatible.

> Do you still have reasons for keeping the composite label
> portion in the draft? If not please take it off the WG document.

Well, it is a WG I-D so my reason, as editor, is governed by what the WG wants.
I had formed the opinion, in the run up to WG adoption, that the WG supported
this idea. And before I posted the revised I-D, I circulated the text on the
list, received a couple of comments, and tweaked the text. I don't believe I
heard anyone objecting to the idea at that time.

Perhaps the chairs can help guide us to understand what the WG wants included in
the document.

Thanks,
Adrian

---

From: Rajan Rao <[email-masked]>
Date: Wed, 23 Jul 2014 06:11:44 +0000

Adrian,

The composite label section in the draft (sec 4.3) refers to RFC 7139.  In OTN label we did not enforce this.  The OTN Label allows use of non-contiguous time slots within a Te-Link.  It is not clear from this draft as to why we shouldn't take the same approach?

Perhaps we should step back and look at possible uses cases that would fall in to VCAT/inverse-muxing (IM) categories.  I can think of the following:

1. IM across Te-Links within a single fiber
2. IM across Te-links in different fibers
3. IM across Te-links within a bundle
4. IM across frequency slots within a Te-Link

While none of these are defined by ITU, this label draft seems to be addressing #4.  It is not clear why one would enforce VCAT/IM within a Te-Link.   Do you have a use case in mind?

If we take same position as in RFC 7139 then there is no reason to restrict use of single Label with non-contiguous frequency slots.

Thx
Rajan

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Sunday, July 20, 2014 5:54 AM
To: Iftekhar Hussain
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

ITU
> data plane definition as of today. 

I'm sorry I have given you that impression. Sorrier still if the text in the I-D leaves you with that impression.

It was my intention that this document defined a label that could be used for the limited form of concatenated slot that is currently defined by the ITU-T.
It was also my intention that the document clearly and unequivocally states that the label is not for any undefined (by the ITU-T) data plane constructs.
However, I wanted to ensure that the defined label is forward compatible.

> Do you still have reasons for keeping the composite label portion in 
> the draft? If not please take it off the WG document.

Well, it is a WG I-D so my reason, as editor, is governed by what the WG wants.
I had formed the opinion, in the run up to WG adoption, that the WG supported this idea. And before I posted the revised I-D, I circulated the text on the list, received a couple of comments, and tweaked the text. I don't believe I heard anyone objecting to the idea at that time.

Perhaps the chairs can help guide us to understand what the WG wants included in the document.

Thanks,
Adrian

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Jul 2014 21:19:20 +0100

Hello Rajan,

> The composite label section in the draft (sec 4.3) refers to RFC 7139.

The draft says...
   The creation of a composite of multiple channels to support inverse
   multiplexing is already supported in GMPLS for TDM and OTN [RFC4606],
   [RFC6344], [RFC7139].  The mechanism used for flexigrid is similar.

> In OTN label we did not enforce this. 

I don't understand that.
RFC 7139 *is* signaling for OTN. What is it you didn't enforce in OTN label?

> The OTN Label allows use of non-contiguous time slots within a Te-Link. 

This is true.

> It is not clear from this draft as to why we shouldn't take the
> same approach?

Because the data plane to support this has not been defined by the ITU-T.
(If you disagree with this, perhaps you could point me at the relevant
Recommendation.)

> Perhaps we should step back and look at possible uses cases that would fall in
to
> VCAT/inverse-muxing (IM) categories.  I can think of the following:
> 
> While none of these are defined by ITU, this label draft seems to be
addressing
> #4.  It is not clear why one would enforce VCAT/IM within a Te-Link.   Do you
have
> a use case in mind?

The draft says...

   Note further that while the mechanism described here naturally means
   that all component channels are corouted, a composite channel can
   also be achieved by constructing individual LSPs from single flexi-
   grid slots and managing those LSPs as a group.  A mechanism for
   achieving this for TDM is described in [RFC6344], but is out of scope
   for discussion in this document because the labels used are normal,
   single slot labels and require no additional definitions.

This seems to cover 1, 2, and 3.
Do you see a way that those models are handled in our OTN signaling without
sending more than one signaling message?
But note that the ITU-T does not currently define how you would achieve such a
composite channel in flexi-grid, and that would mean that anyone writing an I-D
that explained how achieve this would be blocked until the data plane had been
documented.

The document also says...

   At the time of writing [G.694.1] only supports only groupings of
   adjacent slots (i.e., without intervening unused slots that could be
   used for other purposes) of identical width (same value of m), and
   the component slots must be in increasing order of frequency (i.e.,
   increasing order of the value n).  The mechanism defined here MUST
   NOT be used for other forms of grouping unless and until those forms
   are defined and documented in Recommendations published by the ITU-T.

This covers 4, and explains how that case is split into two different scenarios.

What is not clear about this text?

> If we take same position as in RFC 7139 then there is no reason to restrict
use of
> single Label with non-contiguous frequency slots.

But we do take the same position!
7139 did not do anything that was not already defined in a data pane
specification.
We are taking the same approach.

Adrian

---

From: Rajan Rao <[email-masked]>
Date: Thu, 24 Jul 2014 00:45:35 +0000

Adrian,

No issues with 1-3.  For # 4, As long as we don't preclude use of single label for multiple flex grid slots we should be fine.  Para # 2 starts with composite label  but clarification later in the section you have is good.

Thx
Rajan
________________________________________
From: Adrian Farrel <[email-masked]>
Sent: Wednesday, July 23, 2014 1:19:20 PM
To: Rajan Rao; Iftekhar Hussain
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action:        draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hello Rajan,

The draft says...

I don't understand that.

This is true.

to
addressing
have

The draft says...

use of

Adrian