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

[Daniele Ceccarelli <[e-mail]>]

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]

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

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