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

[Lou Berger <[e-mail]>]

Fatai,
	I think you missed the following:

http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html

As stated in that message:

> 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.

(probably best to respond to that message if you have a comment on it.)

Lou

On 5/22/2013 9:13 PM, Fatai Zhang wrote:
> 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
> 
>  
> 
> Fatai
> 
>  
> 
> *From:*Fatai Zhang [mailto:[e-mail]]
> *Sent:* Monday, May 20, 2013 5:09 PM
> *To:* Lou Berger
> *Cc:* BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
> [e-mail]
> *Subject:* RE: R: Closing G.709 open issues
> 
>  
> 
> Hi Lou,
> 
>  
> 
> I think my mail on May13rd 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 proposedapproach (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
> proposedapproach).
> 
>  
> 
> ======================================================================================================================
> 
> (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 17, 2013 11:16 PM
> To: Fatai Zhang
> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
> [e-mail]
> 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
> 
>  
> 
>  
>