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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 23 Jul 2012 19:21:02 +0200

Hi Julien,

I'm pretty sure i've written somewhere (maybe the info-model, i need to check) that homogeneous hierarchy stands for same muxing capability *and* same TSG.

By the way the text you're proposing can be added as a procedure for the non homogeneous hierarchies (same muxing but different tsg)

Thanks

Daniele

--Original message---
Sender: "Julien Meuric" <[email-masked]>
Sent time: 23/lug/2012 17:24
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft

Hi Fatai, hi Daniele.

It feels like the proposed wording is leaving out the case of
"homogeneous hierarchy + different TSGs": is it on purpose?

Since it is not obvious if you are talking about data plane capabilities
or control plane supports, what about adding something like the following?
"If component links supporting an homogeneous hierarchy but different
TSGs are bundled together, the smallest commonly supported TSG SHOULD be
used (i.e. fallback is forced for lower granularity components)."

Regards,

Julien

Le 23/07/2012 05:05, Fatai Zhang a écrit :
> 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:[email-masked]]
> 发送时间: 2012年7月20日 17:53
> 收件人: Fatai Zhang; John E Drake; Lou Berger
> 抄送: [email-masked]; Khuzema Pithewan; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao; [email-masked]; 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:[email-masked]]
>> Sent: venerdì 20 luglio 2012 9.52
>> To: Daniele Ceccarelli; John E Drake; Lou Berger
>> Cc: [email-masked]; Khuzema Pithewan;
>> [email-masked]; Linyi;
>> [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>> VITTORIO); Diego Caviglia; Rajan Rao;
>> [email-masked]; 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:[email-masked]]
>> 发送时间: 2012年7月19日 20:05
>> 收件人: Fatai Zhang; John E Drake; Lou Berger
>> 抄送: [email-masked]; Khuzema Pithewan;
>> [email-masked]; Linyi;
>> [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>> VITTORIO); Diego Caviglia; Rajan Rao;
>> [email-masked]; 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:[email-masked]]
>>> 发送时间: 2012年7月19日 5:01
>>> 收件人: Daniele Ceccarelli; Fatai Zhang; Lou Berger
>>> 抄送: [email-masked]; Khuzema Pithewan;
>>> [email-masked]; Linyi;
>>> [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>>> VITTORIO); Diego Caviglia; Rajan Rao;
>>> [email-masked]; 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:[email-masked]]
>>>> Sent: Wednesday, July 18, 2012 10:02 AM
>>>> To: John E Drake; Fatai Zhang; Lou Berger
>>>> Cc: [email-masked]; Khuzema Pithewan;
>> [email-masked];
>>>> Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>>>> VITTORIO); Diego Caviglia; Rajan Rao; [email-masked];
>>>> 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:[email-masked]]
>>>>> Sent: mercoledì 18 luglio 2012 17.58
>>>>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
>>>>> Cc: [email-masked]; Khuzema Pithewan;
>>> [email-masked];
>>>>> Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>>>>> VITTORIO); Diego Caviglia; Rajan Rao; [email-masked];
>>>>> 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:[email-masked]]
>>>>>> Sent: Wednesday, July 18, 2012 3:30 AM
>>>>>> To: John E Drake; Fatai Zhang; Lou Berger
>>>>>> Cc: [email-masked]; Khuzema Pithewan;
>>>>>> [email-masked]; Linyi; [email-masked];
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan
>>>>>> Rao; [email-masked]; 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:[email-masked]]
>>>>>>   Sent: martedì 17 luglio 2012 16.18
>>>>>>   To: Fatai Zhang; Lou Berger; Daniele Ceccarelli
>>>>>>   Cc: [email-masked]; Khuzema Pithewan;
>>>>> [email-masked];
>>>>>> Linyi; [email-masked]; GRANDI, PIETRO
>> VITTORIO (PIETRO
>>>>>> VITTORIO); Diego Caviglia; Rajan Rao; [email-masked];
>>>>>> 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:[email-masked]]
>>>>>>   Sent: Monday, July 16, 2012 7:03 PM
>>>>>>   To: Lou Berger; Daniele Ceccarelli
>>>>>>   Cc: John E Drake; [email-masked]; Khuzema Pithewan;
>>>>>> [email-masked]; Linyi; [email-masked];
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia;
>>>>> Rajan Rao;
>>>>>> [email-masked]; 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:[email-masked]]
>>>>>>   发送时间: 2012年7月16日 20:47
>>>>>>   收件人: Daniele Ceccarelli
>>>>>>   抄送: Fatai Zhang; John E Drake; [email-masked]; Khuzema
>>>>> Pithewan;
>>>>>> [email-masked]; Linyi; [email-masked];
>>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia;
>>>>> Rajan Rao;
>>>>>> [email-masked]; BELOTTI, SERGIO
>>>>>> (SERGIO)
>>>>>>   主题: Re: 答复: 答复: Updates on OTN signaling draft
>>>>>>
>>>>>>
>>>>>>
>>>>>>   [snip]
>>>>>>
>>>>>>
>>>>>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp