Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Khuzema Pithewan <kpithewan@infinera.com> Fri, 24 May 2013 09:32 UTC

Return-Path: <kpithewan@infinera.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E0421F9643 for <ccamp@ietfa.amsl.com>; Fri, 24 May 2013 02:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WtkyEIpHSrC for <ccamp@ietfa.amsl.com>; Fri, 24 May 2013 02:32:28 -0700 (PDT)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id CC24621F9401 for <ccamp@ietf.org>; Fri, 24 May 2013 02:32:24 -0700 (PDT)
Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Fri, 24 May 2013 02:32:23 -0700
From: Khuzema Pithewan <kpithewan@infinera.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
Thread-Index: AQHOViWNlSQKnFOnHEGp0kX3EXiVcJkTJgxwgACV9oCAAFWBoA==
Date: Fri, 24 May 2013 09:32:22 +0000
Message-ID: <D8D01B39D6B38C45AA37C06ECC1D65D53FD74A36@SV-EXDB-PROD2.infinera.com>
References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B39A@SZXEML552-MBX.china.huawei.com> <518CED28.30303@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B943@SZXEML552-MBX.china.huawei.com> <B9FEE68CE3A78C41A2B3C67549A96F4802BCBD@FR711WXCHMBA05.zeu.alcatel-lucent.com> <F82A4B6D50F9464B8EBA55651F541CF84317BEA2@SZXEML552-MBX.china.huawei.com> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <B9FEE68CE3A78C41A2B3C67549A96F4802C534@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5193A26A.1090005@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317D2BA@SZXEML552-MBX.china.huawei.com> <519649B4.5060408@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84319607D@SZXEML552-MBX.china.huawei.com> <519B73C9.2030308@labn.net> <D8D01B39D6B38C45AA37C06ECC1D65D53FD7445C@SV-EXDB-PROD2.infinera.com> <519E84F9.1040103@labn.net>
In-Reply-To: <519E84F9.1040103@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 09:32:33 -0000

Hi Lou,

-> Are you just trying to be exhaustive in your definitions, or do you have an actual use case?  If the latter, can you elaborate on your desired use?


There is no actual usecase, rather intent is to align dataplane spec with control plane spec.

In reality, there may not arise any backward compatibility issue in foreseeable future, because GPid range is very large (16 bits) and vendor specific client payload may choose to use very high Gpid value, where standard defined GPid may not reach.

Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4) as reserved. What purpose does it serve? 

Either we define reserved values that underlying dataplane defines, or we don't define at all. 

 If we have convention of defining reserved GPids, then why not match it with data plane spec. 

However, I believe defining or not defining reserved value, is not going to have any material impact on the way standard will be implemented. I am fine either way!

Regards
Khuzema

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Friday, May 24, 2013 2:37 AM
To: Khuzema Pithewan
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)



On 5/23/2013 3:15 PM, Khuzema Pithewan wrote:
> Hi Lou,
> 
> 
> -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.
> 
> Let say some vendor uses reserved (80-8F, which will never be 
> standardized by ITU, as per Note4 in Table 15-8) payload code point 
> and uses some GPid 'x' in Control plane for that code point. Now if in 
> future, Control plane defines x for some other client.
> 
> There will be backward compatibility issues.

Khuzema,

	I agree.  Vendors have always used (and continue to use)  standard code points for proprietary purposes at their own peril.  There is nothing new or unique about this in the context of the documents we're discussing.

Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types?

> 
> Since it is clearly mentioned that these 16 code points in dataplane, 
> will not standardized, is a standardization in way,

> which must be
> followed up in control plane by reserving 16 GPids for the purpose.

Why?  [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs:

  PT      Interpretation
0x01      Experimental mapping \
0x55      Not available
0x66      Not available
0x80-0x8F Reserved codes for proprietary use
0xFF      Not available

Are you just trying to be exhaustive in your definitions, or do you have an actual use case?  If the latter, can you elaborate on your desired use?

BTW you might want to look at the current IANA G-PID assignments before answering.  I suspect you'll find that you can address your concerns using existing assignments.

Thanks,
Lou

> Regds
> Khuzema
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, May 21, 2013 6:47 PM
> To: CCAMP
> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
> 
> All,
> 
> In the interest of moving this discussion quickly to closure, I spent 
> some time trying to come up with the full list of G.709 PT to G-PID 
> mappings.  In coming up with this list I tried to be consistent with 
> the last consensus point that I can identify on this topic (the 
> previously referenced July 2012 thread & presentation), which included:
> 
> A) Defining new G-PIDs for client types not identified by an assigned 
> G-PID (per
> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet
> ers.xml)
> 
> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a
> G.709 payload type, and define new G-PIDs when reuse not possible.
> 
> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.
> 
> Here's what I've come up with:
> 
>     G.709
>    Payload
>     Type   G-PID   Type/Comment    LSP Encoding
>     ====   =====   ==============  ===================
>     0x01           No standard value
>     0x02    49     CBRa            G.709 ODUk
>     0x03    50     CBRb            G.709 ODUk
>     0x04    32     ATM             G.709 ODUk
>     0x05    TBA1   Framed GFP      G.709 ODUk
>     0x06    ???    Is any valued needed?
>     0x07    55     Ethernet PHY    G.709 ODUk (k=0)
>                    (transparent    G.709 ODUk (k=3)
>                    GFP)            G.709 ODUk (k=4)
>     0x08    58     Fiber Channel   G.709 ODUk (k=2e)
>     0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)
>     0x0A    TBA2   STM-1           G.709 ODUk (k=0)
>     0x0B    TBA3   STM-4           G.709 ODUk (k=0)
>     0x0C    58     Fiber Channel   G.709 ODUk (k=0)
>     0x0D    58     Fiber Channel   G.709 ODUk (k=1)
>     0x0E    58     Fiber Channel   G.709 ODUflex
>     0x0F    58     Fiber Channel   G.709 ODUflex
>     0x10    51     BSOT            G.709 ODUk
>     0x11    52     BSNT            G.709 ODUk
>     0x12    TBA4   InfiniBand      G.709 ODUflex
>     0x13    TBA4   InfiniBand      G.709 ODUflex
>     0x14    TBA4   InfiniBand      G.709 ODUflex
>     0x15    TBA5   Serial Digital  G.709 ODUk (k=0)
>                    Interface
>     0x16    TBA6   Serial Digital  G.709 ODUk (k=1)
>                    Interface/1.001
>     0x17    TBA5   Serial Digital  G.709 ODUk (k=1)
>                    Interface
>     0x18    TBA6   Serial Digital  G.709 ODUflex
>                    Interface/1.001
>     0x19    TBA5   Serial Digital  G.709 ODUflex
>                    Interface
>     0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)
>                    (IANA to update Type field)
>     0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)
>     0x1C    58     Fiber Channel   G.709 ODUk
>     0x20    47     G.709 ODU-2.5G  G.709 ODUk
>                                      (k=2,3)
>                    (IANA to update Type field)
>             TBA8   G.709 ODU-1.25G G.709 ODUk
>                                      (k=1,2,3)
>     0x21    TBA8   G.709 ODU-1.25G G.709 ODUk
>                                      (k=2,3,4)
>             TBA9   G.709 ODU-Any   G.709 ODUk
>                                    (k=2,3)
>     0x55           No standard value
>     0x66           No standard value
>     0x80-0x8F      No standard value
>     0xFD    TBA10  Null Test       G.709 ODUk
>     0xFE    TBA11  Random Test     G.709 ODUk
>     0xFF           No standard value
> 
> Note that there are a few differences with Fatai's list, which doesn't 
> format well in e-mail, but is available in the archive 
> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html
> 
> Please speak up if you think the above is not aligned with prior 
> consensus or if you have an issue with any of the above.
> 
> Much thanks,
> Lou
> 
> 
> On 5/20/2013 5:09 AM, Fatai Zhang wrote:
>> Hi Lou,
>>
>>  
>>
>> I think my mail on March 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 current approach of this draft (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 on discussing this point 
>> (because there is no issue to stick to the data plane by using the 
>> current approach of this draft).
>>
>>  
>>
>> =====================================================================
>> =================================================
>>
>> (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
>>
>>  
>>
>> Fatai
>>
>>  
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Friday, May 17, 2013 11:16 PM
>> To: Fatai Zhang
>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; 
>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>> Subject: Re: R: Closing G.709 open issues
>>
>>  
>>
>> Fatai,
>>
>>         
>>
>> 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
>>
>> following:
>>
>>  
>>
>>>> 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,
>>
>> Lou
>>
>>  
>>
>>  
>>
> 
> 
> 
>