Re: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

[Rajan Rao <[e-mail]>]

Fatai,

Thanks for the comments.  Please see response inline.

From: Fatai Zhang [mailto:[e-mail]]
Sent: Wednesday, March 16, 2011 3:04 AM
To: Rajan Rao; [e-mail]
Subject: Re: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

Hi Rajan,

I have some comments on this draft.

(1) Confused Lo ODU Terminology

I think you may have some misunderstanding on LO ODU terminology. According to the ITU-T recommendation, a LO ODUj could represent the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. For example, 100GE over ODU4, this ODU4 is Lo ODU4, not Ho ODU4.

[RR] The meaning should be as per section-7.0 of G.709-v3; there is no change in meaning intended.  Please point to the section where there is confusion. We will take an action to correct.

(2) Non-normative signal types

When [OTN-FWK] document was discussed quite long time ago, the experts from CCAMP raised that ODU1e, ODU3e1, ODU3e2 are non-normative, which should not be referenced.

[RR] Fair enough, we will remove.  The point we were trying to make was that these signal types are covered if they ever become reality.

(3) IMCD advertisement for link CD in Section 6.2

For link CD, it is assumed that it can support OTU2-ODU2-ODU1-ODU0, and in IMCD2, ODU2-ODU1-ODU0 is advertised, why "ODU1-ODU0" should be advertised? Actually, for the link CD, it can not support ODU1->ODU0.

[RR]  The architecture/model should be capable of supporting FAs at ODU2 and ODU1 layers for the above muxing hierarchy.   The IMCD1 & IMCD2 support FA creation at ODU2 layer while IMCD3 is meant to allow FA creation at ODU1 layer.
            IMCD1:
                G-PID = ODU2-ODU1
                Available HO-ODUj count at Pi = 1 (ODU2)

          IMCD2:
                G-PID = ODU2-ODU1-ODU0
                Available HO-ODUj count at Pi = 1 (ODU2)

          IMCD3:
                G-PID = ODU1-ODU0
                Available HO-ODUj count at Pi = 4 (ODU1)

In addition, based on your approach, if link CD can support OD4-ODU3-ODU2-ODU1-ODU0 capability, how to advertise this information?
[RR] In this case you need to advertise the ability to support FA at ODU4, ODU3, ODU2 and ODU1 layers. Please refer to e.g. in section 6.3.  It will be on similar lines

(4) In section 5.1, 5.2 and 5.3

There is some text to describe "Maximum Bandwidth", however, this parameter is not used in RFC4201.
[RR] True;  bundling case use Max LSP BW as per RFC 4201.  This is referenced in section 5.1.

In Section 5.3, it says "Implementations may choose to ignore this attribute and consider per ODU-rate Unreserved Bandwidth defined in Interface Switch Capability Descriptor for "G.709 ODUk" encoding type. " . How about "Maximum Reservable Bandwidth"?

[RR] For Max Reservable BW field, the intent is to encode as follows
  - Unbundled link -  as per RFC 3630
  - Bundled Link - as per RFC4201

This is captured in section-5.2.


(5) In Section 3

In this section, OTU, ODUk, ODUj links are listed, but I don't see much difference between from the descrition in your draft. Could you clarify this?
In addtion, could you clarify how these types of links are advertised based on the protocol defined in the next sections of your draft.

 [RR] Xihua had similar comments.  We will take an action to clarify the following cases. Our intent was to show the follows cases:


a)      OTUk links  - P2P segment

b)      ODUk links - FA ( going beyond one segment)

c)       ODUj links  - FA ( going beyond one segment)

Thanks
Rajan

Thanks

Fatai

Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: [phone]
Fax: [phone]
----- Original Message -----
From: "Rajan Rao" <[e-mail]<mailto:[e-mail]>>
To: <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 15, 2011 9:14 AM
Subject: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

Hi,

We have submitted updates to the following draft. Please review & comment.

http://tools.ietf.org/html/draft-ashok-ccamp-gmpls-ospf-g709-03

Thanks
Authors


-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Monday, March 14, 2011 4:15 PM
To: [e-mail]<mailto:[e-mail]>
Subject: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title           : OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks
Author(s)       : A. Kunjidhapatham, et al.
Filename        : draft-ashok-ccamp-gmpls-ospf-g709-03.txt
Pages           : 30
Date            : 2011-03-14

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 the 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 describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ashok-ccamp-gmpls-ospf-g709-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
________________________________
> _______________________________________________
> CCAMP mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp
>