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

[John E Drake <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, November 02, 2010 2:30 AM
To: John E Drake; Rajan Rao; [e-mail]
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.

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<mailto:[e-mail]>
To: Rajan Rao<mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]> ; Fatai Zhang<mailto:[e-mail]>
Cc: Khuzema Pithewan<mailto:[e-mail]> ; Mohit Misra<mailto:[e-mail]> ; Radhakrishna Valiveti<mailto:[e-mail]> ; Biao Lu<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, October 29, 2010 6:00 PM
To: John E Drake; [e-mail]<mailto:[e-mail]>; 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; [e-mail]; 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

Please see response inline.

Thanks
Rajan

From: John E Drake [mailto:[e-mail]]
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; [e-mail]; 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(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

From: [e-mail] [mailto:[e-mail]] On Behalf Of Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: [e-mail]; 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,



Interesting discussion. Please find the response below.



Authors of draft-khuzema



-----Original Message-----
From: Fatai Zhang [mailto:[e-mail]]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: [e-mail]; 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" <[e-mail]>

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

Cc: <[e-mail]>; "Biao Lu" <[e-mail]>

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 [[e-mail]]

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

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: [e-mail]; 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:[e-mail]>

To: [e-mail]<mailto:[e-mail]>

Cc: Khuzema Pithewan<mailto:[e-mail]> ; Mohit Misra<mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

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