Re: [CCAMP] R: OTN open issues for OTN framework and OTN Info

[[e-mail]]

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)" <[e-mail]> 
2011-07-14 下午 09:29

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




Hi Xihua, 
 
please see in line.
 
Thanks
sergio
 
SERGIO BELOTTI 
ALCATEL-LUCENT 
Terrestrial System Architect 
Optics Portfolio Evolution 
via Trento 30 , Vimercate(MI)  Italy 
T: [phone] 
[e-mail] 
 

Da: [e-mail] [mailto:[e-mail]] 
Inviato: giovedì 14 luglio 2011 14.59
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; [e-mail]
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

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

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

>   
> 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.   
[Xihua]:  TS granularity has been taken in label. So what do you want? 
Is G-PID in LABEL_REQUEST enough for payload type requirement? 
 
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.

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


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