Subject: Re: [CCAMP] R: FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Mon, 1 Nov 2010 16:21:38 -0400

It is not the intention of G.709 (or any ITU Recommendation) to dictate equipment functionality. This sentence on scope in revised G709 is simply saying that the number of levels supported within equipment or a domain is outside the scope of the Recommendation. This will vary depending on an operator's needs and the application. This sentence was added to G709 to clarify this understanding (for those with ITU membership, the reports are quite clear).

GMPLS also does not dictate/limit what data plane functionality is supported in equipment/domain and solution work should not preclude multiplexing support within a domain as it is a G.709 capability - a key capability for large operators.

Deborah

(Chair hat off/Operator hat on)

From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Sunday, October 31, 2010 6:21 AM
To: Rajan Rao
Cc: Khuzema Pithewan; [email-masked]; Radhakrishna Valiveti; Mohit Misra
Subject: [CCAMP] R: FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all as requirement/feature in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Before thinking about specific signaling and routing solutions we need to have stable ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Routing and Signaling drafts) we just placed some placeholder on the subject.

[AK, KP, RR] { 

 Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to be single stage. The G.709 OTN frame formats fully support this capability. 

Vendors may choose to implement limited number of muxing levels. This should not impact the signaling solution we come up with.

}

Rao,

I'd like to understand where in Figure-7.1A (G.709 12/2009) you desume multi-stage multiplexing as requirement? This is an interesting point since I was present in the ITU meeting in which this figure was discussed and know perfectly story and meaning of it.

Are you talking about single domain or multi-domain? This is the first clarification needed to have a clear picture of what we are discussing.

About sinle domain ,

on the opposite of your statement,  is explicitly said that any information and picture about possible interconnection of different multiplexing is outside the scope of the G.709. 

In the 7-1A you can deduce information about the possible new multiplexing capability , needed to introduce due to the new container not the chain of possible multiplexing stage. Full stop.

What we context in your sentence it is not the "possibility) to make in a  multi-domain network heterogeneous interconnection of stage of multiplexing but that this is a requirement as you mention for the new container like ODU0 or ODUflex that instead are clear differentiation respect older G.709 version. 

If you are referring to multi-domain , so your statement about requirement , want to say we need to touch multi-domain multi-area signalling and routing scope ??  

Best Regards

Sergio

Sergio Belotti 

System Architecture 
Optics Division-Terrestrial Optics Unit 
ALCATEL-LUCENT 

+39 039 6863033 
+39 039 6863590 

________________________________

Da: [email-masked] [mailto:[email-masked]] Per conto di Rajan Rao
Inviato: venerdì 29 ottobre 2010 21.05
A: [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Oggetto: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Fatai,

Interesting discussion. Please find the response below. 

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

You said there are the following differences between two drafts:

-  G.709 multi-stage multiplexing (v3 & beyond)

-  NMC treatment (ref to section-4 in the draft)

-  Support for VCAT (NVC >1 )

- TPN format

We have to repeat that there is not much substantial difference between two drafts except multi-stage muxing. 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before and it is quite easy for [draft-zhang] to do that. For example, for NMC, there is an editors note in the previous versions  such as 04 version to discuss NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviously that [draft-zhang] can support it.

Now we can focus your key driver-multi-stage muxing.

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all as requirement/feature in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Before thinking about specific signaling and routing solutions we need to have stable ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Routing and Signaling drafts) we just placed some placeholder on the subject.

[AK, KP, RR] { 

 Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to be single stage. The G.709 OTN frame formats fully support this capability. 

Vendors may choose to implement limited number of muxing levels. This should not impact the signaling solution we come up with.

}

2) We are confused by your simplified multi-stage muxing label distribution rule

There is no detailed text to describe multi-stage muxing label distribution procedures in your draft and your explaination in your below mail just focuses on one single node rather than how to create the end-to-end LSP.

It is known that GMPLS standard procedure impose that every node has to allocate a label/labels consistent with the Generalized Label Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no disagreement here.  Generalized label request doesn't change. It is fully consistent with RFC-4328. This is precisely the reason why we spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).

Multi-stage label concept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Request  which is relayed end-to-end.

}

For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we need a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute the labels in Node B, C, D? What is the traffic parameters will be transmitted in the nodes B, C, D and nodes A, E?

[AK, KP, RR]{ 

There are 2 ways to handle this case: with FA or without FA. Both are explained with an example below      

 We have expanded the example as follows:

          A---------------B---------------C---------------D----------------E

                OTU1             OTU3            OTU3          OTU1

 Assume that:

   - ODU0 LSP is created from A to E. 

   - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0  or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. 

-    Generalized Label request in this case will be for ODU0 only. 

Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering and multi-stage label that needs to exchanged between the nodes. 

          A---------------B---------------C---------------D----------------E

                OTU1             OTU3            OTU3          OTU1

          |<-------------------------------------------------------------à|         

          |                           ODU0                                 |

          |ß------------à|                               |ß------------à|           

          |       ODU1     |                               |      ODU1     |

          |                |ß-----------à|ß------------à|               |

          |                |      ODU2    |      ODU2      |               |

          |                |ß-----------à|ß------------à|               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

#of stages|        1       |         2    |         2      |         1     |

Stage-1   |   ODU1ßODU0   |   ODU3ßODU2  |   ODU3ßODU2   |    ODU1ßODU0  |

Stage-2   |                |   ODU2ßODU0  |   ODU2ßODU0   |               |

------------------------------------------------------------------------------

Case-2) With FA: 

If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-Link by itself. In that case, ODU0 will be routed directly over ODU2 - which is single stage only (no need of multi-stage label in that case). 

The creation of FA-LSP is outside the scope of our draft. 

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt]

 

----- Original Message ----- 

From: "Rajan Rao" <[email-masked]>

To: "Fatai Zhang" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; "Mohit Misra" <[email-masked]>; "Ashok Kunjidhapatham" <[email-masked]>

Cc: <[email-masked]>; "Biao Lu" <[email-masked]>

Sent: Thursday, October 28, 2010 2:17 PM

Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Fatai,

Please see response inline.

thanks

Rajan

________________________________________

From: Fatai Zhang [[email-masked]]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: [email-masked]; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

Happy to see your draft, but except multi-stage muxing supported in your draft,  I don't see any substantial difference between your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

[Rajan]{

Multi stage muxing is one of the key drivers for  signaling extensions. Any solution is incomplete without this. The label format proposed is intended to support G.709-v3 & future OTN extensions. Section 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

We see following key differences between the drafts:

 Our draft addresses

-          G.709 multi-stage multiplexing (v3 & beyond)

-          NMC treatment (ref to section-4 in the draft)

-          Support for VCAT (NVC >1 )

}

You may say that TPN info is incorporated into label Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already stated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label).

[Rajan]{

The key thing here is the mux layers.  The TPN in label object is intended to address per mux layer case.... more efficient. 

I think this should be captured in framework doc (section 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly). 

}

In addtion, for multi-stage muxing, I really suspect that it can be resolved so easily, because it is MLN stuff and it needs to indicate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in this way as your draft describes, we all will be much happy.

[Rajan]{

The label structure we have defined is to address muxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn't result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.

 For example,  we need 3 labels to create an ODU0 LSP with following muxing structure on a given TeLink

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0

Num-of-mux-stages = 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set

}

Best Regards

Fatai

----- Original Message -----

From: Rajan Rao<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

Cc: Khuzema Pithewan<mailto:[email-masked]> ; Mohit Misra<mailto:[email-masked]>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi,

We have a draft on "GMPLS Signaling extensions for OTN" available for review.  It can be accessed from the following link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

The above draft is not on IETF repository as we missed the submission deadline.  We will submit to IETF as soon as possible.

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, there is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is also specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

Thanks

Authors

________________________________

_______________________________________________

CCAMP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ccamp

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 02 Nov 2010 17:30:09 +0800

Hi Rajan,

I fully agree with John.

I also don't understand how the ODU2 connection (along B-C-D) can be instantiated or established. 

Could you prepare some slides with animation to show the action for each node?

Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: John E Drake 
  To: Rajan Rao ; [email-masked] ; Fatai Zhang 
  Cc: Khuzema Pithewan ; Mohit Misra ; Radhakrishna Valiveti ; Biao Lu 
  Sent: Saturday, October 30, 2010 10:35 PM
  Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  Comments inline.

  Sent from my iPhone

  From: Rajan Rao [mailto:[email-masked]] 
  Sent: Friday, October 29, 2010 6:00 PM
  To: John E Drake; [email-masked]; Fatai Zhang
  Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu; Rajan Rao
  Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  John, et al

  With the muxing structure of G.709,   customers may chose to use the mux stages their own ways. Having FA-LSPs or virtual links on pt-2-pt segments doesn't make much sense and will lead to scaling issues & managing complexities.

  JD:  You are making an assertion.   Since in this example we are talking about a node that can activate an ODU2 dynamically, it could advertise the ODU0, as you suggested.  Why you would want to do this rather than having multi-hop FAs between select points in the network is beyond me, except as a debating point.

  JD:  However, the more important point is that *existing* GMPLS signaling *exactly* supports the configuration in your example. 

  The signaling extensions can easily take care of OTN muxing hierarchy as shown in our draft.  We should address MLN RFC-6001 alignment  by adding OTN-MLN details in the  framework doc.

  JD:  See above.  Btw, in your proposal where are the parameters associated with establishing the ODU2 carried? 

  Thanks

  Rajan

  From: Rajan Rao 
  Sent: Friday, October 29, 2010 2:50 PM
  To: John E Drake; [email-masked]; Fatai Zhang
  Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu
  Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  John, et al

  Thanks

  Rajan

  From: John E Drake [mailto:[email-masked]] 
  Sent: Friday, October 29, 2010 1:41 PM
  To: Rajan Rao; [email-masked]; Fatai Zhang
  Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
  Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  Hi,

  Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link.  This is necessary because otherwise the CSPF at A will not consider routing the ODU0 LSP via B, C, and D.

  [Rajan] {

  This is not the case.  Even without virtual TE link or FA-LSP  the ODU0 LSPs can be setup between A-E. This is  because we advertise #ODU0s for OTU3 links B-C & C-D.  Note that #ODU0 containers advertised is non-zero even though TSG=2.5G. This is the key point here. 

  We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate sub-TLV within SCSI. 

  The instantiation of ODU2 to support ODU0 is done as part of signaling which brings in the label format for mux levels.  The instantiation of mux layers is a local matter.  This can be different on each segment. The labels tell exactly what to instantiate on the local interface.  

  In this example, each NE decides locally (segment basis) how ODU0 should/can be supported.  If it requires additional mux layers they are requested in the label going down stream.

  }

  When the ODU0 Path message is received at B, it is held up while a separate ODU2 Path message is sent from B to C to D to activate the B-D ODU2 Link.  Once it is activated, using LSP Hierarchy ( RFC4206) B sends the ODU0 request to D, which in turn sends it to E.

  [Rajan] {

  This is allowed. As said below, this is an alternate way. We can do without this as shown in the examples.

  }

  When we were first developing GMPLS, we looked at packaging multiple LSP setup requests together and decided it was a Bad IdeaT.  So, the multistage signaling you are suggesting is not only unnecessary, but not in alignment with the GMPLS architecture.

  [Rajan] {

   Not sure on the alignment.    Think of a scenario where I have muxing restriction within an FA. What do you do here?  Create more FAs?  Works of course with scaling implications.   

  }

  The other alternatives are to instantiate the B-D ODU2 link or  B-C and C-D ODU2 links beforehand. 

  [Rajan] {

   Agree,  this is listed as FA case in the example below.

  }

  Thanks,

  John

  Sent from my iPhone

  From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
  Sent: Friday, October 29, 2010 12:05 PM
  To: [email-masked]; Fatai Zhang
  Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
  Subject: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  Fatai,

  Authors of draft-khuzema

  -----Original Message-----
  From: Fatai Zhang [mailto:[email-masked]] 
  Sent: Friday, October 29, 2010 1:26 PM
  To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
  Cc: [email-masked]; Biao Lu
  Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  Hi Rajan,

  - TPN format

  [AK, KP, RR] { 

  }

  [AK, KP, RR]{

  }

  [AK, KP, RR]{ 

                  OTU1             OTU3            OTU3          OTU1

   Assume that:

   

                  OTU1             OTU3            OTU3          OTU1

            |                           ODU0                                 |

            |       ODU1     |                               |      ODU1     |

            |                |      ODU2    |      ODU2      |               |

            |                |      ODU3    |      ODU3      |               |

            |                |              |                |               |

  Label     |                |              |                |               |

  Case-2) With FA: 

  }

  Thanks

  Ashok/Khuzema/Rajan

  Thanks,

   

  ----- Original Message ----- 

   

  Fatai,

  thanks

  Rajan

  Hi Rajan,

  [Rajan]{

   Our draft addresses

  }

  [Rajan]{

  The key thing here is the mux layers.  The TPN in label object is intended to address per mux layer case.. more efficient. 

  }

  [Rajan]{

  Num-of-mux-stages = 3

  }

  Best Regards

  Fatai

  ----- Original Message -----

  Hi,

  Abstract:

  Thanks

  Authors

  CCAMP mailing list

  [email-masked]

---

From: John E Drake <[email-masked]>
Date: Tue, 2 Nov 2010 05:43:17 -0700

So, in addition to there not being any place in the ODU0 Path message to place the parameters (e.g., T  Spec and five tuple) needed to establish the ODU2, the ODU0 Path message will specify an TE link on which to place the ODU0, the ODU2, which doesn't exist yet.

To make the point again, this is already a solved problem in GMPLS.

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
Sent: Tuesday, November 02, 2010 2:30 AM
To: John E Drake; Rajan Rao; [email-masked]
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu
Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

I fully agree with John.

Best Regards

Fatai

----- Original Message -----
From: John E Drake<mailto:[email-masked]>
To: Rajan Rao<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Fatai Zhang<mailto:[email-masked]>
Cc: Khuzema Pithewan<mailto:[email-masked]> ; Mohit Misra<mailto:[email-masked]> ; Radhakrishna Valiveti<mailto:[email-masked]> ; Biao Lu<mailto:[email-masked]>
Sent: Saturday, October 30, 2010 10:35 PM
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Comments inline.

Sent from my iPhone

To: John E Drake; [email-masked]<mailto:[email-masked]>; Fatai Zhang

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

When we were first developing GMPLS, we looked at packaging multiple LSP setup requests together and decided it was a Bad Idea(tm).  So, the multistage signaling you are suggesting is not only unnecessary, but not in alignment with the GMPLS architecture.
[Rajan] {
 Not sure on the alignment.    Think of a scenario where I have muxing restriction within an FA. What do you do here?  Create more FAs?  Works of course with scaling implications.
}
The other alternatives are to instantiate the B-D ODU2 link or  B-C and C-D ODU2 links beforehand.
[Rajan] {
 Agree,  this is listed as FA case in the example below.
}

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |<--------------------------------------------------------------->|

          |                           ODU0                                 |

          |<---------------->|                               |<---------------->|

          |       ODU1     |                               |      ODU1     |

          |                |<--------------->|<---------------->|               |

          |                |      ODU2    |      ODU2      |               |

          |                |<--------------->|<---------------->|               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Stage-1   |   ODU1<--ODU0   |   ODU3<--ODU2  |   ODU3<--ODU2   |    ODU1<--ODU0  |

Stage-2   |                |   ODU2<--ODU0  |   ODU2<--ODU0   |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Tue, 2 Nov 2010 10:18:37 -0500

Hi John,

If the network consists of a mix of equipment - some that includes support for ODU0 while other does not, then it cannot be assumed that dynamically creating an ODU2 to the immediate neighbor will allow for the ODU0 to be transported.  To amplify, consider the following example:

A---B---C---D---E

where nodes A, C and E support ODU0 while B and D do not.

For an end to end ODU0 to be established, FAs will need to be created between A and C as well as C and E.  This can be done in advance (as GMPLS is able to do) or they can be created dynamically.  If we require them to be created in advance, we place a burden on the operator.  If we create the multi-hop FA dynamically, Node A needs to be able to tell 1) if FAs are necessary and 2) where to have them stop/start as a part of path computation.  This information is unavailable with the existing advertisements.

When the FA is dynamically created, an ODU2-scoped RSVP session is invoked separate from the ODU0 RSVP session.  The ODU2 session conveys the specific parameters for the ODU2 FA, while the ODU0 carries the specific parameters for the ODU0 FA.

And finally, you are correct there is possibility of creating ODU2 FAs separately for A-C and C-E as well as one "long" ODU2 FA from A-E.  You ask why the shorter FAs would be used when the longer is possible.  This is a matter of operator policy - they may have a large number of ODU0 demands in their network and may wish to have C act as a ODU0 grooming point allowing for better use of the ODU2 FAs.

An additional question is why would the operator setup an ODU2 FA if an ODU1 FA carrying ODU0s the was possible.  Again, this is a matter of operator policy.   They may wish to have the ODU0s carried over an ODU1 FA that used separate ODU2 FAs that go from A-B, B-C, C-D and D-E.  Of course, it is necessary to know that the equipment has that capability.

Jonathan Sadler

P.S. Scenarios similar to the one above are included in the Liaison that was sent by ITU-T to CCAMP.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Saturday, October 30, 2010 9:35 AM
To: Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit Misra
Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Comments inline.

Sent from my iPhone

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Tue, 2 Nov 2010 08:43:19 -0700

Comments inline

Sent from my iPhone

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Tuesday, November 02, 2010 8:19 AM
To: John E Drake; Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit Misra
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi John,

A---B---C---D---E

JD:  That's not the example we have been discussing. The  A-B and D-E links support  ODU0.  One or more ODU2 LSPs need to be created between B and D in order to support the A-E ODU0 LSP.

JD:  In the example we have been considering, rather than the one to which you switched, node A does not need to know where FAs need to be established.  Your last sentence is correct but gratuitous;  we are in the process of determining how to support the latest version of OTN.

JD:  Absolutely correct.

JD:  Again, in the example we have been considering,  I don't see any advantage to a two FAs, B-C and C-D, versus a single FA, B-D,  between the same pair of nodes.  More importantly, though, you seem to be agreeing with my statement "having multi-hop FAs between select points in the network", where select points would be the grooming points you mention.

Jonathan Sadler

Comments inline.

Sent from my iPhone

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 2 Nov 2010 18:51:05 +0100

Hi Deborah,

I think we are aligned on the point: my statement did not want  to preclude any support functionality from GMPLS point of view but just make an important and essential clarification about OTN , G.709 requirement.

BR

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

________________________________
Da: BRUNGARD, DEBORAH A (ATTLABS) [mailto:[email-masked]]
Inviato: lunedì 1 novembre 2010 21.22
A: BELOTTI, SERGIO (SERGIO); Rajan Rao
Cc: Khuzema Pithewan; [email-masked]; Radhakrishna Valiveti; Mohit Misra
Oggetto: RE: [CCAMP] R: FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Deborah

[AK, KP, RR] {

Rao,

Best Regards

Sergio

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Tue, 2 Nov 2010 11:37:57 -0700

FA approach is well understood and is one way to address muxing hierarchy.  There is no disagreement here.  What we are bringing to the table is an alternate and simple mechanism to address OTN muxing hierarchy.

If you look at the ODU0 example carefully, we do NOT have an LSP at ODU2 layer between nodes B-C or C-D.  This is not required when nodes are ODU0 switching capable.   Here is how it works:

1.       The muxing restriction is a local matter to the segment.

2.       The need to create one or more muxing layers (doesn't mean an LSP) to support a service is decided by nodes on the segment.

a.       The muxing capability on a segment is known via LMP or configuration

3.       The muxing layers can vary segment to segment for the same service

Steps during ODU0 service creation:

·         When ODU0-LSP request arrives at B from A,  node-B knows it requires ODU2 mux layer to support ODU0 service on segment B-C. It indicates to node-C  via label format as specified in draft-khuzema:

o   Num-of-mux-stages = 2

o   An ODU2-label: which includes these fields

§  ST = ODU2

§  TSs carved out of OPU3 ( 8 bits set out of 32)

§  TS granularity of the OPU2 (T-bit = 1.25G)

§  TPN

§  There is no traffic parameter for ODU2.  There is no request to create ODU2-LSP here. It is just a mux layer required to support ODU0.

o   An ODU0-label: which includes the following:

§  ST = ODU0

§  TSs carved out of OPU2 ( 1 bits set out of 8)

§  T-bit= 1.25 ( don't care)

§  TPN

·         When this request arrives at node-C, it knows from the label that node-B is requesting an ODU2 mux layer creation (again, this is not a request for ODU2-LSP creation) to support ODU0 service.

o   Node-B creates ODU2 mux layer

o   Rest is service layer creation.......

·         Similar steps as above on Link C-D

This scheme is simple because it eliminates the need for FA-LSP & additional Te-Links for each intermediate mux layer.   FA is required in cases where switching limitations exist (e.g. if intermediate nodes are not capable of ODU0 switching).

Best regards
Rajan

From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, November 02, 2010 8:43 AM
To: Sadler, Jonathan B.; Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit Misra
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Comments inline

Sent from my iPhone

Hi John,

A---B---C---D---E

JD:  Absolutely correct.

Jonathan Sadler

Comments inline.

Sent from my iPhone

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 03 Nov 2010 14:49:38 +0800

Hi Rajan,

An amazing "idea", but it will totally destroy the basic principle of GMPLS (RSVP-TE).

Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: Rajan Rao 
  To: John E Drake ; Sadler, Jonathan B. ; [email-masked] ; Fatai Zhang 
  Cc: Khuzema Pithewan ; Radhakrishna Valiveti ; [email-masked] ; Mohit Misra ; Ashok Kunjidhapatham 
  Sent: Wednesday, November 03, 2010 2:37 AM
  Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  o   Num-of-mux-stages = 2

  §  ST = ODU2

  §  TPN

  §  ST = ODU0

  §  TPN

  o   Rest is service layer creation...

  Best regards

  Rajan

  Comments inline

  Sent from my iPhone

  Hi John,

  A---B---C---D---E

  JD:  Absolutely correct.

  Jonathan Sadler

  Comments inline.

  Sent from my iPhone

  John, et al

  Thanks

  Rajan

  From: Rajan Rao 

  John, et al

  Thanks

  Rajan

  Hi,

  [Rajan] {

  }

  [Rajan] {

  }

  [Rajan] {

  }

  [Rajan] {

  }

  Thanks,

  John

  Sent from my iPhone

  Fatai,

  Authors of draft-khuzema

  -----Original Message-----
  From: Fatai Zhang [mailto:[email-masked]] 
  Sent: Friday, October 29, 2010 1:26 PM
  To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
  Cc: [email-masked]; Biao Lu
  Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

  Hi Rajan,

  - TPN format

  [AK, KP, RR] { 

  }

  [AK, KP, RR]{

  }

  [AK, KP, RR]{ 

                  OTU1             OTU3            OTU3          OTU1

   Assume that:

   

                  OTU1             OTU3            OTU3          OTU1

            |                           ODU0                                 |

            |       ODU1     |                               |      ODU1     |

            |                |      ODU2    |      ODU2      |               |

            |                |      ODU3    |      ODU3      |               |

            |                |              |                |               |

  Label     |                |              |                |               |

  Case-2) With FA: 

  }

  Thanks

  Ashok/Khuzema/Rajan

  Thanks,

   

  ----- Original Message ----- 

   

  Fatai,

  thanks

  Rajan

  Hi Rajan,

  [Rajan]{

   Our draft addresses

  }

  [Rajan]{

  }

  [Rajan]{

  Num-of-mux-stages = 3

  }

  Best Regards

  Fatai

  ----- Original Message -----

  Hi,

  Abstract:

  Thanks

  Authors

  CCAMP mailing list

  [email-masked]

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 3 Nov 2010 03:07:38 -0700

Hi Fatai,

I am wondering what aspect of GMPLS (RSVP-TE) is violated by multi-stage label format.

GMPLS is not just about FAs. Creating tons of FAs/Virtual TE Links to circumvent multiplexing limitations in the LSP path can lead to scalability issue. By avoiding FAs (where ever possible) and solving the same limitation using multi-stage label, we think, is still within the framework of GMPLS.

The solution restrict the local problem of multiplexing limitation to the nodes involved rather than creating ripples in network by advertising large number of FAs/Virtual Te Links.

FA approach not only causes scalability problem, but also (as Jonathan rightly pointed out) an operator's nightmare when it comes to configure the parameters of a LSP that creates FAs on the fly.

Regards
Khuzema (& Ashok)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Wednesday, November 03, 2010 12:20 PM
To: Rajan Rao; John E Drake; Sadler, Jonathan B.; [email-masked]
Cc: Khuzema Pithewan; Mohit Misra; [email-masked]; Radhakrishna Valiveti
Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

Best Regards

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: John E Drake<mailto:[email-masked]> ; Sadler, Jonathan B.<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Fatai Zhang<mailto:[email-masked]>
Cc: Khuzema Pithewan<mailto:[email-masked]> ; Radhakrishna Valiveti<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Mohit Misra<mailto:[email-masked]> ; Ashok Kunjidhapatham<mailto:[email-masked]>
Sent: Wednesday, November 03, 2010 2:37 AM
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

*         When ODU0-LSP request arrives at B from A,  node-B knows it requires ODU2 mux layer to support ODU0 service on segment B-C. It indicates to node-C  via label format as specified in draft-khuzema:

o   Num-of-mux-stages = 2

*  ST = ODU2

*  TSs carved out of OPU3 ( 8 bits set out of 32)

*  TS granularity of the OPU2 (T-bit = 1.25G)

*  TPN

*  There is no traffic parameter for ODU2.  There is no request to create ODU2-LSP here. It is just a mux layer required to support ODU0.

*  ST = ODU0

*  TSs carved out of OPU2 ( 1 bits set out of 8)

*  T-bit= 1.25 ( don't care)

*  TPN

*         When this request arrives at node-C, it knows from the label that node-B is requesting an ODU2 mux layer creation (again, this is not a request for ODU2-LSP creation) to support ODU0 service.

*         Similar steps as above on Link C-D

Best regards
Rajan

Comments inline

Sent from my iPhone

Hi John,

A---B---C---D---E

JD:  Absolutely correct.

Jonathan Sadler

Comments inline.

Sent from my iPhone

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Wed, 3 Nov 2010 05:22:29 -0700

A bunch of emphatic  assertions

Sent from my iPhone

From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Wednesday, November 03, 2010 3:08 AM
To: Fatai Zhang; Rajan Rao; John E Drake; Sadler, Jonathan B.; [email-masked]
Cc: Mohit Misra; [email-masked]; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Fatai,

Regards
Khuzema (& Ashok)

Hi Rajan,

Best Regards

Fatai

----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: John E Drake<mailto:[email-masked]> ; Sadler, Jonathan B.<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Fatai Zhang<mailto:[email-masked]>
Cc: Khuzema Pithewan<mailto:[email-masked]> ; Radhakrishna Valiveti<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Mohit Misra<mailto:[email-masked]> ; Ashok Kunjidhapatham<mailto:[email-masked]>
Sent: Wednesday, November 03, 2010 2:37 AM
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

o   Num-of-mux-stages = 2

*  ST = ODU2

*  TPN

*  ST = ODU0

*  TPN

Best regards
Rajan

Comments inline

Sent from my iPhone

Hi John,

A---B---C---D---E

JD:  Absolutely correct.

Jonathan Sadler

Comments inline.

Sent from my iPhone

John, et al

Thanks
Rajan

From: Rajan Rao

John, et al

Thanks
Rajan

Hi,

[Rajan] {

Thanks,

John

Sent from my iPhone

Fatai,

Authors of draft-khuzema

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Hi Rajan,

- TPN format

[AK, KP, RR] {

}

[AK, KP, RR]{

}

[AK, KP, RR]{

                OTU1             OTU3            OTU3          OTU1

 Assume that:

                OTU1             OTU3            OTU3          OTU1

          |                           ODU0                                 |

          |       ODU1     |                               |      ODU1     |

          |                |      ODU2    |      ODU2      |               |

          |                |      ODU3    |      ODU3      |               |

          |                |              |                |               |

Label     |                |              |                |               |

Case-2) With FA:

}

Thanks

Ashok/Khuzema/Rajan

Thanks,

----- Original Message -----

Fatai,

thanks

Rajan

Hi Rajan,

[Rajan]{

 Our draft addresses

}

[Rajan]{

}

[Rajan]{

Num-of-mux-stages = 3

}

Best Regards

Fatai

----- Original Message -----

Hi,

Abstract:

Thanks

Authors

CCAMP mailing list

---

From: [email-masked]
Date: Mon, 8 Nov 2010 20:58:26 +0800

Hi Rajan,

Multi-stage multiplexing always depends on the network planning. I don't 
think that node can decide which multi-stage multiplexing hierarchy shoud 
be used during the distributed signaling. On the other hand, after path 
computation entity decides which multi-stage hierarchy should be used 
within the end points of FA-LSP, it should inform the multi-stage 
hierarchy to the boundary nodes by signaling message. 

Xihua Fu

Rajan Rao <[email-masked]> 
发件人:  [email-masked]
2010-11-03 上午 02:37

收件人
John E Drake <[email-masked]>, "Sadler, Jonathan B." 
<[email-masked]>, "[email-masked]" <[email-masked]>, Fatai 
Zhang <[email-masked]>
抄送
Khuzema Pithewan <[email-masked]>, Mohit Misra 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
Radhakrishna Valiveti <[email-masked]>
主题
Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

FA approach is well understood and is one way to address muxing 
hierarchy.  There is no disagreement here.  What we are bringing to the 
table is an alternate and simple mechanism to address OTN muxing 
hierarchy. 
 
If you look at the ODU0 example carefully, we do NOT have an LSP at ODU2 
layer between nodes B-C or C-D.  This is not required when nodes are ODU0 
switching capable.   Here is how it works:
1.       The muxing restriction is a local matter to the segment.  
2.       The need to create one or more muxing layers (doesn’t mean an 
LSP) to support a service is decided by nodes on the segment.   
a.       The muxing capability on a segment is known via LMP or 
configuration
3.       The muxing layers can vary segment to segment for the same 
service

·         When ODU0-LSP request arrives at B from A,  node-B knows it 
requires ODU2 mux layer to support ODU0 service on segment B-C. It 
indicates to node-C  via label format as specified in draft-khuzema:
o   Num-of-mux-stages = 2
o   An ODU2-label: which includes these fields
§  ST = ODU2
§  TSs carved out of OPU3 ( 8 bits set out of 32)
§  TS granularity of the OPU2 (T-bit = 1.25G)
§  TPN
§  There is no traffic parameter for ODU2.  There is no request to create 
ODU2-LSP here. It is just a mux layer required to support ODU0.
o   An ODU0-label: which includes the following:
§  ST = ODU0
§  TSs carved out of OPU2 ( 1 bits set out of 8)
§  T-bit= 1.25 ( don’t care)
§  TPN
·         When this request arrives at node-C, it knows from the label 
that node-B is requesting an ODU2 mux layer creation (again, this is not a 
request for ODU2-LSP creation) to support ODU0 service.
o   Node-B creates ODU2 mux layer 
o   Rest is service layer creation…….
·         Similar steps as above on Link C-D
 
This scheme is simple because it eliminates the need for FA-LSP & 
additional Te-Links for each intermediate mux layer.   FA is required in 
cases where switching limitations exist (e.g. if intermediate nodes are 
not capable of ODU0 switching).  
 
Best regards
Rajan
 
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 8:43 AM
To: Sadler, Jonathan B.; Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit 
Misra
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Comments inline
 
Sent from my iPhone
 
From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 8:19 AM
To: John E Drake; Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit 
Misra
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Hi John,
 
If the network consists of a mix of equipment – some that includes 
support for ODU0 while other does not, then it cannot be assumed that 
dynamically creating an ODU2 to the immediate neighbor will allow for the 
ODU0 to be transported.  To amplify, consider the following example:
 
A---B---C---D---E

JD:  That’s not the example we have been discussing. The  A-B and D-E 
links support  ODU0.  One or more ODU2 LSPs need to be created between B 
and D in order to support the A-E ODU0 LSP.
 
For an end to end ODU0 to be established, FAs will need to be created 
between A and C as well as C and E.  This can be done in advance (as GMPLS 
is able to do) or they can be created dynamically.  If we require them to 
be created in advance, we place a burden on the operator.  If we create 
the multi-hop FA dynamically, Node A needs to be able to tell 1) if FAs 
are necessary and 2) where to have them stop/start as a part of path 
computation.  This information is unavailable with the existing 
advertisements.
 
JD:  In the example we have been considering, rather than the one to which 
you switched, node A does not need to know where FAs need to be 
established.  Your last sentence is correct but gratuitous;  we are in the 
process of determining how to support the latest version of OTN.
 
When the FA is dynamically created, an ODU2-scoped RSVP session is invoked 
separate from the ODU0 RSVP session.  The ODU2 session conveys the 
specific parameters for the ODU2 FA, while the ODU0 carries the specific 
parameters for the ODU0 FA.
 
JD:  Absolutely correct.
 
And finally, you are correct there is possibility of creating ODU2 FAs 
separately for A-C and C-E as well as one “long” ODU2 FA from A-E.  You 
ask why the shorter FAs would be used when the longer is possible.  This 
is a matter of operator policy – they may have a large number of ODU0 
demands in their network and may wish to have C act as a ODU0 grooming 
point allowing for better use of the ODU2 FAs.
 
JD:  Again, in the example we have been considering,  I don’t see any 
advantage to a two FAs, B-C and C-D, versus a single FA, B-D,  between the 
same pair of nodes.  More importantly, though, you seem to be agreeing 
with my statement “having multi-hop FAs between select points in the 
network”, where select points would be the grooming points you mention. 
 
An additional question is why would the operator setup an ODU2 FA if an 
ODU1 FA carrying ODU0s the was possible.  Again, this is a matter of 
operator policy.   They may wish to have the ODU0s carried over an ODU1 FA 
that used separate ODU2 FAs that go from A-B, B-C, C-D and D-E.  Of 
course, it is necessary to know that the equipment has that capability.
 
Jonathan Sadler
 
P.S. Scenarios similar to the one above are included in the Liaison that 
was sent by ITU-T to CCAMP.
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
John E Drake
Sent: Saturday, October 30, 2010 9:35 AM
To: Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Radhakrishna Valiveti; [email-masked]; Mohit 
Misra
Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Comments inline.
 
Sent from my iPhone
 
From: Rajan Rao [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 6:00 PM
To: John E Drake; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu; Rajan 
Rao
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
John, et al
 
With the muxing structure of G.709,   customers may chose to use the mux 
stages their own ways. Having FA-LSPs or virtual links on pt-2-pt segments 
doesn’t make much sense and will lead to scaling issues & managing 
complexities.
 
JD:  You are making an assertion.   Since in this example we are talking 
about a node that can activate an ODU2 dynamically, it could advertise the 
ODU0, as you suggested.  Why you would want to do this rather than having 
multi-hop FAs between select points in the network is beyond me, except as 
a debating point.
 
JD:  However, the more important point is that *existing* GMPLS signaling 
*exactly* supports the configuration in your example. 
 
The signaling extensions can easily take care of OTN muxing hierarchy as 
shown in our draft.  We should address MLN RFC-6001 alignment  by adding 
OTN-MLN details in the  framework doc.
 
JD:  See above.  Btw, in your proposal where are the parameters associated 
with establishing the ODU2 carried? 
 
Thanks
Rajan
 
From: Rajan Rao 
Sent: Friday, October 29, 2010 2:50 PM
To: John E Drake; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
John, et al

Thanks
Rajan
 
From: John E Drake [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 
- draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Hi,
 
Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. 
This is necessary because otherwise the CSPF at A will not consider 
routing the ODU0 LSP via B, C, and D.
 
[Rajan] {
This is not the case.  Even without virtual TE link or FA-LSP  the ODU0 
LSPs can be setup between A-E. This is  because we advertise #ODU0s for 
OTU3 links B-C & C-D.  Note that #ODU0 containers advertised is non-zero 
even though TSG=2.5G. This is the key point here. 
We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate 
sub-TLV within SCSI. 
 
The instantiation of ODU2 to support ODU0 is done as part of signaling 
which brings in the label format for mux levels.  The instantiation of mux 
layers is a local matter.  This can be different on each segment. The 
labels tell exactly what to instantiate on the local interface. 
 
In this example, each NE decides locally (segment basis) how ODU0 
should/can be supported.  If it requires additional mux layers they are 
requested in the label going down stream.
}
 
When the ODU0 Path message is received at B, it is held up while a 
separate ODU2 Path message is sent from B to C to D to activate the B-D 
ODU2 Link.  Once it is activated, using LSP Hierarchy ( RFC4206) B sends 
the ODU0 request to D, which in turn sends it to E.
[Rajan] {
This is allowed. As said below, this is an alternate way. We can do 
without this as shown in the examples.
}
 
When we were first developing GMPLS, we looked at packaging multiple LSP 
setup requests together and decided it was a Bad Idea™.  So, the 
multistage signaling you are suggesting is not only unnecessary, but not 
in alignment with the GMPLS architecture.
[Rajan] {
 Not sure on the alignment.    Think of a scenario where I have muxing 
restriction within an FA. What do you do here?  Create more FAs?  Works of 
course with scaling implications. 
}
The other alternatives are to instantiate the B-D ODU2 link or  B-C and 
C-D ODU2 links beforehand. 
[Rajan] {
 Agree,  this is listed as FA case in the example below.
}
 
Thanks,
 
John
 
Sent from my iPhone
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: [email-masked]; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Fatai,

Authors of draft-khuzema
 
-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [email-masked]; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Hi Rajan,

We have to repeat that there is not much substantial difference between 
two drafts except multi-stage muxing. 
 
We don't want to talk more on "NMC", "NVC", "TPN", because they have been 
discussed before and it is quite easy for [draft-zhang] to do that. For 
example, for NMC, there is an editors note in the previous versions  such 
as 04 version to discuss NMC stuff (and some people opposed to deprecate 
NMC). For NVC, it is obviously that [draft-zhang] can support it.

1) At page 3, in the list of added OTN features is present explicitly the 
"Multi-stage ODU Multiplexing". Actually, multi-stage is not present at 
all as requirement/feature in G.709. Our intention to postpone technical 
solution regarding multi-stage multiplexing is justified by on going ITU-T 
SG15 progress. Before thinking about specific signaling and routing 
solutions we need to have stable ITU-T requirements. This why in all our 
common drafts (FWK, Info-Model, Routing and Signaling drafts) we just 
placed some placeholder on the subject.
 
[AK, KP, RR] { 
 Your understanding is not correct. Please refer to Figure-7-1A (G.709 
12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it 
has to be single stage. The G.709 OTN frame formats fully support this 
capability. 
 
Vendors may choose to implement limited number of muxing levels. This 
should not impact the signaling solution we come up with.
}

2) We are confused by your simplified multi-stage muxing label 
distribution rule
 
There is no detailed text to describe multi-stage muxing label 
distribution procedures in your draft and your explaination in your below 
mail just focuses on one single node rather than how to create the 
end-to-end LSP.
 
It is known that GMPLS standard procedure impose that every node has to 
allocate a label/labels consistent with the Generalized Label Request. 
Very important: Generalized Label Request cannot be changed during 
signaling path.
[AK, KP, RR]{
  There is no disagreement here.  Generalized label request doesn’t 
change. It is fully consistent with RFC-4328. This is precisely the reason 
why we spelled out NMC treatment with ODU2e case (ref to section 4.0 in 
draft-khuzema).
 
Multi-stage label concept is enforced on the Generalized Label only. This 
affects only the labels exchanged between the peers. This does not affect 
the Generalized Label Request  which is relayed end-to-end.
}
 
For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we 
need a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the 
path is A-B-C-D-E, in node B and node D will finish the two-stage 
muxing/demuxing. How you to create the LSP? how you to distribute the 
labels in Node B, C, D? What is the traffic parameters will be transmitted 
in the nodes B, C, D and nodes A, E?
 
[AK, KP, RR]{ 
 
There are 2 ways to handle this case: with FA or without FA. Both are 
explained with an example below 

 
 Assume that:
   - ODU0 LSP is created from A to E. 
   - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. 
Hence ODU0 service can be supported on this interface only through 
ODU3-ODU2-ODU0  or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this 
example. 
-    Generalized Label request in this case will be for ODU0 only. 
 
Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run 
between B & D.  They terminate between B-C and C-D respectively. Following 
is the layering and multi-stage label that needs to exchanged between the 
nodes. 

          |<-------------------------------------------------------------
à| 
          |                           ODU0 |
          |ß------------à|                               |ß------------à
| 
          |       ODU1     |                               |      ODU1 |
          |                |ß-----------à|ß------------à| |
          |                |      ODU2    |      ODU2      | |
          |                |ß-----------à|ß------------à| |
          |                |      ODU3    |      ODU3      | |
          |                |              |                | |
Label     |                |              |                | |
#of stages|        1       |         2    |         2      |         1 |
Stage-1   |   ODU1ßODU0   |   ODU3ßODU2  |   ODU3ßODU2   |    ODU1ßODU0  |
Stage-2   |                |   ODU2ßODU0  |   ODU2ßODU0   | |
------------------------------------------------------------------------------
 
Case-2) With FA: 
If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 
layer & this will be a TE-Link by itself. In that case, ODU0 will be 
routed directly over ODU2 – which is single stage only (no need of 
multi-stage label in that case). 

Thanks,

 
 
----- Original Message ----- 
From: "Rajan Rao" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "Khuzema Pithewan" 
<[email-masked]>; "Mohit Misra" <[email-masked]>; "Ashok 
Kunjidhapatham" <[email-masked]>
Cc: <[email-masked]>; "Biao Lu" <[email-masked]>
Sent: Thursday, October 28, 2010 2:17 PM
Subject: RE: [CCAMP] Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

Fatai,

thanks
Rajan
________________________________________
From: Fatai Zhang [[email-masked]]
Sent: Wednesday, October 27, 2010 6:08 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra
Cc: [email-masked]; Zhang, Fatai
Subject: Re: [CCAMP] Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Hi Rajan,
 
Happy to see your draft, but except multi-stage muxing supported in your 
draft,  I don't see any substantial difference between your draft and 
[draft-zhang-ccamp-gmpls-evolving-g709-06.txt].
 
[Rajan]{
Multi stage muxing is one of the key drivers for  signaling extensions. 
Any solution is incomplete without this. The label format proposed is 
intended to support G.709-v3 & future OTN extensions. Section 5.2 in 
draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

You may say that TPN info is incorporated into label Object, but you know 
it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that 
and we already stated it in the slides for IETF78th meeting ( we just make 
the door open at this moment and there are some advantages to decouple TPN 
and Label).
 
[Rajan]{
The key thing here is the mux layers.  The TPN in label object is intended 
to address per mux layer case…. more efficient. 
I think this should be captured in framework doc (section 3.1.2.1in 
framework doc doesn't cover hierarchy aspect clearly). 
}
 
In addtion, for multi-stage muxing, I really suspect that it can be 
resolved so easily, because it is MLN stuff and it needs to indicate how 
to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can 
be done in this way as your draft describes, we all will be much happy.
 
[Rajan]{
The label structure we have defined is to address muxing levels of G.709. 
This is not solving MLN using FA. i.e. it doesn’t result in creation of 
FA automatically. There is no FA involved or intended here (out of scope). 
Please refer to section-3.0 in 
https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.
 
 For example,  we need 3 labels to create an ODU0 LSP with following 
muxing structure on a given TeLink

Num-of-mux-stages = 3
 
}

Best Regards
 
Fatai
 
----- Original Message -----
From: Rajan Rao<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Cc: Khuzema Pithewan<mailto:[email-masked]> ; Mohit Misra<
mailto:[email-masked]>
Sent: Wednesday, October 27, 2010 5:26 AM
Subject: [CCAMP] Signaling extensions for G.709 - 
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
 
Hi,
 
We have a draft on “GMPLS Signaling extensions for OTN” available for 
review.  It can be accessed from the following link:
http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
The above draft is not on IETF repository as we missed the submission 
deadline.  We will submit to IETF as soon as possible.
 
Please review and comment.
Abstract:
As OTN network capabilities continue to evolve, there is an increased need 
to support GMPLS control for the same. [RFC4328] introduced GMPLS 
signaling extensions for supporting early version of G.709 [G.709-v1].The 
basic routing considerations from signaling perspective is also specified 
in [RFC4328].
The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] 
have introduced new ODU containers (both fixed and flexible) and 
additional ODU multiplexing capabilities, enabling support for optimal 
service aggregation.
This document extends [RFC4328] to provide GMPLS signaling support for the 
new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling 
extensions described in this document caters to ODU layer switching only. 
Optical Channel Layer switching considerations in [RFC4328] are not 
modified in this document.
 
Thanks
Authors