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

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

Looks good

Sent from my iPhone

> -----Original Message-----
> From: Fatai Zhang [mailto:[e-mail]]
> Sent: Sunday, July 22, 2012 8:05 PM
> To: Daniele Ceccarelli; John E Drake; 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: 答复: 答复: 答复: Updates on OTN signaling draft
>
> Hi Daniele,
>
> If non-homogeneous component links MUST NOT be bundled together, it
> means that component links with different characteristics MUST be
> advertised in different LSAs (as different TE links) instead of
> different ISCDs in the same LSA (as one single TE link).
>
> Therefore, I would suggest the following text by removing "and a
> different ISCD MUST be used for each different muxing hierarchy (muxing
> tree in the following examples) and different TSG supported within the
> TE Link, if it includes component links with differing
> characteristics." , because this text conflicts with " Component links
> supporting non homogenous hierarchies MUST NOT be bundled together".
>
> Hope all the people are interested in OTN protocol to review this NEW
> text.
>
> NEW:
>    A single ISCD MAY be used for the advertisement of unbundled or
>    bundled links supporting homogeneous multiplexing hierarchies and
> the
>    same Tributary Slot Granularity (TSG). Component links supporting
> non homogenous
>    hierarchies MUST NOT be bundled together.
>
>
>
> Thanks
>
> Fatai
>
> -----邮件原件-----
> 发件人: Daniele Ceccarelli [mailto:[e-mail]]
> 发送时间: 2012年7月20日 17:53
> 收件人: Fatai Zhang; John E Drake; Lou Berger
> 抄送: [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
>
> Hi Fatai,
>
> 1. wrt the text in the OSPF draft - I was assuming that the text was
> implying that component links with non homogeneous hierarchies could
> not be bundled, but maybe it is bettere making it explicit. What about:
>
> OLD:
>    A single ISCD MAY be used for the advertisement of unbundled or
>    bundled links supporting homogeneous multiplexing hierarchies and
> the
>    same Tributary Slot Granularity (TSG).  A different ISCD MUST be
> used
>    for each different muxing hierarchy (muxing tree in the following
>    examples) and different TSG supported within the TE Link, if it
>    includes component links with differing characteristics.
> NEW:
>    A single ISCD MAY be used for the advertisement of unbundled or
>    bundled links supporting homogeneous multiplexing hierarchies and
> the
>    same Tributary Slot Granularity (TSG).  Component links supporting
> non homogenous
>    hierarchies MUST NOT be bundled together and a different ISCD MUST
> be used
>    for each different muxing hierarchy (muxing tree in the following
>    examples) and different TSG supported within the TE Link, if it
>    includes component links with differing characteristics.
>
> I just realized that the version -03 we've been working on has not been
> published. I'll introduce this change in the -03 version and upload it
> on July 30th.
>
> 2. Wrt the utilization of the "strict ERO" - All the past
> considerations are still true as the bundling of only homogenous
> hierarchies has been taken into account. Hence the "strict ERO" is
> still needed because the information needed by the penultimate hop for
> the H-LSP choice is not only depending on what is the H-LSP capability
> but what is being carried by the LSP being signaled.
>
> Thanks,
> Daniele
>
>
> >-----Original Message-----
> >From: Fatai Zhang [mailto:[e-mail]]
> >Sent: venerdì 20 luglio 2012 9.52
> >To: Daniele Ceccarelli; John E Drake; 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: 答复: 答复: 答复: Updates on OTN signaling draft
> >
> >Hi Daniele,
> >
> >Correct. What you said is my suggestion in 11th July (ie., remove link
> >bundling (or bundle the homogeneous component links).
> >
> >However, the quoted text from [OTN-OSPF] draft, it allows to bundle
> >heterogeneous component links by different ISCDs. If it states
> >explicitly that only homogeneous component links could be bundled
> (ie.,
> >heterogeneous component links MUST not bundled), then what you said
> >below is completely correct.
> >
> >Let's step further, if no bundling or only bundling the homogeneous
> >component links, there is no need to have hierarchy information and no
> >need to have "strict" ERO (ie., indicate egress interface), because
> the
> >node can pick up the component link locally (ie., any of the component
> >is fine).
> >
> >This should be the perfect solution.
> >
> >Is this clear now?
> >
> >===============================================================
> >======================================================
> >For each bundled TE link you can only have component links with the
> >same hierarchy and TSG supported, so any component link of the bundled
> >link works fine and there is no need to indicate the component link ID
> >but just the TE-link.
> >
> >
> >>" A single ISCD MAY be used for the advertisement of
> >unbundled or bundled links supporting homogeneous multiplexing
> >hierarchies and the same Tributary Slot Granularity (TSG).  A
> different
> >ISCD MUST be used for each different muxing hierarchy (muxing tree in
> >the following examples) and different TSG supported within the TE
> Link,
> >if it includes component links with differing characteristics.
> >
> >
> >Thanks
> >
> >Fatai
> >
> >
> >-----邮件原件-----
> >发件人: Daniele Ceccarelli [mailto:[e-mail]]
> >发送时间: 2012年7月19日 20:05
> >收件人: Fatai Zhang; John E Drake; Lou Berger
> >抄送: [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
> >
> >Hi Fatai,
> >
> >Please find comments/replies in line
> >
> >Thanks,
> >Daniele
> >>
> >>Hi John and Daniele,
> >>
> >>It seems that people are converging. If we step further, I
> >think people
> >>can understand the bundling issue that I raised in 13rd July.
> >>
> >>The problem is how we can specify the egress interface (ID) ?
> >>To be precise, it is egress interface of penultimate node of
> >the H-LSP.
> >
> >Correct, but indeed it is the same thing, isn't it?
> >
> >>
> >>As I said in 13rd July, for a bundling link, it just shows the
> >>collection capability of all the component links and it cannot
> >>differentiate which component can support which capability.
> >>
> >>To clarify the quoted text from Daniele, the routing approach below
> >>still cannot differentiate which component can support which
> >>capability, because there is no association between one specific
> >>component link (ID) and one specific capability is advertised in the
> >>routing.
> >
> >For each bundled TE link you can only have component links with the
> >same hierarhcy and TSG supported, so any component link of the bundled
> >link works fine and there is no need to indicate the component link ID
> >but just the TE-link.
> >
> >>===============================================================
> >>===============================================
> >>bundling is not a problem IMHO, as the OTN ID already states that:
> >>
> >>" A single ISCD MAY be used for the advertisement of unbundled or
> >>bundled links supporting homogeneous multiplexing hierarchies and the
> >>same Tributary Slot Granularity (TSG).  A different ISCD MUST be used
> >>for each different muxing hierarchy (muxing tree in the following
> >>examples) and different TSG supported within the TE Link, if it
> >>includes component links with differing characteristics. "
> >>
> >>
> >>
> >>
> >>
> >>
> >>Thanks
> >>
> >>Fatai
> >>
> >>
> >>-----邮件原件-----
> >>发件人: John E Drake [mailto:[e-mail]]
> >>发送时间: 2012年7月19日 5:01
> >>收件人: Daniele Ceccarelli; Fatai Zhang; Lou Berger
> >>抄送: [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
> >>
> >>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]
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>
> >