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

[Fatai Zhang <[e-mail]>]

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]
>> >>
>> >>
>> >
>> >
>