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

[John E Drake <[e-mail]>]

This sounds like a plan.  Lou, if the signaling draft could be re-spun with these changes prior to Vancouver, then could we discuss the draft there and set the stage for a LC of it and the routing draft?

Sent from my iPhone


> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Thursday, July 19, 2012 8:46 AM
> To: John E Drake
> Cc: Daniele Ceccarelli; Fatai Zhang; [e-mail]; Khuzema Pithewan;
> [e-mail]; Linyi; [e-mail];
> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao;
> [e-mail]; BELOTTI, SERGIO (SERGIO)
> Subject: Re: 答复: 答复: Updates on OTN signaling draft
>
> 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:[e-mail]]
> >> Sent: Thursday, July 19, 2012 3:20 AM
> >> To: John E Drake; Fatai Zhang; Lou Berger
> >> Cc: [e-mail]; Khuzema Pithewan; [e-mail];
> >> Linyi; [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO
> >> VITTORIO); Diego Caviglia; Rajan Rao; [e-mail];
> >> 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:[e-mail]]
> >>> Sent: mercoledì 18 luglio 2012 23.01
> >>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
> >>> Cc: [e-mail]; Khuzema Pithewan;
> [e-mail];
> >>> Linyi; [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO
> >>> VITTORIO); Diego Caviglia; Rajan Rao; [e-mail];
> >>> 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:[e-mail]]
> >>>> Sent: Wednesday, July 18, 2012 10:02 AM
> >>>> To: John E Drake; Fatai Zhang; Lou Berger
> >>>> Cc: [e-mail]; Khuzema Pithewan;
> >>>> [e-mail]; Linyi; [e-mail];
> >>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan
> >>>> Rao; [e-mail]; 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:[e-mail]]
> >>>>> Sent: mercoledì 18 luglio 2012 17.58
> >>>>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
> >>>>> Cc: [e-mail]; Khuzema Pithewan;
> >>> [e-mail];
> >>>>> Linyi; [e-mail]; GRANDI, PIETRO VITTORIO (PIETRO
> >>>>> VITTORIO); Diego Caviglia; Rajan Rao; [e-mail];
> >>>>> 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:[e-mail]]
> >>>>>> Sent: Wednesday, July 18, 2012 3:30 AM
> >>>>>> To: John E Drake; Fatai Zhang; Lou Berger
> >>>>>> Cc: [e-mail]; Khuzema Pithewan;
> >>>>>> [e-mail]; Linyi; [e-mail];
> >>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan
> >>>>>> Rao; [e-mail]; 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:[e-mail]]
> >>>>>>        Sent: martedì 17 luglio 2012 16.18
> >>>>>>        To: Fatai Zhang; Lou Berger; Daniele Ceccarelli
> >>>>>>        Cc: [e-mail]; Khuzema Pithewan;
> >>>>> [e-mail];
> >>>>>> Linyi; [e-mail]; GRANDI, PIETRO VITTORIO
> (PIETRO
> >>>>>> VITTORIO); Diego Caviglia; Rajan Rao; [e-mail];
> >>>>>> 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:[e-mail]]
> >>>>>>        Sent: Monday, July 16, 2012 7:03 PM
> >>>>>>        To: Lou Berger; Daniele Ceccarelli
> >>>>>>        Cc: John E Drake; [e-mail]; Khuzema Pithewan;
> >>>>>> [e-mail]; 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,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>        [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:[e-mail]]
> >>>>>>        发送时间: 2012年7月16日 20:47
> >>>>>>        收件人: Daniele Ceccarelli
> >>>>>>        抄送: Fatai Zhang; John E Drake; [e-mail]; Khuzema
> >>>>> Pithewan;
> >>>>>> [e-mail]; Linyi; [e-mail];
> >>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia;
> >>>>> Rajan Rao;
> >>>>>> [e-mail]; BELOTTI, SERGIO
> >>>>>> (SERGIO)
> >>>>>>        主题: Re: 答复: 答复: Updates on OTN signaling draft
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>        [snip]
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>