Request comments on draft-zhang-ccamp-gmpls-uni-app

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

OTN OSPF draft

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: I-D Action: draft-ietf-ccamp-gmpls-g709-framework-05.txt

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance
technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples
given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft
discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to
avoid fragmentation. 

Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 

Regards,
Young

-----Original Message-----
From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Thursday, September 08, 2011 5:16 PM
To: i-d-announce <at> ietf.org
Cc: ccamp <at> ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
	Pages           : 14
	Date            : 2011-09-08

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

I-D Action: draft-ietf-ccamp-rwa-info-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-info-12.txt
	Pages           : 27
	Date            : 2011-09-09

   This document provides a model of information needed by the routing
   and wavelength assignment (RWA) process in wavelength switched
   optical networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath computation in
   WSONs. This model takes into account compatibility constraints
   between WSON signal attributes and network elements but does not
   include constraints due to optical impairments. Aspects of this
   information that may be of use to other technologies utilizing a
   GMPLS control plane are discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

Hi,

This update (version 12) includes the following:

(i) Replaced all instances of "ingress" with "input" and all instances of "egress" with "output". 
(ii) Added clarifying text on relationship between resource block model and physical entities such as
line cards.

This draft is now very mature and incorporated all the comments raised in the mailing list and the last
meetings. 

Thanks,
Young

-----Original Message-----
From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Friday, September 09, 2011 4:20 PM
To: i-d-announce <at> ietf.org
Cc: ccamp <at> ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-info-12.txt
	Pages           : 27
	Date            : 2011-09-09

   This document provides a model of information needed by the routing
   and wavelength assignment (RWA) process in wavelength switched
   optical networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath computation in
   WSONs. This model takes into account compatibility constraints
   between WSON signal attributes and network elements but does not
   include constraints due to optical impairments. Aspects of this
   information that may be of use to other technologies utilizing a
   GMPLS control plane are discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg, 
I have the following comments:

   1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
       For example (from RFC 3630): 

     "The Link TLV describes a single link.  It is constructed of a set of
       sub-TLVs.  There are no ordering requirements for the sub-TLVs.

      Only one Link TLV shall be carried in each LSA, allowing for fine  
      granularity changes in topology."

      However, use the term "advertised" rather than "carried". After all, these are
      Link State Advertisements. 

   2. The same comment for all the Sub-TLVs. Here is another example from 
        RFC 3630:

      "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
       exactly once.  All other sub-TLVs defined here may occur at most
       once.  These restrictions need not apply to future sub-TLVs.
       Unrecognized sub-TLVs are ignored."

       The new Sub-TLVs you are defining need this level of specification. 

   3. I know I told you not to use the term "multi-instance LSA". I still don't like
       the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
       the term LSA instance is used to denote a particular version of the same LSA - NOT
       an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
       RFC 2328. 

      The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
       identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
       to this field as the "Instance", I believe this term should be avoided given the 
       semantics in the OSPF base specification. Hence, I'd suggest the 
       following changes:

225,226c225,226
<    the rest and make use of multiple TE LSA instances per source, per
<    [RFC3630] multiple instance capability.
---
>    the rest and be advertised with multiple TE LSAs per OSPF router, as
>    described in [RFC3630] and [RFC5250].
342,344c342,344
<    the dynamic information sub-TLVs into separate LSAs within an Optical
<    Node Property TLV using multiple TE LSA instances per source, per the
<    reference [RFC3630] multiple instance capability.
---
>    the dynamic information sub-TLVs from the static information sub-TLVs
>    and advertise them in OSPF TE LSAs, each with the Optical Node
>    Property TLV at the top level ([RFC3630 and RFC5250]). 
392c392
<    into smaller sub-TLVs that can be sent in separate LSA instances.
---
>    into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
399c399
<    sub-TLVs that can be sent in multiple LSA instances. The
---
>    sub-TLVs that can be sent in multiple OSPF TE LSAs. The
473c473
<    into multiple LSA instances each containing a disjoint assembly of
---
>    into multiple OSPF TE LSAs each containing a disjoint assembly of

     Additionally, I'd add RFC 5250 as at least a informative reference.

   4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
       "GMPLS OSPF Enhancement..." since you are not really enhancing base 
       OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
       this distinction. 

Thanks,
Acee 

  
On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

> Hi,
> 
> This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance
technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples
given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft
discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to
avoid fragmentation. 
> 
> Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 
> 
> Regards,
> Young
> 
> 
> 
> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
> Sent: Thursday, September 08, 2011 5:16 PM
> To: i-d-announce <at> ietf.org
> Cc: ccamp <at> ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 	Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                          Greg M. Bernstein
> 	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 	Pages           : 14
> 	Date            : 2011-09-08
> 
>   This document provides GMPLS OSPF routing enhancements to support
>   signal compatibility constraints associated with WSON network
>   elements. These routing enhancements are required in common optical
>   or hybrid electro-optical networks where not all of the optical
>   signals in the network are compatible with all network elements
>   participating in the network.
> 
>   This compatibility constraint model is applicable to common optical
>   or hybrid electro optical systems such as OEO switches, regenerators,
>   and wavelength converters since such systems can be limited to
>   processing only certain types of WSON signals.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Acee,

I personally agree with your comments on "multi-instance LSA".

I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".




Thanks
 
Fatai


-----Original Message-----
From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Acee Lindem
Sent: 2011年9月13日 6:58
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,
I have the following comments:

   1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
       For example (from RFC 3630): 

     "The Link TLV describes a single link.  It is constructed of a set of
       sub-TLVs.  There are no ordering requirements for the sub-TLVs.

      Only one Link TLV shall be carried in each LSA, allowing for fine  
      granularity changes in topology."

      However, use the term "advertised" rather than "carried". After all, these are
      Link State Advertisements. 

   2. The same comment for all the Sub-TLVs. Here is another example from 
        RFC 3630:

      "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
       exactly once.  All other sub-TLVs defined here may occur at most
       once.  These restrictions need not apply to future sub-TLVs.
       Unrecognized sub-TLVs are ignored."

       The new Sub-TLVs you are defining need this level of specification. 

   3. I know I told you not to use the term "multi-instance LSA". I still don't like
       the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
       the term LSA instance is used to denote a particular version of the same LSA - NOT
       an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
       RFC 2328. 

      The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
       identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
       to this field as the "Instance", I believe this term should be avoided given the 
       semantics in the OSPF base specification. Hence, I'd suggest the 
       following changes:

225,226c225,226
<    the rest and make use of multiple TE LSA instances per source, per
<    [RFC3630] multiple instance capability.
---
>    the rest and be advertised with multiple TE LSAs per OSPF router, as
>    described in [RFC3630] and [RFC5250].
342,344c342,344
<    the dynamic information sub-TLVs into separate LSAs within an Optical
<    Node Property TLV using multiple TE LSA instances per source, per the
<    reference [RFC3630] multiple instance capability.
---
>    the dynamic information sub-TLVs from the static information sub-TLVs
>    and advertise them in OSPF TE LSAs, each with the Optical Node
>    Property TLV at the top level ([RFC3630 and RFC5250]). 
392c392
<    into smaller sub-TLVs that can be sent in separate LSA instances.
---
>    into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
399c399
<    sub-TLVs that can be sent in multiple LSA instances. The
---
>    sub-TLVs that can be sent in multiple OSPF TE LSAs. The
473c473
<    into multiple LSA instances each containing a disjoint assembly of
---
>    into multiple OSPF TE LSAs each containing a disjoint assembly of

     Additionally, I'd add RFC 5250 as at least a informative reference.
    
    

   4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
       "GMPLS OSPF Enhancement..." since you are not really enhancing base 
       OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
       this distinction. 


Thanks,
Acee 


  
On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

> Hi,
> 
> This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance
technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples
given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft
discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to
avoid fragmentation. 
> 
> Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 
> 
> Regards,
> Young
> 
> 
> 
> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf 
> Of internet-drafts <at> ietf.org
> Sent: Thursday, September 08, 2011 5:16 PM
> To: i-d-announce <at> ietf.org
> Cc: ccamp <at> ietf.org
> Subject: [CCAMP] I-D Action: 
> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 	Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                          Greg M. Bernstein
> 	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 	Pages           : 14
> 	Date            : 2011-09-08
> 
>   This document provides GMPLS OSPF routing enhancements to support
>   signal compatibility constraints associated with WSON network
>   elements. These routing enhancements are required in common optical
>   or hybrid electro-optical networks where not all of the optical
>   signals in the network are compatible with all network elements
>   participating in the network.
> 
>   This compatibility constraint model is applicable to common optical
>   or hybrid electro optical systems such as OEO switches, regenerators,
>   and wavelength converters since such systems can be limited to
>   processing only certain types of WSON signals.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

> tibility-ospf-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat
> ibility-ospf-05.txt _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp


_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Acee,

Sorry for a mistake, 

I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".






Thanks
 
Fatai


-----Original Message-----
From: Zhangfatai 
Sent: 2011年9月13日 11:38
To: 'Acee Lindem'; Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Acee,

I personally agree with your comments on "multi-instance LSA".

I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".




Thanks
 
Fatai


-----Original Message-----
From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Acee Lindem
Sent: 2011年9月13日 6:58
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,
I have the following comments:

   1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
       For example (from RFC 3630): 

     "The Link TLV describes a single link.  It is constructed of a set of
       sub-TLVs.  There are no ordering requirements for the sub-TLVs.

      Only one Link TLV shall be carried in each LSA, allowing for fine  
      granularity changes in topology."

      However, use the term "advertised" rather than "carried". After all, these are
      Link State Advertisements. 

   2. The same comment for all the Sub-TLVs. Here is another example from 
        RFC 3630:

      "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
       exactly once.  All other sub-TLVs defined here may occur at most
       once.  These restrictions need not apply to future sub-TLVs.
       Unrecognized sub-TLVs are ignored."

       The new Sub-TLVs you are defining need this level of specification. 

   3. I know I told you not to use the term "multi-instance LSA". I still don't like
       the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
       the term LSA instance is used to denote a particular version of the same LSA - NOT
       an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
       RFC 2328. 

      The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
       identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
       to this field as the "Instance", I believe this term should be avoided given the 
       semantics in the OSPF base specification. Hence, I'd suggest the 
       following changes:

225,226c225,226
<    the rest and make use of multiple TE LSA instances per source, per
<    [RFC3630] multiple instance capability.
---
>    the rest and be advertised with multiple TE LSAs per OSPF router, as
>    described in [RFC3630] and [RFC5250].
342,344c342,344
<    the dynamic information sub-TLVs into separate LSAs within an Optical
<    Node Property TLV using multiple TE LSA instances per source, per the
<    reference [RFC3630] multiple instance capability.
---
>    the dynamic information sub-TLVs from the static information sub-TLVs
>    and advertise them in OSPF TE LSAs, each with the Optical Node
>    Property TLV at the top level ([RFC3630 and RFC5250]). 
392c392
<    into smaller sub-TLVs that can be sent in separate LSA instances.
---
>    into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
399c399
<    sub-TLVs that can be sent in multiple LSA instances. The
---
>    sub-TLVs that can be sent in multiple OSPF TE LSAs. The
473c473
<    into multiple LSA instances each containing a disjoint assembly of
---
>    into multiple OSPF TE LSAs each containing a disjoint assembly of

     Additionally, I'd add RFC 5250 as at least a informative reference.
    
    

   4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
       "GMPLS OSPF Enhancement..." since you are not really enhancing base 
       OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
       this distinction. 


Thanks,
Acee 


  
On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

> Hi,
> 
> This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance
technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples
given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft
discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to
avoid fragmentation. 
> 
> Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 
> 
> Regards,
> Young
> 
> 
> 
> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf 
> Of internet-drafts <at> ietf.org
> Sent: Thursday, September 08, 2011 5:16 PM
> To: i-d-announce <at> ietf.org
> Cc: ccamp <at> ietf.org
> Subject: [CCAMP] I-D Action: 
> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 	Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                          Greg M. Bernstein
> 	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 	Pages           : 14
> 	Date            : 2011-09-08
> 
>   This document provides GMPLS OSPF routing enhancements to support
>   signal compatibility constraints associated with WSON network
>   elements. These routing enhancements are required in common optical
>   or hybrid electro-optical networks where not all of the optical
>   signals in the network are compatible with all network elements
>   participating in the network.
> 
>   This compatibility constraint model is applicable to common optical
>   or hybrid electro optical systems such as OEO switches, regenerators,
>   and wavelength converters since such systems can be limited to
>   processing only certain types of WSON signals.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

> tibility-ospf-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat
> ibility-ospf-05.txt _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp


_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : OSPF-TE Extensions for General Network Element Constraints
	Author(s)       : Fatai Zhang
                          Young Lee
                          Jianrui Han
                          Greg Bernstein
                          Yunbin Xu
	Filename        : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt
	Pages           : 12
	Date            : 2011-09-13

   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies including packet switching (e.g., MPLS),
   time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
   spatial switching (e.g., incoming port or fiber to outgoing port or
   fiber). In some of these technologies network elements and links may
   impose additional routing constraints such as asymmetric switch
   connectivity, non-local label assignment, and label range limitations
   on links. This document describes OSPF routing protocol extensions to
   support these kinds of constraints under the control of Generalized
   MPLS (GMPLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp