[CCAMP] R: Closing G.709 open issues

["BELOTTI, SERGIO (SERGIO)" <[e-mail]>]

Hi Fatai,

I agree with you, for both point 1 and 2.

Best Regards
Sergio

Belotti Sergio-  System Architect
ALCATE-LUCENT  Optics Division
via Trento 30 Vimercate (MB) - Italy
phone [phone]
-----Messaggio originale-----
Da: Fatai Zhang [mailto:[e-mail]] 
Inviato: lunedì 13 maggio 2013 5.33
A: Lou Berger
Cc: Daniele Ceccarelli; CCAMP; [e-mail]; [e-mail]
Oggetto: RE: Closing G.709 open issues

Hi Lou,

I think you have two major points here. 

(1) Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)?

I think this has been discussed for quite long time before Vancouver meeting, which was famous as "penultimate" issue. Note that this TSG in GPID is different from the *implicit* TSG in label format.

I don't think we need discuss this anymore.

(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:[e-mail]] 
Sent: Friday, May 10, 2013 8:51 PM
To: Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [e-mail]; [e-mail]
Subject: Re: Closing G.709 open issues



On 5/9/2013 9:41 PM, Fatai Zhang wrote:
> Hi Lou,
> 
> For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

Great.

> 
> I hesitate to make a decision on either approach, I would like to defer to the WG consensus.
> 

I believe we already have a consensus position.  The question in my mail
was do we need to revisit it.  I take your response as a no. (thank you!)

> For point 2), I compared [G.709-2003] and [G.709-2012], and checked
> the GPIDs defined in [RFC4328], I think the following new GPIDs
> (values could be 59-79) should be added (besides updating some GPIDs
> defined in RFC4328, like 32,47,49-52):
> 

I suggest going through the full PT list and identifying them in the
table (as I started in my last message) so that there is no confusion in
implementations.

In the list below it looks like you have moved away from the 'grouped
G-PID' approach.  Is there a reason for this change?

Refer to
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml
in subsequent comments.

>     Value       G-PID Type             LSP Encoding Type
>      -----       ----------             -----------------
>    59(TBA)     G.709 ODU-1.25G        G.709 ODUk 
>    60(TBA)     G.709 ODU-any          G.709 ODUk

Do you really need 3 G-PID types for an ODU (I thought TSG was already
covered)?

>    61(TBA)     PCS                    G.709 ODUk (k=0)
>    62(TBA)     FC-1200                G.709 ODUk (k=2e)
Why not us existing G-PID 58?

>    63(TBA)     eOPU2                 G.709 ODUk (k=2)

>    64(TBA)     STM-1                  G.709 ODUk (k=0)
>    65(TBA)     STM-4                  G.709 ODUk (k=0)
Why not us existing G-PID 34?

>    66(TBA)     FC-100                 G.709 ODUk (k=0)
>    67(TBA)     FC-200                 G.709 ODUk (k=1)
>    68(TBA)     FC-400                 G.709 ODUflex
>    69(TBA)     FC-800                 G.709 ODUflex
Why not us existing G-PID 58?

>    70(TBA)     IB SDR                 G.709 ODUflex
>    71(TBA)     IB DDR                 G.709 ODUflex
>    72(TBA)     IB QDR                 G.709 ODUflex
Can these be one value with rate implying SDR/DDR/QDR?

>    73(TBA)     SDIa                   G.709 ODUk (k=0)
>    74(TBA)     SDIb                   G.709 ODUk (k=1)
>    75(TBA)     SDIc                   G.709 ODUk (k=1)
>    76(TBA)     SDId                   G.709 ODUflex
>    77(TBA)     SDIe                   G.709 ODUflex

Can these be one value with rate implying a-e?

>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)
Why not us existing G-PID 56?

>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)
> 
> 
> 
> 

Thanks,
Lou