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

[Daniele Ceccarelli <[e-mail]>]

OK!

Thanks
Daniele

>-----Original Message-----
>From: John E Drake [mailto:[e-mail]]
>Sent: lunedì 23 luglio 2012 14.45
>To: Fatai Zhang; Daniele Ceccarelli; 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
>
>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]
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>
>> >
>