Subject: Re: [CCAMP] Ask for comments

From: Yabin Ye <[email-masked]>
Date: Tue, 03 Aug 2010 18:12:40 +0200

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:[email-masked]] 
Sent: Tuesday, July 27, 2010 4:27 PM
To: Yabin Ye
Cc: [email-masked]; Siamak Azodolmolky; [email-masked]; 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.

       - 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: +49 89 158 834 4078

Cell: +49 162 2047570

Fax: +49 89 158 834 4447

E-mail: [email-masked]<mailto:[email-masked]>

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

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

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 3 Aug 2010 15:00:22 -0400

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.

Thanks,

Yabin

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

Hi Yabin,

       - 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

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

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: +49 89 158 834 4078

Cell: +49 162 2047570

Fax: +49 89 158 834 4447

---

From: Acee Lindem <[email-masked]>
Date: Tue, 3 Aug 2010 15:05:40 -0400

Hi Yabin,

See Below. 

Thanks,
Acee