Re: [CCAMP] Ask for comments

[Acee Lindem <[e-mail]>]

Hi Yabin,

On Aug 3, 2010, at 12:12 PM, Yabin Ye wrote:


Dear Acee,



Thanks for your comments and sorry for my late reply due to some urgent issues.



Please see my reply inline.



Thanks,



Yabin







-----Original Message-----
From: Acee Lindem [mailto:[e-mail]]
Sent: Tuesday, July 27, 2010 4:27 PM
To: Yabin Ye
Cc: [e-mail]<mailto:[e-mail]>; Siamak Azodolmolky; [e-mail]<mailto:[e-mail]>; Michèle Wilmet
Subject: Re: [CCAMP] Ask for comments



Hi Yabin,



I have a couple comments:



       - First, this document extends OSPF TE rather than the OSPF protocol itself.

.

>>>>>Yes, you are right. This document is for OSPF-TE extensions.



       - Second, the document refers to PLI TE LSAs as if they were separate LSAs. However, I believe these are just additional TE LSAs as described in RFC 3630.

>>>>>>  The motivation for a new LSA is that type 10 LSA has an area flooding scope. However, not all the PLI information has the same flooding scope, for example, the PMD is not suitable for relatively small area network, i.e. metro network, it only makes sense in regional or long haul network. From the networking point of view, taking the flooding scope into account when distributing PLI information will reduce the generated traffic. From the network resource provider point of view, it gives the flexibility and capability to the choice of flooding scope, in order to apply local policy. From the software implementation point of view, it reduces the need of big memory to buffer more PLI information. Therefore hierarchical PLI is proposed.

You can not change the flooding scope with a new LSA. Refer to RFC 5250. Should your draft advance, you could request a new LSA option type as described in the IANA section of RFC 5250. However, for OSPF, you only have 3 alternatives for flooding scope (Link-local, Area, OSPF Routing Domain Wide).

Thanks,
Acee







       - Similarly, the document refers to the top-level Link and Node TLVs as if they are new PLI TLVs. However, these are referenced with the same code points as the existing Link and Node TLVs. They will need new types if you want to redefine them with different semantics.

       - Same for the Remote Interface IP Address Sub-TLV and Local Interface IP Address Sub-TLV. These are not new Sub-TLVs and probably don't need to be even if new top-level PLI TLVs are required.

>>>>>>---Yes, I agree. We could use the existing code points defined in [RFC3630] and [draft-ietf-ospf-te-node-addr] for top-level link TLV and Node TLV. However other sub-TLVs related to impairment information are new and the main focus of this draft.



From a high-level, it seems the only new TLVs required are the ones for PLI and this information can be just advertised with the existing TE information. However, due to the volume and frequency of change, you may want separate LSAs.



Thanks,

Acee



On Jul 26, 2010, at 6:26 AM, Yabin Ye wrote:



Dear All,



We have submitted a draft entitled “OSPF Extensions in Support of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs)”.



http://tools.ietf.org/html/draft-agraz-ccamp-wson-impairment-ospf-00



This document suggests to extend the OSPF-TE protocols by including the physical impairments in order to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE)    control of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs).



Due to urgent issues, we are not able to attend the meeting. Attached please find the presentation, and kindly let us know if you have any comments.



Background: This draft is the output of EU FP7 funded DICONET project. More details of this project can be found at http://www.diconet.eu/homepage.asp



Thanks and regards,



Yabin Ye





*********************************************************

Yabin Ye 叶亚斌

European Research Center

Huawei Technologies

Riesstr. 25

80992 Munich

Germany

Tel: [phone]

Cell: [phone]

Fax: [phone]

E-mail: [e-mail]<mailto:[e-mail]>

www.huawei.com<http://www.huawei.com/>

*********************************************************



<WSON impairment ospf V1.ppt><ATT00001..txt>