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

[Lou Berger <[e-mail]>]

Daniele,

See below.

On 7/13/2012 10:59 AM, Daniele Ceccarelli wrote:
> Lou,
> 
>>
>> Daniele,
>>
>>
>> On 7/13/2012 9:04 AM, Daniele Ceccarelli wrote:
>>> Lou,
>>>
>>> [...]
>>>>
>>>> So what do you believe is needed to support 1?
>>>>
>>>> How does this differ than what is needed for generic MLN?
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>
>>> What is needed in OTN is:
>>> A) TSG
>>
>> And this is covered in the current (MRN/MLN-aligned) proposal
>> via G-PID, right?
> 
> Correct
> 
>>
>>> B) Hierarchy (i must be honest, i should re-think about it because i
>>> don't remember why it is needed but i'm sure we came to the
>> conclusion
>>> it is need)
>>>
>>
>> Given the current discussion (including John's comments) it
>> would be good to understand what purpose this serves and how
>> it differs from what is needed to satisfy your next point.
> 
> Well, the main reason is that the famoous penultimte hop, when
> reached by the path message, needs to know not only that an e.g. ODU4
> is being set up but that e.g. An ODU2->ODU3->ODU4 needs to be
> established, hence an H-LPS supporting ODU2->ODU3->ODU4 demuxing on
> the other end of the link is needed.
> 

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?

>>
>>
>>> What is needed in MLN is also:
>>> C) adaptation information (not needed in intra-OTN as there is a 1:1
>>> relationship for any mapping)
>>
>> Presumably this is the focus of
>> draft-bcg-ccamp-gmpls-ml-implications-00, right?
> 
> Sort of. Such draft was born as a consequence of comments received in
> Paris. The goal was defining requirements and use cases for INTER
> Switch Cap MLN (followed then by protocol extensions). 

Okay.

> What is coming out in these days is also INTRA Switch Cap issues. 

Agreed.

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

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