Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

From: Rajan Rao <[email-masked]>
Date: Sat, 21 May 2011 00:56:00 +0000

Hi,

During  ‘draft-khuzema’ presentation in Prague IETF we had an action to provide problem statement and the requirements relating to OTN muxing hierarchy and GMPLS signaling.  Please find details relating to multi-stage labels in the file attached.

We request for review & feedback from WG and contribute contained text to OTN framework document.

Thanks
Draft-khuzema-authors

From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, April 20, 2011 10:56 AM
To: Fatai Zhang; John E Drake; Rajan Rao; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: RE: [CCAMP] R: R: Discussion of multi-stage solutions

Fathai,

I think you are surprised because you seem not to understand about 75% of what I and Rajan are trying to say, which is in the nutshell the following: for the devices with limited switching/multiplexing capabilities it is advantageous to use hop-by-hop multi-stage approach and “pretend” that such limitations do not exist, i.e. they can switch the whole hierarchy they claim in their advertisements to support. You do not necessarily need H-LSPs for this purpose. I am not against H_LSPs, in fact, all my multi-layer solutions are based on them. However, H_LSPs are needed as a way of building topologies, they are product of careful network planning, and are created in a different time frame the connections they serve.  Whether H-LSPs and their clients are created by CP or MP is irrelevant for this discussion. In fact, our implementation allows for the CP<=>MP ownership transfer both or either of them at any time.

Cheers,
Igor

From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, April 20, 2011 10:21 AM
To: Igor Bryskin; John E Drake; Rajan Rao; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Hi Igor,

I agree with John and I am really surprise by your following sentences.

Do you know why the operator needs the management plane? Sorry for asking this question to you because I admire you for your active work and I think obviously you must know it.
Do you agree that  CP could be regarded as the extension of the management plane?

No matter which solution (either multi-stage labels or H-LSP), the data plane does the same thing (ie., the hierarchy happens), and I think people can undestand that this hierarchy (let me clearly say the hierarchy in the data plane) should be under the control of the mangement plane.

If something is created by CP, but CP and MP can not see it and manage it, how the network could be administrable?

I think if people see the unjustified small advantages, they also should face the disadvantages fearlessly.

We can leave out of account to discuss whether single hop is special or common at this moment (even though I think definitely it is special case for OTN networks and H-LSP can resolve this special case, so there is no scaling issue that you folks assumed). However, the people who advocate multi-stage labels must face the general questions:

(1) Does multi-stage labels follow the GMPLS principle? Why GMPLS needs H-LSP approach?

(2) How to manage the network for the operators if something is created through CP, but it is invisible for the CP and MP?

(3) How to plan the network (ie., the hierarchy in the data plane) if multi-stage labels was used?

If some people who advocate multi-stage labels are not confident to face and clarify these simple questions that I have repeated several times, I really hope the co-chairs to help the WG to guide the discussion.

Fatai

Thanks
----- Original Message -----
From: Igor Bryskin<mailto:[email-masked]>
To: John E Drake<mailto:[email-masked]> ; Rajan Rao<mailto:[email-masked]> ; Steve Balls<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Cc: 'CCAMP'<mailto:[email-masked]>
Sent: Wednesday, April 20, 2011 3:47 AM
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

John,

In hop-by-hop multi-stage approach from CP point of view there are no hierarchical LSPs: the hierarchy happens only in the data plane, and this fact is completely concealed from CP.  In other words  CP does not even realize that multi-stage configuration is actually happening, it just cannot tell multi-stage from single-stage

Igor

From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 3:31 PM
To: Igor Bryskin; Rajan Rao; Steve Balls; [email-masked]<mailto:[email-masked]>
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Igor,

It is fair to say that multi-stage labels are marginally better than one hop hierarchical LSPs.   It is also fair to ask why in the world one would want to do either?

My email was implicitly asking that question by comparing multi-stage labels with multi-hop hierarchical LSPs;  each  of my two sentences was a comparison between multi-stage labels and  multi-hop  hierarchical LSPs.

Thanks,

John

Sent from my iPhone

From: Igor Bryskin [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 12:03 PM
To: John E Drake; Rajan Rao; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

John,

Please, see in line

From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 2:26 PM
To: Igor Bryskin; Rajan Rao; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

An intermediate node would be involved in the signaling of and the maintaining state for all of the individual LSPs that would be hidden from it within a hierarchical LSP.

IB>> Disagree, from CP point of view it will be a single LSP using multi-stage labels

JD:  You are actually agreeing with me.  Every individual LSP, with its multi-stage labels, will be visible in the control plane.

  Similarly, for restoration it is faster and less control plane intensive to signal a hierarchical LSP than to signal all of the individual LSPs contained within it.

IB>> I think you completely misunderstood the idea: in hop-by-hop multi-stage approach from the CP point of view there is no hierarchical LSPs

JD:  That was my point.  With multi-stage labels there are no hierarchical LSPs and every individual LSPs, with its multistage labels, will need to be re-signaled.

Cheers,
Igor

Sent from my iPhone

From: Igor Bryskin [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 11:15 AM
To: Rajan Rao; John E Drake; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

IMO  hop-by-hop multi-stage approach is a reasonable one. It saves a lot of CP state and activity that would be necessary if everything is done via FAs. Importantly, it also saves connection setup time, which is very important during restoration.

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: Tuesday, April 19, 2011 1:52 PM
To: John E Drake; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

John,

We (authors of draft-khuzema) have an action from Prague meeting  to clarify the problem statement and the requirements relating to multi-stage hierarchy/labels.  We will provide this soon.

Thanks
Rajan

From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 10:43 AM
To: Rajan Rao; Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Hi,

I think the guidance I heard from Lou was to implement but not standardize multi-stage label?

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: Tuesday, April 19, 2011 10:38 AM
To: Steve Balls; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Steve,

I don’t think this case is a functional restriction of multi-stage label.  The multi-stage label is meant to address hop by hop (Te-Link basis) intermediate ODU layer requirement to carry service.   It is not meant to create ODU2 cross connection at B for E2E ODU0 service.  As you said, it requires H-LSP from A to C. The routing figures this out from IMCDs.

Fully agree on the point that it is operator choice to use multi-stage label.

Thanks
Rajan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Balls
Sent: Tuesday, April 19, 2011 9:50 AM
To: [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Hi Xihua,

In terms of cases that will not work with multi-stage labels, consider setting up an ODU0 connection in the following network.

      A -------- B -------- C

Node A supports ODU2->ODU0
Node B supports ODU2 switching only
Node C supports ODU2->ODU0

This case requires an ODU2 H-LSP to be used to carry the ODU0 connection.

The other functional restrictions of multi-stage labels are that when they can be used, the HO-ODUs are not subject to direct management by the control plane.  This means that, for example, the single hop they are being used over cannot be subject to protection mechanisms at the HO-ODU.

However, it should also be pointed out that should multi-stage labels be used, they are still not mandatory.  It would be an individual nodes / operators choice to decide if an H-LSP or multi-stage label should be used across a hop.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]]
Sent: 18 April 2011 03:27
To: Steve Balls
Cc: 'CCAMP'; [email-masked]
Subject: Re: Re: [CCAMP] R: R: Discussion of multi-stage solutions

Hi Steve,

You wrote:
“
Assuming they do, there are two options.

i)              Multi-stage labels
ii)             Induced H-LSPs

Solution (i) is not complete because there are still cases that will not work automatically with multistage labels; plus there are functional restrictions that others have pointed out already.  However, they are very significantly easier to implement, and if standardized should be supported by all devices.
”
 [Xihua] Would you like to clarify why it couldn't work automatically with multistage labels?

"
So it seems to us that while multistage labels may have some functional restrictions, they have some operational and implementation benefits that we should weigh dispassionately.  However, we have seen no input from operators (direct or indirect) to say whether they think that the configuration of FA-LSPs will actually be a problem for them, or if they expect connections to be automatic where possible.  Does anyone reading this have any feedback on that point?
"

[Xihua] Would you like to clarify what is the functional restrictions?

Xihua Fu
Steve Balls <[email-masked]>
发件人:  [email-masked]

2011-04-14 下午 10:18

收件人

'CCAMP' <[email-masked]>

抄送

主题

Re: [CCAMP] R:  R:  Discussion of multi-stage solutions

All

We'd like to take a step back from this debate and offer a different perspective.

The debate about whether a multistage label represents one or multiple LSPs is moot, because there is not an authoritative definition of an LSP that can resolve it one way or another.  We all understand conceptually what a multi-stage label is, and we should focus the debate on its advantages and disadvantages on its own merits.

We do not have a preference here, but think there are some further discussion points to be made, and it would be beneficial to request further viewpoints on the below.

We all understand there are several scenarios (see the examples from the presentations at Prague) where single stage labels are not enough to set up a connection.  We also know that one option to solve this is for operators to pre-provision an FA-LSP.  However, it’s not clear to us whether this is acceptable to operators – would they in fact want such connections to come up automatically?

Assuming they do, there are two options.

i)              Multi-stage labels
ii)             Induced H-LSPs

Solution (i) is not complete because there are still cases that will not work automatically with multistage labels; plus there are functional restrictions that others have pointed out already.  However, they are very significantly easier to implement, and if standardized should be supported by all devices.

Solution (ii) will solve most scenarios (given a suitable routing calculation) but depends on all devices having the capability to induce an H-LSP.  This, as far as we are aware, is not guaranteed and there’s currently no standard way to advertise this capability.

So it seems to us that while multistage labels may have some functional restrictions, they have some operational and implementation benefits that we should weigh dispassionately.  However, we have seen no input from operators (direct or indirect) to say whether they think that the configuration of FA-LSPs will actually be a problem for them, or if they expect connections to be automatic where possible.  Does anyone reading this have any feedback on that point?

Best regards,

Steve & Jon

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 13 April 2011 11:07
To: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [email-masked]
Subject: [CCAMP] R: R: Discussion of multi-stage solutions

Hi Sergio

Ok, understand.

Thank you for your clarification.

Best regards

Fei

:)
"BELOTTI, SERGIO (SERGIO)" <[email-masked]>

2011-04-13 16:06

收件人

"[email-masked]" <[email-masked]>

抄送

"'CCAMP'" <[email-masked]>, "[email-masked]" <[email-masked]>, Daniele Ceccarelli <[email-masked]>, Khuzema Pithewan <[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>, Rajan Rao <[email-masked]>, Fatai Zhang <[email-masked]>, "BELOTTI, SERGIO (SERGIO)" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

R: [CCAMP] R:  Discussion of multi-stage solutions

Hi Fei,

[Fei]Just my two cents, hierarchical LSP works well, but the non-hierarchical LSP works also.

Quote from RFC 3471 : From par. 3.2 ” A Generalized Label only carries a single level of label, i.e., it is
  non-hierarchical.  When multiple levels of label (LSPs within LSPs)
  are required, each LSP must be established separately, see [MPLS-
  HIERARCHY]”
Our interpretation is that based on Generalized Label Request , RSVP-TE returns only one label per link.
Doing in a different way means to change RSVP-TE standard behaviour. In our opinion “optimization” for specific case is not a strong argument.

[Fei] Agree, but the correct TSs allocation in OPUk can be carried back by the using of multi-stage labels in the context of  "non-FA" solution.
     Is there any other information lost?

See above : if you need an extra label you’re setting up an LSP .

[Fei] Why ODU2 LSP is must (of course, ODU2 LSP works well )?   Let's go back to the definition of LSP, and according to my understanding,  ODU2 LSP means the data plane (forwarding, OAM, protection, the last two is optional) and the control plane (the 5-tuple carried in the session and template object in signaling state).
Obvioulsy, the "non-FA solution" did not say that ODU2 is a LSP. The multi-stage labels represent  the allocated resources, which can be reflected by the routing and signaling processing,  but only the label informaion does not indicate that an independent session for the ODU2 is MUST.

Again, please justify why we should change what reported in the standard RFC 3471

Thanks

Best Regards

authors of [draft-zhang]

________________________________

Da: [email-masked] [mailto:[email-masked]]
Inviato: mercoledì 13 aprile 2011 3.20
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [email-masked]; Daniele Ceccarelli; Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Rajan Rao; BELOTTI, SERGIO (SERGIO); Fatai Zhang
Oggetto: R: [CCAMP] R: Discussion of multi-stage solutions

Hi Sergio

Thank you for your quick response.

See in line.

If there are some misunderstanding about your interpretation, please do not hesitate to let me know.

BR

Fei
"BELOTTI, SERGIO (SERGIO)" <[email-masked]>

2011-04-12 19:53

收件人

"[email-masked]" <[email-masked]>

抄送

"'CCAMP'" <[email-masked]>, "[email-masked]" <[email-masked]>, Khuzema Pithewan <[email-masked]>, Rajan Rao <[email-masked]>, Daniele Ceccarelli <[email-masked]>, Fatai Zhang <[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>, "BELOTTI, SERGIO (SERGIO)" <[email-masked]>

主题

R: [CCAMP] R:  Discussion of multi-stage solutions

Hi Fei,

see in line

Thanks

BR

authors of [draft-zhang]

________________________________

Da: [email-masked] [mailto:[email-masked]]
Inviato: martedì 12 aprile 2011 13.37
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [email-masked]; Khuzema Pithewan; Rajan Rao
Oggetto: Re: [CCAMP] R: Discussion of multi-stage solutions

Hi Sergio & Pietro

From a purely technical point of view it may be noticed that G.709 and G.872 define a 1:1:1 correspondence among ODUk:OTUk:Och.

[Fei]

Yeah, I agree. But for the case of ODU0-ODU2-ODU3, do we really need the existing of OTU2 and Och for OTU2?
Obvioulsy not. If i need to have a multiplexing on ODU 3 , only OTU3 is present.

[Fei]  Great, we have the same understanding about G.709 and G.872. So for the solution of multi-stage multiplexing, why the creation of ODU2 hierarchical LSP SHOULD be the only one?
        Just my two cents, hierarchical LSP works well, but the non-hierarchical LSP works also.

If yeah, why?

If not, ODU2 can be just used as multiplexing/demultiplexing. In this way, although ODU0 LSP is requested, ODU0 is inseted into ODU2 and ODU2 is inserted ODU3, I did not see why there SHOULD be some restriction that the label for ODU2 can not be returned.

Did I catch the idea of discussion?
It seems as though you did not catch the point. There is no 1:1 correspondence between ODUj and ODUk

[Fei] Of course, there is no 1:1 relationship between ODUj and ODUk.

If you need to multiplex ODU 2 into ODU3 , it is not a simple mapping, in fact you need to have a correct TSs allocation in OPUk.

[Fei] Agree, but the correct TSs allocation in OPUk can be carried back by the using of multi-stage labels in the context of  "non-FA" solution.
     Is there any other information lost?

You need to have an ODU2 LSP , and the label has to represent this TS allocation referred to ODUk.

[Fei] Why ODU2 LSP is must (of course, ODU2 LSP works well )?   Let's go back to the definition of LSP, and according to my understanding,  ODU2 LSP means the data plane (forwarding, OAM, protection, the last two is optional) and the control plane (the 5-tuple carried in the session and template object in signaling state).
Obvioulsy, the "non-FA solution" did not say that ODU2 is a LSP. The multi-stage labels represent  the allocated resources, which can be reflected by the routing and signaling processing,  but only the label informaion does not indicate that an independent session for the ODU2 is MUST.

You do not have the choice that instead is present in case of ODUk(j)-OTUk(j).

[Fei] Totally agree, this point is well written in the corresponding document.

Thanks and best regards

Fei
"BELOTTI, SERGIO (SERGIO)" <[email-masked]>
发件人:  [email-masked]

2011-04-12 17:17

收件人

Rajan Rao <[email-masked]>, Khuzema Pithewan <[email-masked]>

抄送

'CCAMP' <[email-masked]>

主题

[CCAMP] R:  Discussion of multi-stage solutions

Hi Rajan, Khuzema

It seems as though you did not capture completely our points of the example, which is used to prove that multi-stage labels should not be used.

In all the three cases, GMPLS have the session to manage and control the connection entities (e.g., ODU1, ODU3) . You may have misunderstood  on case 1 and case 2. In case 1, due to 1:1:1, there is wavelength connection session for ODU3.  For your response in case 2, ODU2 LSP can not be treated as ODU3, otherwise there is no session entity for ODU2 and in this way, the operator will lost the capability to control ODU2).

Hope this can clarify your misunderstanding.

Thanks

BR

authors of [draft-zhang]

________________________________

Da: Rajan Rao [mailto:[email-masked]]
Inviato: giovedì 7 aprile 2011 20.42
A: BELOTTI, SERGIO (SERGIO); Khuzema Pithewan
Cc: Fatai Zhang; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Oggetto: RE: [CCAMP] Discussion of multi-stage solutions

Sergio & Pietro,

Thanks for the example.  I think this is a good example to close the gap. Please see response inline.

Summary:   If an LSP works without CP representation at ODUk layer, it should work for other HO-ODUj layers as well.

Thanks
Rajan & Khuzema

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, April 04, 2011 2:04 AM
To: Rajan Rao; Khuzema Pithewan
Cc: Fatai Zhang; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO)
Subject: R: [CCAMP] Discussion of multi-stage solutions

Hi Rajan,Khuzema,

regarding point 1 from Adrian's mail, we think that Adrian's understanding is that multi-stage multiplexing will not be deployed extensively since the cost of multi-stage board will be high. This why he talked about "specific case ".

For point 2
"2. What is an LSP?
Historically we have ted ourselves in knots by failing to clearly understand
that an LSP is a data plane thing (a "connection") and also a the control
plane representation of the data pane thing (i.e. control plane, signaling
state). It is helpful to try to maintain a 1:1 mapping between the terms
in our work."

Adrian is substantially right and Fatai interpretation is also in line with Adrian's point.

From a purely technical point of view it may be noticed that G.709 and G.872 define a 1:1:1 correspondence among ODUk:OTUk:Och.
This permit to consider ODUk as having a double nature : or a simple section 1:1 with OTUk or a real LSP and in this caee ODUk is used as ODUj (e.g. we need to restore it: this is customer choice).
In a multi-stage hierarchy you have only the server ODUk that is compelled in the 1:1:1 relationship. Above ODUk this relationship is not present and all layers have to be treated as LSPs.

To illustrate better the concept suppose to have 3 nodes A,B,C and links A-B and B-C are OTU-3 links.

Case 1: ODU1 LSP from A to C switched in B no ODU3 restoration required
Only one signaling session will be provided containing per each link only one label  indicating the ODU3 tributary slots used by the ODU1.
This is because due to the 1:1:1 correspondence no LSP ODU3 is needed (ODU3 is a section).
[R& K] We agree there is no need for ODU3-LSP.  ODU3 is a path termination. If we go by your argument we would need another LSP at ODU3 layer as there is no control plane representation for ODU3.

If CP works w/o representation for ODU3 layer it should work for ODU2 layer as well.

Case 2: ODU1 LSP from A to C switched in B but ODU3 restoration is required: ODU3 LSP is terminated as in previous case but need to be an LSP to be restored: it is not considered a as a section but a 1 hop path.
First draw ODU3 LSP, with its own signaling session.
Then draw ODU1 LSP as in case 1.

[R &K]  Agree, here you would require ODU3-LSP as you are expecting restoration at ODU3 layer.  Clearly operator decides whether to have ODU3-LSP or not. Extend the same concept to ODU2 layer, if operators needs restoration, he will setup ODU2-LSP otherwise we treat ODU2 layer similar to ODU3 on the segment.

We don’t think this breaks any model.

Case 3: ODU3 path from A to C switched in B carrying an ODU1 from A to C (transparent in B).
First draw ODU3 LSP A to C with its own signaling session: the 1:1:1 correspondence is not applicable since it is a multi-hop path.
Then draw ODU1 LSP from A to C with its own signaling session.

This is for single stage. Multistage comes as an extension of this concept.
Suppose to have a multistage ODU1-ODU2-ODU3 over OTU3. Only for the ODU3 it is valid the 1:1:1 relationship.
So only for the ODU3 there is the choice to draw an LSP or not draw it.
ODU2 and ODU1 should be always signaled as LSPs independently from the number of hop.

Hope this clarify.
Thanks

Sergio and Pietro

Sergio Belotti
Portfolio Evolution
Terrestrial Optics Product Unit
ALCATEL-LUCENT
+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Rajan Rao
Inviato: venerdì 1 aprile 2011 12.56
A: Fatai Zhang; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'
Oggetto: Re: [CCAMP] Discussion of multi-stage solutions

Good. We are agreeing on the problem statement (3 bullets below). What this means is that we are not optimizing for a special case (#1 in Adrian's email), we are addressing network wide flexibility & scalability issue.

FA is a solution, no doubt. But to have full grooming flexibility at every node you would require FAs on every link in the network. This will lead to huge scalability issues in large networks.

Operators have 2 choice w.r.t FAs
(a) manually create or
(b) go for induced FA solution

Both these lead to operational complexity. To make life easier for the operators we need a solution that solves scalability issues and simplifies operations.

Multi-stage label is a solution that addresses above issues.

Please refer to Khuzema's response to Daniele's email (email attached). We will provide more examples.

Thanks
Rajan & Khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, April 01, 2011 7:19 AM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Rajan,

Obviously, the answer to all your questions is "YES", because this is the part of the premise for muxing hierarchy and this is why we are talking about FA and non-FA(multi-stage labels). The only disagreement between us is whether non-FA(multi-stage labels) is applicable or not.

I have repeated Daniele's question, and I would like to repeat once more as follows:

=====================================================================================================================
For the example in your slide 9 (Is this specific enough?), for the ODU1 connection request, why GMPLS should allocate the TSs for ODU2->ODU3 besides allocating the TSs for ODU1? In this way, 1:1 mapping is lost.

Could you give the WG an example to show that when signal type X in Traffic Parameters is requested, GMPLS will allocate the labels for signal type Y additionally?

You should just follow the GMPLS principle to answer this question.

====================================================================================================================

P.S., I will be on the plane to wait for your answers and keep silent for a few days because of my vacations.

Fatai

Thanks

----- Original Message -----
From: "Rajan Rao" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; "Sidd Aanand" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; <[email-masked]>; "'CCAMP'" <[email-masked]>
Sent: Friday, April 01, 2011 5:43 AM
Subject: RE: [CCAMP] Discussion of multi-stage solutions

Fatai,

Can you be more specific please? Which one of the following are you referring:

- multi-stage muxing is not a reality?
- restricted hierarchy is not a reality?
- network consisting of the above is not a reality?

Every scenario we discussed in the past 4 months for routing-draft-merge was related to the above cases.

You raise a good point on the practical deployment. This is the feedback we are looking for from the WG. If you have data available please share. May be we don't need IMCDs to begin with.  This will definitely simplify both routing and signaling extensions.

Thanks
Rajan

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, March 31, 2011 7:53 PM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi Rajan,

I think we should focus on the questions to discuss something. It does not make sense to say something by flying in the air. I think all the people are waiting for the scenarios from the practical deployments.

Please answer Daniele's question first.

Fatai

Thanks

----- Original Message -----
From: "Rajan Rao" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; "Sidd Aanand" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; <[email-masked]>; "'CCAMP'" <[email-masked]>
Sent: Friday, April 01, 2011 1:40 AM
Subject: RE: [CCAMP] Discussion of multi-stage solutions

Fatai,

If you have fewer such restricted links, yes it is an optimization.  The point you are missing is when you have 100s of such links in the network you gain scaling and ease of operation benefits.  This is our main point.

Thanks
Rajan

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, March 31, 2011 7:12 PM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'
Cc: Rajan Rao
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi Rajan,

You said you agreed with point #1, so we don't need to optimize for the special cases.

So the things are very clear, even though you did not answer our other questions directly.

Fatai

Thanks

----- Original Message -----
From: "Rajan Rao" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; "Sidd Aanand" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; <[email-masked]>; "'CCAMP'" <[email-masked]>
Cc: "Rajan Rao" <[email-masked]>
Sent: Friday, April 01, 2011 1:00 AM
Subject: RE: [CCAMP] Discussion of multi-stage solutions

Fatai,

There is no disagreement on point#1.  The proposal is optimized solution, a scalable solution & an operator friendly solution depending on the deployment scenarios.

With the introduction of IMCDs in routing draft we are admitting that muxing restrictions do exist. This is inevitable in the evolution of OTN.

If you have muxing restrictions on every hop in your network, you have 2 choice.  (A) have FAs on every segment or in certain parts of the network (B) use the label proposed in the draft.  Option (B) eliminates the need to have FA on every-hop in such scenarios. This is the key point you are missing.

Note that once you have FAs, it restrict the type of service you can carry (pl refer to examples in the draft).

Hope this helps.

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Thursday, March 31, 2011 6:31 PM
To: Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi Khuzema,

Actually, you don't answer Daniele's question. We know that you don't assume this ODU2 is a LSP.

Daniele asked you: for example, in your slide 9, for the ODU1 connection request, why you need to allocate the TSs for ODU2->ODU3 besides allocating the TSs for ODU1? In this way, 1:1 mapping is lost.

You should just follow the GMPLS principle to answer this question.

In addition, what is your opinion on Adrian's comment 1?

In my presentation, I asked a lot of questions and list a number of the issues about multi-stage labels. These questions and issues should be clarified clearly.

Fatai

Thanks

----- Original Message -----
From: "Khuzema Pithewan" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "Sidd Aanand" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; <[email-masked]>; "'CCAMP'" <[email-masked]>
Sent: Friday, April 01, 2011 12:09 AM
Subject: RE: [CCAMP] Discussion of multi-stage solutions

Hi,

If I correctly understand Daniel's example, ODU2 is not a LSP in control plane, it is just a local ODU2 endpoint in data plane. So the ODU0 lsp sets up ODU2<-ODU0 layer because it is mandated by restrictive multiplexing hierarchy on interface.

This is in context of draft draft-khuzema-ccamp-gmpls-signaling-g709-01. The ppt is located @ http://www.ietf.org/proceedings/80/slides/ccamp-24.pptx

Please refer to examples in draft and ppt for better understanding.

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Thursday, March 31, 2011 5:44 PM
To: Sidd Aanand; Daniele Ceccarelli; Khuzema Pithewan; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi Sidd,

This question should ask Khuzema, why there are multi labels for ODU0 connection request?

Fatai

Thanks

----- Original Message -----
From: "Sidd Aanand" <[email-masked]>
To: "Daniele Ceccarelli" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; <[email-masked]>; "'CCAMP'" <[email-masked]>
Sent: Thursday, March 31, 2011 11:38 PM
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Daniele,

Can you please explain why would we allocate labels for ODU2 when an ODU-0 LSP is requested?

Thanks,
Sidd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, March 31, 2011 9:06 PM
To: Khuzema Pithewan; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi Khuzema,

I agree with Adrian. If i correctly understood your proposal, when and ODU0 LSP is requested, the LSRs should allocate the labels for ODU2 besides allocating the labels for ODU0? In such a way the 1:1 mapping is lost.

My 2c

BR
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: giovedì 31 marzo 2011 11.24
To: [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] Discussion of multi-stage solutions

Hi,

On point#2. I agree with you that a LSP is control plane equivalent of a dataplane connection. But, not all data plane connection need to be modeled in control plane as lsp. We need to model only those dataplane connection in control plane as lsp (or FA), that matters in path computation, or need to be monitored for faults/restoration in control plane.

Best Regards
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, March 31, 2011 11:10 AM
To: 'CCAMP'
Subject: [CCAMP] Discussion of multi-stage solutions

Hi,

<speaking as an individual>

A couple of thoughts that we didn't have time to talk about in the meeting. The chairs may be right that the framework document can help us understand which scenarios we need to address.

1. We don't generally optimize for special cases.
That means we should pick a solution that we can apply across the board.
Separating out a solution that is optimized for a particular case (e.g.
single-
hop) would only be valuable if the savings are really large.

2. What is an LSP?
Historically we have ted ourselves in knots by failing to clearly understand
that an LSP is a data plane thing (a "connection") and also a the control
plane representation of the data pane thing (i.e. control plane, signaling
state). It is helpful to try to maintain a 1:1 mapping between the terms
in our work.

Cheers,
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
_______________________________________________
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_______________________________________________
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: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Tue, 24 May 2011 15:23:13 +0200

Hello Rajan,
we have copied the text and included comments marked as [PGSB].

Regards

Pietro & Sergio

==========================================================================================
A) Problem Statement & Motivation:

G.709-v3 defines multiplexing hierarchy with 2 or more levels.  We can expect operators to deploy networks which will have

      (1) Single stage multiplexing
      (2) Multi-stage multiplexing
      (3) Mix of (1) & (2), i.e. varying muxing stages on different segments

[PGSB] While the statement is correct in principle, we think it is better to make explicit the fact that multi-stage multiplexing
can be obtained as a result of the cascade of single stage network elements as well as equipping multi-stage multiplexing board on some NEs.
Moreover it cannot be assumed that in every case both the endpoints of a link support the same hierarchies.

In the evolution of OTN, it is conceivable that networks deployed will have varying muxing levels (1 thru 4 levels). Given such networks, the creation of ODU-services using GMPLS control plane should be simple for services requiring one or more intermediate ODU mux layers.

B) Requirements:

GMPLS signaling requirements for hierarchical OTN networks
(intended to go in section 5.2 of draft-ietf-ccamp-gmpls-g709-framework doc)

b.1. Support signaling mechanism to instantiate one ODU layer (service) at two ends of a Te-Link.

      - this is to cover services over single stage muxing capable Te-links

[PGSB] Correct

b.2. Support signaling mechanism to instantiate two or more ODU layers at two ends of a Te-Link.

      - this is to cover services over multi-stage muxing capable Te-links. This includes one or more intermediate HO-ODU layers + a service ODU layer.

b.3. Support signaling mechanism where number of intermediate ODU mux layers can vary on a link by link basis.

      - this is to cover the scenarios where the service ODU layer could exist at different muxing hierarchy on every Te-link (hop by hop) along the path potentially.

b.4. Support signaling mechanism to create service ODU layer where one or more intermediate ODU mux layers may be exist prior to service creation

      - the network operation may involve mix of manual and signaled provisioning; the operators may choose to create intermediate mux layers manually in certain scenarios.

b.5. Support signaling mechanism for egress control of ODU layer in relation to one or more intermediate ODU layers

      - this is to cover scenarios where an LSP can have varying intermediate ODU mux layers at output interface of the egress node [RFC4003].

[PGSB]  All the comments from b.2 to b.5 seems more related to a specific solution then to an architectural requirement. The architectural requirement is that signaling
as well as routing has to support the creation of ODU LSPs that may be recursively multiplexed independently from the way in which multiplexing is implemented as
NE cascade or with dedicated ports, and independently from the fact that multi-stage is symmetric or asymmetric (see previous comment).
An additional requirement is that the signaling has to scale where possible.

Following this reasoning, the framework should contain architectural requirements.
The info-model draft should justify why (if it is the case) H-LSPs are not enough and the proposed solution
The RSVP encoding draft should contain the protocol format/encodings associated to the solution

C) Solutions & Comparison:

The existing GMPLS solutions address multi-layered networks (MLN) using H-LSPs. The H-LSPs can be setup manually or dynamically (induced FAs) for multi-stage muxing scenarios. Operators have to go for FAs on every link (hop) if LO-ODU access is required at every node in the network. Such a scheme will lead to

 (a) Operational complexities
 (b) Scalability issues

In OTN networks with varying multiplexing levels, it is possible to create ODU-services without introducing FAs at intermediate mux layers on every hop (link).  The required intermediate mux layer instantiation can be taken care by signaling on a hop by hop basis. This works as intermediate mux layer need is a local matter between two neighboring nodes. Such a scheme requires signaling time-slots for one or more ODU layers.

Example-1: ODU0 service requiring intermediate ODU2 mux layers

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |
      | A  |---------------| B   |
      |    |  [OTU3 Link]  |     |
      |____|               |_____|

Switch at A and B are ODU0 granularity.  ODU0-LSP over this link requires ODU3 & ODU2 layers to be created before ODU0 connection can be established.

In order to create ODU0 LSP in the topology described above, ODU3 and ODU2 layers must be created. ODU2 and ODU3 layers either could be created upfront manually or could be created via signaling.

There are 2 ways to accomplish ODU layer creation via signaling:

1. Creating via FAs:  This approach should follow the methodology described in RFC 4206. In this example, following FAs need to be created in order to setup ODU0 LSP.
   a) ODU3 LSP (FA) from A to B
   b) ODU2 LSP (FA) from A to B

2. Creating via multi-stage label: This approach uses label to carry information for one or more ODU layers. The scope of the label is local to a link. In this example, the Multi-stage label would carry TS information about ODU2 and ODU0 layer in the label.

[PGSB] The carried information would be which OPU-2 is selected to carry the ODU0, which TS are used by ODU-2 in the OPU3 and which TS are used by ODU0 in the  OPU2.

Note that using H-LSP the information related to the selected OPU2 is an address in the NHOP/PHOP object.

Operators should have the choice to use option (1) or (2).

[PGSB] Correct

Example-2: Manual creation of intermediate ODU layer with E2E signaling for service LSPs

      - in the above example, the operator may create ODU2 layer manually at A & B
      - when ODU0 service is signlalled E2E, there is a need to identify the ODU2 (out of 4) to use
      - this can be accomplished with multi-stage label

[PGSB] Which is the difference with respect to example 1 ?

Example-3: Signaling for egress control [RFC 4003]

 - The figure below shows an example where there is a need for an intermediate ODU2 mux layer at the output interface of egress node-Z

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3
        CE----X---A-----B------C-----Z-------CE

              |--------ODU0-LSP------|

      - the ODU2 at the egress node-Z may be created by operator prior to ODU0 service
      - the signaling should have a way to identify the ODU2 instance to use on the egress
      - this can be easily accomplished with multi-stage label
      - As in e.g#1, the ODU2 mux layer can be created using multi-stage label if signaled option is chosen.

[PGSB]  Is it supposed that on link C-Z both C and Z export the same interfaces ? (otherwise FAs are mandatory)

In general looking at the examples, it seems that the multi-stage label is applicable only in case of single hops where
both the sides of the link equip the same hierarchies. Is this correct ? If so the assumption has to be clearly stated in the info-model document.

Pietro & Sergio

============================================
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

---

From: Rajan Rao <[email-masked]>
Date: Tue, 24 May 2011 21:00:11 +0000

Pietro &  Sergio,

Pl see response inline

From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:[email-masked]]
Sent: Tuesday, May 24, 2011 6:23 AM
To: Rajan Rao
Cc: Mohit Misra; [email-masked]; 'CCAMP'; BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: RE: [CCAMP] R: R: Discussion of multi-stage solutions

Hello Rajan,

Regards

Pietro & Sergio

[PGSB] While the statement is correct in principle, we think it is better to make explicit the fact that multi-stage multiplexing
can be obtained as a result of the cascade of single stage network elements as well as equipping multi-stage multiplexing board on some NEs.
[RR] not sure what you mean by cascade of single stage NEs. Please clarify.
Moreover it cannot be assumed that in every case both the endpoints of a link support the same hierarchies.

[RR] Agree that there will be cases where hierarchy may not be same at the two ends.

B) Requirements:

[PGSB] Correct

[PGSB]  All the comments from b.2 to b.5 seems more related to a specific solution then to an architectural requirement.

[RR] As you can see, the solution proposed is generic as it addresses single to 'N' mux levels ( currently defined and possible extensions to OTN).

The architectural requirement is that signaling
as well as routing has to support the creation of ODU LSPs that may be recursively multiplexed independently from the way in which multiplexing is implemented as
NE cascade or with dedicated ports, and independently from the fact that multi-stage is symmetric or asymmetric (see previous comment).

[RR] If I am not mistaken, you are asking for covering  requirements b.3 & b.4 above.  If so, that is the intent.   We will clarify asymmetric case.

[RR] yes.

Following this reasoning, the framework should contain architectural requirements.
[RR] yes.
The info-model draft should justify why (if it is the case) H-LSPs are not enough and the proposed solution
The RSVP encoding draft should contain the protocol format/encodings associated to the solution
[RR]   I think you are suggesting that multi-stage label as a solution should be in Info-model doc, right?

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |

[PGSB] The carried information would be which OPU-2 is selected to carry the ODU0, which TS are used by ODU-2 in the OPU3 and which TS are used by ODU0 in the  OPU2.
[RR] Agree; we can clarify that TSs come from OPU.

[PGSB] Correct
[RR] not sure what the final agreement was in the other email thread.  If there is an agreement to go with multi-stage label, then this doesn't arise.

[PGSB] Which is the difference with respect to example 1 ?
[RR] In this case, the operator has created intermediate DP layer(s) manually.  The signaling uses already created intermediate mux layers.  You need to identify the correct ODU instance to use within a HO-OPU.

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3

              |--------ODU0-LSP------|

[RR] yes, that is correct.
In general looking at the examples, it seems that the multi-stage label is applicable only in case of single hops where
both the sides of the link equip the same hierarchies. Is this correct ? If so the assumption has to be clearly stated in the info-model document.
[RR] Label in general is applicable hop by hop.  We will clarify asymmetric case with an example.
Thanks
Rajan

Pietro & Sergio

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 25 May 2011 14:14:37 +0200

Hi Rao

Pl see in line

Thanks

Sergio and Pietro

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]

________________________________
Da: Rajan Rao [mailto:[email-masked]]
Inviato: martedì 24 maggio 2011 23.00
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: Mohit Misra; [email-masked]; 'CCAMP'; BELOTTI, SERGIO (SERGIO)
Oggetto: RE: [CCAMP] R: R: Discussion of multi-stage solutions

Pietro &  Sergio,

Pl see response inline

Hello Rajan,

Regards

Pietro & Sergio

[PGSB] Please consider the attached official document sent to IETF from ITU, page 8 and following

B) Requirements:

[PGSB] Correct

[PGSB] The real requirement is what we wrote just below. From b.2 to b.5 it is explains characteristics of a solution e.g. in b.5 is consequent form the fact to have a multi-stage label, if you use H-LSP you do not have the problem .
The architectural requirement is that signaling
as well as routing has to support the creation of ODU LSPs that may be recursively multiplexed independently from the way in which multiplexing is implemented as
NE cascade or with dedicated ports, and independently from the fact that multi-stage is symmetric or asymmetric (see previous comment).

[RR] If I am not mistaken, you are asking for covering  requirements b.3 & b.4 above.  If so, that is the intent.   We will clarify asymmetric case.
[PGSB] The requirement is generic . If you think that the solution is covering also the asymmetric case please describe how.

[PGSB] yes

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |

[PGSB] Correct
[RR] not sure what the final agreement was in the other email thread.  If there is an agreement to go with multi-stage label, then this doesn't arise.
[PGSB] At the moment it seems as thoiugh there is not a definite agreement. We are still waiting for a chairs opinion. Anyway whether multi-stage label can be a solution it should be an optional one.

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3

              |--------ODU0-LSP------|

Pietro & Sergio

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 25 May 2011 14:16:37 +0200

Sorry, this time with attachment..

SERGIO BELOTTI

ALCATEL-LUCENT

Pietro &  Sergio,

Pl see response inline

Hello Rajan,

Regards

Pietro & Sergio

B) Requirements:

[PGSB] Correct

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |

[PGSB] Correct

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3

              |--------ODU0-LSP------|

Pietro & Sergio

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 May 2011 09:22:19 -0400

On 5/25/2011 8:14 AM, BELOTTI, SERGIO (SERGIO) wrote:
> [PGSB] Correct
> 
> [RR] not sure what the final agreement was in the other email thread. 
> If there is an agreement to go with multi-stage label, then this doesn’t
> arise.
> 
> [PGSB] At the moment it seems as thoiugh there is not a definite
> agreement. We are still waiting for a chairs opinion. Anyway whether
> multi-stage label can be a solution it should be an optional one.
> 

Sergio/Authors,

IMO it's not really the WG chair's place to define a technical position
(as chair), but rather to ensure that the WG consensus (and, of course,
that IETF process) is followed and documented.

It is the role of the WG document editor(s) to document WG
positions/decisions. In cases where there are open points on specific
portions of a document, I have found it useful to capture the text in
the WG document and flag the portions of such text as "Under discussion
and not representing WG consensus". This approach often helps identify
where there is agreement/disagreement, and where compromises may be
agreed upon. It also allows the WG to see exactly the technical points
and changes being debated.

Perhaps it would be helpful (in moving towards WG consensus) to take
such an approach with the framework document.

Lou (as chair)

---

From: Rajan Rao <[email-masked]>
Date: Wed, 25 May 2011 18:56:06 +0000

Hi Sergio & Pietro,

Please see response inline

Thanks
Rajan

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, May 25, 2011 5:15 AM
To: Rajan Rao
Cc: Mohit Misra; [email-masked]; 'CCAMP'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO)
Subject: R: [CCAMP] R: R: Discussion of multi-stage solutions

Hi Rao

Pl see in line

Thanks

Sergio and Pietro

SERGIO BELOTTI

ALCATEL-LUCENT

Pietro &  Sergio,

Pl see response inline

Hello Rajan,

Regards

Pietro & Sergio

[RR] In cases where asymmetry exists, you will need to have FAs.   The multi-stage label is not intended for FA creation on the fly.

Please refer to example-2 in
http://trac.tools.ietf.org/id/draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

B) Requirements:

[PGSB] Correct

[RR] please see the response above.  The intent of multi-stage label is not to facilitate creation of FAs.
Please refer to example-2 in
http://trac.tools.ietf.org/id/draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

[PGSB] yes

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |

[PGSB] Correct

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3

              |--------ODU0-LSP------|

Pietro & Sergio

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 25 May 2011 20:39:55 -0400

HI Sergio, Pietro,

I did not see the attachment referenced in the email (sent from ITU-T to IETF).

I do agree with Rajan that the multistage label proposal is not intended to create new FAs.  It seems like the confusion is over whether the text is referring to single or multi-stage multiplexing used on a network scale or within a single NE, I would think it is referring to the second.

Cheers,

Lyndon

From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Wednesday, May 25, 2011 5:15 AM
To: Rajan Rao
Cc: 'CCAMP'; [email-masked]; Mohit Misra
Subject: [CCAMP] R: R: R: Discussion of multi-stage solutions

Hi Rao

Pl see in line

Thanks

Sergio and Pietro

SERGIO BELOTTI

ALCATEL-LUCENT

Pietro &  Sergio,

Pl see response inline

Hello Rajan,

Regards

Pietro & Sergio

B) Requirements:

[PGSB] Correct

[PGSB] yes

         ODU1 ODU0       ODU0 ODU1
          \  /            \  /
          ODU2            ODU2
           |               |
            ODU3            ODU3
             |               |
            OTU3            OTU3
        _____                ______
      |    |               |     |

[PGSB] Correct

                                  ODU0
                                 |
                                ODU2
                                 |
                                ODU3
                                   |
                                OTU3

              |--------ODU0-LSP------|

Pietro & Sergio

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 26 May 2011 09:52:37 +0800

Hi Lou,

Thanks for your suggestions and we would like to follow your suggestions.

However, to make the work efficiently, we think an important decicion should be made by the WG or co-chairs first.

Should we break the rule defined in Section 3.2 of RFC3471?  This question is generic. 

We think only if the answer is "YES", we should discuss more on multi-stage labels, otherwise, it does not make sense to go far away.

==============================================================================
 A Generalized Label only carries a single level of label, i.e., it is  non-hierarchical.  When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS-HIERARCHY].
================================================================================

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

---

From: Lou Berger <[email-masked]>
Date: Thu, 26 May 2011 07:11:51 -0400

Hi Fatai,
	I assume you're speaking for the authors of
draft-ietf-ccamp-gmpls-g709-framework, correct?

I'm not sure how to read your mail.

> Thanks for your suggestions and we would like to follow your

Which implies that you plan on following my suggested next step.

Then you say:

> However, to make the work efficiently, we think an important decicion
> should be made by the WG or co-chairs first.
and
> We think only if the answer is "YES", we should discuss more on
> multi-stage labels, otherwise, it does not make sense to go far away.

This implies that you don't plan on following my suggested next step
(i.e., to capture the points under debate in the document and mark them
"as not representing consensus".)

Can you clarify which you/the authors of
draft-ietf-ccamp-gmpls-g709-framework intend?

Much thanks,
Lou

On 5/25/2011 9:52 PM, Fatai Zhang wrote:
> However, to make the work efficiently, we think an important decicion
> should be made by the WG or co-chairs first.
>  
> We think only if the answer is "YES", we should discuss more on
> multi-stage labels, otherwise, it does not make sense to go far away.
>  
>  A Generalized Label only carries a single level of label, i.e., it is 
> non-hierarchical.  When multiple levels of label (LSPs within LSPs) are
> required, each LSP must be established separately, see [MPLS-HIERARCHY].
> From: "Lou Berger" <[email-masked] <mailto:[email-masked]>>
> To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "Rajan Rao" <[email-masked] <mailto:[email-masked]>>;
> "'CCAMP'" <[email-masked] <mailto:[email-masked]>>;
> <[email-masked]
> <mailto:[email-masked]>>; "Mohit
> Misra" <[email-masked] <mailto:[email-masked]>>

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 27 May 2011 09:33:34 +0800

Hi Lou,

Sorry for that I mixed my roles, :-)~~

As one of the authors of draft-ietf-ccamp-gmpls-g709-framework, I (and other
authors) would like to follow your suggestions to capture the signaling
requirements in the generic way (ie., independent of some specific approach,
because framework document will not touch solution).

As one of the authors of draft-zhang-ccamp-gmpls-evolving-g709, in order to
move the "RSVP-TE extension" work forward (this thread is about multi-stage
solution), I think the following decision should be made first anyway.

Fatai

Thanks

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2011年5月26日 19:12
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Rajan Rao; 'CCAMP';
[email-masked]; Mohit Misra
Subject: Re: [CCAMP] R: R: R: Discussion of multi-stage solutions

Hi Fatai,

and

Much thanks,
Lou

> multi-stage labels, otherwise, it does not make sense to go far away.
============================================================================
==
> required, each LSP must be established separately, see [MPLS-HIERARCHY].
============================================================================
====

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 27 May 2011 10:05:27 +0200

Hi all,

Speaking as one of the authors of draft-ietf-ccamp-g709-framework I don't understand why we should speak about single stage or multi stage labels in the OTN framework draft.
I don't see any additional requirement here and whether existing signaling requirements are addressed via a signle stage or multi stage label is not an issue of the framework draft, is it?

It could be possible to move forward a signaling ID speaking about single and mutli stage labels with the explicit statement that there is still a WG agreement on which one (or both) to use, but I believe this is something that has nothing to deal with the framework.

Thanks
Daneile

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]] 
Sent: venerdì 27 maggio 2011 3.34
To: 'Lou Berger'
Cc: 'BELOTTI, SERGIO (SERGIO)'; 'Rajan Rao'; 'CCAMP'; [email-masked]; 'Mohit Misra'
Subject: RE: [CCAMP] R: R: R: Discussion of multi-stage solutions

Hi Lou,

As one of the authors of draft-ietf-ccamp-gmpls-g709-framework, I (and other
authors) would like to follow your suggestions to capture the signaling requirements in the generic way (ie., independent of some specific approach, because framework document will not touch solution).

As one of the authors of draft-zhang-ccamp-gmpls-evolving-g709, in order to move the "RSVP-TE extension" work forward (this thread is about multi-stage solution), I think the following decision should be made first anyway.

Fatai

Thanks

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: 2011年5月26日 19:12
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Rajan Rao; 'CCAMP'; [email-masked]; Mohit Misra
Subject: Re: [CCAMP] R: R: R: Discussion of multi-stage solutions

Hi Fatai,
	I assume you're speaking for the authors of draft-ietf-ccamp-gmpls-g709-framework, correct?

and
> multi-stage labels, otherwise, it does not make sense to go far away.

This implies that you don't plan on following my suggested next step (i.e., to capture the points under debate in the document and mark them "as not representing consensus".)

Can you clarify which you/the authors of draft-ietf-ccamp-gmpls-g709-framework intend?

Much thanks,
Lou

> are required, each LSP must be established separately, see [MPLS-HIERARCHY].
>
>> IMO it's not really the WG chair's place to define a technical 
>> position (as chair), but rather to ensure that the WG consensus (and, 
>> of course, that IETF process) is followed and documented.
>>
>> the WG document and flag the portions of such text as "Under 
>> discussion and not representing WG consensus". This approach often 
>> helps identify where there is agreement/disagreement, and where 
>> compromises may be agreed upon. It also allows the WG to see exactly 
>> the technical points and changes being debated.
>>