Re: [CCAMP] R: R: G.709 signaling - encoding Type

[Daniele Ceccarelli <[e-mail]>]

Lou,

OK. No changes to signaling re explicit indication of mapping and/or TSG in the label.

Trying to summarize, please correct me if i'm missing something.

- Framework: no changes
- Info: no changes
- Signaling: i) GPID list check and ii) add a note on G.709 HEX values vs GPID DEC values
- Routing: new version needed to address the latest last call comments but no other change needed

BR
Daniele

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: mercoledì 20 marzo 2013 17.47
>To: BELOTTI, SERGIO (SERGIO)
>Cc: Fatai Zhang; CCAMP ([e-mail]); Daniele Ceccarelli
>Subject: Re: R: [CCAMP] R: G.709 signaling - encoding Type
>
>Sergio,
>	Thank you for clarifying why you/Daniele raised this 
>topic.  My preference/recommendation would be to not make any 
>change.  I have multiple reasons for this, primarily:
>
>1) TSG is already unambiguous, although it is true that it must be
>   derived.  Adding a second field that carries it explicit allows for
>   inconsistencies and therefore adds error cases that must be detected
>   and handled.
>
>2) I'm not a big fan of guessing what the future holds.  I do agree
>   that we can't preclude what might happen, and need to be supported,
>   but I don't see a lot of value in defining mechanisms today that
>   aren't needed today and might just be useful in the future.  In this
>   particular example, if this ever really becomes an issue, we can
>   just define a new label format.
>
>3) We've had this discussion at least once before and agreed to the
>   current approach.  Revising past decisions is fine if there's good
>   cause, such as new information or issues identified/discovered, but
>   this doesn't seem to apply in this case.
>
>This said, I think we all would prefer to not prematurely 
>limit discussion on this, but also don't want to drag this on too long.
>
>So it's really important that if there is anyone who supports 
>making a change, that they should speak up and state their 
>justification for the change (and soon)...
>
>Thanks,
>Lou
>
>On 3/20/2013 10:04 AM, BELOTTI, SERGIO (SERGIO) wrote:
>> Hi Lou,Fatai
>> 
>> In my summary you are reffering to I said:
>> 
>> ">> On the other hand this discussion is not new , since 
>many time we discussed the opportunity to have dedicated 
>object/fields to explicit adaptation information , at the 
>moment not present in GMPLS."
>> 
>> It is recognized by everybody that we can retrieve information 
>> regarding mapping by the triple you indicated. The 
>discussion is if it 
>> is the case to consider the opportunity to make explicit (in the 
>> label? ) the adaptation information . The fact that now with TSG we 
>> are able to understand the present mapping adopted in OTN, cannot 
>> assure in the future that for any possible extension regarding 
>> adaptation this triple can not be sufficient.
>> 
>> Since I'm one of the author but I'm not alone ..I cannot decide for 
>> everybody but just warn about.
>> 
>
>> 
>> Best Regards
>> 
>> Sergio
>> 
>> Belotti Sergio-  System Architect
>> ALCATE-LUCENT  Optics Division
>> via Trento 30 Vimercate (MB) - Italy
>> phone [phone]
>> 
>> -----Messaggio originale-----
>> Da: Lou Berger [mailto:[e-mail]]
>> Inviato: mercoledì 20 marzo 2013 14.53
>> A: Fatai Zhang
>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([e-mail])
>> Oggetto: Re: [CCAMP] R: G.709 signaling - encoding Type
>> 
>> Great.  Will you propose/add some related text so we don't need to 
>> revisit this again?
>> 
>> Lou
>> 
>> On 3/20/2013 5:27 AM, Fatai Zhang wrote:
>>> Hi Lou,
>>>
>>> I agree on your conclusion, which I have pointed out one or 
>two years ago when we discussed if it needs mapping information.
>>>
>>> I think some people may forgot this. 
>>> 
>=====================================================================
>>> ==================== Per the presented slide and Table 7-10 
>of G.709, 
>>> the mapping method/type is unique per combination of {ODUj, 
>ODUk, TSG}.
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Fatai
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On 
>>> Behalf Of Lou Berger
>>> Sent: Friday, March 15, 2013 7:02 PM
>>> To: BELOTTI, SERGIO (SERGIO)
>>> Cc: CCAMP ([e-mail])
>>> Subject: Re: [CCAMP] R: G.709 signaling - encoding Type
>>>
>>> Sergio,
>>> 	Thank you for clarifying the requirement. I believe you are 
>>> describing an issue that is a little different than what I 
>understood 
>>> from some earlier discussions.  Perhaps others were also in 
>the same situation.
>>>
>>> As I now understand it, the issue that is being raised is 
>one related 
>>> to ODUj LSPs that use an ODUk H-LSP as a hop, there is a 
>need at all 
>>> hops, including at *transit nodes*, to configure the mapping method 
>>> (AMP, GMP) used from the ODUj onto the ODUk H-LSP.  This of course 
>>> means that the mapping function needs to be set on a hop by 
>hop basis for the ODUj LSP.
>>>  (I though an issue on and ODUk H-LSP was being raised.)
>>>
>>> Or in other words there is an issue of per-hop resource 
>>> allocation/management.
>>>
>>> Per the presented slide and Table 7-10 of G.709, the mapping 
>>> method/type is unique per combination of {ODUj, ODUk, TSG}.  
>>> Obviously any hop signaling an ODUj LSP will know and unambiguously 
>>> be able to identify (in signaling) the ODUj and ODUk.  This 
>just leaves the TSG.
>>>
>>> Section 6.1 of the signalling draft already has text 
>covering TSG as 
>>> part of the per-hop label. So TSG is also already being signaled 
>>> unambiguously.
>>>
>>> It looks to me that all that is needed is a sentence or two stating 
>>> that the mapping type is unambiguously based on the above.
>>>
>>> Please let me know if I missed something.
>>>
>>> Lou
>>>
>>> On 3/15/2013 6:05 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>>>
>>>> The requirement comes form discussion had last week 
>related to tolerance .
>>>> We discovered from ITU experts, there is an attribute 
>related to the 
>>>> adaptation function in case of multiplexing of ODUj into ODUk,
>>>>
>>>>  oduTypeAndRate that configures the mapping method (AMP, GMP).
>>>>
>>>> Now , since obviously equipment cannot know whether 
>configuration is provided via management or control plane , 
>conclusion was that control plane should have an equivalent of 
>this attribute in order to be able to configure the right adaptation.
>>>>
>>>> On the other hand this discussion is not new , since many 
>time we discussed the opportunity to have dedicated 
>object/fields to explicit adaptation information , at the 
>moment not present in GMPLS.
>>>>
>>>> This is a summery of requirement.
>>>>
>>>> Thanks
>>>> Sergio
>>>>
>>>> Belotti Sergio-  System Architect
>>>> ALCATE-LUCENT  Optics Division
>>>> via Trento 30 Vimercate (MB) - Italy phone [phone] 
>>>> -----Messaggio originale-----
>>>> Da: Lou Berger [mailto:[e-mail]]
>>>> Inviato: giovedì 14 marzo 2013 19.58
>>>> A: Daniele Ceccarelli
>>>> Cc: Rajan Rao; John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP 
>>>> ([e-mail])
>>>> Oggetto: Re: [CCAMP] G.709 signaling - encoding Type
>>>>
>>>> Daniele, (Sergio?)
>>>>
>>>> Can you summarize the data plane behavior/requirement that is the 
>>>> basis for the change?  i.e., provide the reason why *any* 
>change is required.
>>>>
>>>> Once we all understand the data plane requirements/constraints, we 
>>>> can better decide which (hopefully existing) GMPLS 
>mechanism is best 
>>>> suited to support the requirement.
>>>>
>>>> Thank you,
>>>> Lou
>>>>
>>>> On 3/14/2013 2:41 PM, Daniele Ceccarelli wrote:
>>>>> Using the encoding was one of the possible suggestions.
>>>>>
>>>>> Indeed it has impacts on the routing and it might be 
>worth avoiding it, but another solution is preferrable wrt 
>relying on the Label Length (which might change for several 
>reasons). I would prefer not to put a requirement on the Label 
>lenght only because it is needed to retrieve the adaptation type.
>>>>>
>>>>> Other proposals are welcome. I had a chat with John this 
>morning and he was proposing the utilization of a new field 
>(even a single bit). That could be a viale option for me. 
>Since we're removing the Tolerance from the traffic parameters 
>we're going to have room for a new field.
>>>>>
>>>>> BR
>>>>> Daniele
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rajan Rao [mailto:[e-mail]]
>>>>>> Sent: mercoledì 13 marzo 2013 19.51
>>>>>> To: Lou Berger; John E Drake
>>>>>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([e-mail]); Daniele 
>>>>>> Ceccarelli
>>>>>> Subject: RE: [CCAMP] G.709 signaling - encoding Type
>>>>>>
>>>>>> Lou,
>>>>>>
>>>>>> The new encoding has implications in routing(new ISCDs). 
> I think 
>>>>>> we can minimize the impact using the two fields
>>>>>> mentioned in my email below.   To be specific,
>>>>>>
>>>>>> For the case highlighted in the slide,  the Encoding is AMP when 
>>>>>> Signal Type = ODU1  in traffic spec Length Field  = 8 in  Label
>>>>>>
>>>>>> Thanks
>>>>>> Rajan
>>>>>> -----Original Message-----
>>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>>> Sent: Wednesday, March 13, 2013 6:54 PM
>>>>>> To: John E Drake
>>>>>> Cc: BELOTTI, SERGIO (SERGIO); Rajan Rao; CCAMP ([e-mail]); 
>>>>>> Daniele Ceccarelli
>>>>>> Subject: Re: [CCAMP] G.709 signaling - encoding Type
>>>>>>
>>>>>> John,
>>>>>>
>>>>>> See below.
>>>>>>
>>>>>> On 3/13/2013 6:40 PM, John E Drake wrote:
>>>>>>> Lou,
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> I must have been asleep but I don't remember hearing of 
>an issue.
>>>>>>
>>>>>> No problem, looked like a few others had some trouble getting 
>>>>>> moving this AM too.
>>>>>>
>>>>>>>  It
>>>>>>> was my understanding that AMP and GMP both use G.709 
>encoding in 
>>>>>>> the data plane, so why would we want to make what appears to be 
>>>>>>> an artificial distinction?
>>>>>>
>>>>>> This was covered on slide 3 of Danielle's presentation.  
>>>>>> He/They can provide additional details/justification.
>>>>>>
>>>>>> Lou
>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> Irrespectively Yours,
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> *From:*Lou Berger [mailto:[e-mail]]
>>>>>>> *Sent:* Wednesday, March 13, 2013 3:27 PM
>>>>>>> *To:* John E Drake; BELOTTI, SERGIO (SERGIO); Rajan Rao
>>>>>>> *Cc:* CCAMP ([e-mail]); Daniele Ceccarelli
>>>>>>> *Subject:* Re: [CCAMP] G.709 signaling - encoding Type
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> Do you have an alternate proposal on how to address the 
>issue, or 
>>>>>>> do you just see an issue?
>>>>>>>
>>>>>>> (If the former, the onus will fall on you to provide 
>one. If the 
>>>>>>> latter, it'll fall to Sergio And Danielle to recap the presented
>>>>>>> issue.)
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> On March 13, 2013 6:16:46 PM John E Drake wrote:
>>>>>>>
>>>>>>>     Hi,
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     I don't think this is a good idea and I don't see any
>>>>>> reason for it.
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Irrespectively Yours,
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     John
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     *From:*[e-mail] 
><mailto:[e-mail]>
>>>>>>>     [mailto:[e-mail]] *On Behalf Of *BELOTTI,
>>>>>> SERGIO (SERGIO)
>>>>>>>     *Sent:* Wednesday, March 13, 2013 6:53 AM
>>>>>>>     *To:* Rajan Rao
>>>>>>>     *Cc:* CCAMP ([e-mail] <mailto:[e-mail]>)
>>>>>>>     *Subject:* [CCAMP] R: G.709 signaling - encoding Type
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Rao,
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     it is a proposal: so you should read:  "encoding type can 
>>>>>>> indicate.
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Regards
>>>>>>>
>>>>>>>     Sergio
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     *Belotti Sergio-  System Architect*
>>>>>>>
>>>>>>>     *ALCATE-LUCENT  Optics Division*
>>>>>>>
>>>>>>>     via Trento 30 Vimercate (MB) - Italy
>>>>>>>
>>>>>>>     phone [phone]
>>>>>>>
>>>>>>>     
>>>>>>>
>>>>>> 
>------------------------------------------------------------------
>>>>>> ----
>>>>>>> --
>>>>>>>
>>>>>>>     *Da:*[e-mail] <mailto:[e-mail]>
>>>>>>>     [mailto:[e-mail]] *Per conto di *Rajan Rao
>>>>>>>     *Inviato:* mercoledì 13 marzo 2013 14.40
>>>>>>>     *A:* CCAMP ([e-mail] <mailto:[e-mail]>)
>>>>>>>     *Oggetto:* [CCAMP] G.709 signaling - encoding Type
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Daniele,
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     The presentation slide#3 says:  "encoding type 
>indicates AMP or
>>>>>>>     GMP".   I don't think this is the case.  We use  
>G.709 ODUk as
>>>>>>>     encoding type.  There is no explicit indication of 
>AMP or GMP
>>>>>>>     there.  Are you proposing to change this?
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Note that AMP/GMP can be inferred from Signal Type in
>>>>>> traffic param
>>>>>>>     & Length field ( = 8) in the label.
>>>>>>>
>>>>>>>      
>>>>>>>
>>>>>>>     Thanks
>>>>>>>     Rajan
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>> 
>> 
>> 
>> 
>