Subject: [CCAMP] OTN open issues for OTN framework and OTN Info

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 14 Jul 2011 12:12:43 +0200

Dear CCAMPers,

Some open issues need to be clarified in order to update the OTN framework and OTN info model drafts. The list of issues that we'd like to bring to your attention is:

1. TS granularity/Payload type autonegotiation
At interface commisioning time there is no default adaptation value. The type of adaptation is vendor specific and is provided as soon as a client request is received on the server trail. The type of adaptation is linked to the Payload type..
Given that no default value is available, there is the need for the nodes to advertise the supported payload types and for the signaling to configure the correct payload on the end nodes.

2. When setting up a server trail, it is needed to signal which is the range of client that will be supported in order to be able to select the correct interface on the end nodes.
Payload type information is not enough, because Payload type tells how clients are mapped in the server trail and not which client adaptations are available.

3) It is possible to summarize possible requirement from CP prospective :
*       TS/PT has to be signaled in case of auto-negotiation disabled or we do not force the structuring of the server.
*       TS/PT has to be advertised by routing in case no NMS configuration or LMP is provided

4. It is needed to analyze whether  the current IACD structure is enough in order to represent correctly the mapping of  "non OTN client" over OTN server trails.

5. The merged signaling draft contains a set of requirement that, if approved, will have to be moved to the framework draft. Once this is done, the info model draft will have
to be updated accordingly.

We would like to address these open points and make an update of the draft after this forthcoming 81th IETF meeting.
It would be important either just via mailing list or better , exploiting the IETF meeting in July, starting to discuss these subjects.

Thanks

Best Regards

Daniele, Fatai, Pietro, Sergio

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]

---

From: [email-masked]
Date: Thu, 14 Jul 2011 20:58:47 +0800

Hi Sergio,

I suppose you are talking about the requirement and solution at the same 
time.
I have some comments. Pls see inline.

Xihua

> Dear CCAMPers,
> 
> Some open issues need to be clarified in order to update the OTN 
> framework and OTN info model drafts. The list of issues that we'd 
> like to bring to your attention is:
> 
> At interface commisioning time there is no default adaptation value.
> The type of adaptation is vendor specific and is provided as soon as
> a client request is received on the server trail. The type of 
> adaptation is linked to the Payload type.. 
> Given that no default value is available, there is the need for the 
> nodes to advertise the supported payload types and for the signaling
> to configure the correct payload on the end nodes.

[Xihua]: Could we use notify (CALL) message to negotiation the adapation 
types 
before you trigger the client layer which will be over server layer by one 
adaptation type. 

> 
> 2. When setting up a server trail, it is needed to signal which is 
> the range of client that will be supported in order to be able to 
> select the correct interface on the end nodes.
> Payload type information is not enough, because Payload type tells 
> how clients are mapped in the server trail and not which client 
> adaptations are available.
> 
> TS/PT has to be signaled in case of auto-negotiation disabled or we 
> do not force the structuring of the server. 
[Xihua]:  TS granularity has been taken in label. So what do you want?
Is G-PID in LABEL_REQUEST enough for payload type requirement?

> TS/PT has to be advertised by routing in case no NMS configuration 
> or LMP is provided
[Xihua]: Do you mean we have to consider TS granularity in OSPF again? 
IMO, we don't consider TS granularity in current OTN-OSPF draft. 
The requirement is not clear for me.

> 
> 
> 4. It is needed to analyze whether  the current IACD structure is 
> enough in order to represent correctly the mapping of  “non OTN 
> client” over OTN server trails.
> 
> 5. The merged signaling draft contains a set of requirement that, if
> approved, will have to be moved to the framework draft. Once this is
> done, the info model draft will have
> We would like to address these open points and make an update of the
> draft after this forthcoming 81th IETF meeting.
> It would be important either just via mailing list or better , 
> exploiting the IETF meeting in July, starting to discuss these subjects.
> 
> Thanks
> 
> Best Regards
> 
>  _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 14 Jul 2011 15:29:45 +0200

Hi Xihua,

please see in line.

Thanks
sergio

SERGIO BELOTTI

ALCATEL-LUCENT

________________________________
Da: [email-masked] [mailto:[email-masked]]
Inviato: giovedì 14 luglio 2011 14.59
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [email-masked]
Oggetto: Re: [CCAMP] OTN open issues for OTN framework and OTN Info

Hi Sergio,

I suppose you are talking about the requirement and solution at the same time.
I have some comments. Pls see inline.

Xihua

> to configure the correct payload on the end nodes.

[Xihua]: Could we use notify (CALL) message to negotiation the adapation types
before you trigger the client layer which will be over server layer by one adaptation type.
SB> Yes it could be a method , but first we need to under stand and agree on the needs and requirement, Framework, and then analyze whether actual signalling/routing solution have to be update, that is the Info scope.

SB> You misunderstood the problem : how can you signal TS granularity for an HO trail , when no structured has been made ??? The TS granularity is present but not for the signal on the server trail.

SB> TS granularità should be negotiated link by link and in case LMP is present no prolblem. Other alternative is to have NMS that can configure TS as it is needed.
But the only other alternative in case the first two are not present , is to have TS granularity/PT information inside the routing.

> enough in order to represent correctly the mapping of  "non OTN
> client" over OTN server trails.
>

---

From: [email-masked]
Date: Sat, 16 Jul 2011 22:59:53 +0800

Hi Sergio,

You wrote "SB> You misunderstood the problem : how can you signal TS 
granularity for an HO trail , when no structured has been made ??? The TS 
granularity is present but not for the signal on the server trail."
I think you may refer to the section "4.1. Tributary Slot type" in info 
document. This requirement in this email is still not clear for me. Could 
you give me a further clarification?

When I read through info and frame document. I found there are some 
inconsistent descriptions. 
1. Info and OSPF document mention multi-stage. But framework document 
tries to avoid this terminology.
2. OSPF document support to bundle links with different multiplexing 
hierarchies, but this isn't described in framework and info document.

Info document introduces termination and switching capability concept. 
That's a very good idea.
I use this concept and information in OSPF draft to faciliate the boundary 
nodes determination of FA-LSP. 
Pls refer to the draft (
http://tools.ietf.org/html/draft-fuxh-ccamp-boundary-explicit-control-ext-03
).
It introduces a generic mechanism to determine the boundaries of FA-LSPs 
by using termination and switching capability from IGP database. 
Node B and D support ODUj being mapping into ODUk (k>j). 
Interface IF-B and IF-D support ODUj switching capability (ODUj(S)) and 
ODUk termination capability (ODUk(T)). 
Interface within C only supports ODUk switching capability.  So Node B and 
D could be boundaries of ODUk FA-LSP for ODUj LSP.

Xihua

"BELOTTI, SERGIO (SERGIO)" <[email-masked]> 
2011-07-14 下午 09:29

收件人
"[email-masked]" <[email-masked]>
抄送
"'CCAMP'" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
R: [CCAMP] OTN open issues for OTN framework and OTN Info

Hi Xihua, 
 
please see in line.
 
Thanks
sergio
 
SERGIO BELOTTI 
ALCATEL-LUCENT 

Hi Sergio, 

Xihua

[Xihua]: Could we use notify (CALL) message to negotiation the adapation 
types 
before you trigger the client layer which will be over server layer by one 
adaptation type. 
SB> Yes it could be a method , but first we need to under stand and agree 
on the needs and requirement, Framework, and then analyze whether actual 
signalling/routing solution have to be update, that is the Info scope.

SB> You misunderstood the problem : how can you signal TS granularity for 
an HO trail , when no structured has been made ??? The TS granularity is 
present but not for the signal on the server trail.

[Xihua]:  The requirement is still not clear for me.

SB> TS granularità should be negotiated link by link and in case LMP is 
present no prolblem. Other alternative is to have NMS that can configure 
TS as it is needed.
But the only other alternative in case the first two are not present , is 
to have TS granularity/PT information inside the routing.

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 21 Jul 2011 14:53:57 +0800

Hi Xihua,

For your following understanding, I have to clarify something because maybe
some people have your same understanding.

If you participated in the IETF 79th and IETF 80th meetings, you should know
that “multi-stage muxing” was replaced by “multiplexing hierarchy” in
the FWK document (ie., your statement “But framework document tries to
avoid this terminology” is not the fact). 

Of course, we should make the OSPF and RSVP drafts align with these changes.

 

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

1. Info and OSPF document mention multi-stage. But framework document tries
to avoid this terminology.

Thanks
 
Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 2011年7月16日 23:00
To: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'
Subject: Re: [CCAMP] R: OTN open issues for OTN framework and OTN Info

Hi Sergio, 

When I read through info and frame document. I found there are some
inconsistent descriptions. 
1. Info and OSPF document mention multi-stage. But framework document tries
to avoid this terminology. 
2. OSPF document support to bundle links with different multiplexing
hierarchies, but this isn't described in framework and info document. 

Xihua

---

From: [email-masked]
Date: Thu, 21 Jul 2011 15:27:47 +0800

Hi Fatai,

Thank you for your clarification. 
I know framework document has changed the terminology. They have to be 
consistent.

Xihua

Fatai Zhang <[email-masked]> 
2011-07-21 下午 02:53

收件人
[email-masked], "'BELOTTI, SERGIO (SERGIO)'" 
<[email-masked]>
抄送
'CCAMP' <[email-masked]>
主题
RE: [CCAMP] R:  OTN open issues for OTN framework and OTN Info

Hi Xihua,
 
For your following understanding, I have to clarify something because 
maybe some people have your same understanding.
 
If you participated in the IETF 79th and IETF 80th meetings, you should 
know that “multi-stage muxing” was replaced by “multiplexing hierarchy
” in the FWK document (ie., your statement “But framework document tries 
to avoid this terminology” is not the fact). 
 
Of course, we should make the OSPF and RSVP drafts align with these 
changes.

 
 
==================================================================================================
1. Info and OSPF document mention multi-stage. But framework document 
tries to avoid this terminology.

Thanks
 
Fatai

Hi Sergio, 

Xihua