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

[Lou Berger <[e-mail]>]

Daniele,

See below.

On 7/16/2012 6:13 AM, Daniele Ceccarelli wrote:
> Hi Lou,
> 
> Different week, same thread.
> 
> Please see below (some cuts to make it more readable)
> 
> 
> [snip]
> 
>>
>> So how is this different than any other MRN/MLN example (e.g.,
>> Ether LSP over SDH LSP over Lambda LSP)?
>>
>> As John was implying in his e-mail, (why) does intra-OTN need
>> a different solution?
> 
> Intra-OTN is missing, wrt actual MRN/MLN, the capability of signlaing
> the TSG, while Inter-OTN is missing also the Adaptation between
> client and server layers (e.g. Bit-sync vs Byte-sync mapping, X.86 vs
> GFP etc)
> 
> [snip]

fair enough.

> 
>>
>>> If the other
>>> authors agree it is possible to extend it to the INTRA
>> switch cap case
>>> also and then work on the "technology agnostic" protocols extension.
>>>
>>
>> Well that would certainly fit the WG charter (comment as WG
>> contributor).
>>
>> Also, WRT to the WG document, it's the WG's call, not just the authors.
> 
> Sure, I was referring to the "bcg" draft.

okay, wasn't sure.

> It appears we came to the conclusion that a general "intra switch
> cap" work is needed (non OTN specific).
> 
> My proposal was to include the problem statement in the bcg draft (so
> to make it cover both the inter and intra cases) and then work on a
> different encoding draft (I'm not sure the OTN signaling is the right
> place for general intra switch cap encoding. Maybe a pointer is more
> appropriate.

Sounds workable to me (and aligned with what John was saying).  Now
let's see if others disagree or if we have consensus!

Thanks,
Lou

> 
> Thanks
> Daniele
> 
>> Lou
>>
>>>>
>>>> Thanks,
>>>> Lou
>>>>>
>>>>> Thanks
>>>>> Daniele
>>>>>>>> -----Original Message-----
>>>>>>>> From: Fatai Zhang [mailto:[e-mail]]
>>>>>>>> Sent: venerdì 13 luglio 2012 12.04
>>>>>>>> To: Lou Berger
>>>>>>>> Cc: John E Drake; [e-mail]; Khuzema Pithewan;
>>>>>>>> [e-mail]; Daniele Ceccarelli; Linyi;
>>>>>>>> [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO
>>>>>> VITTORIO);
>>>>>>>> Diego Caviglia; Rajan Rao; [e-mail];
>>>>>> BELOTTI, SERGIO
>>>>>>>> (SERGIO); Fatai Zhang
>>>>>>>> Subject: 答复: 答复: 答复: Updates on OTN signaling draft
>>>>>>>>
>>>>>>>> Hi Lou,
>>>>>>>>
>>>>>>>> For bundling link, it just shows the collection capability
>>>>>> of all the
>>>>>>>> component links and it cannot differentiate which component can
>>>>>>>> support which capability.
>>>>>>>>
>>>>>>>> For example, a TE link with two component links ( one can
>>>> support A
>>>>>>>> (e.g., TSG=1.25)  and another one can support B
>>>>>> (TSG=2.5G)), and then
>>>>>>>> the TE link will claim that it can support both A&B. When an LSP
>>>>>>>> needs to pick up A of the TE link, we have to indicate A in the
>>>>>>>> signaling explicitly to make the corresponding nodes to
>>>> pick up the
>>>>>>>> correct component link with capability A.
>>>>>>>>
>>>>>>>> If no bunding, everything about the TE link (actually it
>>>>>> only has one
>>>>>>>> component link) has been advertised, so the path
>>>>>> computation can make
>>>>>>>> the correct choice (ERO can indicate the correct TE link (ie.,
>>>>>>>> component link)).
>>>>>>>>
>>>>>>>> Does this make sense?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Fatai
>>>>>>>>
>>>>>>>>
>>>>>>>> -----邮件原件-----
>>>>>>>> 发件人: Lou Berger [mailto:[e-mail]]
>>>>>>>> 发送时间: 2012年7月12日 22:31
>>>>>>>> 收件人: Fatai Zhang
>>>>>>>> 抄送: John E Drake; [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)
>>>>>>>> 主题: Re: 答复: 答复: Updates on OTN signaling draft
>>>>>>>>
>>>>>>>> Fatai,
>>>>>>>>       I think I agree with John (as WG contributor).
>>>>>>>>
>>>>>>>> Why isn't the same issue present for non-bundled links when ERO
>>>>>>>> expansion takes place at any place other than the ingress node?
>>>>>>>>
>>>>>>>> How does this issue differ from any MLN H-LSP?
>>>>>>>>
>>>>>>>> Lou
>>>>>>>>
>>>>>>>> On 7/11/2012 11:54 PM, Fatai Zhang wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think TSG and hierarchy information really confused
>>>> many people,
>>>>>>>>> which causes the same questions will come out again after we
>>>>>>>> explained
>>>>>>>>> many times, :-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The simple way is to remove link bundling (or bundle the
>>>>>> homogeneous
>>>>>>>>> component links) in the routing, then all the issues disappear
>>>>>>>>> immediately ( i.e., no need TSG and hierarchy
>>>> information at all),
>>>>>>>>> otherwise, it needs these two kinds of information in
>> some cases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really suspect the value of bundling in the GMPLS for TDM
>>>>>>>> or WSON. I
>>>>>>>>> think this is interesting point to be investigated, but it
>>>>>>>> seems that
>>>>>>>>> not too many people are interested, J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please see in-line below.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fatai
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----邮件原件-----
>>>>>>>>> 发件人: John E Drake [mailto:[e-mail]]
>>>>>>>>> 发送时间: 2012年7月12日 2:54
>>>>>>>>> 收件人: Fatai Zhang; Lou Berger
>>>>>>>>> 抄送: [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)
>>>>>>>>> 主题: RE: 答复: Updates on OTN signaling draft
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fatai,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is it not the case that *any* node, regardless of whether
>>>>>> it is the
>>>>>>>>> ingress node, an intermediate node, or the penultimate
>>>> node, that
>>>>>>>>> selects the interface for the egress LSP endpoint MUST
>>>> ensure that
>>>>>>>>> that interface has a TSG that is compatible with the TSG of
>>>>>>>> interface
>>>>>>>>> for the ingress LSP endpoint?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Fatai] There are two cases for TSG issue. One is for ODU
>>>>>>>> service LSP
>>>>>>>>> (carrying non-ODU) creation, the second one is ODU FA-LSP
>>>>>>>> creation for
>>>>>>>>> carrying another lower ODU. For the first case, the TSG can be
>>>>>>>>> changeable segment by segment (link by link). For
>>>> example, when an
>>>>>>>>> ODU1 (to carry non-ODU) is being created over ODU3 link, the
>>>>>>>> TSG could
>>>>>>>>> be different link by link. For the second case, this is
>>>>>> what we are
>>>>>>>>> talking about with Lou; in this case, only end points and
>>>>>>>> penultimate
>>>>>>>>> node need to have the compatible TSG.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, it occurs to me that hierarchy is not only
>> unnecessary but
>>>>>>>>> counter-productive in signaling.  When one establishes an
>>>>>> ODU3, for
>>>>>>>>> example, that ODU3 may be used to instantiate multiple
>>>>>>>> hierarchies, so
>>>>>>>>> one does not want to specify a particular hierarchy.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If one is establishing this ODU3 in order to eventually
>>>>>> establish an
>>>>>>>>> ODU0 LSP over an ODU2 LSP, then after the ODU3 is
>>>> established, the
>>>>>>>>> ODU2 would be signaled within the ODU3.  Again, since the
>>>>>> ODU2 might
>>>>>>>>> support multiple hierarchies, one does not want to specify a
>>>>>>>> particular hierarchy.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Once the OUD2 is established, the ODU0 is signaled.  Since
>>>>>>>> it does not
>>>>>>>>> support any further hierarchy, none is specified.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Fatai] Hierarchy information is necessary when bundling
>>>>>>>> link is used.
>>>>>>>>> For your example, ODU0->ODU2->ODU3, when creating ODU2
>>>> FA-LSP over
>>>>>>>>> ODU3 links, ODU2 layer should be aware of that it should
>>>>>> pick up the
>>>>>>>>> right component link that can support ODU0 muxing (so the
>>>>>>>>> hierarchy
>>>>>>>>> ODU0->ODU2 should be carried when creating ODU2 FA-LSP),
>>>>>>>>> ODU0->otherwise,
>>>>>>>>> this arbitrary
>>>>>>>>> ODU2 could be only support ODU1->ODU2, then ODU0 cannot
>>>> be carried
>>>>>>>>> over this ODU2 FA-LSP.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>
>>>>>>>>>> From: Fatai Zhang [mailto:[e-mail]]
>>>>>>>>>
>>>>>>>>>> Sent: Tuesday, July 10, 2012 11:25 PM
>>>>>>>>>
>>>>>>>>>> To: Lou Berger
>>>>>>>>>
>>>>>>>>>> Cc: [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
>>>>>>>>>
>>>>>>>>>> Subject: 答复: 答复: Updates on OTN signaling draft
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>