Re: [CCAMP] R: Closing G.709 open issues

Fatai Zhang <> Thu, 23 May 2013 01:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB8DA11E817A for <>; Wed, 22 May 2013 18:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DnA9ow3CN-Ih for <>; Wed, 22 May 2013 18:14:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 36AAE11E815B for <>; Wed, 22 May 2013 18:14:08 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ37132; Thu, 23 May 2013 01:14:07 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 02:13:55 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 09:14:06 +0800
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Thu, 23 May 2013 09:13:41 +0800
From: Fatai Zhang <>
To: Fatai Zhang <>, Lou Berger <>
Thread-Topic: R: Closing G.709 open issues
Date: Thu, 23 May 2013 01:13:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84319B76ESZXEML552MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP <>, "" <>
Subject: Re: [CCAMP] R: Closing G.709 open issues
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 01:14:14 -0000

Hi Lou and all,

I would like to double check again on the original point 2.

I would assume the WG is happy with the proposed approach and then conclude the discussion on point 2 if there is no more comment until this Friday.

Note that I think more people have shown their support on the proposed approach.

Best Regards


From: Fatai Zhang []
Sent: Monday, May 20, 2013 5:09 PM
To: Lou Berger
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
Subject: RE: R: Closing G.709 open issues

Hi Lou,

I think my mail on May 13rd may have answered your following comments. My response quoted as follows.

In addition, if people look at the full list that I provided, I think people can realize that RFC4328 (section 3.1.3) used the same approach as the proposed approach (ie., 1:1 mapping between GPIDs and payload types defined by G.709), ie., we are following what RFC4328 did.

BTW, I am not sure if we need spend so much time on discussing this point (because there is no issue to stick to the data plane by using the proposed approach).


(2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined in this draft)

We realize that it is safe to use 1:1 mapping approach to avoid some potential issues after investigation. We know this payload types have been defined by G.709 (data plane), so physically it is better to use 1:1 mapping approach.

For the potential issues I mentioned above, for example, we cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC-800, right? So, it is better to assign different GPIDs to these different payload types defined by the data plane.

Furthermore, I think it is much cheaper to create new GPIDs in the control plane than in the data plane (these payload types will be carried in the OH).

Best Regards


-----Original Message-----
From: Lou Berger []
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
Subject: Re: R: Closing G.709 open issues


That's a great start for the WG.  Thank you.

To answer your implied question as to why my request for the full list.

My feeling is that there have been too many "surprises" on the 709

documents in areas that I thought were either obvious (but from the IETF

& GMPLS context, not ITU-T or G.709 perspectives) or resolved by past

discussions.  At this point, as co-chair and Document shepherd, I want

to ensure that any open point on the documents are unambiguously closed

and that past discussions (i.e., points of consensus) are 100% captured,

so that we can smoothly move through the planned second LC and

publication request.

To that end, in my previous message I asked two questions about points

where it seems you are proposing moving away from what has been

previously been discussed & agreed to by the WG.  Can you answer the


>> My questions on the new G-PIDs come down to:

>> - Why are rate specific G-PIDs being proposed (rather than

>>   continuing to use the previous approach documented in the draft

>>   and in Section 3.1.3 of rfc4328)?

>> - Why are new values being defined rather than using existing

>>   values, e.g., G-PID 56?


Much thanks,