Subject: [CCAMP] Updates on OTN signaling draft

From: Fatai Zhang <[email-masked]>
Date: Fri, 6 Jul 2012 01:25:31 +0000

Hi all,

We are updating OTN signaling draft. Since we had lots of discussion on the TSG stuff in the list, let's converge on the solution.

Based on the previous discussion between Lou and co-authors, the authors prefer the following changes:

(1) Extending GPID to carry TSG in signaling, since its purpose in signaling is to ensure that endpoints of the LSP being signaled have a consistent view of the TSG to be offered to its clients and LSP endpoint consistency is the purpose for which the GPID was designed.

(2)Extending LSPA to carry hierarchy information (ie., Type=2 - Hierarchy TLV).

Any comments?

Thanks

Fatai

---

From: Lou Berger <[email-masked]>
Date: Mon, 09 Jul 2012 17:27:25 -0400

[Woops, this was stuck in my outbox from last week!]

Fatai/Authors,
	G-PID is a fine place to carry information about the format/type of
information carried by an LSP. An important consideration is that G-PID
information is not used as part of path computation, and is not used by
transit nodes except in the case of the penultimate hop (for PHP).

When we last discussed this, some authors stated that TSG was needed as
part of path computation, including at transit nodes doing loose ERO
expansion.  Hence the discussed inclusion of TSG in LSP Encoding Type.
If the authors are now willing to state that TSG isn't needed for loose
ERO expansion, then G-PID seems the perfect choice.

Do all the authors agree with such this statement (and change)?

As I mentioned on the on the conference call, and my mail of 6/18, the
use of G-PID as part of a path selection is really part of the general
issue seen in MLN. On the call we agreed that non-OTN MLN will be
handled as the standard MLN case, without OTN-specific additions.

Unless I'm misreading your mail, you are *not* proposing to treat the
intra-OTN (hierarchy) case as generic MLN but rather a special case by
bundling some upper OTN hierarchy information as part of a lower H-LSPs
(in Hierarchy TLV).

Correct?

If my reading is correct, then I think the authors need to discuss their
technical reasons for their "preference" and why the previously reached
compromise position (as articulated in my mail of 6/18) is not acceptable.

Speaking only as an individual contributor, given the difficulty in
reaching a consensus on how to treat intra-OTN (hierarchy) as a special
case, I personally now prefer to avoid any technology specific
co-mingling of layers and to address the intra-OTN (hierarchy) case via
generic MLN (or other generic mechanisms).  I think this position would
translate to removing the Hierarchy TLV from the OTN signaling draft and
spinning up a new draft to cover (OTN and generic) intra-technology MLN.

Lou

On 7/5/2012 9:25 PM, Fatai Zhang wrote:
> 
> Hi all,
> 
> We are updating OTN signaling draft. Since we had lots of discussion on
> the TSG stuff in the list, let's converge on the solution.
> 
> (1) Extending GPID to carry TSG in signaling, since its purpose in
> signaling is to ensure that endpoints of the LSP being signaled have a
> consistent view of the TSG to be offered to its clients and LSP endpoint
> consistency is the purpose for which the GPID was designed.
>

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 10 Jul 2012 09:34:21 +0000

Hi Lou,

Please see in-line below.

Note that let’s use HTML format to make the mails readable, :)

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2012年7月10日 5:27
收件人: Fatai Zhang
抄送: [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E Drake
主题: Re: Updates on OTN signaling draft

Fatai/Authors,

         G-PID is a fine place to carry information about the format/type of information carried by an LSP. An important consideration is that G-PID information is not used as part of path computation, and is not used by transit nodes except in the case of the penultimate hop (for PHP).

When we last discussed this, some authors stated that TSG was needed as part of path computation, including at transit nodes doing loose ERO expansion.  Hence the discussed inclusion of TSG in LSP Encoding Type.

If the authors are now willing to state that TSG isn't needed for loose ERO expansion, then G-PID seems the perfect choice.

[Authors] After lots of discussion, the authors came to conclude that it is needed only for penultimate hop to select right link to egress and hence the change.

As I mentioned on the on the conference call, and my mail of 6/18, the use of G-PID as part of a path selection is really part of the general issue seen in MLN. On the call we agreed that non-OTN MLN will be handled as the standard MLN case, without OTN-specific additions.

Unless I'm misreading your mail, you are *not* proposing to treat the intra-OTN (hierarchy) case as generic MLN but rather a special case by bundling some upper OTN hierarchy information as part of a lower H-LSPs (in Hierarchy TLV).

Correct?

[Authors] Correct, it is the latter one.

If my reading is correct, then I think the authors need to discuss their technical reasons for their "preference" and why the previously reached compromise position (as articulated in my mail of 6/18) is not acceptable.

[Authors] After checking after conf call, the authors think that Encoding type is an end to end constraint (See RFC4328) and GPID should be the right place as you mention above.

Speaking only as an individual contributor, given the difficulty in reaching a consensus on how to treat intra-OTN (hierarchy) as a special case, I personally now prefer to avoid any technology specific co-mingling of layers and to address the intra-OTN (hierarchy) case via generic MLN (or other generic mechanisms).  I think this position would translate to removing the Hierarchy TLV from the OTN signaling draft and spinning up a new draft to cover (OTN and generic) intra-technology MLN.

[Authors] The authors would like to focus on OTN specific by removing Encoding type and Switching type in the Hierarchy TLV(but keeping Signal Type). It is OK to have a new draft to cover generic intra-technology MLN.

Lou

On 7/5/2012 9:25 PM, Fatai Zhang wrote:

> (2)Extending LSPA to carry hierarchy information (ie., Type=2 Hierarchy TLV).

---

From: Lou Berger <[email-masked]>
Date: Tue, 10 Jul 2012 10:33:25 -0400

Fatai,

See below for in-line responses.

On 7/10/2012 5:34 AM, Fatai Zhang wrote:
> Note that let’s use HTML format to make the mails readable, J
> 
>  
> 
>  
> 
> Thanks
> 
>  
> 
> Fatai
> 
>  
> 
>  
> 
> -----邮件原件-----
> 抄送: [email-masked]; Khuzema Pithewan; [email-masked];
> [email-masked]; Linyi; [email-masked];
> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked];
> Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E Drake
>          G-PID is a fine place to carry information about the
> format/type of information carried by an LSP. An important consideration
> is that G-PID information is not used as part of path computation, and
> is not used by transit nodes except in the case of the penultimate hop
> (for PHP).
>  
> [Authors] After lots of discussion, the authors came to conclude that it
> is needed only for penultimate hop to select right link to egress and
> hence the change.

Can one of the authors summarize the discussion for the WG?

The authors are asking for WG support, so should provide the technical
basis for the position. Once the requirements are articulated, the WG
can be in a position to judge/agree/disagree with the proposed solution.

> [Authors] After checking after conf call, the authors think that
> Encoding type is an end to end constraint (See RFC4328) and GPID should
> be the right place as you mention above.

This goes to requirements, in today's GMPLS G-PID is not part of path
computation except in the context of MRN/MLN.

> [Authors] The authors would like to focus on OTN specific by removing
> Encoding type and Switching type in the Hierarchy TLV(but keeping Signal
> Type). It is OK to have a new draft to cover generic intra-technology MLN.

How is the revised TLV to be used?  Do the authors have a specific
proposal that covers "generic intra-technology MLN"?

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 11 Jul 2012 06:24:45 +0000

Hi Lou,

Let me repeat the requirement of this information. 
When an ODU (e.g., ODU1) with one specific TSG (because of the ingress interface constraint) needs to be created over another higher ODU (e.g., ODU3 FA-LSP), the penultimate hop of this ODU3 FA-LSP needs to be aware of which TSG should be picked up from the TE link (ie., choose the right component link which can support the client TSG), so the client TSG information (and hierarchy information) needs to be conveyed in the signaling to create the ODU FA-LSP. 

The requirement has been discussed in the previous IETF meetings, please get more information from the presentation slides of Taipei and Paris meetings.

Given that people understand the above requirment, let's focus on the potential solutions. In Taipei meeting, the authors compared three alternatives and discussed in the list:
(1) Introducing a new object: WG prefer to re-use the existing things, so the authors switched to (2).
(2) Extending GPID to carry TSG/PT information: Lou once suggested this approach and the authors finally agreed on this because it is needed only for penultimate hop to select right link to egress. Note that TSG isn't needed for loose ERO expansion.
(3) Extending Encoding Type: Encoding type is an end to end constraint (See RFC4328), so the authors think it is not the right place.

Do we need to poll how many people support which approach perspectively (or any other approach)?

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2012年7月10日 22:33
收件人: Fatai Zhang
抄送: [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E Drake
主题: Re: 答复: Updates on OTN signaling draft

Fatai,

 

The authors are asking for WG support, so should provide the technical basis for the position. Once the requirements are articulated, the WG can be in a position to judge/agree/disagree with the proposed solution.

> [Authors] After checking after conf call, the authors think that Encoding type is an end to end constraint (See RFC4328) and GPID should be the right place as you mention above.

This goes to requirements, in today's GMPLS G-PID is not part of path computation except in the context of MRN/MLN.

> [Authors] The authors would like to focus on OTN specific by removing Encoding type and Switching type in the Hierarchy TLV(but keeping Signal Type). It is OK to have a new draft to cover generic i…

How is the revised TLV to be used?  Do the authors have a specific proposal that covers "generic intra-technology MLN"?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 Jul 2012 09:38:14 -0400

Fatai,
	It sounds you/the Authors are proposing/moving towards G-PID + MRN/MLN
to support intra-OTN H-LSPs.  From a WG perspective, this is great as it
leverages/extends existing technology-independent GMPLS mechanisms.

I think you may have missed a process point in my previous mail.

As I'm sure you know, author's consensus does not mean there is WG
consensus.  You say that there has been much (off-line) discussion among
the authors. While off-line discussions are always a fine way to make
progress among individuals, the results of private discussions do not
represent WG consensus.

So from my previous mail:
> Can one of the authors summarize the [off-line author's]
> discussion for the WG?

...

>> [Authors] The authors would like to focus on OTN specific by
>> removing Encoding type and Switching type in the Hierarchy TLV
>> (but keeping Signal Type). It is OK to have a new draft to cover
>> generic intra-technology MLN.
>

Lou

BTW The use of G-PID was first discussed in
draft-ietf-ccamp-otn-g709-info-model-01 and Signal Type in John's mail
on 7/27/2011.

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Jul 2012 11:54:26 -0700

Fatai,

Is it not the case that *any* node, regardless of whether it is the ingress node, an intermediate node, or the penultimate node, that selects the interface for the egress LSP endpoint MUST ensure that that interface has a TSG that is compatible with the TSG of interface for the ingress LSP endpoint?

Also, it occurs to me that hierarchy is not only unnecessary but counter-productive in signaling.  When one establishes an ODU3, for example, that ODU3 may be used to instantiate multiple hierarchies, so one does not want to specify a particular hierarchy.

If one is establishing this ODU3 in order to eventually establish an ODU0 LSP over an ODU2 LSP, then after the ODU3 is established, the ODU2 would be signaled within the ODU3.  Again, since the ODU2 might support multiple hierarchies, one does not want to specify a particular hierarchy.

Once the OUD2 is established, the ODU0 is signaled.  Since it does not support any further hierarchy, none is specified.

Thanks,

John 

Sent from my iPhone

> -----Original Message-----
> From: Fatai Zhang [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 11:25 PM
> To: Lou Berger
> Cc: [email-masked]; Khuzema Pithewan; [email-masked];
> Subject: 答复: 答复: Updates on OTN signaling draft
> 
> Hi Lou,
> 
> When an ODU (e.g., ODU1) with one specific TSG (because of the ingress
> interface constraint) needs to be created over another higher ODU
> (e.g., ODU3 FA-LSP), the penultimate hop of this ODU3 FA-LSP needs to
> be aware of which TSG should be picked up from the TE link (ie., choose
> the right component link which can support the client TSG), so the
> client TSG information (and hierarchy information) needs to be conveyed
> in the signaling to create the ODU FA-LSP.
> 
> The requirement has been discussed in the previous IETF meetings,
> please get more information from the presentation slides of Taipei and
> Paris meetings.
> 
> Given that people understand the above requirment, let's focus on the
> potential solutions. In Taipei meeting, the authors compared three
> alternatives and discussed in the list:
> (2) Extending GPID to carry TSG/PT information: Lou once suggested this
> approach and the authors finally agreed on this because it is needed
> only for penultimate hop to select right link to egress. Note that TSG
> isn't needed for loose ERO expansion.
> (3) Extending Encoding Type: Encoding type is an end to end constraint
> (See RFC4328), so the authors think it is not the right place.
> 
> > GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
> > [email-masked]; Rajan Rao; [email-masked];
> > BELOTTI, SERGIO (SERGIO); John E Drake
> format/type of information carried by an LSP. An important
> consideration is that G-PID information is not used as part of path
> computation, and is not used by transit nodes except in the case of the
> penultimate hop (for PHP).
> >
> > When we last discussed this, some authors stated that TSG was needed
> as part of path computation, including at transit nodes doing loose ERO
> > If the authors are now willing to state that TSG isn't needed for
> loose ERO expansion, then G-PID seems the perfect choice.
> >
> > [Authors] After lots of discussion, the authors came to conclude that
> it is needed only for penultimate hop to select right link to egress
> and hence the change.
> 
> > As I mentioned on the on the conference call, and my mail of 6/18,
> the use of G-PID as part of a path selection is really part of the
> general issue seen in MLN. On the call we agreed that non-OTN MLN will
> be handled as the standard MLN case, without OTN-specific additions.
> >
> > If my reading is correct, then I think the authors need to discuss
> their technical reasons for their "preference" and why the previously
> reached compromise position (as articulated in my mail of 6/18) is not
> acceptable.
> >
> case, I personally now prefer to avoid any technology specific co-
> mingling of layers and to address the intra-OTN (hierarchy) case via
> translate to removing the Hierarchy TLV from the OTN signaling draft
> and spinning up a new draft to cover (OTN and generic) intra-technology
> MLN.
> >
> Encoding type and Switching type in the Hierarchy TLV(but keeping
> Signal Type). It is OK to have a new draft to cover generic intra-
> technology MLN.
> 
> > consistent view of the TSG to be offered to its clients and LSP
> > endpoint consistency is the purpose for which the GPID was designed.
> >
> >>
> >
> >> (2)Extending LSPA to carry hierarchy information (ie., Type=2
> >> Hierarchy
> > TLV).
> >
> >>
> >
> >> Any comments?
> >
> >>
> >
> >> Thanks
> >
> >>
> >
> >> Fatai
> >

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 12 Jul 2012 03:54:00 +0000

Hi John,

I think TSG and hierarchy information really confused many people, which causes the same questions will come out again after we explained many times, :-)

The simple way is to remove link bundling (or bundle the homogeneous component links) in the routing, then all the issues disappear immediately ( i.e., no need TSG and hierarchy information at all), otherwise, it needs these two kinds of information in some cases.

I really suspect the value of bundling in the GMPLS for TDM or WSON. I think this is interesting point to be investigated, but it seems that not too many people are interested, :)

Thanks

Fatai

-----邮件原件-----
发件人: John E Drake [mailto:[email-masked]]
发送时间: 2012年7月12日 2:54
收件人: Fatai Zhang; Lou Berger
抄送: [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO)
主题: RE: 答复: Updates on OTN signaling draft

Fatai,

[Fatai] There are two cases for TSG issue. One is for ODU service LSP (carrying non-ODU) creation, the second one is ODU FA-LSP creation for carrying another lower ODU. For the first case, the TSG can be changeable segment by segment (link by link). For example, when an ODU1 (to carry non-ODU) is being created over ODU3 link, the TSG could be different link by link. For the second case, this is what we are talking about with Lou; in this case, only end points and penultimate node need to have the compatible TSG.

[Fatai] Hierarchy information is necessary when bundling link is used. For your example, ODU0->ODU2->ODU3, when creating ODU2 FA-LSP over ODU3 links, ODU2 layer should be aware of that it should pick up the right component link that can support ODU0 muxing (so the hierarchy ODU0->ODU2 should be carried when creating ODU2 FA-LSP), otherwise, this arbitrary ODU2 could be only support ODU1->ODU2, then ODU0 cannot be carried over this ODU2 FA-LSP.

Thanks,

John

Sent from my iPhone

> Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E

> Drake

> (1) Introducing a new object: WG prefer to re-use the existing things,

> so the authors switched to (2).

> Do we need to poll how many people support which approach perspectively

> (or any other approach)?

> Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E

> Drake

> > 抄送: [email-masked]; Khuzema Pithewan;

> [email-masked];

> can be in a position to judge/agree/disagree with the proposed

> solution.

> >> We are updating OTN signaling draft. Since we had lots of discussion

> >> on

> >> Based on the previous discussion between Lou and co-authors, the

> > authors prefer the following changes:

> > signaling is to ensure that endpoints of the LSP being signaled have

> a

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 12 Jul 2012 06:25:05 +0000

Hi Lou,

How about let me update the draft first, because I only have two working days to update and submit a new version? :-)

Let's discuss more in Vancouver meeting and get the WG consensus there. 

Anyway, any changes should defer to the WG consensus, otherwise the authors would like to continue to update the draft based on WG consensus.

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2012年7月11日 21:38
收件人: Fatai Zhang
抄送: [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO); John E Drake
主题: Re: 答复: 答复: Updates on OTN signaling draft

Fatai,

...

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Jul 2012 07:48:42 -0400

Fatai,
	Sure get the document out.  Given there will still be 2 weeks after
that before the meeting, and that WG consensus must be achieved on the
list, we should continue the discussion on the list (i.e., reply to my
previous mail) once the draft is submitted and not wait for Vancouver.

As I mentioned in my previous mail, the shift towards leveraging
technology-independent GMPLS mechanisms to address intra-OTN H-LSP
signaling is well aligned with the WG charter/objectives. I think we
should try not to loose momentum by waiting for the meeting.

Lou

On 7/12/2012 2:25 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> How about let me update the draft first, because I only have two
> working days to update and submit a new version? :-)
> 
> Anyway, any changes should defer to the WG consensus, otherwise the
> authors would like to continue to update the draft based on WG
> consensus.
>  
> Thanks
> 
> Fatai
> 
> 
> -----邮件原件-----

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Jul 2012 10:30:35 -0400

Fatai,
	I think I agree with John (as WG contributor).

Why isn't the same issue present for non-bundled links when ERO
expansion takes place at any place other than the ingress node?

How does this issue differ from any MLN H-LSP?

Lou

On 7/11/2012 11:54 PM, Fatai Zhang wrote:
> 
> 
> Hi John,
> 
>  
> 
> I think TSG and hierarchy information really confused many people, which
> causes the same questions will come out again after we explained many
> times, :-)
> 
>  
> 
> The simple way is to remove link bundling (or bundle the homogeneous
> component links) in the routing, then all the issues disappear
> immediately ( i.e., no need TSG and hierarchy information at all),
> otherwise, it needs these two kinds of information in some cases.
> 
>  
> 
> I really suspect the value of bundling in the GMPLS for TDM or WSON. I
> think this is interesting point to be investigated, but it seems that
> not too many people are interested, J
> 
>  
> 
> Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO)
> Is it not the case that *any* node, regardless of whether it is the
> ingress node, an intermediate node, or the penultimate node, that
> selects the interface for the egress LSP endpoint MUST ensure that that
> interface has a TSG that is compatible with the TSG of interface for the
> ingress LSP endpoint?
> 
>  
> 
> [Fatai] There are two cases for TSG issue. One is for ODU service LSP
> (carrying non-ODU) creation, the second one is ODU FA-LSP creation for
> carrying another lower ODU. For the first case, the TSG can be
> changeable segment by segment (link by link). For example, when an ODU1
> (to carry non-ODU) is being created over ODU3 link, the TSG could be
> different link by link. For the second case, this is what we are talking
> about with Lou; in this case, only end points and penultimate node need
> to have the compatible TSG.
> 
>  
> 
> Also, it occurs to me that hierarchy is not only unnecessary but
> counter-productive in signaling.  When one establishes an ODU3, for
> example, that ODU3 may be used to instantiate multiple hierarchies, so
> one does not want to specify a particular hierarchy.
> 
>  
> 
> If one is establishing this ODU3 in order to eventually establish an
> ODU0 LSP over an ODU2 LSP, then after the ODU3 is established, the ODU2
> would be signaled within the ODU3.  Again, since the ODU2 might support
> multiple hierarchies, one does not want to specify a particular hierarchy.
> 
>  
> 
> Once the OUD2 is established, the ODU0 is signaled.  Since it does not
> support any further hierarchy, none is specified.
> 
>  
> 
> [Fatai] Hierarchy information is necessary when bundling link is used.
> For your example, ODU0->ODU2->ODU3, when creating ODU2 FA-LSP over ODU3
> links, ODU2 layer should be aware of that it should pick up the right
> component link that can support ODU0 muxing (so the hierarchy ODU0->ODU2
> should be carried when creating ODU2 FA-LSP), otherwise, this arbitrary
> ODU2 could be only support ODU1->ODU2, then ODU0 cannot be carried over
> this ODU2 FA-LSP.
> 
>  
> 
> Thanks,
> 
>  
> 
> John
> 
>  
> 
> Sent from my iPhone
> 
>  
>

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Jul 2012 09:48:16 -0700

Comments inline

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 8:54 PM
To: John E Drake; Lou Berger
Cc: [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO)
Subject: 答复: 答复: Updates on OTN signaling draft

Hi John,

Thanks

Fatai

-----邮件原件-----
发件人: John E Drake [mailto:[email-masked]]
发送时间: 2012年7月12日 2:54
收件人: Fatai Zhang; Lou Berger
抄送: [email-masked]<mailto:[email-masked]>; Khuzema Pithewan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Linyi; [email-masked]<mailto:[email-masked]>; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]<mailto:[email-masked]>; Rajan Rao; [email-masked]<mailto:[email-masked]>; BELOTTI, SERGIO (SERGIO)
主题: RE: 答复: Updates on OTN signaling draft

Fatai,

JD:  I am talking about the second case as well.  The issue is that the endpoints of a hierarchical LSP need to be the same wrt TSG.  Therefore, the node that selects egress LSP interface must ensure this.  In most cases this is the ingress node, however, it can be any node along LSP’s path including the penultimate node.  To keep insisting that it is only an issue for the penultimate node is incorrect.

JD:  Hierarchy is unnecessary in signaling as I indicated in my example, above.

Thanks,

John

Sent from my iPhone

> Cc: [email-masked]<mailto:[email-masked]>; Khuzema Pithewan; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; Linyi; [email-masked]<mailto:[email-masked]>;

> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]<mailto:[email-masked]>;

> Rajan Rao; [email-masked]<mailto:[email-masked]>; BELOTTI, SERGIO (SERGIO); John E

> 抄送: [email-masked]<mailto:[email-masked]>; Khuzema Pithewan; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; Linyi; [email-masked]<mailto:[email-masked]>;

> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]<mailto:[email-masked]>;

> Rajan Rao; [email-masked]<mailto:[email-masked]>; BELOTTI, SERGIO (SERGIO); John E

> > 抄送: [email-masked]<mailto:[email-masked]>; Khuzema Pithewan;

> [email-masked]<mailto:[email-masked]>;

> > [email-masked]<mailto:[email-masked]>; Linyi; [email-masked]<mailto:[email-masked]>;

> > [email-masked]<mailto:[email-masked]>; Rajan Rao; [email-masked]<mailto:[email-masked]>;

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 13 Jul 2012 10:04:11 +0000

Hi Lou,

For bundling link, it just shows the collection capability of all the component links and it cannot differentiate which component can support which capability. 

For example, a TE link with two component links ( one can support A (e.g., TSG=1.25)  and another one can support B (TSG=2.5G)), and then the TE link will claim that it can support both A&B. When an LSP needs to pick up A of the TE link, we have to indicate A in the signaling explicitly to make the corresponding nodes to pick up the correct component link with capability A.

If no bunding, everything about the TE link (actually it only has one component link) has been advertised, so the path computation can make the correct choice (ERO can indicate the correct TE link (ie., component link)).

Does this make sense?

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2012年7月12日 22:31
收件人: Fatai Zhang
抄送: John E Drake; [email-masked]; Khuzema Pithewan; [email-masked]; [email-masked]; Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); [email-masked]; Rajan Rao; [email-masked]; BELOTTI, SERGIO (SERGIO)
主题: Re: 答复: 答复: Updates on OTN signaling draft

Fatai,

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 13 Jul 2012 14:37:13 +0200

Hi all,

 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. "

A penultimate node (being it the last hop of the path or the first node of an H-LSP teminating on the same egress node of the LSP) needs to know 2 things:

1. what is "being carried"
2. what the link or the H-LSP towards the egress node can support/terminate

The problem is not 2, as it is perfectly know. What needs to be put is signaling is 1. in order to provide the node with the information required to choose the correct TE link/H-LSP among the ones whose 2. is perfectly known.

Thanks
Daniele

>Sent: venerdì 13 luglio 2012 12.04
>To: Lou Berger
>Cc: John E Drake; [email-masked]; Khuzema Pithewan;
>[email-masked]; Daniele Ceccarelli; 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,
>
>For bundling link, it just shows the collection capability of
>all the component links and it cannot differentiate which
>component can support which capability.
>
>For example, a TE link with two component links ( one can
>support A (e.g., TSG=1.25)  and another one can support B
>(TSG=2.5G)), and then the TE link will claim that it can
>support both A&B. When an LSP needs to pick up A of the TE
>link, we have to indicate A in the signaling explicitly to
>make the corresponding nodes to pick up the correct component
>link with capability A.
>
>If no bunding, everything about the TE link (actually it only
>has one component link) has been advertised, so the path
>computation can make the correct choice (ERO can indicate the
>correct TE link (ie., component link)).
>
>Does this make sense?
>
>Thanks
>
>Fatai
>
>
>-----邮件原件-----
>抄送: John E Drake; [email-masked]; Khuzema Pithewan;
>[email-masked]; Linyi;
>[email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>VITTORIO); [email-masked]; Rajan Rao;
>[email-masked]; BELOTTI, SERGIO (SERGIO)
>Why isn't the same issue present for non-bundled links when
>ERO expansion takes place at any place other than the ingress node?
>
>> I think TSG and hierarchy information really confused many people,
>> which causes the same questions will come out again after we
>explained
>> many times, :-)
>>
>>
>>
>> BELOTTI, SERGIO (SERGIO)
>> selects the interface for the egress LSP endpoint MUST ensure that
>> that interface has a TSG that is compatible with the TSG of
>interface
>> for the ingress LSP endpoint?
>>
>>
>>
>> changeable segment by segment (link by link). For example, when an
>> ODU1 (to carry non-ODU) is being created over ODU3 link, the
>TSG could
>> be different link by link. For the second case, this is what we are
>> talking about with Lou; in this case, only end points and
>penultimate
>> node need to have the compatible TSG.
>>
>>
>>
>> ODU0 LSP over an ODU2 LSP, then after the ODU3 is established, the
>> ODU2 would be signaled within the ODU3.  Again, since the ODU2 might
>> support multiple hierarchies, one does not want to specify a
>particular hierarchy.
>>
>>
>>
>> For your example, ODU0->ODU2->ODU3, when creating ODU2 FA-LSP over
>> ODU3 links, ODU2 layer should be aware of that it should pick up the
>> right component link that can support ODU0 muxing (so the hierarchy
>> ODU0->ODU2 should be carried when creating ODU2 FA-LSP), otherwise,
>> this arbitrary
>> ODU2 could be only support ODU1->ODU2, then ODU0 cannot be carried
>> over this ODU2 FA-LSP.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> John
>>
>>
>>
>> Sent from my iPhone
>>
>>
>>
>>> [email-masked];
>>
>>> [email-masked];
>>
>>> > removing

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2012 08:50:47 -0400

Daniele,

>    includes component links with differing characteristics. "

Thanks. Was just about to point to my comment saying the same in mail to
the list on 10/4/11.

> The problem is not 2, as it is perfectly know. What needs to be put is signaling is 1. in order to provide the node with the information required to choose the correct TE link/H-LSP among the ones…

So what do you believe is needed to support 1?

How does this differ than what is needed for generic MLN?

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 13 Jul 2012 15:04:00 +0200

Lou,

[...]
>How does this differ than what is needed for generic MLN?

What is needed in OTN is:
A) TSG
B) Hierarchy (i must be honest, i should re-think about it because i don't remember why it is needed but i'm sure we came to the conclusion it is need)

What is needed in MLN is also:
C) adaptation information (not needed in intra-OTN as there is a 1:1 relationship for any mapping)

Thanks
Daniele

>VITTORIO);
>>> Diego Caviglia; Rajan Rao; [email-masked];
>BELOTTI, SERGIO
>>> (SERGIO); Fatai Zhang
>>> For bundling link, it just shows the collection capability
>of all the
>>> component links and it cannot differentiate which component can
>>> support which capability.
>>>
>>> For example, a TE link with two component links ( one can support A
>>> (e.g., TSG=1.25)  and another one can support B
>(TSG=2.5G)), and then
>>> the TE link will claim that it can support both A&B. When an LSP
>>> needs to pick up A of the TE link, we have to indicate A in the
>>> signaling explicitly to make the corresponding nodes to pick up the
>>> correct component link with capability A.
>>>
>>> If no bunding, everything about the TE link (actually it
>only has one
>>> component link) has been advertised, so the path
>computation can make
>>> the correct choice (ERO can indicate the correct TE link (ie.,
>>> component link)).
>>>
>>> Does this make sense?
>>>
>>> Thanks
>>>
>>> Fatai
>>>
>>>
>>> -----邮件原件-----
>>> [email-masked]; [email-masked];
>>> Linyi; [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO
>>>>> please get more information from the presentation slides
>of Taipei
>>>>> and
>>>>
>>>>> Paris meetings.
>>>>
>>>>>
>>>>
>>>>> (2) Extending GPID to carry TSG/PT information: Lou once
>suggested
>>>>> this
>>>>
>>>>> only for penultimate hop to select right link to egress.
>Note that
>>>>> TSG
>>>>
>[email-masked];
>>>>
>>>>> computation, and is not used by transit nodes except in
>the case of
>>>>> the
>>>>
>>>>> as part of path computation, including at transit nodes
>doing loose
>>>>> ERO
>>>>
>>>>>> Unless I'm misreading your mail, you are *not* proposing
>to treat
>>>>>> the
>>>>
>>>>> intra-OTN (hierarchy) case as generic MLN but rather a
>special case
>>>>> by
>>>>
>>>>> reached compromise position (as articulated in my mail of
>6/18) is
>>>>> not
>>>>
>>>>> acceptable.
>>>>
>>>>>>
>>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2012 10:27:23 -0400

Daniele,

> What is needed in OTN is:

And this is covered in the current (MRN/MLN-aligned) proposal via G-PID,
right?

> B) Hierarchy (i must be honest, i should re-think about it because i don't remember why it is needed but i'm sure we came to the conclusion it is need)

Given the current discussion (including John's comments) it would be
good to understand what purpose this serves and how it differs from what
is needed to satisfy your next point.

> C) adaptation information (not needed in intra-OTN as there is a 1:1 relationship for any mapping)

Presumably this is the focus of
draft-bcg-ccamp-gmpls-ml-implications-00, right?

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 13 Jul 2012 16:59:51 +0200

Lou,

>And this is covered in the current (MRN/MLN-aligned) proposal
>via G-PID, right?

Correct

>
>> B) Hierarchy (i must be honest, i should re-think about it because i
>> don't remember why it is needed but i'm sure we came to the
>conclusion
>> it is need)
>>
>
>Given the current discussion (including John's comments) it
>would be good to understand what purpose this serves and how
>it differs from what is needed to satisfy your next point.

Well, the main reason is that the famoous penultimte hop, when reached by the path message, needs to know not only that an e.g. ODU4 is being set up but that e.g. An ODU2->ODU3->ODU4 needs to be established, hence an H-LPS supporting ODU2->ODU3->ODU4 demuxing on the other end of the link is needed.

>draft-bcg-ccamp-gmpls-ml-implications-00, right?

Sort of. Such draft was born as a consequence of comments received in Paris. The goal was defining requirements and use cases for INTER Switch Cap MLN (followed then by protocol extensions). What is coming out in these days is also INTRA Switch Cap issues. If the other authors agree it is possible to extend it to the INTRA switch cap case also and then work on the "technology agnostic" protocols extension.

>support A
>>>>>> ODU0->ODU2 should be carried when creating ODU2 FA-LSP),
>>>>>> ODU0->otherwise,
>>>>>> this arbitrary
>>>>>>> be aware of which TSG should be picked up from the TE
>link (ie.,
>>>>>>> choose
>>>>>>
>>>>>>>> [Authors] After lots of discussion, the authors came
>to conclude
>>>>>>>> that
>>>>>>
>>>>>>> general issue seen in MLN. On the call we agreed that
>non-OTN MLN
>>>>>>> will
>>>>>>
>>>>>>> bundling some upper OTN hierarchy information as part
>of a lower
>>>>>>> H-LSPs
>>>>>>
>>>>>>> (in Hierarchy TLV).
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>> Correct?
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>> Encoding type is an end to end constraint (See RFC4328)
>and GPID
>>>>>>> should
>>>>>>
>>>>>>> co-
>>>>>>> mingling of layers and to address the intra-OTN
>(hierarchy) case
>>>>>>> via
>>>>>>
>>>>>>> generic MLN (or other generic mechanisms).  I think
>this position
>>>>>>> would
>>>>>>
>>>>>>>> signaling is to ensure that endpoints of the LSP being
>signaled
>>>>>>>> have
>>>>>>
>>>>>>> a
>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2012 11:15:31 -0400

Daniele,

See below.

On 7/13/2012 10:59 AM, Daniele Ceccarelli wrote:
> Well, the main reason is that the famoous penultimte hop, when
> reached by the path message, needs to know not only that an e.g. ODU4
> is being set up but that e.g. An ODU2->ODU3->ODU4 needs to be
> established, hence an H-LPS supporting ODU2->ODU3->ODU4 demuxing on
> the other end of the link is needed.
> 

So how is this different than any other MRN/MLN example (e.g., Ether LSP
over SDH LSP over Lambda LSP)?

As John was implying in his e-mail, (why) does intra-OTN need a
different solution?

> Sort of. Such draft was born as a consequence of comments received in
> Paris. The goal was defining requirements and use cases for INTER
> Switch Cap MLN (followed then by protocol extensions). 

Okay.

> What is coming out in these days is also INTRA Switch Cap issues. 

Agreed.

> If the other
> authors agree it is possible to extend it to the INTRA switch cap
> case also and then work on the "technology agnostic" protocols
> extension.
> 

Well that would certainly fit the WG charter (comment as WG contributor).

Also, WRT to the WG document, it's the WG's call, not just the authors.

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 16 Jul 2012 12:13:31 +0200

Hi Lou,

Different week, same thread.

Please see below (some cuts to make it more readable)

[snip]

>
>So how is this different than any other MRN/MLN example (e.g.,
>Ether LSP over SDH LSP over Lambda LSP)?
>
>As John was implying in his e-mail, (why) does intra-OTN need
>a different solution?

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]

>
>> If the other
>> authors agree it is possible to extend it to the INTRA
>switch cap case
>> also and then work on the "technology agnostic" protocols extension.
>>
>

Sure, I was referring to the "bcg" draft.
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.

Thanks
Daniele

>>>>>>>>> reaching a consensus on how to treat intra-OTN
>(hierarchy) as a
>>>>>>>>> special
>>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Jul 2012 08:47:03 -0400

Daniele,

See below.

On 7/16/2012 6:13 AM, Daniele Ceccarelli wrote:
> 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.

> Sure, I was referring to the "bcg" draft.

okay, wasn't sure.

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

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 17 Jul 2012 02:02:44 +0000

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.

=======================================================================================================================

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?

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

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]

---

From: John E Drake <[email-masked]>
Date: Tue, 17 Jul 2012 07:17:45 -0700

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]

fair enough.

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2012年7月16日 20:47
收件人: Daniele Ceccarelli
抄送: Fatai Zhang; John E Drake; [email-masked]<mailto:[email-masked]>; Khuzema Pithewan; [email-masked]<mailto:[email-masked]>; Linyi; [email-masked]<mailto:[email-masked]>; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao; [email-masked]<mailto:[email-masked]>; BELOTTI, SERGIO (SERGIO)
主题: Re: 答复: 答复: Updates on OTN signaling draft

[snip]

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Jul 2012 12:30:41 -0400

Fatai,
	While you addressed your mail to me, it looks like your questions are
really for Daniele. I assume that he'll respond.

Lou

On 7/16/2012 10:02 PM, Fatai Zhang wrote:
> 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?
> 
>  
> 
> [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
> 
>  
> 
> -----邮件原件-----
> 抄送: Fatai Zhang; John E Drake; [email-masked]; Khuzema Pithewan;
> [email-masked]; Linyi; [email-masked]; GRANDI,
> PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao;

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 18 Jul 2012 12:29:59 +0200

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,

	Thanks,

	John  

	Sent from my iPhone

	Hi Lou,

	[snip]

	fair enough.

	 

	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]

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Jul 2012 08:20:43 -0400

Daniele,
	Please see below.

On 7/18/2012 6:29 AM, Daniele Ceccarelli wrote:
> 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. 

So why is this any different than the normal MRN/MLN case?

> Let's try to make an example (switched to
> plain text for the drawing):

for example change:
ODU1-LSP --> MPLS (TE/TP) LSP
ODU2-LSP --> Ethernet LSP
ODU3-LSP --> Lambda LSP

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

Generally we/GMPLS has used crankback to handle odd-ball corner cases
rather than complicating/optimizing the common case for the most complex
cases.  Is there a reason not to look to crankback for this extremely
rare case?

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 18 Jul 2012 15:38:18 +0200

Hi Lou,

Please find replies in line

[snip]

>So why is this any different than the normal MRN/MLN case?

Mmm, indeed it isn't. The same "bug" is present also in the MRN/MLN case

>
>> Let's try to make an example (switched to plain text for the 
>drawing):
>
>for example change:

Looks like the same issue. What about the mapping? It is missign too, isn't it?

[snip]

>Generally we/GMPLS has used crankback to handle odd-ball 
>corner cases rather than complicating/optimizing the common 
>case for the most complex cases.  Is there a reason not to 
>look to crankback for this extremely rare case?

Not everyone likes cranckbacks. I don't really mind as the work around is already there (strict ERO), butin case someone wants/must use a loose ERO i am not against an *optional* object like the hierarchy. 

I don't remember what happens if NO path is feasible from A to E. In case the hierarchy is used, C can tell A that no route to E is feasible, but what happens in case of crankback? Retries on a timer bases? 

Thanks,
Daniele

>
>Thanks,
>Lou
>
>> 
>> Please note that the problem does not exist using a strict 
>ERO (which 
>> i wuold suggest :-)
>> 
>> Thanks,
>> Daniele
>>  
>>  
>> 
>> 
>> 	Cc: [email-masked]; Khuzema Pithewan; 
>[email-masked]; Linyi; 
>> 	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
>> 
>> 	 
>> 
>[email-masked]; Linyi; 
>> 	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
>> 
>> 	 
>> 
>> 	-----邮件原件-----
>> 	抄送: Fatai Zhang; John E Drake; [email-masked]; Khuzema 
>Pithewan; [email-masked]; Linyi;

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 18 Jul 2012 16:04:12 +0200

I think my replies to John and Lou do not fully answer all of Fatai's questions.

More comments in line

BR
Daniele

>
>Fatai,
>	While you addressed your mail to me, it looks like your 
>questions are really for Daniele. I assume that he'll respond.
>
>Lou
>
>signlaing
>> [Fatai] Did you mean (or agree) that intra-OTN is missing the 
>> capability of signaling the TSG? Should Inter-OTN be generic MRN/MLN?

Yes, I meant that intra-OTN is miising the capability of TSG (it is missing hierarchy too but we need to understand if we want to address it).
And both Inter-OTN and Intra-OTN should be generic MRN/MLN

>> 
>>  
>> 
>>> It appears we came to the conclusion that a general "intra 
>switch cap"
>> work is needed (non OTN specific).
>> 
>>>
>> 
>> remove TSG or hierachy information or bothe of them (ie., GPID 
>> extension for TSG and hierachy inforamtion in LSPA)?

Not exactly. I mean that the OTN specific draft should define the OTN specific extensions of a general MLN/MRN encoding defined in another draft (still to be written)

>> [email-masked]; Linyi; [email-masked]; 
>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; 
>Rajan Rao;

---

From: John E Drake <[email-masked]>
Date: Wed, 18 Jul 2012 08:58:21 -0700

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

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2012 3:30 AM
> To: John E Drake; Fatai Zhang; Lou Berger
> VITTORIO); Diego Caviglia; Rajan Rao; [email-masked];
> BELOTTI, SERGIO (SERGIO)
> 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
> 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.
> 
> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao;
> 	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
> 
> 
> 
> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan Rao;
> 	=================================================================
> ======================================================
> 
> 
> 
> between client and server layers (e.g. Bit-sync vs Byte-sync mapping,
> X.86 vs GFP etc)
> 
> 	>
> 
> 	> [snip]
> 
> 
> 
> 	fair enough.
> 
> 
> 
> 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!
> 
> 
> 
> [email-masked]; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
> Diego Caviglia; Rajan Rao; [email-masked]; BELOTTI, SERGIO
> (SERGIO)

---

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

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

>Sent: mercoledì 18 luglio 2012 17.58
>To: Daniele Ceccarelli; Fatai Zhang; Lou Berger
>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
>
>
>> is not aware of layer 1. Let's try to make an example (switched to 
>> 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)
>> 
>discussion of 
>> this topic in which I argued in support of the Infinera approach of 
>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.
>> 
>> 
>> 
>focusing on OTN 
>Pithewan;

---

From: John E Drake <[email-masked]>
Date: Wed, 18 Jul 2012 14:00:31 -0700

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

> Sent: Wednesday, July 18, 2012 10:02 AM
> 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
> 
> >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
> >
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 19 Jul 2012 12:20:14 +0200

That could be another option perfectly reasonable.

However I don't know which one is faster and cheaper. An RFC bis modifies the behavior of existing implementaitons while an totally new object already defined that only needs to be imported into the new MRN/MLN extensions only applies to new implementations. 
I assume the existing ones rely on cranck-backs or EROs including, among the others, the egress interface (e.g. strict ERO).

Thanks,
Daniele

>Sent: mercoledì 18 luglio 2012 23.01
>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
>
>
>> 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).
>> >> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan 
>> >> Rao; [email-masked]; BELOTTI, SERGIO (SERGIO)
>> >> 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
>> >>         |     |      |     |      |     |      |     |    
>> >>         |     |      |     |      |     |      |     |    
>> >> intermediate hierarchy in support of a given client ODUj, and 
>> >> nobody bought my arguments..
>> >>
>> >>
>> >>
>> >> 	Thanks,
>> >>
>> >>
>> >>
>> >> 	John
>> >>
>> >>
>> >>
>> >> 	Sent from my iPhone
>> >>
>> >>
>> >>
>> >> 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
>> >>
>> >>
>> >>
>> >> 	-----邮件原件-----

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 19 Jul 2012 10:18:33 +0000

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.

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. 
==============================================================================================================
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

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 19 Jul 2012 04:09:39 -0700

Daniele,

What concerns me is that we are headed in a design direction in which signaling is required to carry all of the information necessary to allow any intermediate node to select the egress interface for an LSP.  The issue I have with this is that it requires every intermediate node to have exactly the same capabilities as the ingress/egress nodes, which makes the incremental introduction of new capabilities more challenging.

Allowing heterogeneous nodal capabilities is one of the reasons we include all of this information in routing in the first place.

Thanks,

John 

Sent from my iPhone

> Sent: Thursday, July 19, 2012 3:20 AM
> However I don't know which one is faster and cheaper. An RFC bis
> modifies the behavior of existing implementaitons while an totally new
> object already defined that only needs to be imported into the new
> MRN/MLN extensions only applies to new implementations.
> I assume the existing ones rely on cranck-backs or EROs including,
> among the others, the egress interface (e.g. strict ERO).
> 
> Thanks,
> Daniele
> 
> >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
> >
> >
> saying).

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 19 Jul 2012 13:57:19 +0200

It sounds reasonable unless there are serious reasons for not using an ERO with that information (e.g. need to use an "empty" ERO).
Does anyone see any of those reasons?  I can't...and continue to prefer the strict ERO :-)

BR
Daniele

>Sent: giovedì 19 luglio 2012 13.10
>What concerns me is that we are headed in a design direction
>in which signaling is required to carry all of the information
>necessary to allow any intermediate node to select the egress
>interface for an LSP.  The issue I have with this is that it
>requires every intermediate node to have exactly the same
>capabilities as the ingress/egress nodes, which makes the
>incremental introduction of new capabilities more challenging.
>
>Allowing heterogeneous nodal capabilities is one of the
>reasons we include all of this information in routing in the
>first place.
>
>Thanks,
>
>John
>
>Sent from my iPhone
>
>> >> 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).
>> >> >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
>> >> >>            |
>        |
>> >> >>            |                           ODU2-H-LSP
>        |
>        |
>        |
>> >> >>            |            |                   ODU3-H-LSP
>        |
>|-------------------------|
>> >> >>            |            |            |
>        |
>> >> >> Linyi; [email-masked]; GRANDI, PIETRO VITTORIO
>> >> >> (PIETRO VITTORIO); Diego Caviglia; Rajan Rao;
>> >> >>        4)      The ingress will sequentially signal
>multiple ODUj
>> LSPs,
>> >> >>        > 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
>> >> >> 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.
>> >> >>
>> >> >>
>> >> >>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 19 Jul 2012 14:05:00 +0200

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.

>===============================================================
>===============================================
>" 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
>
>
>-----邮件原件-----

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Jul 2012 11:39:41 -0400

John,
	Just to be clear.  This was a bit of a joke right?  There are a
plethora of platform and even network specific reasons that lead to
specifying one address or another as both and LSP target and incoming
interface of an egress.  Some may recall the long discussions on
incoming vs outgoing interfaces in EROs in the early days of MPLS.  Like
then, I (personally) think GMPLS should continue to avoid specifying
behavior based on vendor implementation limitations.

More seriously, if you really think there is a technology-specific
restriction (rather than a particular vendor-limitation) then a BCP on
ERO specification may be appropriate.

Lou

On 7/18/2012 5:00 PM, John E Drake wrote:
> 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
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Jul 2012 11:45:41 -0400

John/All,
	It sounds like we've reach some agreement on this thread, right?

(As participant in thread) I read that the conclusion is to not optimize
for a very special corner case and:
1) basically treat the intra-OTN case the same as any other MRN/MLN case
   (leveraging GPID, and no new hierarchy object)
2) Use Daniele's new draft on MRN/MLN as the starting point in the
discussion of how to address the limitations in MRN/MLN identified in
this discussion.

Did I miss anything?

Thanks,
Lou

On 7/19/2012 7:09 AM, John E Drake wrote:
> Daniele,
> 
> What concerns me is that we are headed in a design direction in which
> signaling is required to carry all of the information necessary to
> allow any intermediate node to select the egress interface for an
> LSP.  The issue I have with this is that it requires every
> intermediate node to have exactly the same capabilities as the
> ingress/egress nodes, which makes the incremental introduction of new
> capabilities more challenging.
> 
> Allowing heterogeneous nodal capabilities is one of the reasons we
> include all of this information in routing in the first place.
> 
> Thanks,
> 
> John 
> 
> Sent from my iPhone
>

---

From: John E Drake <[email-masked]>
Date: Thu, 19 Jul 2012 08:54:03 -0700

This sounds like a plan.  Lou, if the signaling draft could be re-spun with these changes prior to Vancouver, then could we discuss the draft there and set the stage for a LC of it and the routing draft?

Sent from my iPhone

> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, July 19, 2012 8:46 AM
> To: John E Drake
> Cc: Daniele Ceccarelli; Fatai Zhang; [email-masked]; Khuzema Pithewan;
> Subject: Re: 答复: 答复: Updates on OTN signaling draft
>
> John/All,
> (As participant in thread) I read that the conclusion is to not
> optimize for a very special corner case and:
> LSP.
> > The issue I have with this is that it requires every intermediate
> node
> > to have exactly the same capabilities as the ingress/egress nodes,
> > which makes the incremental introduction of new capabilities more
> > challenging.
> >
> >> modifies the behavior of existing implementaitons while an totally
> >> new object already defined that only needs to be imported into the
> >> new MRN/MLN extensions only applies to new implementations.
> >>> interface in the ERO?  We seem to be spending a lot time and effort
> >>> to work around this.
> >>>
> >>> Sent from my iPhone
> >>>
> >>>
> >>>> info (exactly that piece of information), when I refer to a strict
> (PIETRO
> Adaptation

---

From: John E Drake <[email-masked]>
Date: Thu, 19 Jul 2012 09:07:13 -0700

Lou,

I find it best if no-one is ever completely sure whether I am serious 8->, but in this case I actually was serious.

I was proposing that the ingress node ensure that the characteristics of the LSP endpoints be compatible.  In practice what this means is that the ingress node selects the interface on which the egress LSP ends and includes it in the ERO.  Whether that interface is an ingress or egress interface on the egress node is at the discretion of the ingress node.

Thanks,

John

Sent from my iPhone

> Sent: Thursday, July 19, 2012 8:40 AM
> To: John E Drake
> incoming vs outgoing interfaces in EROs in the early days of MPLS.
> Like then, I (personally) think GMPLS should continue to avoid
> specifying behavior based on vendor implementation limitations.
> 
> >> that piece of information, the rest of the path is meaningless in
> >> this context).
> >>> sufficient for the ingress to specify the egress interface in the
> >>> ERO rather than computing a strict ERO?
> >>>
> >>> Thanks,
> >>>
> >>> John
> >>>
> >>> Sent from my iPhone
> >>>
> >>>
> >>>>         |     |      |     |      |     |      |     |      |
> >>>>         |     |      |     |      |     |      |     |      |

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Jul 2012 12:12:47 -0400

On 7/19/2012 11:54 AM, John E Drake wrote:
> This sounds like a plan. 

great!

> Lou, if the signaling draft could be
> re-spun with these changes prior to Vancouver, then could we discuss
> the draft there and set the stage for a LC of it and the routing
> draft?

I assume you're asking a chair question.  From the WG process (and
chair) standpoint:

- it's always good practice to have a WG draft reflect changes discussed
by the WG at the earliest opportunity, which would be on Monday 7/30 in
this case.

- WG presentations really should be aimed at reviewing recent
changes/agreements and identifying/resolving open issues.  So, it would
be a mistake for a WG presentation to omit progress on the list just
because the progress took place after the ID cutoff.

- WRT LC.  Clearly LC can't happen until all anticipated updates are
published.  Let's also see how the discussion goes in Vancouver -- we
have put time on the agenda to discuss any remaining open issues.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 20 Jul 2012 07:51:59 +0000

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,

Thanks,
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 20 Jul 2012 11:53:15 +0200

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

>Sent: venerdì 20 luglio 2012 9.52
>To: Daniele Ceccarelli; John E Drake; Lou Berger
>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).
>
>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
>component links with differing characteristics.
>
>
>Thanks
>
>Fatai
>
>
>-----邮件原件-----
>think people
>>can understand the bundling issue that I raised in 13rd July.
>>
>>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.
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 23 Jul 2012 03:05:07 +0000

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,

OLD:

Thanks,
Daniele

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Jul 2012 05:44:59 -0700

Looks good

Sent from my iPhone

> Sent: Sunday, July 22, 2012 8:05 PM
> 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".
>
> 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:
> 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
>
>
> >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).
> >
> >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.
> >
> >
> 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
> >
> >
> >-----邮件原件-----
> >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.
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 23 Jul 2012 16:40:46 +0200

OK!

Thanks
Daniele

>Sent: lunedì 23 luglio 2012 14.45
>To: Fatai Zhang; Daniele Ceccarelli; Lou Berger
>> 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
>> Hope all the people are interested in OTN protocol to review
>this NEW
>> text.
>>
>> NEW:
>>    same Tributary Slot Granularity (TSG).  Component links
>supporting
>> non homogenous
>>    hierarchies MUST NOT be bundled together and a different
>ISCD MUST
>> be used
>> 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.
>>
>> >Correct. What you said is my suggestion in 11th July (ie., remove
>> >link bundling (or bundle the homogeneous component links).
>> >
>> >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).
>> >
>> >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.
>> >
>> >
>> >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.
>> >
>> >>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
>> >>> (exactly that piece of information), when I refer to a
>strict ERO
>> >>> I speak about an ERO including info of all the hops (hence
>> >>> 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
>> >>>
>> >>> >> 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
>+======================================+
>> >>> >>            |            |
>         |
>> >>> >>            |            |
>         |
>> >>> >>            |            |
>ODU3-H-LSP         |
>> >>> >>            |            |
>> >>> >> each with a different value of j, in order to instantiate an
>> >>> >> OTN hierarchy between a given ingress/egress pair
>> >>> >>
>> >>> >>
>> >>> >>
>capability of
>missing the
>> >>> >> draft should remove TSG or hierachy information or bothe of
>> >>> >> them (ie., GPID extension for TSG and hierachy
>inforamtion in LSPA)?
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>  Thanks
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>  Fatai
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>  -----邮件原件-----

---

From: Julien Meuric <[email-masked]>
Date: Mon, 23 Jul 2012 17:24:44 +0200

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 :
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Jul 2012 08:45:09 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Julien Meuric
> Sent: Monday, July 23, 2012 8:25 AM
> To: Fatai Zhang; Daniele Ceccarelli
> Cc: [email-masked]
> Subject: Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft
>
> Hi Fatai, hi Daniele.
>
> Since it is not obvious if you are talking about data plane
> capabilities or control plane supports, what about adding something
> like the following?
> TSGs are bundled together, the smallest commonly supported TSG SHOULD
> be used (i.e. fallback is forced for lower granularity components)."
>
> Regards,
>
> Julien
>
>
> supporting non homogenous
> >> (ie., heterogeneous component links MUST not bundled), then what you
> >> said below is completely correct.
> >>
> >> because the node can pick up the component link locally (ie., any of
> >> the component is fine).
> >>
> >> characteristics.
> >>> the same Tributary Slot Granularity (TSG).  A different ISCD MUST
> be
> new

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Jul 2012 08:49:31 -0700

Julien,

My apologies for misspelling your name in my previous email.

Thanks,

John

Sent from my iPhone

> Of John E Drake
> Sent: Monday, July 23, 2012 8:45 AM
> To: Julien Meuric; Fatai Zhang; Daniele Ceccarelli
> Cc: [email-masked]
> 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
>
> > > Hope all the people are interested in OTN protocol to review this
> > > NEW
> > text.
> > >
> > > NEW:
> > >     same Tributary Slot Granularity (TSG).  A different ISCD MUST
> be
> > used
> bundle
> > >> (ie., heterogeneous component links MUST not bundled), then what
> > >> you said below is completely correct.
> > >>
> homogeneous
> > >> because the node can pick up the component link locally (ie., any
> > >> of the component is fine).
> > >>
> which
> > >>>> (exactly that piece of information), when I refer to a strict
> ERO
> > I
> > >>>> speak about an ERO including info of all the hops (hence
> > >>>>>> signalling message of layer 2, needs to choose the FA at layer
> > >>>>>>             |            |            |-----------------------
> --
> > |
> > >>>>>>             |            |            |
> > |
> > >>>>>> them (ie., GPID extension for TSG and hierachy inforamtion in
> LSPA)?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>   Thanks
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>   Fatai
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>   -----邮件原件-----

---

From: Julien Meuric <[email-masked]>
Date: Tue, 24 Jul 2012 17:34:05 +0200

Hi John.

I think your sentence itself is clear. My intend was not so different 
from yours. I was trying to explicitly tackle the case where component 
links with the same hierarchy but _different TSGs in the data plane_ 
will necessarily have the _same TSG in the control plane_ if they are 
bundled (i.e. a TSG they both support).

Cheers,

Julien

Le 23/07/2012 17:45, John E Drake a écrit :
 >> -----Original Message----- From: [email-masked]
 >> [mailto:[email-masked]] On Behalf Of Julien Meuric
 >>
 >> Hi Fatai, hi Daniele.
 >>
 >> 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
 >>
 >>
 >> characteristics." , because this text conflicts with " Component
 >> links supporting non homogenous hierarchies MUST NOT be bundled
 >> together".
 >>>
 >>> NEW: A single ISCD MAY be used for the advertisement of unbundled
 >>> or bundled links supporting homogeneous multiplexing hierarchies
 >>> and
 >> the
 >>> -----邮件原件----- 发件人: Daniele Ceccarelli
 >>> [mailto:[email-masked]] 发送时间: 2012年7月20日 
17:53 收
 >>> 件人: Fatai Zhang; John E Drake; Lou Berger 抄送: [email-masked];
 >>> Khuzema Pithewan;
 >>> [email-masked]; BELOTTI, SERGIO (SERGIO) 主题: RE: 答复: 答
 >>> 复: Updates on OTN signaling draft
 >>>
 >>> Hi Fatai,
 >>>
 >> 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
 >>> 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
 >>> 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.
 >>>
 >> 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]; BELOTTI, SERGIO (SERGIO) Subject: 答复:
 >>>> 答复: 答复: Updates on OTN signaling draft
 >>>>
 >>>> Hi Daniele,
 >>>>
 >>>> 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).
 >>>>
>>>> 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.
 >>>>
 >>>>
 >>>> (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]; BELOTTI, SERGIO (SERGIO) 主题: RE: 答复:
 >>>> 答复: Updates on OTN signaling draft
 >>>>
 >>>> Hi Fatai,
 >>>>
 >>>> Thanks, Daniele
 >>>>> 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.
 >>>>
 >>>>> 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.
 >>>>>
 >>>>> advertised in
 >>>> 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.
 >>>>
 >>>>> unbundled or bundled links supporting homogeneous
 >>>>> multiplexing hierarchies and the same Tributary Slot
 >>>>> Granularity (TSG). A different ISCD MUST
 >> be
 >>>>> 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]; BELOTTI, SERGIO (SERGIO) 主题: RE: 答
 >>>>> 复: 答复: Updates on OTN signaling draft
 >>>>>
 >>>>>> -----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]; 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
 >>>>>> context). I know the terminology is not exact but I didn't
 >>>>>> want to invent
 >> new
 >>>>>> 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;
 >>>>>>> sufficient for the ingress to specify the egress
 >>>>>>> interface
 >>>>> in the ERO
 >>>>>>>> -----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
 >>>>>>>> partially agree. I think the hierarchy is still needed
 >>>>>>>> for
 >>>>>>> those cases
 >>>>>>>> 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
 >>>>>>>> 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
 >>>>>>>> on E is ODU1->ODU2->ODU3 and the only way to let C know
 >>>>>>>> it, is introducing the hierarchy in signaling.
 >>>>>>>>
 >>>>>>>> real case, but if there is a 0,00001% possibility it
 >>>>>>>> can
 >>>>> happen, we
 >>>>>>>> should cover the case.
 >>>>>>>>
 >>>>>>>> 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;
 >>>>>>>> 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)
 >>>>>>>>
 >>>>>>>> ODUj
 >>>>>>>> each with a different value of j, in order to
 >>>>>>>> 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
 >>>>>>>> [email-masked]; GRANDI, PIETRO VITTORIO
 >>>>>>>> [email-masked]; BELOTTI, SERGIO (SERGIO);
 >>>>>>>> Fatai Zhang Subject: 答复: 答复: 答复: Updates on OTN
 >>>>>>>> signaling draft
 >>>>>>>>
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> Hi Lou,
 >>>>>>>>
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> [snip]
 >>>>>>>>
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> missing the capability of signaling the TSG? Should
 >>>>>>>> Inter-OTN be generic
 >>>>>> MRN/MLN?
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> signaling draft, did you mean that this draft (OTN
 >>>>>>>> signaling) should focus on OTN specific (intra-OTN) as
 >>>>>>>> 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]; GRANDI, PIETRO VITTORIO
 >>>>>>>> [email-masked]; BELOTTI, SERGIO (SERGIO) 主题:
 >>>>>>>> Re: 答复: 答复: Updates on OTN signaling draft
 >>>>>>>>
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> [snip]
 >>>>>>>>
 >>>>>>>>
 >>>>>>>
 >>> _______________________________________________ CCAMP mailing
 >>> list [email-masked] https://www.ietf.org/mailman/listinfo/ccamp
 >>
 >>
 >> _______________________________________________ CCAMP mailing list
 >> [email-masked] https://www.ietf.org/mailman/listinfo/ccamp