John/All,
	It sounds like we've reach some agreement on this thread, right?

(As participant in thread) I read that the conclusion is to not optimize
for a very special corner case and:
1) basically treat the intra-OTN case the same as any other MRN/MLN case
   (leveraging GPID, and no new hierarchy object)
2) Use Daniele's new draft on MRN/MLN as the starting point in the
discussion of how to address the limitations in MRN/MLN identified in
this discussion.

Did I miss anything?

Thanks,
Lou

On 7/19/2012 7:09 AM, John E Drake wrote:
> Daniele,
> 
> What concerns me is that we are headed in a design direction in which
> signaling is required to carry all of the information necessary to
> allow any intermediate node to select the egress interface for an
> LSP.  The issue I have with this is that it requires every
> intermediate node to have exactly the same capabilities as the
> ingress/egress nodes, which makes the incremental introduction of new
> capabilities more challenging.
> 
> Allowing heterogeneous nodal capabilities is one of the reasons we
> include all of this information in routing in the first place.
> 
> Thanks,
> 
> John 
> 
> Sent from my iPhone
> 
>> -----Original Message-----
>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>> Sent: Thursday, July 19, 2012 3:20 AM
>> To: John E Drake; Fatai Zhang; Lou Berger
>> Cc: ccamp@ietf.org; Khuzema Pithewan; zhangguoying@mail.ritt.com.cn;
>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO
>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com;
>> BELOTTI, SERGIO (SERGIO)
>> Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>
>> That could be another option perfectly reasonable.
>>
>> However I don't know which one is faster and cheaper. An RFC bis
>> modifies the behavior of existing implementaitons while an totally new
>> object already defined that only needs to be imported into the new
>> MRN/MLN extensions only applies to new implementations.
>> I assume the existing ones rely on cranck-backs or EROs including,
>> among the others, the egress interface (e.g. strict ERO).
>>
>> Thanks,
>> Daniele
>>
>>> -----Original Message-----
>>> From: John E Drake [mailto:jdrake@juniper.net]
>>> Sent: mercoledì 18 luglio 2012 23.01
>>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
>>> Cc: ccamp@ietf.org; Khuzema Pithewan;
>>> zhangguoying@mail.ritt.com.cn; Linyi;
>>> xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
>>> Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; BELOTTI, SERGIO
>>> (SERGIO)
>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>>
>>> That's fair, but perhaps we should stipulate in an RFC
>>> 3471/3473 bis that the ingress node MUST specify the egress interface
>>> in the ERO?  We seem to be spending a lot time and effort to work
>>> around this.
>>>
>>> Sent from my iPhone
>>>
>>>
>>>> -----Original Message-----
>>>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>>>> Sent: Wednesday, July 18, 2012 10:02 AM
>>>> To: John E Drake; Fatai Zhang; Lou Berger
>>>> Cc: ccamp@ietf.org; Khuzema Pithewan; zhangguoying@mail.ritt.com.cn;
>>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO
>>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com;
>>>> BELOTTI, SERGIO (SERGIO)
>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>>>
>>>> Hi John,
>>>>
>>>> Yes it is, but it falls in the case I call strict ERO.
>>>> When I use the term loose ERO I refer to an ERO lacking of some info
>>>> (exactly that piece of information), when I refer to a strict ERO I
>>>> speak about an ERO including info of all the hops (hence including
>>>> that piece of information, the rest of the path is
>>> meaningless in this
>>>> context).
>>>> I know the terminology is not exact but I didn't want to invent new
>>>> names when referring to an ERO with that info and ERO without it.
>>>>
>>>> BR
>>>> Daniele
>>>>
>>>>> -----Original Message-----
>>>>> From: John E Drake [mailto:jdrake@juniper.net]
>>>>> Sent: mercoledì 18 luglio 2012 17.58
>>>>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
>>>>> Cc: ccamp@ietf.org; Khuzema Pithewan;
>>> zhangguoying@mail.ritt.com.cn;
>>>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO
>>>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com;
>>>>> BELOTTI, SERGIO
>>>>> (SERGIO)
>>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>>>>
>>>>> Daniele,
>>>>>
>>>>> You are correct.  One question though, isn't it the case that it is
>>>>> sufficient for the ingress to specify the egress interface
>>> in the ERO
>>>>> rather than computing a strict ERO?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> John
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>>>>>> Sent: Wednesday, July 18, 2012 3:30 AM
>>>>>> To: John E Drake; Fatai Zhang; Lou Berger
>>>>>> Cc: ccamp@ietf.org; Khuzema Pithewan;
>>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn;
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan
>>>>>> Rao; IBryskin@advaoptical.com; BELOTTI, SERGIO (SERGIO)
>>>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> partially agree. I think the hierarchy is still needed for
>>>>> those cases
>>>>>> in which 3 or more layer are being involved, in
>>> particular when the
>>>>>> penultimate node, performing the choice of the FA, receives a
>>>>>> signalling message of layer 2, needs to choose the FA at layer 3
>>>>>> and is not aware of layer 1. Let's try to make an example
>>> (switched
>>>>>> to plain text for the drawing):
>>>>>>
>>>>>>                                  ODU1-LSP
>>>>>>            .....................................................
>>>>>>            |                                                   |
>>>>>>            |                           ODU2-H-LSP              |
>>>>>>            |            +======================================+
>>>>>>            |            |                                      |
>>>>>>            |            |                                      |
>>>>>>            |            |                   ODU3-H-LSP         |
>>>>>>            |            |            |-------------------------|
>>>>>>            |            |            |                         |
>>>>>>         +--+--+      +-----+      +--+--+      +---+-+
>>>  +-----+
>>>>>>         |     |      |     |      |     |      |     |
>>>  |     |
>>>>>>         |  A  +------+  B  +------+  C  +------+  D
>>> |------+  E  |
>>>>>>         |     |      |     |      |     |      |     |
>>>  |     |
>>>>>>         +-----+      +-----+      +-----+      +-----+
>>>  +-----+
>>>>>>
>>>>>>
>>>>>> The LSP being signaled (ODUj), from A to E is an ODU1
>>>>> (called layer 1
>>>>>> above). B receives a path message related to the ODU1 and
>>> starts a
>>>>>> signaling for an ODU2. C receives the ODU2 path message whose
>>>>>> destination is E and needs to "choose among a set
>>>>> of"/"request the set
>>>>>> up of" an ODU3 H-LSP from itself to E (loose ERO used). The
>>>>> only thing
>>>>>> that C knows is that the interface on E must be able to perform
>> an
>>>>>> ODU2->ODU3 demuxing to extract the client traffic from the ODU2.
>>>>>>
>>>>>> This is not correct, the demuxing capability required on the
>>>>> interface
>>>>>> on E is ODU1->ODU2->ODU3 and the only way to let C know it, is
>>>>>> introducing the hierarchy in signaling.
>>>>>>
>>>>>> I think this is quite a corner case, more academic
>>> speculation than
>>>>>> real case, but if there is a 0,00001% possibility it can
>>> happen, we
>>>>>> should cover the case.
>>>>>>
>>>>>> Please note that the problem does not exist using a strict
>>>>> ERO (which
>>>>>> i wuold suggest :-)
>>>>>>
>>>>>> Thanks,
>>>>>> Daniele
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> 	From: John E Drake [mailto:jdrake@juniper.net]
>>>>>> 	Sent: martedì 17 luglio 2012 16.18
>>>>>> 	To: Fatai Zhang; Lou Berger; Daniele Ceccarelli
>>>>>> 	Cc: ccamp@ietf.org; Khuzema Pithewan;
>>>>> zhangguoying@mail.ritt.com.cn;
>>>>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO
>>>>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com;
>>>>>> BELOTTI, SERGIO (SERGIO)
>>>>>> 	Subject: RE: 答复: 答复: Updates on OTN signaling draft
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Fatai,
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	To recap my previous emails:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	1)      TSG info needs to be carried in signaling in the
>> GPID
>>>>>>
>>>>>> 	2)      Any node that performs CSPF and selects the egress
>>>>>> interface for an LSP needs to ensure that interface’s TSG is
>>>>>> compatible with the ingress interface’s TSG as indicated in
>>>>> signaling
>>>>>> (the GPID)
>>>>>>
>>>>>> 	3)      Signaling should not carry hierarchy info because
>>>>>> signaling only instantiates a single ODUj
>>>>>>
>>>>>> 	4)      The ingress will sequentially signal multiple ODUj
>> LSPs,
>>>>>> each with a different value of j, in order to instantiate an OTN
>>>>>> hierarchy between a given ingress/egress pair
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	As an aside, just over a year ago, we had an extended
>>>>> discussion of
>>>>>> this topic in which I argued in support of the Infinera
>>> approach of
>>>>>> using a single signaling message to instantiate any necessary
>>>>>> intermediate hierarchy in support of a given client ODUj, and
>>>>>> nobody bought my arguments..
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	John
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Sent from my iPhone
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	From: Fatai Zhang [mailto:zhangfatai@huawei.com]
>>>>>> 	Sent: Monday, July 16, 2012 7:03 PM
>>>>>> 	To: Lou Berger; Daniele Ceccarelli
>>>>>> 	Cc: John E Drake; ccamp@ietf.org; Khuzema Pithewan;
>>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn;
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia;
>>>>> Rajan Rao;
>>>>>> IBryskin@advaoptical.com; BELOTTI, SERGIO (SERGIO); Fatai Zhang
>>>>>> 	Subject: 答复: 答复: 答复: Updates on OTN signaling draft
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Hi Lou,
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	[snip]
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Let's understand where we are, :-),
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	If my following understanding is not correct, please
>>>>> list some items
>>>>>> that we need to get the consensus.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> =================================================================
>>>>>> ======================================================
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	[Fatai] Did you mean (or agree) that intra-OTN is missing
>> the
>>>>>> capability of signaling the TSG? Should Inter-OTN be generic
>>>> MRN/MLN?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	> 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!
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	[Fatai] I understood Daniele's proposal. However,
>>>>> focusing on OTN
>>>>>> signaling draft, did you mean that this draft (OTN signaling)
>>>>>> should focus on OTN specific (intra-OTN) as what it is or this
>>>>>> draft should remove TSG or hierachy information or bothe of them
>>>>>> (ie., GPID extension for TSG and hierachy inforamtion in LSPA)?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	Fatai
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	-----邮件原件-----
>>>>>> 	发件人: Lou Berger [mailto:lberger@labn.net]
>>>>>> 	发送时间: 2012年7月16日 20:47
>>>>>> 	收件人: Daniele Ceccarelli
>>>>>> 	抄送: Fatai Zhang; John E Drake; ccamp@ietf.org; Khuzema
>>>>> Pithewan;
>>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn;
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia;
>>>>> Rajan Rao;
>>>>>> IBryskin@advaoptical.com; BELOTTI, SERGIO
>>>>>> (SERGIO)
>>>>>> 	主题: Re: 答复: 答复: Updates on OTN signaling draft
>>>>>>
>>>>>>
>>>>>>
>>>>>> 	[snip]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>