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

[<[e-mail]>]

Let me add something to this discussion that explains the nature of the underlying problem here.

First, note that there are always 2 layer networks present in all networking scenarios:
-       a TOS layer network that interfaces with external message/file/stream applications using appropriate adaptation functions...this is the raison d’être of all networking, and its implications are far reaching (though not often well understood/appreciated), eg it is why all non-TOS layer network MUST provide transparency as the key client service and don’t need E-NNIs, etc.;
-       a BOS layer network that modulates an EM Wave on either metallic/optical/radio media.

One should strive to reduce to a minimum (ideally none) the number of other layer networks that lie between these TOS and BOS mandatory extremes.  This TOS to BOS layer network count is a good 1st~ estimator of complexity/cost.  I’ll come back on what is needed to address this specific problem shortly...but first a little history....

The PDH created a fixed hierarchy of nested (co-cs mode) layer networks due to breakpoints in semiconductor technology advancement....initially based on a factor of 4 muxing increase.  SDH carried on with this approach albeit with a larger muxing ratio.  And G.709 has sadly done the same.

There is a fundamental flaw with this approach.  The problem is that the party who owns layer network N often wants its traffic units (frames) transparently carried over some lower layer network often owned by a different party.....which means creating a larger BW N+1 layer network traffic unit....which in turn requires creating an even larger N+2 layer network traffic unit to carry the layer N+1 layer network traffic units transparently...so it goes on and on....

Clearly we are creating massive hierarchies of layer networks for no real purpose...remember the raison d’être of *all* networking is to carry the message/file/stream external applications of the TOS layer network....all lower networks are subservient to this primary driver.  Some folks seem to have completely lost sight of this point in my experience.

Indeed some folks seem to have made a career out of promulgating the initial (semiconductor technology 'state-of-the-art' limitations of the) PDH hierarchical model...and then trying force all manner of additional/consequential unnecessary problems on all the layer networks so produced, eg E-NNIs in non-TOS layer networks, peer-interworking of different modes/technologies, TCM OAM in each unnecessary layer network, etc.

Aside=> I am not going to discuss what is required to properly solve the ‘QoS/importance/arbitrage’ networking issue of the external message/file/stream applications here....but it for sure is not creating lots of traffic classes in a single network mode/technology as folks have tried/failed for the last 30 years - especially one that is not TOS.

We need a solution to stop the never-ending fixed hierarchy model.  IMO we need a digital wrapper approach to the true BOS layer network.  That is, a generic framing structure that we can simply increase the bit rate of to suit increasing speed requirements.

regards, Neil

Neil Harrison
BT Design

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000




From: [e-mail] [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: 19 April 2011 21:22
To: John E Drake; Rajan Rao; Steve Balls; [e-mail]
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: R: Discussion of multi-stage solutions

John,

Let me illustrate on a simple and stupid example. Suppose:

N1------------N2--------------N3------------N4,

Suppose, all the nodes can only switch OD0overOD1overODU2overODU3overODU4overODU5.

Suppose, I need to setup an OD0 connection between N1 and N4.

Single stage approach says:
1) Setup ODU5 LSP;
2) Setup ODU4 LSP;
3) Setup ODU3 LSP;
4) Setup ODU2 LSP;
5) Setup ODU1 LSP;
6) Setup ODU0 LSP;

Multi- stage approach says:

1) Setup ODU0 LSP

Igor


Actually the control plane is aware of multi-stage labels; they are present in the signaling messages.  Furthermore, it needs to properly configure the cross-connect with the multi-stage labels.

However, that was not the point of either of my two previous emails.  Rather, it was that given the choice between hop-by-hop multi-stage labels for N individual ODUj LSPs and 1 multi-hop hierarchical LSP,  why would anyone ever choose the former?

Thanks,

John

Sent from my iPhone

From: Igor Bryskin [mailto:[e-mail]]
Sent: Tuesday, April 19, 2011 12:48 PM
To: John E Drake; Rajan Rao; Steve Balls; [e-mail]
Cc: 'CCAMP'
Subject: RE: 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:[e-mail]]
Sent: Tuesday, April 19, 2011 3:31 PM
To: Igor Bryskin; Rajan Rao; Steve Balls; [e-mail]
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:[e-mail]]
Sent: Tuesday, April 19, 2011 12:03 PM
To: John E Drake; Rajan Rao; Steve Balls; [e-mail]
Cc: 'CCAMP'
Subject: RE: Re: [CCAMP] R: R: Discussion of multi-stage solutions

John,

Please, see in line

From: John E Drake [mailto:[e-mail]]
Sent: Tuesday, April 19, 2011 2:26 PM
To: Igor Bryskin; Rajan Rao; Steve Balls; [e-mail]
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:[e-mail]]
Sent: Tuesday, April 19, 2011 11:15 AM
To: Rajan Rao; John E Drake; Steve Balls; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Rajan Rao
Sent: Tuesday, April 19, 2011 1:52 PM
To: John E Drake; Steve Balls; [e-mail]
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:[e-mail]]
Sent: Tuesday, April 19, 2011 10:43 AM
To: Rajan Rao; Steve Balls; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Rajan Rao
Sent: Tuesday, April 19, 2011 10:38 AM
To: Steve Balls; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Steve Balls
Sent: Tuesday, April 19, 2011 9:50 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]]
Sent: 18 April 2011 03:27
To: Steve Balls
Cc: 'CCAMP'; [e-mail]
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 <[e-mail]>
发件人:  [e-mail]
2011-04-14 下午 10:18
收件人
'CCAMP' <[e-mail]>
抄送

主题
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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 13 April 2011 11:07
To: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [e-mail]
Subject: [CCAMP] R: R: Discussion of multi-stage solutions


Hi Sergio

Ok, understand.

Thank you for your clarification.

Best regards

Fei

:)
"BELOTTI, SERGIO (SERGIO)" <[e-mail]>
2011-04-13 16:06

收件人
"[e-mail]" <[e-mail]>
抄送
"'CCAMP'" <[e-mail]>, "[e-mail]" <[e-mail]>, Daniele Ceccarelli <[e-mail]>, Khuzema Pithewan <[e-mail]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[e-mail]>, Rajan Rao <[e-mail]>, Fatai Zhang <[e-mail]>, "BELOTTI, SERGIO (SERGIO)" <[e-mail]>, "[e-mail]" <[e-mail]>
主题
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: [e-mail] [mailto:[e-mail]]
Inviato: mercoledì 13 aprile 2011 3.20
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [e-mail]; 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)" <[e-mail]>
2011-04-12 19:53


收件人
"[e-mail]" <[e-mail]>
抄送
"'CCAMP'" <[e-mail]>, "[e-mail]" <[e-mail]>, Khuzema Pithewan <[e-mail]>, Rajan Rao <[e-mail]>, Daniele Ceccarelli <[e-mail]>, Fatai Zhang <[e-mail]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[e-mail]>, "BELOTTI, SERGIO (SERGIO)" <[e-mail]>
主题
R: [CCAMP] R:  Discussion of multi-stage solutions












Hi Fei,

see in line

Thanks

BR

authors of [draft-zhang]



________________________________________



Da: [e-mail] [mailto:[e-mail]]
Inviato: martedì 12 aprile 2011 13.37
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [e-mail]; 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)" <[e-mail]>
发件人:  [e-mail]
2011-04-12 17:17



收件人
Rajan Rao <[e-mail]>, Khuzema Pithewan <[e-mail]>
抄送
'CCAMP' <[e-mail]>
主题
[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:[e-mail]]
Inviato: giovedì 7 aprile 2011 20.42
A: BELOTTI, SERGIO (SERGIO); Khuzema Pithewan
Cc: Fatai Zhang; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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:[e-mail]]
Sent: Monday, April 04, 2011 2:04 AM
To: Rajan Rao; Khuzema Pithewan
Cc: Fatai Zhang; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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
[phone]
[phone]


-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di Rajan Rao
Inviato: venerdì 1 aprile 2011 12.56
A: Fatai Zhang; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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:[e-mail]]
Sent: Friday, April 01, 2011 7:19 AM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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" <[e-mail]>
To: "Fatai Zhang" <[e-mail]>; "Khuzema Pithewan" <[e-mail]>; "Sidd Aanand" <[e-mail]>; "Daniele Ceccarelli" <[e-mail]>; <[e-mail]>; "'CCAMP'" <[e-mail]>
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:[e-mail]]
Sent: Thursday, March 31, 2011 7:53 PM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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" <[e-mail]>
To: "Fatai Zhang" <[e-mail]>; "Khuzema Pithewan" <[e-mail]>; "Sidd Aanand" <[e-mail]>; "Daniele Ceccarelli" <[e-mail]>; <[e-mail]>; "'CCAMP'" <[e-mail]>
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:[e-mail]]
Sent: Thursday, March 31, 2011 7:12 PM
To: Rajan Rao; Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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" <[e-mail]>
To: "Fatai Zhang" <[e-mail]>; "Khuzema Pithewan" <[e-mail]>; "Sidd Aanand" <[e-mail]>; "Daniele Ceccarelli" <[e-mail]>; <[e-mail]>; "'CCAMP'" <[e-mail]>
Cc: "Rajan Rao" <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf Of Fatai Zhang
Sent: Thursday, March 31, 2011 6:31 PM
To: Khuzema Pithewan; Sidd Aanand; Daniele Ceccarelli; [e-mail]; '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" <[e-mail]>
To: "Fatai Zhang" <[e-mail]>; "Sidd Aanand" <[e-mail]>; "Daniele Ceccarelli" <[e-mail]>; <[e-mail]>; "'CCAMP'" <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf Of Fatai Zhang
Sent: Thursday, March 31, 2011 5:44 PM
To: Sidd Aanand; Daniele Ceccarelli; Khuzema Pithewan; [e-mail]; '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" <[e-mail]>
To: "Daniele Ceccarelli" <[e-mail]>; "Khuzema Pithewan" <[e-mail]>; <[e-mail]>; "'CCAMP'" <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, March 31, 2011 9:06 PM
To: Khuzema Pithewan; [e-mail]; '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: [e-mail] [mailto:[e-mail]] On Behalf Of Khuzema Pithewan
Sent: giovedì 31 marzo 2011 11.24
To: [e-mail]; '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: [e-mail] [mailto:[e-mail]] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp