Subject: [CCAMP] Mail regarding draft-bccg-ccamp-otn-g709-info-model

From: Rajan Rao <[email-masked]>
Date: Tue, 22 Mar 2011 15:38:16 -0700

Sergio, et al,

Couple of comments on the draft:

1)      Can you please clarify section 4.7 in relation to FAs?

*         Since the requirement is mainly relating to inducing an FA at HO-ODU, it should be spelled out clearly, I think.

*         The need to advertise mux/demux capability (i.e. termination) is to allow head-end (Fig-5 & Fig-6) to compute path for an ODU0-LSP which requires ODU2-FA to be dynamically established (path computed).

*         It will be very useful if you clarify the above in relation to manual-FAs.
             For e.g,  if manual FA is already created (ODU2-FA along A-B-C-D & A-B-E-D), the ODU0-LSP restoration works without needing "Termination" capability information.  Here ODU2-FA would be advertising  ODU0 switching BW.

2)      Suggestion: Since this doc is listing few requirements it is useful to have all requirements in one place, i.e. the Framework doc.

Thanks
Rajan

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 24 Mar 2011 11:18:44 +0100

Rajan,

see in line

BR

Sergio, Daniele, Pietro and Fatai

Sergio Belotti

Portfolio Evolution
Terrestrial Optics Product Unit
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Rajan Rao
Inviato: martedì 22 marzo 2011 23.38
A: [email-masked]
Cc: [email-masked]
Oggetto: [CCAMP] Mail regarding draft-bccg-ccamp-otn-g709-info-model

Sergio, et al,

·         Since the requirement is mainly relating to inducing an FA at HO-ODU, it should be spelled out clearly, I think.

Why do you assume that the requirement is "mainly" related to inducing FA? The requirement is independent from FA creation and is related to path computation process.

·         The need to advertise mux/demux capability (i.e. termination) is to allow head-end (Fig-5 & Fig-6) to compute path for an ODU0-LSP which requires ODU2-FA to be dynamically established (path computed).

No, the need to advertise T/S capability is to help path computation to avoid possible crankback in case you wrongly setup an LSP that is not aligned with interface characteristics. i.e. trying to switch an ODU container on an interface that can only terminate this container and viceversa .

·         It will be very useful if you clarify the above in relation to manual-FAs.
             For e.g,  if manual FA is already created (ODU2-FA along A-B-C-D & A-B-E-D), the ODU0-LSP restoration works without needing "Termination" capability information.  Here ODU2-FA would be advertising  ODU0 switching BW.

This is not true . Imagine you have a board in which you need to terminate ODU0 to extract a non-ODU client (e.g. GE) . In this case the Termination capability information is still absolutely needed.
Moreover having an FA does not imply that the carried signal type  must be terminated e.g. the FA LSP could be used in case of stitching, and then the carried signal just switched.

The presence of the list of requirements is only as reference of what obviously reported in the Framework to easy understand the information needed to cope with the requirements.

Thanks
Rajan