Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft

[Lou Berger <[e-mail]>]

Fatai,
	Sure get the document out.  Given there will still be 2 weeks after
that before the meeting, and that WG consensus must be achieved on the
list, we should continue the discussion on the list (i.e., reply to my
previous mail) once the draft is submitted and not wait for Vancouver.

As I mentioned in my previous mail, the shift towards leveraging
technology-independent GMPLS mechanisms to address intra-OTN H-LSP
signaling is well aligned with the WG charter/objectives. I think we
should try not to loose momentum by waiting for the meeting.

Lou

On 7/12/2012 2:25 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> How about let me update the draft first, because I only have two
> working days to update and submit a new version? :-)
> 
> Let's discuss more in Vancouver meeting and get the WG consensus
> there.
> 
> Anyway, any changes should defer to the WG consensus, otherwise the
> authors would like to continue to update the draft based on WG
> consensus.
>  
> Thanks
> 
> Fatai
> 
> 
> -----邮件原件-----
> 发件人: Lou Berger [mailto:[e-mail]] 
> 发送时间: 2012年7月11日 21:38
> 收件人: Fatai Zhang
> 抄送: [e-mail]; Khuzema Pithewan; [e-mail]; [e-mail]; Linyi; [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [e-mail]; Rajan Rao; [e-mail]; BELOTTI, SERGIO (SERGIO); John E Drake
> 主题: Re: 答复: 答复: Updates on OTN signaling draft
> 
> Fatai,
> 	It sounds you/the Authors are proposing/moving towards G-PID + MRN/MLN
> to support intra-OTN H-LSPs.  From a WG perspective, this is great as it
> leverages/extends existing technology-independent GMPLS mechanisms.
> 
> I think you may have missed a process point in my previous mail.
> 
> As I'm sure you know, author's consensus does not mean there is WG
> consensus.  You say that there has been much (off-line) discussion among
> the authors. While off-line discussions are always a fine way to make
> progress among individuals, the results of private discussions do not
> represent WG consensus.
> 
> So from my previous mail:
>> Can one of the authors summarize the [off-line author's]
>> discussion for the WG?
> 
> ...
> 
>>> [Authors] The authors would like to focus on OTN specific by
>>> removing Encoding type and Switching type in the Hierarchy TLV
>>> (but keeping Signal Type). It is OK to have a new draft to cover
>>> generic intra-technology MLN.
>>
>> How is the revised TLV to be used?  Do the authors have a specific
>> proposal that covers "generic intra-technology MLN"?
> 
> Lou
> 
> BTW The use of G-PID was first discussed in
> draft-ietf-ccamp-otn-g709-info-model-01 and Signal Type in John's mail
> on 7/27/2011.
> 
> On 7/11/2012 2:24 AM, Fatai Zhang wrote:
>> Hi Lou,
>>
>> Let me repeat the requirement of this information. 
>> When an ODU (e.g., ODU1) with one specific TSG (because of the ingress interface constraint) needs to be created over another higher ODU (e.g., ODU3 FA-LSP), the penultimate hop of this ODU3 FA-LSP needs to be aware of which TSG should be picked up from the TE link (ie., choose the right component link which can support the client TSG), so the client TSG information (and hierarchy information) needs to be conveyed in the signaling to create the ODU FA-LSP. 
>>
>> The requirement has been discussed in the previous IETF meetings, please get more information from the presentation slides of Taipei and Paris meetings.
>>
>> Given that people understand the above requirment, let's focus on the potential solutions. In Taipei meeting, the authors compared three alternatives and discussed in the list:
>> (1) Introducing a new object: WG prefer to re-use the existing things, so the authors switched to (2).
>> (2) Extending GPID to carry TSG/PT information: Lou once suggested this approach and the authors finally agreed on this because it is needed only for penultimate hop to select right link to egress. Note that TSG isn't needed for loose ERO expansion.
>> (3) Extending Encoding Type: Encoding type is an end to end constraint (See RFC4328), so the authors think it is not the right place.
>>
>> Do we need to poll how many people support which approach perspectively (or any other approach)?
>>
>>
>>
>> Thanks
>>
>> Fatai
>>
>>
>> -----邮件原件-----
>> 发件人: Lou Berger [mailto:[e-mail]] 
>> 发送时间: 2012年7月10日 22:33
>> 收件人: Fatai Zhang
>> 抄送: [e-mail]; Khuzema Pithewan; [e-mail]; [e-mail]; Linyi; [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [e-mail]; Rajan Rao; [e-mail]; BELOTTI, SERGIO (SERGIO); John E Drake
>> 主题: Re: 答复: Updates on OTN signaling draft
>>
>> Fatai,
>>
>> See below for in-line responses.
>>
>> On 7/10/2012 5:34 AM, Fatai Zhang wrote:
>>>
>>>
>>> Hi Lou,
>>>
>>>  
>>>
>>> Please see in-line below.
>>>>  
>>>
>>> Note that let’s use HTML format to make the mails readable, J
>>>
>>>    
>>>
>>> Thanks
>>>
>>>  
>>>
>>> Fatai
>>>
>>>  
>>>
>>>  
>>>
>>> -----邮件原件-----
>>> 发件人: Lou Berger [mailto:[e-mail]]
>>> 发送时间: 2012年7月10日 5:27
>>> 收件人: Fatai Zhang
>>> 抄送: [e-mail]; Khuzema Pithewan; [e-mail];
>>> [e-mail]; Linyi; [e-mail];
>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [e-mail];
>>> Rajan Rao; [e-mail]; BELOTTI, SERGIO (SERGIO); John E Drake
>>> 主题: Re: Updates on OTN signaling draft
>>>
>>>  
>>>
>>> [Woops, this was stuck in my outbox from last week!]
>>>
>>>  
>>>
>>> Fatai/Authors,
>>>
>>>          G-PID is a fine place to carry information about the format/type of information carried by an LSP. An important consideration is that G-PID information is not used as part of path computation, and is not used by transit nodes except in the case of the penultimate hop (for PHP).
>>>  
>>> When we last discussed this, some authors stated that TSG was needed as part of path computation, including at transit nodes doing loose ERO expansion.  Hence the discussed inclusion of TSG in LSP Encoding Type.
>>>
>>> If the authors are now willing to state that TSG isn't needed for loose ERO expansion, then G-PID seems the perfect choice.
>>>
>>> Do all the authors agree with such this statement (and change)?
>>  
>>> [Authors] After lots of discussion, the authors came to conclude that it is needed only for penultimate hop to select right link to egress and hence the change.
>>
>> Can one of the authors summarize the discussion for the WG?
>>
>> The authors are asking for WG support, so should provide the technical basis for the position. Once the requirements are articulated, the WG can be in a position to judge/agree/disagree with the proposed solution.
>>
>>>
>>> As I mentioned on the on the conference call, and my mail of 6/18, the use of G-PID as part of a path selection is really part of the general issue seen in MLN. On the call we agreed that non-OTN MLN will be handled as the standard MLN case, without OTN-specific additions.
>>>
>>> Unless I'm misreading your mail, you are *not* proposing to treat the intra-OTN (hierarchy) case as generic MLN but rather a special case by bundling some upper OTN hierarchy information as part of a lower H-LSPs (in Hierarchy TLV).
>>>
>>> Correct?
>>>
>>> [Authors] Correct, it is the latter one.
>>>
>>> If my reading is correct, then I think the authors need to discuss their technical reasons for their "preference" and why the previously reached compromise position (as articulated in my mail of 6/18) is not acceptable.
>>>
>>> [Authors] After checking after conf call, the authors think that Encoding type is an end to end constraint (See RFC4328) and GPID should be the right place as you mention above.
>>
>> This goes to requirements, in today's GMPLS G-PID is not part of path computation except in the context of MRN/MLN.
>>
>>>
>>> Speaking only as an individual contributor, given the difficulty in reaching a consensus on how to treat intra-OTN (hierarchy) as a special case, I personally now prefer to avoid any technology specific co-mingling of layers and to address the intra-OTN (hierarchy) case via generic MLN (or other generic mechanisms).  I think this position would translate to removing the Hierarchy TLV from the OTN signaling draft and spinning up a new draft to cover (OTN and generic) intra-technology MLN.
>>>
>>> [Authors] The authors would like to focus on OTN specific by removing Encoding type and Switching type in the Hierarchy TLV(but keeping Signal Type). It is OK to have a new draft to cover generic intra-technology MLN.
>>
>> How is the revised TLV to be used?  Do the authors have a specific proposal that covers "generic intra-technology MLN"?
>>
>> Lou
>>
>>>
>>>  
>>> Lou
>>>
>>>  
>>>
>>> On 7/5/2012 9:25 PM, Fatai Zhang wrote:
>>>
>>>>
>>>
>>>> Hi all,
>>>
>>>>
>>>
>>>> We are updating OTN signaling draft. Since we had lots of discussion on
>>> the TSG stuff in the list, let's converge on the solution.
>>>
>>>>
>>>
>>>> Based on the previous discussion between Lou and co-authors, the
>>> authors prefer the following changes:
>>>
>>>>
>>>
>>>> (1) Extending GPID to carry TSG in signaling, since its purpose in
>>> signaling is to ensure that endpoints of the LSP being signaled have a
>>> consistent view of the TSG to be offered to its clients and LSP endpoint
>>> consistency is the purpose for which the GPID was designed.
>>>
>>>>
>>>
>>>> (2)Extending LSPA to carry hierarchy information (ie., Type=2 Hierarchy
>>> TLV).
>>>
>>>>
>>>
>>>> Any comments?
>>>
>>>>
>>>
>>>> Thanks
>>>
>>>>
>>>
>>>> Fatai
>>>