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

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

Julien,

My apologies for misspelling your name in my previous email.

Thanks,

John

Sent from my iPhone


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of John E Drake
> Sent: Monday, July 23, 2012 8:45 AM
> To: Julien Meuric; Fatai Zhang; Daniele Ceccarelli
> Cc: [e-mail]
> Subject: Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft
>
> Julian,
>
> I think the intent is that component links with different hierarchies
> *or* TSGs MUST NOT be bundled.  If the proposed text isn't clear on
> this point, is my preceding sentence sufficiently clear?
>
> Sent from my iPhone
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Julien Meuric
> > Sent: Monday, July 23, 2012 8:25 AM
> > To: Fatai Zhang; Daniele Ceccarelli
> > Cc: [e-mail]
> > 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:[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]
> > >>>>>>
> > >>>>>>
> > >>>>>
> > > _______________________________________________
> > > CCAMP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp