Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samasung LCD 19"

From: "[email-masked]" <[email-masked]>
Date: Mon, 1 Sep 2008 02:37:06 +0200

COMPUTADORAS con 1 A�O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL
ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA
CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIOR. CONSULTE
FACTURA A o B
CEL: 15-3197-5821
EMail: [email-masked]

-Modelo: CORE 2 DUO
-Procesador: E7200 CORE DUO 2.53 3MB cache 775 BOX 3 a�os de garantia
-Motherboard: Asus P5GC-MX Socket 775 BOX 
-Memoria: DDR2 2GB 667MHZ
-Placa de video: PCI-E 512MB NX8400GS-TD256E MSI
-Disco r�gido: 250GB SATA 2
-Medio optico: ReGrabadora de DVD PHILIPS 20X
-Placa de red: 10/100 integrada
-Placa de sonido: 6 canales
-Puertos: 2USB frontales y 4USB traseros
-Gabinete: SENTEY ATX c2 coolers fuente 500W
-Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2
-Garantia equipo 12 meses
-Sistema operativo instalado y funcionando FULL, todos los programas y utilidades
-Monitor: LCD 19" Samsung 943NWX 3 a�os de garantia
-PRECIO $2499 FINAL (IVA inc)

Consulte otras configuraciones a medida, notebooks, camaras digitales y mucho mas

Delivery-date: Fri, 29 Aug 2008 19:14:21 +0000
Date: Fri, 29 Aug 2008 12:10:13 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-575769772-1220037013=:22737
Content-Type: text/plain; charset=us-ascii

Are you calling me silly? Are you coming to Minneapolis? :=)

Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability:
a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s);
b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process.

In my opinion this is exactly what is needed for the OSPF-based L1VPN application.

Igor

----- Original Message ----
From: "Drake, John E" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Friday, August 29, 2008 2:31:36 PM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

So you are proposing an OSPF route reflector?  At what point does the
silliness stop? 

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: Friday, August 29, 2008 11:29 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Hi John,
>
>No, not really. When you add a PE you configure local 
>interfaces, local VPN port mappings, stuff like that. While 
>doing this you will also configure an IPinIP tunnel to one of 
>your spoke Ps and enable L1VPN OSPF instance on the tunnel. 
>Once you did that the local VPN information will be flooded 
>accross the overlay, likewise, the new PE will get all the 
>necessary information from other PEs.
>
>Cheers,
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Friday, August 29, 2008 11:20:16 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Igor,
>
>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
>added to a given L1VPN?
>
>Thanks,
>
>John 
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 5:51 AM
>>To: Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Yakov,
>>
>>You said:
>>
>>
>>... And while on the subject of scaling, please keep in mind that BGP 
>>only stores L1VPN routes on PEs that have sites of that VPN connected 
>>to them, and on an RR if used, but *not* on any of the P routers. In 
>>contrast, rfc5252 (OSPF for L1VPN
>>autodiscovery) results in storing *all VPN TE information for all the 
>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
>>approach scales better than OSPF-based approach.
>>
>>Yakov.
>>
>>This is not true in case of multi-instance OSPF: one can build an 
>>overlay interconnecting PEs via one or small number of Ps 
>using IPinIP 
>>tunnels and run in this overlay an instance of OSPF specifically 
>>designated for distribution of L1VPN information. In this 
>case the OSPF 
>>solution won't scale any worse than the BGP approach. Note. 
>that rfc252 
>>never said that the instance of OSPF used for flooding of the L1VPN 
>>information must be the same instance that is used for the 
>distribution 
>>of IP-related LSAs.
>>
>>Regards,
>>Igor
>>
>>
>>
>>
>
>
>
>

--0-575769772-1220037013=:22737
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Are you calling me silly? Are you coming to Minneapolis? :=)<br><br>Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability:<br>a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s);<br>b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process.<br><br>In my opinion this is exactly what is needed for the OSPF-based L1VPN application.<br><br>Igor<br><br><br><br><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message
 ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Friday, August 29, 2008 2:31:36 PM<br>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
So you are proposing an OSPF route reflector?&nbsp; At what point does the<br>silliness stop? <br><br>&gt;-----Original Message-----<br>&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;No, not really. When you add a PE you configure local <br>&gt;interfaces, local VPN port mappings, stuff like that. While <br>&gt;doing this you will also configure an IPinIP tunnel to one of <br>&gt;your spoke Ps and enable L1VPN
 OSPF instance on the tunnel. <br>&gt;Once you did that the local VPN information will be flooded <br>&gt;accross the overlay, likewise, the new PE will get all the <br>&gt;necessary information from other PEs.<br>&gt;<br>&gt;Cheers,<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original Message ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to a given L1VPN?<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <br>&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Yakov,<br>&gt;&gt;<br>&gt;&gt;You said:<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;... And while on the subject of scaling, please keep in mind that BGP <br>&gt;&gt;only stores L1VPN routes on PEs that have sites of that VPN connected <br>&gt;&gt;to them, and on an RR if used, but *not* on any of the P routers. In <br>&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;autodiscovery) results in storing *all VPN TE information for all the <br>&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt;&gt;approach scales better than OSPF-based approach.<br>&gt;&gt;<br>&gt;&gt;Yakov.<br>&gt;&gt;<br>&gt;&gt;This is not true in case of multi-instance OSPF:
 one can build an <br>&gt;&gt;overlay interconnecting PEs via one or small number of Ps <br>&gt;using IPinIP <br>&gt;&gt;tunnels and run in this overlay an instance of OSPF specifically <br>&gt;&gt;designated for distribution of L1VPN information. In this <br>&gt;case the OSPF <br>&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt;that rfc252 <br>&gt;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&gt;&gt;information must be the same instance that is used for the <br>&gt;distribution <br>&gt;&gt;of IP-related LSAs.<br>&gt;&gt;<br>&gt;&gt;Regards,<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br></div></div></div><br>

      </body></html>
--0-575769772-1220037013=:22737--

Delivery-date: Fri, 29 Aug 2008 18:35:51 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Fri, 29 Aug 2008 11:31:36 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

So you are proposing an OSPF route reflector?  At what point does the
silliness stop?=20

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]=20
>Sent: Friday, August 29, 2008 11:29 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Hi John,
>
>No, not really. When you add a PE you configure local=20
>interfaces, local VPN port mappings, stuff like that. While=20
>doing this you will also configure an IPinIP tunnel to one of=20
>your spoke Ps and enable L1VPN OSPF instance on the tunnel.=20
>Once you did that the local VPN information will be flooded=20
>accross the overlay, likewise, the new PE will get all the=20
>necessary information from other PEs.
>
>Cheers,
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Friday, August 29, 2008 11:20:16 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Igor,
>
>Doesn't this defeat auto-discovery?  I.e., how is a new PE=20
>added to a given L1VPN?
>
>Thanks,
>
>John=20
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 5:51 AM
>>To: Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Yakov,
>>
>>You said:
>>
>>
>>... And while on the subject of scaling, please keep in mind that BGP=20
>>only stores L1VPN routes on PEs that have sites of that VPN connected=20
>>to them, and on an RR if used, but *not* on any of the P routers. In=20
>>contrast, rfc5252 (OSPF for L1VPN
>>autodiscovery) results in storing *all VPN TE information for all the=20
>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20
>>approach scales better than OSPF-based approach.
>>
>>Yakov.
>>
>>This is not true in case of multi-instance OSPF: one can build an=20
>>overlay interconnecting PEs via one or small number of Ps=20
>using IPinIP=20
>>tunnels and run in this overlay an instance of OSPF specifically=20
>>designated for distribution of L1VPN information. In this=20
>case the OSPF=20
>>solution won't scale any worse than the BGP approach. Note.=20
>that rfc252=20
>>never said that the instance of OSPF used for flooding of the L1VPN=20
>>information must be the same instance that is used for the=20
>distribution=20
>>of IP-related LSAs.
>>
>>Regards,
>>Igor
>>
>>
>>
>>
>
>
>
>

Delivery-date: Fri, 29 Aug 2008 18:32:20 +0000
Date: Fri, 29 Aug 2008 11:28:38 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-763070498-1220034518=:96489
Content-Type: text/plain; charset=us-ascii

Hi John,

No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs.

Cheers,
Igor

----- Original Message ----
From: "Drake, John E" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Friday, August 29, 2008 11:20:16 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a
given L1VPN?

Thanks,

John 

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: Friday, August 29, 2008 5:51 AM
>To: Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Yakov,
>
>You said:
>
>
>... And while on the subject of scaling, please keep in mind 
>that BGP only stores L1VPN routes on PEs that have sites of 
>that VPN connected to them, and on an RR if used, but *not* on 
>any of the P routers. In contrast, rfc5252 (OSPF for L1VPN 
>autodiscovery) results in storing *all VPN TE information for 
>all the VPNs* on *all* the IGP nodes, both P and PE. So, 
>clearly BGP-based approach scales better than OSPF-based approach.
>
>Yakov.
>
>This is not true in case of multi-instance OSPF: one can build 
>an overlay interconnecting PEs via one or small number of Ps 
>using IPinIP tunnels and run in this overlay an instance of 
>OSPF specifically designated for distribution of L1VPN 
>information. In this case the OSPF solution won't scale any 
>worse than the BGP approach. Note. that rfc252 never said that 
>the instance of OSPF used for flooding of the L1VPN 
>information must be the same instance that is used for the 
>distribution of IP-related LSAs.
>
>Regards,
>Igor
>
>
>
>

--0-763070498-1220034518=:96489
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Hi John,<br><br>No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs.<br><br>Cheers,<br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]&gt;; Lou Berger
 &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Friday, August 29, 2008 11:20:16 AM<br>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
Igor,<br><br>Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE added to a<br>given L1VPN?<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt;To: Yakov Rekhter; Lou Berger<br>&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Yakov,<br>&gt;<br>&gt;You said:<br>&gt;<br>&gt;<br>&gt;... And while on the subject of scaling, please keep in mind <br>&gt;that BGP only stores L1VPN routes on PEs that have sites of <br>&gt;that VPN connected to them, and on an RR
 if used, but *not* on <br>&gt;any of the P routers. In contrast, rfc5252 (OSPF for L1VPN <br>&gt;autodiscovery) results in storing *all VPN TE information for <br>&gt;all the VPNs* on *all* the IGP nodes, both P and PE. So, <br>&gt;clearly BGP-based approach scales better than OSPF-based approach.<br>&gt;<br>&gt;Yakov.<br>&gt;<br>&gt;This is not true in case of multi-instance OSPF: one can build <br>&gt;an overlay interconnecting PEs via one or small number of Ps <br>&gt;using IPinIP tunnels and run in this overlay an instance of <br>&gt;OSPF specifically designated for distribution of L1VPN <br>&gt;information. In this case the OSPF solution won't scale any <br>&gt;worse than the BGP approach. Note. that rfc252 never said that <br>&gt;the instance of OSPF used for flooding of the L1VPN <br>&gt;information must be the same instance that is used for the <br>&gt;distribution of IP-related
 LSAs.<br>&gt;<br>&gt;Regards,<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>

      </body></html>
--0-763070498-1220034518=:96489--

Delivery-date: Fri, 29 Aug 2008 18:15:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ross Callon" <[email-masked]>, <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Draft response to ITU-T on VCAT
Date: Fri, 29 Aug 2008 19:10:40 +0100

Hi CCAMP,

We have a liaison to respond to from the ITU-T on VCAT 
(https://datatracker.ietf.org/liaison/429/).

Please a draft response below.
Comments to me by Friday September 5.

Thanks,
Adrian

=====

The IETF CCAMP working group thanks you for your liaison on GMPLS control of 
VCAT/LCAS dated February 1st 2008, and received February 29th.

Please find our responses in line.

> Here are our comments to the responses provided in your liaison:
>
> a) Regarding your response to Question 1 on protocol
>    extensibility to encompass technologies other than
>    SONET/SDH, we notice that the recent I-D
>    (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the
>    number of VCGs per call to one. We support this
>    position and consider this to be a VCAT call.

Thank you. Your support is noted.

> b) Regarding your response to Question 4 on multiple calls
>    support, VCAT is viewed as a layer of its own and has its
>    own call controller.
>    As per the interlayer architecture in G.8080 section 6.6,
>    the VCAT call would be associated with a server layer call
>    or calls, each of which would have/own one or more server
>    layer connections.  It is these connections that are part of the
>    VCG. In retrospect, a single call is sufficient for diverse
>    routing as it can hold details of both connections so that they
>    don't use the same resources.
>    An example where multiple server calls associated with one
>    VCAT call would be useful is when all VCAT connections
>    are to be protected.
>    Here, rather than one call maintain the knowledge of all
>    working/protection pairs, it is simpler to have multiple calls
>    each of which only maintains one working/protection pair.
>    This is even more convenient when restoration behavior is
>    applied when the protection connection fails.

We note that in a functional architecture it makes good sense to separate 
the VCAT layer from the server/protection layer. We also observe that the 
protocol solution does not need to be tied rigidly to the functional 
architecture where optimizations may be made from collapsing layers into a 
single set of protocol exchanges.

> c) Regarding your response to Question 6 on IP address format in
>    GMPLS, we suggest the I-D clarifies that there are different name
>    (or identifier) spaces even though they may all use the same IP
>    address format, e.g.
>    - Control component
>      The identifiers used to identify the entities that perform the 
> control
>      plane functions, such as route computation, signaling, control plane
>      message delivering, etc.
>    - Transport resource
>      The identifiers used to identify transport resource when they are
>      referred to in the control plane messages. Note that these 
> identifiers
>      may not be the same as those referred to in the management plane
>      messages.
>    - SCN
>      The addresses used to deliver control plane messages
>
>    Examples of a similar address format in use in two different name
>    spaces can be seen in the OSPF routing protocol, where router ID
>    (control and transport link scope) and IP address (used by the
>    forwarder) do not have to be the same.

While we understand that these distinctions are not clear from reading this 
particular Internet-Draft, we believe that the distinction is clear from the 
weight of GMPLS RFCs. However, we thank you for pointing out that further 
clarity could be achieved, and will look at ways to add text to this 
document.

The CCAMP working group is currently entering the final phase of work on 
this topic. The current version of the draft can be seen at 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt 
and we would welcome any final input from ITU-T SG15 before we complete the 
publication process. With that in mind, we invite you to review this 
document and send us any comments before our November meeting. The response 
date to this liaison is set accordingly.

Delivery-date: Fri, 29 Aug 2008 16:34:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Comments on ITU's Work Plan for Optical Transport Networks
Date: Fri, 29 Aug 2008 17:29:50 +0100

Hi,

We received a liaison back in February 
(https://datatracker.ietf.org/liaison/425/) asking for our comments on ITU-T 
Study Group 15's "Optical Transport Networks & Technologies Standardization 
Work Plan" (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html)

Please let me know by Friday September 5th if you have any comments you 
would like us to make. If I don't receive anything, I will send a response 
to thank them for keeping us informed and asking them to share any future 
work plans with us.

Thanks,
Adrian 

Delivery-date: Fri, 29 Aug 2008 15:24:41 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Fri, 29 Aug 2008 08:20:16 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Igor,

Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a
given L1VPN?

Thanks,

John=20

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]=20
>Sent: Friday, August 29, 2008 5:51 AM
>To: Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Yakov,
>
>You said:
>
>
>... And while on the subject of scaling, please keep in mind=20
>that BGP only stores L1VPN routes on PEs that have sites of=20
>that VPN connected to them, and on an RR if used, but *not* on=20
>any of the P routers. In contrast, rfc5252 (OSPF for L1VPN=20
>autodiscovery) results in storing *all VPN TE information for=20
>all the VPNs* on *all* the IGP nodes, both P and PE. So,=20
>clearly BGP-based approach scales better than OSPF-based approach.
>
>Yakov.
>
>This is not true in case of multi-instance OSPF: one can build=20
>an overlay interconnecting PEs via one or small number of Ps=20
>using IPinIP tunnels and run in this overlay an instance of=20
>OSPF specifically designated for distribution of L1VPN=20
>information. In this case the OSPF solution won't scale any=20
>worse than the BGP approach. Note. that rfc252 never said that=20
>the instance of OSPF used for flooding of the L1VPN=20
>information must be the same instance that is used for the=20
>distribution of IP-related LSAs.
>
>Regards,
>Igor
>
>
>
>

Delivery-date: Fri, 29 Aug 2008 13:40:08 +0000
Date: Fri, 29 Aug 2008 09:35:41 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Adrian Farrel <[email-masked]>, [email-masked],[email-masked]

Yakov,
         See below.

At 07:47 PM 8/28/2008, Yakov Rekhter wrote:
>Lou,
>
> > Yakov,
> >          see below.
> >
> > At 12:00 PM 8/28/2008, Yakov Rekhter wrote:
> > >Lou,
> > >
> > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> > > > >Lou,
> > > > >
> > > > > > If you drop the "unless they share identical Traffic Engineering
> > > > > > Attributes" then we have alignment.
> > > > >
> > > > >If they do share identical TE attributes, then there is no
> > > > >problem  to aggregate such routes. So, the current text is correct.
> > > > >
> > > > >Yakov.
> > > >
> > > > I think you need some additional semantic and aggregation function
> > > > definition if you want to aggregate. (For example: Does the TE
> > > > aggregate represent the resources available to *each* route or to
> > > > *all* the routes?  If the latter, what's the distribution function?)
> > >
> > >Constructing BGP TE attribute when aggregating routes with identical
> > >BGP TE attributes follows procedure of rfc4201.
> >
> > ahh, that wasn't obvious.  Need some specific language to that effect.
>
>Sure. To make it obvious I'll add the following:
>
>   Constructing BGP TE attribute when aggregating routes with identical
>   BGP TE attributes follows procedure of rfc4201.

great.

>
> > > > Also I think some discussion on impact on scaling is
> > > > warranted.  (consider the case where each <PPI, CPI> tuple from a PE
> > > > now needs it's own advisement due to dissimilar TE 
> information per port.)
> > >
> > >As I said before, the granularity of L1VPN auto-discovery advertisements
> > >is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
> > >forms its own route anyway.
> >
> > Sure, but as the doc says more than one NLRI can be included in a
> > MP_REACH_NLRI  attribute.
>
>That does not change the number of routes that PEs and RRs have
>to maintain.

sure, but there's potential for significant impact on number/size of 
advertisements and corresponding processing.

> > >And while on the subject of scaling, please keep in mind that BGP
> > >only stores L1VPN routes on PEs that have sites of that VPN connected
> > >to them, and on an RR if used, but *not* on any of the P routers. In
> > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
> > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
> > >and PE. So, clearly BGP-based approach scales better than OSPF-based
> > >approach.
> >
> > sure this is made clear in the l1vpn document.  What isn't made clear
> > is that, per this document, when TE attributes cannot be aggregated,
> > each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and*
> > advertisement.
>
>It would be quite clear if you would read base BGP spec (which is
>quoted as a Normative Refence in this document). Quoting Section
>3.1 of BGP spec (rfc4271):
>
>    Multiple routes that have the same path attributes can be advertised
>    in a single UPDATE message by including multiple prefixes in the NLRI
>    field of the UPDATE message.

I believe it is both worthwhile and appropriate to discuss how this 
draft impacts/relates to scaling.  In essence, I'm suggesting a 
similar/parallel to section 5 of rfc 5195.  (which also states things 
that are "quite clear if you would read" BGP specs.)

Lou

>Yakov.

Delivery-date: Fri, 29 Aug 2008 12:56:38 +0000
Date: Fri, 29 Aug 2008 05:50:49 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-1589213789-1220014249=:41469
Content-Type: text/plain; charset=us-ascii

Yakov,

You said:

... And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.

This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs.

Regards,
Igor

--0-1589213789-1220014249=:41469
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Yakov,<br><br>You said:<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><br>... And while on the subject of scaling, please keep in mind that BGP<br>only stores L1VPN routes on PEs that have sites of that VPN connected<br>to them, and on an RR if used, but *not* on any of the P routers. In<br>contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing<br>*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P<br>and PE. So, clearly BGP-based approach scales better than OSPF-based<br>approach.<br><br>Yakov.<br><br>This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels
 and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs.<br><br>Regards,<br>Igor<br><br></div></div></div><br>

      </body></html>
--0-1589213789-1220014249=:41469--

Delivery-date: Fri, 29 Aug 2008 11:59:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Greg Bernstein" <[email-masked]>
Subject: RWA Info model as WG I-D
Date: Fri, 29 Aug 2008 12:48:22 +0100

Hi,

I heard no objections to this.

Authors, please submit as draft-ietf-ccamp-rwa-info-00.txt

(Note the subtle change in file name)

Please run I-D nits (http://tools.ietf.org/tools/idnits/) and clean up 
before submission.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 05, 2008 5:24 PM
Subject: Poll for RWA Info model as WG I-D

> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed 
> to be pretty mature.
>
> Note that despite the file name, the content of this document is 
> consistent with its title: "Routing and Wavelength Assignment Information 
> Model for Wavelength Switched Optical Networks." That is, the scope is 
> limited to the information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready to be 
> adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
> 

Delivery-date: Fri, 29 Aug 2008 09:12:52 +0000
Date: Fri, 29 Aug 2008 11:07:58 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel-Lucent
To: Diego Caviglia <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was  MPLS over OTN)

This is a multi-part message in MIME format.
--------------060808090408050600000300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
... resent this mail because it did not appear on the mailing lists <span
 class="moz-smiley-s2"><span> :-( </span></span>.<br>
<br>
<font face="Trebuchet MS">Hi Diego,<br>
<br>
</font><br>
Diego Caviglia wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Stewart,
           I think i agree here.

Even if i'm coming from sdh i don'e see the need to hane osi capability
in brand new mpls-tp boxes.
  </pre>
</blockquote>
I actually do not fully agree here. If, due to historical reasons, the
existing DCN<br>
is an OSI network and if the new MPLS-TP boxes will only understand IP
and have<br>
to use the existing OSI-based DCN, then the new MPLS-TP boxes need to
support<br>
at least tunneling of IP over CLNP tunnels. Otherwise, a dual stack DCN
would<br>
indeed be needed (I am assuming here that the existing OSI-only DCN
cannot be<br>
turned into an IP-only DCN).<br>
<br>
<br>
Cheers,<br>
Dieter<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Br

Diego

  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta content="text/html;" http-equiv="Content-Type">
<title></title>
<hr size="2" width="100%">
</div>
<br>
<div class="moz-signature">-- <br>
<meta content="text/html;" http-equiv="Content-Type">
<title></title>
<hr size="2" width="100%">
</div>
</body>
</html>

--------------060808090408050600000300
Content-Type: text/x-vcard; charset=utf-8;
 name="D_Beller.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="D_Beller.vcf"

begin:vcard
fn:Dieter Beller
n:Beller;Dieter
org:Alcatel-Lucent, Carrier Business Group;Optics Division - Network & Product Strategy
adr:;;Lorenzstrasse 10;Stuttgart;;70435;Germany
email;internet:[email-masked]
tel;work:+49 711 821-43125
tel;cell:+49 175 7266874
note;quoted-printable:Alcatel-Lucent Deutschland AG:=0D=0A=
	=0D=0A=
	Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026=0D=0A=
	Vorsitzender des Aufsichtsrats: Michael Oppenhoff=0D=0A=
	Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger,Al=
	f Henryk Wulf
x-mozilla-html:TRUE
version:2.1
end:vcard

--------------060808090408050600000300--

Delivery-date: Thu, 28 Aug 2008 23:54:10 +0000
To: Lou Berger <[email-masked]>
cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Thu, 28 Aug 2008 16:47:57 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> Yakov,
>          see below.
> 
> At 12:00 PM 8/28/2008, Yakov Rekhter wrote:
> >Lou,
> >
> > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> > > >Lou,
> > > >
> > > > > If you drop the "unless they share identical Traffic Engineering
> > > > > Attributes" then we have alignment.
> > > >
> > > >If they do share identical TE attributes, then there is no
> > > >problem  to aggregate such routes. So, the current text is correct.
> > > >
> > > >Yakov.
> > >
> > > I think you need some additional semantic and aggregation function
> > > definition if you want to aggregate. (For example: Does the TE
> > > aggregate represent the resources available to *each* route or to
> > > *all* the routes?  If the latter, what's the distribution function?)
> >
> >Constructing BGP TE attribute when aggregating routes with identical
> >BGP TE attributes follows procedure of rfc4201.
> 
> ahh, that wasn't obvious.  Need some specific language to that effect.

Sure. To make it obvious I'll add the following:

  Constructing BGP TE attribute when aggregating routes with identical
  BGP TE attributes follows procedure of rfc4201.
  
> > > Also I think some discussion on impact on scaling is
> > > warranted.  (consider the case where each <PPI, CPI> tuple from a PE
> > > now needs it's own advisement due to dissimilar TE information per port.)
> >
> >As I said before, the granularity of L1VPN auto-discovery advertisements
> >is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
> >forms its own route anyway.
> 
> Sure, but as the doc says more than one NLRI can be included in a 
> MP_REACH_NLRI  attribute.

That does not change the number of routes that PEs and RRs have
to maintain. 

> >And while on the subject of scaling, please keep in mind that BGP
> >only stores L1VPN routes on PEs that have sites of that VPN connected
> >to them, and on an RR if used, but *not* on any of the P routers. In
> >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
> >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
> >and PE. So, clearly BGP-based approach scales better than OSPF-based
> >approach.
> 
> sure this is made clear in the l1vpn document.  What isn't made clear 
> is that, per this document, when TE attributes cannot be aggregated, 
> each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and* 
> advertisement.

It would be quite clear if you would read base BGP spec (which is
quoted as a Normative Refence in this document). Quoting Section 
3.1 of BGP spec (rfc4271):

   Multiple routes that have the same path attributes can be advertised
   in a single UPDATE message by including multiple prefixes in the NLRI
   field of the UPDATE message.

Yakov.

Delivery-date: Thu, 28 Aug 2008 18:33:47 +0000
Date: Thu, 28 Aug 2008 14:29:25 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>,[email-masked], [email-masked]

Yakov,
         see below.

At 12:00 PM 8/28/2008, Yakov Rekhter wrote:
>Lou,
>
> > At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> > >Lou,
> > >
> > > > If you drop the "unless they share identical Traffic Engineering
> > > > Attributes" then we have alignment.
> > >
> > >If they do share identical TE attributes, then there is no
> > >problem  to aggregate such routes. So, the current text is correct.
> > >
> > >Yakov.
> >
> > I think you need some additional semantic and aggregation function
> > definition if you want to aggregate. (For example: Does the TE
> > aggregate represent the resources available to *each* route or to
> > *all* the routes?  If the latter, what's the distribution function?)
>
>Constructing BGP TE attribute when aggregating routes with identical
>BGP TE attributes follows procedure of rfc4201.

ahh, that wasn't obvious.  Need some specific language to that effect.

> > Also I think some discussion on impact on scaling is
> > warranted.  (consider the case where each <PPI, CPI> tuple from a PE
> > now needs it's own advisement due to dissimilar TE information per port.)
>
>As I said before, the granularity of L1VPN auto-discovery advertisements
>is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
>forms its own route anyway.

Sure, but as the doc says more than on NLRI can be included in a 
MP_REACH_NLRI  attribute.

>And while on the subject of scaling, please keep in mind that BGP
>only stores L1VPN routes on PEs that have sites of that VPN connected
>to them, and on an RR if used, but *not* on any of the P routers. In
>contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
>*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
>and PE. So, clearly BGP-based approach scales better than OSPF-based
>approach.

sure this is made clear in the l1vpn document.  What isn't made clear 
is that, per this document, when TE attributes cannot be aggregated, 
each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and* 
advertisement.

Lou

>Yakov.

Delivery-date: Thu, 28 Aug 2008 18:09:42 +0000
To: Lou Berger <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Thu, 28 Aug 2008 09:00:05 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> >Lou,
> >
> > > If you drop the "unless they share identical Traffic Engineering
> > > Attributes" then we have alignment.
> >
> >If they do share identical TE attributes, then there is no
> >problem  to aggregate such routes. So, the current text is correct.
> >
> >Yakov.
> 
> I think you need some additional semantic and aggregation function 
> definition if you want to aggregate. (For example: Does the TE 
> aggregate represent the resources available to *each* route or to 
> *all* the routes?  If the latter, what's the distribution function?)

Constructing BGP TE attribute when aggregating routes with identical 
BGP TE attributes follows procedure of rfc4201.

> Also I think some discussion on impact on scaling is 
> warranted.  (consider the case where each <PPI, CPI> tuple from a PE 
> now needs it's own advisement due to dissimilar TE information per port.)

As I said before, the granularity of L1VPN auto-discovery advertisements
is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
forms its own route anyway.

And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.

Delivery-date: Thu, 28 Aug 2008 08:59:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: RFC 5284 on User-Defined Errors for RSVP
Date: Thu, 28 Aug 2008 09:49:24 +0100

Hi,

FYI

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 28, 2008 12:27 AM
Subject: RFC 5284 on User-Defined Errors for RSVP

> A new Request for Comments is now available in online RFC libraries.
>
>        RFC 5284
>
>        Title:      User-Defined Errors for RSVP
>        Author:     G. Swallow, A. Farrel
>        Status:     Standards Track
>        Date:       August 2008
>        Mailbox:    [email-masked],
>                    [email-masked]
>        Pages:      9
>        Characters: 17452
>        Updates/Obsoletes/SeeAlso:   None
>
>        I-D Tag:    draft-ietf-tsvwg-rsvp-user-error-spec-08.txt
>
>        URL:        http://www.rfc-editor.org/rfc/rfc5284.txt
>
> The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
> for communicating errors.  That object has a defined format that
> permits the definition of 256 error codes.  As RSVP has been
> developed and extended, the convention has been to be conservative in
> defining new error codes.  Further, no provision for user-defined
> errors exists in RSVP.
>
> This document defines a USER_ERROR_SPEC to be used in addition to the
> ERROR_SPEC to carry additional user information related to errors.
>
> This document is a product of the Transport Area Working Group Working 
> Group of the IETF.

Delivery-date: Wed, 27 Aug 2008 18:42:21 +0000
Date: Wed, 27 Aug 2008 14:40:14 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Adrian Farrel <[email-masked]>, [email-masked],[email-masked]

At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
>Lou,
>
> > If you drop the "unless they share identical Traffic Engineering
> > Attributes" then we have alignment.
>
>If they do share identical TE attributes, then there is no
>problem  to aggregate such routes. So, the current text is correct.
>
>Yakov.

I think you need some additional semantic and aggregation function 
definition if you want to aggregate. (For example: Does the TE 
aggregate represent the resources available to *each* route or to 
*all* the routes?  If the latter, what's the distribution function?)

Also I think some discussion on impact on scaling is 
warranted.  (consider the case where each <PPI, CPI> tuple from a PE 
now needs it's own advisement due to dissimilar TE information per port.)

Lou 

Delivery-date: Wed, 27 Aug 2008 17:22:21 +0000
To: "Adrian Farrel" <[email-masked]>
cc: "Don Fedyk" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG 
Date: Wed, 27 Aug 2008 09:05:40 -0700
From: Yakov Rekhter <[email-masked]>

Adrian,

> Hi Yakov,
> 
> You have answered my first question, within the limited scope of basic mode, 
> single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with 
> your interpretation.
> 
> This is good, and I support the use of this draft in that limited scenario, 
> and I suspect that the concept is extensible to any port-based VPN.
> 
> Will you be adding to the draft to say that this is the full extent of the 
> applicability of this draft (perhaps using RFC 2119 language)?
> 
> If not, then I'm afraid that my question stands. What will happen in the 
> case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE 
> links?

To address this I would propose to add the following to the Abstract
and Introduction:

    The scope and applicability of this protocol extension
    currently excludes its use for non-VPN deployment scenarios.

Yakov.

-
> Thanks,
> Adrian
> 
> >> >> 1. A CE is attached by parallel links to a single PE
> >> >>
> >> >>    Suppose the links have the same switching types, but
> >> >>    different bandwidths. Link-a has plenty of bandwidth
> >> >>    available with an MTU size of x. Link-b has not much
> >> >>    bandwidth available with an MTU size of y > x.
> >> >
> >> > Interface MTU is part of the PSC TE attributes in the our spec. If the
> >> > MTUs are different they should not be aggregated.
> >>
> >> Right. Aggregation in this case is hard to make representative of 
> >> reality.
> >>
> >> > Also In L1VPN (LSC and TDM) networks the Switching type
> >> > covers Switching granularity (which is like an MTU).
> >>
> >> Sure. But I wanted to keep in PSC, because that problem represents a 
> >> single
> >> layer network.
> >>
> >> > I'm trying to understand if you are saying the following text would
> >> > fix the problem or you see a larger issue:
> >> > "Therefore, such routes and the corresponding TE information
> >> > SHALL NOT be aggregated unless they share identical Traffic
> >> > Engineering Attributes".
> >>
> >> The question I am asking is - is the solution to this problem to 
> >> advertise
> >> two routes?  (Clearly two is a special case of many.)
> >>
> >> I don't believe that in the general (non-TE case) we would consider the 
> >> case
> >> of two parallel links between CE and PE as route aggregation. The PE 
> >> would
> >> simply advertise reachability (through itself) to the CE.
> >
> > Let's put the general (non-TE) case aside, and focus on the L1VPN
> > scenario.
> >
> > According to the bgp-auto-discovery and l1vpn-basic-mode drafts in
> > the context of L1VPN what is advertised in the BGP auto-discovery
> > information is the information about *ports*.  Therefore, in the
> > context of L1VPN TE information advertisements are associated with
> > individual *ports*, not with a particular CE.  Which means that if
> > a CE is connected to a PE by N ports, then the BGP auto-discovery
> > information has to advertise all these N ports, and associated with
> > each such advertisement may be the TE information.
> >
> >> Hence my question below.
> >>
> >> >>    Normally, we would expect the PE to advertise a single
> >> >>    piece of reachability information for the CE leaving
> >> >>    the actual choice of links to be made by the PE.
> >> >>
> >> >>    What would the PE advertise in this case?
> >> >>    - It cannot aggregate the TE information because that
> >> >>      would imply that there was lots of bandwidth at the
> >> >>      larger MTU size.
> >> >>    - It could include duplicate Switching Capability
> >> >>      Descriptors, but that would need some clarification as
> >> >>      duplicate descriptors are intended for different
> >> >>      switching caps in the IGP RFCs.
> >> >>    - It could advertise two pieces of reachability
> >> >>      information, but that would be a change to how the
> >> >>      implementation currently works.
> >
> > The answer to your question is that if the implementation follows
> > the spec, it would advertise information about *ports*.  So, if a
> > CE has two ports that connect it to a PE, then the PE originates
> > two L1VPN advertisements, one per port, each with its own TE
> > attribute.
> 

Delivery-date: Wed, 27 Aug 2008 16:16:01 +0000
To: Lou Berger <[email-masked]>
cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Wed, 27 Aug 2008 09:02:19 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> If you drop the "unless they share identical Traffic Engineering 
> Attributes" then we have alignment.

If they do share identical TE attributes, then there is no
problem  to aggregate such routes. So, the current text is correct.

Yakov.

> 
> Lou
> 
> At 09:50 AM 8/27/2008, Yakov Rekhter wrote:
> >Lou,
> >
> > > Why "SHOULD NOT" rather than "MUST NOT"?
> >
> >It is already there (Section 4):
> >
> >    Routes that carry the Traffic Engineering Attribute have additional
> >    semantics that could affect traffic forwarding behavior. Therefore,
> >    such routes SHALL NOT be aggregated unless they share identical
> >    Traffic Engineering Attributes.
> >
> >Yakov.
> >
> > >
> > > Lou
> > >
> > > At 06:51 AM 8/27/2008, Adrian Farrel wrote:
> > > >Hi again Yakov,
> > > >
> > > >Thanks also for the reply to my second question.
> > > >
> > > >Your answer seems to imply that the applicability of your work is strict
ly
> > > >limited to L1VPNs.
> > > >
> > > >If this is the case, we can easily close this discussion by adding text 
to
> > > >the Abstract and Introduction such as:
> > > >
> > > >   The scope and applicability of this protocol extension is
> > > >   currently limited to single-AS deployment scenarios of the
> > > >   basic mode of L1VPNs. Further applications are for
> > > >   future study, but these mechanisms SHOULD NOT be
> > > >   used in any attempt to support TE aggregation.
> > > >
> > > >Cheers,
> > > >Adrian
> > > >
> > > > >> 2. There is more than one AS
> > > > >>
> > > > >>    Consider
> > > > >>
> > > > >>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
> > > > >>
> > > > >>    PE2 advertises reachability to CE2 and includes TE
> > > > >>    information. The TE attribute is non-transitive so it is
> > > > >>    not just passed on, but ASBR2 wants to announce
> > > > >>    reachability to CE2 (in the VPN case, we may want to
> > > > >>    support a multi-AS VPN).
> > > > >>
> > > > >>    So ASBR2 can advertise reachability to CE2, but what TE
> > > >>    parameters does it advertise? The parameters for the
> > > > >>    link PE2-CE2 are not so helpful because the TE
> > > > >>    reachability across AS2 may be different. Yet any attempt
> > > > >>    to perform a computation of the TE reachability across
> > > > >>    AS2 (i.e. TE aggregation) is complex and potentially
> > > > >>    unstable. (Of course, if a tunnel is pre-established
> > > > >>    between ASBR2 and PE2 this is a different matter.)
> > > > >>
> > > > >> I think that these two different scenarios need attention
> > > > >> in the I-D.
> > > > >>
> > > > >> For the first one, it may just be a matter of indicating
> > > > >> which approach is to be used.
> > > > >>
> > > > >> For the second one, I hope the answer is to recommend
> > > > >> against any form of TE aggregation. This could easily be
> > > > >> added to section 4, and I would be happy to provide text.
> > > > >> BUT, it will still leave open the question about if and how
> > > > >> TE information is propagated beyond the AS.
> > > > >
> > > > > For the second one the answer is in rfc5251:
> > > > >
> > > > >   Consideration of inter-AS and inter-provider L1VPNs requires furthe
r
> > > > >   analysis beyond the scope of this document.
> > > >
> > > >_______________________________________________
> > > >Softwires mailing list
> > > >[email-masked]
> > > >https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> 
> 

Delivery-date: Wed, 27 Aug 2008 14:30:40 +0000
Date: Wed, 27 Aug 2008 10:29:15 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Adrian Farrel <[email-masked]>, [email-masked],[email-masked]

If you drop the "unless they share identical Traffic Engineering 
Attributes" then we have alignment.

Lou

At 09:50 AM 8/27/2008, Yakov Rekhter wrote:
>Lou,
>
> > Why "SHOULD NOT" rather than "MUST NOT"?
>
>It is already there (Section 4):
>
>    Routes that carry the Traffic Engineering Attribute have additional
>    semantics that could affect traffic forwarding behavior. Therefore,
>    such routes SHALL NOT be aggregated unless they share identical
>    Traffic Engineering Attributes.
>
>Yakov.
>
> >
> > Lou
> >
> > At 06:51 AM 8/27/2008, Adrian Farrel wrote:
> > >Hi again Yakov,
> > >
> > >Thanks also for the reply to my second question.
> > >
> > >Your answer seems to imply that the applicability of your work is strictly
> > >limited to L1VPNs.
> > >
> > >If this is the case, we can easily close this discussion by adding text to
> > >the Abstract and Introduction such as:
> > >
> > >   The scope and applicability of this protocol extension is
> > >   currently limited to single-AS deployment scenarios of the
> > >   basic mode of L1VPNs. Further applications are for
> > >   future study, but these mechanisms SHOULD NOT be
> > >   used in any attempt to support TE aggregation.
> > >
> > >Cheers,
> > >Adrian
> > >
> > > >> 2. There is more than one AS
> > > >>
> > > >>    Consider
> > > >>
> > > >>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
> > > >>
> > > >>    PE2 advertises reachability to CE2 and includes TE
> > > >>    information. The TE attribute is non-transitive so it is
> > > >>    not just passed on, but ASBR2 wants to announce
> > > >>    reachability to CE2 (in the VPN case, we may want to
> > > >>    support a multi-AS VPN).
> > > >>
> > > >>    So ASBR2 can advertise reachability to CE2, but what TE
> > > >>    parameters does it advertise? The parameters for the
> > > >>    link PE2-CE2 are not so helpful because the TE
> > > >>    reachability across AS2 may be different. Yet any attempt
> > > >>    to perform a computation of the TE reachability across
> > > >>    AS2 (i.e. TE aggregation) is complex and potentially
> > > >>    unstable. (Of course, if a tunnel is pre-established
> > > >>    between ASBR2 and PE2 this is a different matter.)
> > > >>
> > > >> I think that these two different scenarios need attention
> > > >> in the I-D.
> > > >>
> > > >> For the first one, it may just be a matter of indicating
> > > >> which approach is to be used.
> > > >>
> > > >> For the second one, I hope the answer is to recommend
> > > >> against any form of TE aggregation. This could easily be
> > > >> added to section 4, and I would be happy to provide text.
> > > >> BUT, it will still leave open the question about if and how
> > > >> TE information is propagated beyond the AS.
> > > >
> > > > For the second one the answer is in rfc5251:
> > > >
> > > >   Consideration of inter-AS and inter-provider L1VPNs requires further
> > > >   analysis beyond the scope of this document.
> > >
> > >_______________________________________________
> > >Softwires mailing list
> > >[email-masked]
> > >https://www.ietf.org/mailman/listinfo/softwires
> >
> >

Delivery-date: Wed, 27 Aug 2008 13:52:54 +0000
To: Lou Berger <[email-masked]>
cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Wed, 27 Aug 2008 06:50:28 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> Why "SHOULD NOT" rather than "MUST NOT"?

It is already there (Section 4):

   Routes that carry the Traffic Engineering Attribute have additional
   semantics that could affect traffic forwarding behavior. Therefore,
   such routes SHALL NOT be aggregated unless they share identical
   Traffic Engineering Attributes.

Yakov.

> 
> Lou
> 
> At 06:51 AM 8/27/2008, Adrian Farrel wrote:
> >Hi again Yakov,
> >
> >Thanks also for the reply to my second question.
> >
> >Your answer seems to imply that the applicability of your work is strictly
> >limited to L1VPNs.
> >
> >If this is the case, we can easily close this discussion by adding text to
> >the Abstract and Introduction such as:
> >
> >   The scope and applicability of this protocol extension is
> >   currently limited to single-AS deployment scenarios of the
> >   basic mode of L1VPNs. Further applications are for
> >   future study, but these mechanisms SHOULD NOT be
> >   used in any attempt to support TE aggregation.
> >
> >Cheers,
> >Adrian
> >
> > >> 2. There is more than one AS
> > >>
> > >>    Consider
> > >>
> > >>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
> > >>
> > >>    PE2 advertises reachability to CE2 and includes TE
> > >>    information. The TE attribute is non-transitive so it is
> > >>    not just passed on, but ASBR2 wants to announce
> > >>    reachability to CE2 (in the VPN case, we may want to
> > >>    support a multi-AS VPN).
> > >>
> > >>    So ASBR2 can advertise reachability to CE2, but what TE
> > >>    parameters does it advertise? The parameters for the
> > >>    link PE2-CE2 are not so helpful because the TE
> > >>    reachability across AS2 may be different. Yet any attempt
> > >>    to perform a computation of the TE reachability across
> > >>    AS2 (i.e. TE aggregation) is complex and potentially
> > >>    unstable. (Of course, if a tunnel is pre-established
> > >>    between ASBR2 and PE2 this is a different matter.)
> > >>
> > >> I think that these two different scenarios need attention
> > >> in the I-D.
> > >>
> > >> For the first one, it may just be a matter of indicating
> > >> which approach is to be used.
> > >>
> > >> For the second one, I hope the answer is to recommend
> > >> against any form of TE aggregation. This could easily be
> > >> added to section 4, and I would be happy to provide text.
> > >> BUT, it will still leave open the question about if and how
> > >> TE information is propagated beyond the AS.
> > >
> > > For the second one the answer is in rfc5251:
> > >
> > >   Consideration of inter-AS and inter-provider L1VPNs requires further
> > >   analysis beyond the scope of this document.
> >
> >_______________________________________________
> >Softwires mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/softwires
> 
> 

Delivery-date: Wed, 27 Aug 2008 13:32:14 +0000
Date: Wed, 27 Aug 2008 09:30:25 -0400
To: Adrian Farrel <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Cc: "Yakov Rekhter" <[email-masked]>,[email-masked], [email-masked]

Why "SHOULD NOT" rather than "MUST NOT"?

Lou

At 06:51 AM 8/27/2008, Adrian Farrel wrote:
>Hi again Yakov,
>
>Thanks also for the reply to my second question.
>
>Your answer seems to imply that the applicability of your work is strictly
>limited to L1VPNs.
>
>If this is the case, we can easily close this discussion by adding text to
>the Abstract and Introduction such as:
>
>   The scope and applicability of this protocol extension is
>   currently limited to single-AS deployment scenarios of the
>   basic mode of L1VPNs. Further applications are for
>   future study, but these mechanisms SHOULD NOT be
>   used in any attempt to support TE aggregation.
>
>Cheers,
>Adrian
>
> >> 2. There is more than one AS
> >>
> >>    Consider
> >>
> >>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
> >>
> >>    PE2 advertises reachability to CE2 and includes TE
> >>    information. The TE attribute is non-transitive so it is
> >>    not just passed on, but ASBR2 wants to announce
> >>    reachability to CE2 (in the VPN case, we may want to
> >>    support a multi-AS VPN).
> >>
> >>    So ASBR2 can advertise reachability to CE2, but what TE
> >>    parameters does it advertise? The parameters for the
> >>    link PE2-CE2 are not so helpful because the TE
> >>    reachability across AS2 may be different. Yet any attempt
> >>    to perform a computation of the TE reachability across
> >>    AS2 (i.e. TE aggregation) is complex and potentially
> >>    unstable. (Of course, if a tunnel is pre-established
> >>    between ASBR2 and PE2 this is a different matter.)
> >>
> >> I think that these two different scenarios need attention
> >> in the I-D.
> >>
> >> For the first one, it may just be a matter of indicating
> >> which approach is to be used.
> >>
> >> For the second one, I hope the answer is to recommend
> >> against any form of TE aggregation. This could easily be
> >> added to section 4, and I would be happy to provide text.
> >> BUT, it will still leave open the question about if and how
> >> TE information is propagated beyond the AS.
> >
> > For the second one the answer is in rfc5251:
> >
> >   Consideration of inter-AS and inter-provider L1VPNs requires further
> >   analysis beyond the scope of this document.
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

Delivery-date: Wed, 27 Aug 2008 10:54:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 27 Aug 2008 11:51:45 +0100

Hi again Yakov,

Thanks also for the reply to my second question.

Your answer seems to imply that the applicability of your work is strictly 
limited to L1VPNs.

If this is the case, we can easily close this discussion by adding text to 
the Abstract and Introduction such as:

  The scope and applicability of this protocol extension is
  currently limited to single-AS deployment scenarios of the
  basic mode of L1VPNs. Further applications are for
  future study, but these mechanisms SHOULD NOT be
  used in any attempt to support TE aggregation.

Cheers,
Adrian

>> 2. There is more than one AS
>>
>>    Consider
>>
>>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
>>
>>    PE2 advertises reachability to CE2 and includes TE
>>    information. The TE attribute is non-transitive so it is
>>    not just passed on, but ASBR2 wants to announce
>>    reachability to CE2 (in the VPN case, we may want to
>>    support a multi-AS VPN).
>>
>>    So ASBR2 can advertise reachability to CE2, but what TE
>>    parameters does it advertise? The parameters for the
>>    link PE2-CE2 are not so helpful because the TE
>>    reachability across AS2 may be different. Yet any attempt
>>    to perform a computation of the TE reachability across
>>    AS2 (i.e. TE aggregation) is complex and potentially
>>    unstable. (Of course, if a tunnel is pre-established
>>    between ASBR2 and PE2 this is a different matter.)
>>
>> I think that these two different scenarios need attention
>> in the I-D.
>>
>> For the first one, it may just be a matter of indicating
>> which approach is to be used.
>>
>> For the second one, I hope the answer is to recommend
>> against any form of TE aggregation. This could easily be
>> added to section 4, and I would be happy to provide text.
>> BUT, it will still leave open the question about if and how
>> TE information is propagated beyond the AS.
>
> For the second one the answer is in rfc5251:
>
>   Consideration of inter-AS and inter-provider L1VPNs requires further
>   analysis beyond the scope of this document.

Delivery-date: Wed, 27 Aug 2008 10:48:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG 
Date: Wed, 27 Aug 2008 11:46:26 +0100

Hi Yakov,

You have answered my first question, within the limited scope of basic mode, 
single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with 
your interpretation.

This is good, and I support the use of this draft in that limited scenario, 
and I suspect that the concept is extensible to any port-based VPN.

Will you be adding to the draft to say that this is the full extent of the 
applicability of this draft (perhaps using RFC 2119 language)?

If not, then I'm afraid that my question stands. What will happen in the 
case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE 
links?

Thanks,
Adrian

>> >> 1. A CE is attached by parallel links to a single PE
>> >>
>> >>    Suppose the links have the same switching types, but
>> >>    different bandwidths. Link-a has plenty of bandwidth
>> >>    available with an MTU size of x. Link-b has not much
>> >>    bandwidth available with an MTU size of y > x.
>> >
>> > Interface MTU is part of the PSC TE attributes in the our spec. If the
>> > MTUs are different they should not be aggregated.
>>
>> Right. Aggregation in this case is hard to make representative of 
>> reality.
>>
>> > Also In L1VPN (LSC and TDM) networks the Switching type
>> > covers Switching granularity (which is like an MTU).
>>
>> Sure. But I wanted to keep in PSC, because that problem represents a 
>> single
>> layer network.
>>
>> > I'm trying to understand if you are saying the following text would
>> > fix the problem or you see a larger issue:
>> > "Therefore, such routes and the corresponding TE information
>> > SHALL NOT be aggregated unless they share identical Traffic
>> > Engineering Attributes".
>>
>> The question I am asking is - is the solution to this problem to 
>> advertise
>> two routes?  (Clearly two is a special case of many.)
>>
>> I don't believe that in the general (non-TE case) we would consider the 
>> case
>> of two parallel links between CE and PE as route aggregation. The PE 
>> would
>> simply advertise reachability (through itself) to the CE.
>
> Let's put the general (non-TE) case aside, and focus on the L1VPN
> scenario.
>
> According to the bgp-auto-discovery and l1vpn-basic-mode drafts in
> the context of L1VPN what is advertised in the BGP auto-discovery
> information is the information about *ports*.  Therefore, in the
> context of L1VPN TE information advertisements are associated with
> individual *ports*, not with a particular CE.  Which means that if
> a CE is connected to a PE by N ports, then the BGP auto-discovery
> information has to advertise all these N ports, and associated with
> each such advertisement may be the TE information.
>
>> Hence my question below.
>>
>> >>    Normally, we would expect the PE to advertise a single
>> >>    piece of reachability information for the CE leaving
>> >>    the actual choice of links to be made by the PE.
>> >>
>> >>    What would the PE advertise in this case?
>> >>    - It cannot aggregate the TE information because that
>> >>      would imply that there was lots of bandwidth at the
>> >>      larger MTU size.
>> >>    - It could include duplicate Switching Capability
>> >>      Descriptors, but that would need some clarification as
>> >>      duplicate descriptors are intended for different
>> >>      switching caps in the IGP RFCs.
>> >>    - It could advertise two pieces of reachability
>> >>      information, but that would be a change to how the
>> >>      implementation currently works.
>
> The answer to your question is that if the implementation follows
> the spec, it would advertise information about *ports*.  So, if a
> CE has two ports that connect it to a PE, then the PE originates
> two L1VPN advertisements, one per port, each with its own TE
> attribute.

Delivery-date: Tue, 26 Aug 2008 13:01:35 +0000
To: "Adrian Farrel" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], "Yakov Rekhter" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG 
Date: Tue, 26 Aug 2008 05:54:19 -0700
From: Yakov Rekhter <[email-masked]>

Adrian,

> Hi,
> 
> > From: David Ward <[email-masked]> 
> > Sent: Tue Aug 12 23:48 
> > Subject: BGP TE attr last call by softwires WG 
> >
> > The softwire WG has LC'ed 
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-softwire-
> > bgp-te-attribute-01.txt 
> >
> > We will keep open an additional two-week period for wider
> > review before moving forward in the publication process. 
> > Please have any comments to the authors and softwires WG 
> > by Aug 26, 2008. 
> 
> I have no objection to the basic idea of distributing TE
> information about CE-PE links especially for use in VPNs. 
> But I am worried by one aspect of the document. Hopefully
> this is just an editorial issue.
> 
> The last call in Softwires appears to have generated some
> discussion about aggregation, and this led to the addition 
> of section 4.
> 
> | 4. Implication on aggregation
> |
> |    Routes that carry the Traffic Engineering Attribute 
> |    have additional semantics that could affect traffic 
> |    forwarding behavior. Therefore, such routes SHALL NOT 
> |    be aggregated unless they share identical Traffic
> |    Engineering Attributes.
> 
> As far as it goes, this paragraph is great. It says "do not
> perform route aggregation unless it is sensible to do so."
> 
> But it says nothing about TE aggregation.
> 
> Notwithstanding the TE attribute is non-transitive, there 
> is the potential for an implementation to believe that it
> should provide some form of TE aggregation.
> 
> Consider two cases:
> 
> 1. A CE is attached by parallel links to a single PE
> 
>    Suppose the links have the same switching types, but 
>    different bandwidths. Link-a has plenty of bandwidth
>    available with an MTU size of x. Link-b has not much
>    bandwidth available with an MTU size of y > x.
> 
>    Normally, we would expect the PE to advertise a single
>    piece of reachability information for the CE leaving
>    the actual choice of links to be made by the PE.
> 
>    What would the PE advertise in this case?
>    - It cannot aggregate the TE information because that
>      would imply that there was lots of bandwidth at the 
>      larger MTU size.
>    - It could include duplicate Switching Capability
>      Descriptors, but that would need some clarification as
>      duplicate descriptors are intended for different 
>      switching caps in the IGP RFCs.
>    - It could advertise two pieces of reachability
>      information, but that would be a change to how the
>      implementation currently works.

I already answered this in my other e-mail yesterday.

> 2. There is more than one AS
> 
>    Consider
> 
>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
> 
>    PE2 advertises reachability to CE2 and includes TE 
>    information. The TE attribute is non-transitive so it is
>    not just passed on, but ASBR2 wants to announce
>    reachability to CE2 (in the VPN case, we may want to 
>    support a multi-AS VPN).
> 
>    So ASBR2 can advertise reachability to CE2, but what TE
>    parameters does it advertise? The parameters for the 
>    link PE2-CE2 are not so helpful because the TE 
>    reachability across AS2 may be different. Yet any attempt
>    to perform a computation of the TE reachability across
>    AS2 (i.e. TE aggregation) is complex and potentially
>    unstable. (Of course, if a tunnel is pre-established
>    between ASBR2 and PE2 this is a different matter.)
> 
> 
> I think that these two different scenarios need attention
> in the I-D. 
> 
> For the first one, it may just be a matter of indicating 
> which approach is to be used.
> 
> For the second one, I hope the answer is to recommend 
> against any form of TE aggregation. This could easily be
> added to section 4, and I would be happy to provide text.
> BUT, it will still leave open the question about if and how
> TE information is propagated beyond the AS.

For the second one the answer is in rfc5251:

   Consideration of inter-AS and inter-provider L1VPNs requires further
   analysis beyond the scope of this document.

Yakov.

Delivery-date: Mon, 25 Aug 2008 18:18:40 +0000
To: "Adrian Farrel" <[email-masked]>
cc: "Don Fedyk" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG 
Date: Mon, 25 Aug 2008 11:14:15 -0700
From: Yakov Rekhter <[email-masked]>

Adrian,

> Hello Don,
> 
> Thanks for the response.
> 
> >> 1. A CE is attached by parallel links to a single PE
> >>
> >>    Suppose the links have the same switching types, but
> >>    different bandwidths. Link-a has plenty of bandwidth
> >>    available with an MTU size of x. Link-b has not much
> >>    bandwidth available with an MTU size of y > x.
> >
> > Interface MTU is part of the PSC TE attributes in the our spec. If the
> > MTUs are different they should not be aggregated.
> 
> Right. Aggregation in this case is hard to make representative of reality.
> 
> > Also In L1VPN (LSC and TDM) networks the Switching type
> > covers Switching granularity (which is like an MTU).
> 
> Sure. But I wanted to keep in PSC, because that problem represents a single 
> layer network.
> 
> > I'm trying to understand if you are saying the following text would
> > fix the problem or you see a larger issue:
> > "Therefore, such routes and the corresponding TE information
> > SHALL NOT be aggregated unless they share identical Traffic
> > Engineering Attributes".
> 
> The question I am asking is - is the solution to this problem to advertise 
> two routes?  (Clearly two is a special case of many.)
> 
> I don't believe that in the general (non-TE case) we would consider the case 
> of two parallel links between CE and PE as route aggregation. The PE would 
> simply advertise reachability (through itself) to the CE.

Let's put the general (non-TE) case aside, and focus on the L1VPN
scenario. 

According to the bgp-auto-discovery and l1vpn-basic-mode drafts in
the context of L1VPN what is advertised in the BGP auto-discovery
information is the information about *ports*.  Therefore, in the
context of L1VPN TE information advertisements are associated with
individual *ports*, not with a particular CE.  Which means that if
a CE is connected to a PE by N ports, then the BGP auto-discovery
information has to advertise all these N ports, and associated with
each such advertisement may be the TE information.

> Hence my question below.
> 
> >>    Normally, we would expect the PE to advertise a single
> >>    piece of reachability information for the CE leaving
> >>    the actual choice of links to be made by the PE.
> >>
> >>    What would the PE advertise in this case?
> >>    - It cannot aggregate the TE information because that
> >>      would imply that there was lots of bandwidth at the
> >>      larger MTU size.
> >>    - It could include duplicate Switching Capability
> >>      Descriptors, but that would need some clarification as
> >>      duplicate descriptors are intended for different
> >>      switching caps in the IGP RFCs.
> >>    - It could advertise two pieces of reachability
> >>      information, but that would be a change to how the
> >>      implementation currently works.

The answer to your question is that if the implementation follows
the spec, it would advertise information about *ports*.  So, if a
CE has two ports that connect it to a PE, then the PE originates
two L1VPN advertisements, one per port, each with its own TE
attribute.
  
Yakov.

Delivery-date: Mon, 25 Aug 2008 03:31:56 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-03.txt 
Date: Sun, 24 Aug 2008 20:30:01 -0700 (PDT)

--NextPart

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           : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-isis-interas-te-extension-03.txt
	Pages           : 20
	Date            : 2008-08-24

This document describes extensions to the ISIS (ISIS) protocol to 
support Multiprotocol Label Switching (MPLS) and Generalized MPLS 
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 
(ASes). It defines ISIS-TE extensions for the flooding of TE 
information about inter-AS links which can be used to perform inter-
AS TE path computation. 

 No support for flooding information from within one AS to another AS 
is proposed or defined in this document. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-03.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-isis-interas-te-extension-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 22 Aug 2008 15:49:15 +0000
Date: Fri, 22 Aug 2008 17:42:18 +0200
Subject: Re: BGP TE attr last call by softwires WG
From: JP Vasseur <[email-masked]>
To: Adrian Farrel <[email-masked]>, Don Fedyk <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, Yakov Rekhter <[email-masked]>, Hamid Ould-Brahim <[email-masked]>

Hi all,

I'd like to second Adrian's point here - see below.

On 8/22/08 1:18 AM, "Adrian Farrel" <[email-masked]> wrote:

> Hello Don,
> 
> Thanks for the response.
> 
>>> 1. A CE is attached by parallel links to a single PE
>>> 
>>>    Suppose the links have the same switching types, but
>>>    different bandwidths. Link-a has plenty of bandwidth
>>>    available with an MTU size of x. Link-b has not much
>>>    bandwidth available with an MTU size of y > x.
>> 
>> Interface MTU is part of the PSC TE attributes in the our spec. If the
>> MTUs are different they should not be aggregated.
> 
> Right.
> Aggregation in this case is hard to make representative of reality.

That is also my concern ... It would be really nice to clarify that TE
aggregation must be avoided.

> 
>> Also In L1VPN (LSC and TDM) networks the Switching type
>> covers Switching granularity (which is like an MTU).
> 
> Sure. But I wanted to keep in PSC, because that problem represents a single
> layer network.
> 
>> I'm trying to understand if you are saying the following text would
>> fix the problem or you see a larger issue:
>> "Therefore, such routes and the corresponding TE information
>> SHALL NOT be aggregated unless they share identical Traffic
>> Engineering Attributes".
> 
> The question I am asking is - is the solution to this problem to advertise
> two routes?
> (Clearly two is a special case of many.)
> 
> I don't believe that in the general (non-TE case) we would consider the case
> of two parallel links between CE and PE as route aggregation. The PE would
> simply advertise reachability (through itself) to the CE.
> 
> Hence my question below.
> 
>>>    Normally, we would expect the PE to advertise a single
>>>    piece of reachability information for the CE leaving
>>>    the actual choice of links to be made by the PE.
>>> 
>>>    What would the PE advertise in this case?
>>>    - It cannot aggregate the TE information because that
>>>      would imply that there was lots of bandwidth at the
>>>      larger MTU size.
>>>    - It could include duplicate Switching Capability
>>>      Descriptors, but that would need some clarification as
>>>      duplicate descriptors are intended for different
>>>      switching caps in the IGP RFCs.
>>>    - It could advertise two pieces of reachability
>>>      information, but that would be a change to how the
>>>      implementation currently works.
> 
>>> 2. There is more than one AS
> [SNIP]
>> I remember we discussed this aspect originally in the context of
>> L1VPNs and limited it to a single AS since L1VPNs Basic Mode
>> are limited to a single AS. I don't recall if we thought this was
>> applicable to a multi-AS solution.
>> 
>> We should clarify this point either way.
> 
> Thanks.
> I guess:
> - if applicable, how?
> - if not applicable, how prevent?
> 

Same question.

Thanks Don.

JP.

> Cheers,
> Adrian

Delivery-date: Fri, 22 Aug 2008 13:50:46 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt 
Date: Fri, 22 Aug 2008 09:47:16 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

In preparing the proto for publishing, I had several editorial comments
which this updated draft reflects.
Thanks Authors-
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, August 22, 2008 3:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt=20

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           : draft-ietf-ccamp-pc-and-sc-reqs-05.txt
	Author(s)       : D. Caviglia, et al.
	Filename        : draft-ietf-ccamp-pc-and-sc-reqs-05.txt
	Pages           : 11
	Date            : 2008-08-22

>From a Carrier perspective, the possibility of turning a Permanent
Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic being carried
over it, is a valuable option.  In other terms, such operation can be
seen as a way of transferring the ownership and control of an
existing and in-use Data Plane connection between the Management
Plane and the Control Plane, leaving its Data Plane state untouched.

This memo sets out the requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.t
xt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Fri, 22 Aug 2008 07:46:53 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt 
Date: Fri, 22 Aug 2008 00:45:01 -0700 (PDT)

--NextPart

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           : draft-ietf-ccamp-pc-and-sc-reqs-05.txt
	Author(s)       : D. Caviglia, et al.
	Filename        : draft-ietf-ccamp-pc-and-sc-reqs-05.txt
	Pages           : 11
	Date            : 2008-08-22

>From a Carrier perspective, the possibility of turning a Permanent
Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic being carried
over it, is a valuable option.  In other terms, such operation can be
seen as a way of transferring the ownership and control of an
existing and in-use Data Plane connection between the Management
Plane and the Control Plane, leaving its Data Plane state untouched.

This memo sets out the requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-pc-and-sc-reqs-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 21 Aug 2008 23:19:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG
Date: Fri, 22 Aug 2008 00:18:02 +0100

Hello Don,

Thanks for the response.

>> 1. A CE is attached by parallel links to a single PE
>>
>>    Suppose the links have the same switching types, but
>>    different bandwidths. Link-a has plenty of bandwidth
>>    available with an MTU size of x. Link-b has not much
>>    bandwidth available with an MTU size of y > x.
>
> Interface MTU is part of the PSC TE attributes in the our spec. If the
> MTUs are different they should not be aggregated.

Right.
Aggregation in this case is hard to make representative of reality.

> Also In L1VPN (LSC and TDM) networks the Switching type
> covers Switching granularity (which is like an MTU).

Sure. But I wanted to keep in PSC, because that problem represents a single 
layer network.

> I'm trying to understand if you are saying the following text would
> fix the problem or you see a larger issue:
> "Therefore, such routes and the corresponding TE information
> SHALL NOT be aggregated unless they share identical Traffic
> Engineering Attributes".

The question I am asking is - is the solution to this problem to advertise 
two routes?
(Clearly two is a special case of many.)

I don't believe that in the general (non-TE case) we would consider the case 
of two parallel links between CE and PE as route aggregation. The PE would 
simply advertise reachability (through itself) to the CE.

Hence my question below.

>>    Normally, we would expect the PE to advertise a single
>>    piece of reachability information for the CE leaving
>>    the actual choice of links to be made by the PE.
>>
>>    What would the PE advertise in this case?
>>    - It cannot aggregate the TE information because that
>>      would imply that there was lots of bandwidth at the
>>      larger MTU size.
>>    - It could include duplicate Switching Capability
>>      Descriptors, but that would need some clarification as
>>      duplicate descriptors are intended for different
>>      switching caps in the IGP RFCs.
>>    - It could advertise two pieces of reachability
>>      information, but that would be a change to how the
>>      implementation currently works.

>> 2. There is more than one AS
[SNIP]
>I remember we discussed this aspect originally in the context of
>L1VPNs and limited it to a single AS since L1VPNs Basic Mode
>are limited to a single AS. I don't recall if we thought this was
>applicable to a multi-AS solution.
>
>We should clarify this point either way.

Thanks.
I guess:
- if applicable, how?
- if not applicable, how prevent?

Cheers,
Adrian

Delivery-date: Thu, 21 Aug 2008 23:08:58 +0000
Content-class: urn:content-classes:message
Subject: RE: BGP TE attr last call by softwires WG
Date: Thu, 21 Aug 2008 19:04:46 -0400
From: "Don Fedyk" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>

Hi Adrian

I should talk this over with my Co-authors so for now I won't answer all
your points but I will ask for clarification.

See Inline:

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]=20
>=20
> Hi,
>=20
> > From: David Ward <[email-masked]>=20
> > Sent: Tue Aug 12 23:48=20
> > Subject: BGP TE attr last call by softwires WG=20
> >
> > The softwire WG has LC'ed=20
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-softwire-
> > bgp-te-attribute-01.txt=20
> >
> > We will keep open an additional two-week period for wider
> > review before moving forward in the publication process.=20
> > Please have any comments to the authors and softwires WG=20
> > by Aug 26, 2008.=20
>=20
> I have no objection to the basic idea of distributing TE
> information about CE-PE links especially for use in VPNs.=20
> But I am worried by one aspect of the document. Hopefully
> this is just an editorial issue.
>=20
> The last call in Softwires appears to have generated some
> discussion about aggregation, and this led to the addition=20
> of section 4.
>=20
> | 4. Implication on aggregation
> |
> |    Routes that carry the Traffic Engineering Attribute=20
> |    have additional semantics that could affect traffic=20
> |    forwarding behavior. Therefore, such routes SHALL NOT=20
> |    be aggregated unless they share identical Traffic
> |    Engineering Attributes.
>=20
> As far as it goes, this paragraph is great. It says "do not
> perform route aggregation unless it is sensible to do so."
>=20
> But it says nothing about TE aggregation.
>=20
> Notwithstanding the TE attribute is non-transitive, there=20
> is the potential for an implementation to believe that it
> should provide some form of TE aggregation.
>=20
> Consider two cases:
>=20
> 1. A CE is attached by parallel links to a single PE
>=20
>    Suppose the links have the same switching types, but=20
>    different bandwidths. Link-a has plenty of bandwidth
>    available with an MTU size of x. Link-b has not much
>    bandwidth available with an MTU size of y > x.

Interface MTU is part of the PSC TE attributes in the our spec. If the
MTUs are different they should not be aggregated.=20
Also In L1VPN (LSC and TDM) networks the Switching type covers Switching
granularity (which is like an MTU). =20

I'm trying to understand if you are saying the following text would fix
the problem or you see a larger issue:=20
"Therefore, such routes and the corresponding TE information SHALL NOT
be aggregated unless they share identical Traffic Engineering
Attributes".

>=20
>    Normally, we would expect the PE to advertise a single
>    piece of reachability information for the CE leaving
>    the actual choice of links to be made by the PE.
>=20
>    What would the PE advertise in this case?
>    - It cannot aggregate the TE information because that
>      would imply that there was lots of bandwidth at the=20
>      larger MTU size.
>    - It could include duplicate Switching Capability
>      Descriptors, but that would need some clarification as
>      duplicate descriptors are intended for different=20
>      switching caps in the IGP RFCs.
>    - It could advertise two pieces of reachability
>      information, but that would be a change to how the
>      implementation currently works.
>=20
> 2. There is more than one AS
>=20
>    Consider
>=20
>      CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
>=20
>    PE2 advertises reachability to CE2 and includes TE=20
>    information. The TE attribute is non-transitive so it is
>    not just passed on, but ASBR2 wants to announce
>    reachability to CE2 (in the VPN case, we may want to=20
>    support a multi-AS VPN).
>=20
>    So ASBR2 can advertise reachability to CE2, but what TE
>    parameters does it advertise? The parameters for the=20
>    link PE2-CE2 are not so helpful because the TE=20
>    reachability across AS2 may be different. Yet any attempt
>    to perform a computation of the TE reachability across
>    AS2 (i.e. TE aggregation) is complex and potentially
>    unstable. (Of course, if a tunnel is pre-established
>    between ASBR2 and PE2 this is a different matter.)

I remember we discussed this aspect originally in the context of L1VPNs
and limited it to a single AS since L1VPNs Basic Mode are limited to a
single AS. I don't recall if we thought this was applicable to a multi
AS solution.  We should clarify this point either way. =20

We will get back to you shortly on this point.=20
Thanks,
Don=20

>=20
>=20
> I think that these two different scenarios need attention
> in the I-D.=20
>=20
> For the first one, it may just be a matter of indicating=20
> which approach is to be used.
>=20
> For the second one, I hope the answer is to recommend=20
> against any form of TE aggregation. This could easily be
> added to section 4, and I would be happy to provide text.
> BUT, it will still leave open the question about if and how
> TE information is propagated beyond the AS.
>=20
> Thanks for any clarifications.
>=20
> Adrian
>=20

Envelope-to: [email-masked]
Delivery-date: Thu, 21 Aug 2008 18:50:49 +0000
To: [email-masked], [email-masked]
Subject: RFC 5298 on Analysis of Inter-Domain Label Switched Path (LSP) Recovery
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Thu, 21 Aug 2008 11:48:33 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5298

        Title:      Analysis of Inter-Domain Label Switched 
                    Path (LSP) Recovery 
        Author:     T. Takeda, Ed., A. Farrel, Ed.,
                    Y. Ikejiri, JP. Vasseur
        Status:     Informational
        Date:       August 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],
                    [email-masked]
        Pages:      26
        Characters: 59894
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5298.txt

Protection and recovery are important features of service offerings
in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks.  Increasingly, MPLS and GMPLS networks are being extended
from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label
Switched Paths (LSPs) in multi-domain environments.  These are
discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering".

This document analyzes the application of these techniques to
protection and recovery in multi-domain networks.  The main focus for
this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks.  This memo provides
information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Delivery-date: Thu, 21 Aug 2008 09:59:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Hamid Ould-Brahim" <[email-masked]>
Subject: Re: BGP TE attr last call by softwires WG
Date: Thu, 21 Aug 2008 10:53:59 +0100

Hi,

> From: David Ward <[email-masked]> 
> Sent: Tue Aug 12 23:48 
> Subject: BGP TE attr last call by softwires WG 
>
> The softwire WG has LC'ed 
>
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-
> bgp-te-attribute-01.txt 
>
> We will keep open an additional two-week period for wider
> review before moving forward in the publication process. 
> Please have any comments to the authors and softwires WG 
> by Aug 26, 2008. 

I have no objection to the basic idea of distributing TE
information about CE-PE links especially for use in VPNs. 
But I am worried by one aspect of the document. Hopefully
this is just an editorial issue.

The last call in Softwires appears to have generated some
discussion about aggregation, and this led to the addition 
of section 4.

| 4. Implication on aggregation
|
|    Routes that carry the Traffic Engineering Attribute 
|    have additional semantics that could affect traffic 
|    forwarding behavior. Therefore, such routes SHALL NOT 
|    be aggregated unless they share identical Traffic
|    Engineering Attributes.

As far as it goes, this paragraph is great. It says "do not
perform route aggregation unless it is sensible to do so."

But it says nothing about TE aggregation.

Notwithstanding the TE attribute is non-transitive, there 
is the potential for an implementation to believe that it
should provide some form of TE aggregation.

Consider two cases:

1. A CE is attached by parallel links to a single PE

   Suppose the links have the same switching types, but 
   different bandwidths. Link-a has plenty of bandwidth
   available with an MTU size of x. Link-b has not much
   bandwidth available with an MTU size of y > x.

   Normally, we would expect the PE to advertise a single
   piece of reachability information for the CE leaving
   the actual choice of links to be made by the PE.

   What would the PE advertise in this case?
   - It cannot aggregate the TE information because that
     would imply that there was lots of bandwidth at the 
     larger MTU size.
   - It could include duplicate Switching Capability
     Descriptors, but that would need some clarification as
     duplicate descriptors are intended for different 
     switching caps in the IGP RFCs.
   - It could advertise two pieces of reachability
     information, but that would be a change to how the
     implementation currently works.

2. There is more than one AS

   Consider

     CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2

   PE2 advertises reachability to CE2 and includes TE 
   information. The TE attribute is non-transitive so it is
   not just passed on, but ASBR2 wants to announce
   reachability to CE2 (in the VPN case, we may want to 
   support a multi-AS VPN).

   So ASBR2 can advertise reachability to CE2, but what TE
   parameters does it advertise? The parameters for the 
   link PE2-CE2 are not so helpful because the TE 
   reachability across AS2 may be different. Yet any attempt
   to perform a computation of the TE reachability across
   AS2 (i.e. TE aggregation) is complex and potentially
   unstable. (Of course, if a tunnel is pre-established
   between ASBR2 and PE2 this is a different matter.)

I think that these two different scenarios need attention
in the I-D. 

For the first one, it may just be a matter of indicating 
which approach is to be used.

For the second one, I hope the answer is to recommend 
against any form of TE aggregation. This could easily be
added to section 4, and I would be happy to provide text.
BUT, it will still leave open the question about if and how
TE information is propagated beyond the AS.

Thanks for any clarifications.

Adrian

Delivery-date: Wed, 20 Aug 2008 10:03:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Dan Li'" <[email-masked]>, "'Igor Bryskin'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Date: Wed, 20 Aug 2008 11:01:05 +0100

Hi Tony,

(and by the way, welcome to CCAMP)

>> 1) The amount of information advertised
>> The amount of information carried and the stability of that information 
>> is
>> similar to that used in TE networks today. In those networks, when a TE 
>> LSP
>> is set up or torn down, there is a change in the bandwidth availability 
>> on
>> all links traversed. This causes an update to the TE information 
>> advertised
>> in the IGP for those links.
>
> True.  However, typically the number of TE LSPs that are established is a
> static number.  Even in extreme cases, folks typically use O(n^2) LSPs to
> form a complete mesh of their nodes.
>
> In the applications that I think that you're contemplating, there are many
> more links, with the ability of end users to set up their own links
> throughout the network.  Please correct me if I'm misunderstanding.

I think there is some misunderstanding here.
It is true that in a private lambda model, the end-user may request the 
establishment of the LSP (where the end-user might be a packet network), but 
I don't think we should assume that the connectivity is worse than that in a 
TE network. Indeed, it is likely to be much less. This is in part due to the 
expense of equipment, the topology of the network, and the constraint of the 
number of lambdas supported on any link. That means that a single PE will 
only connect to a realtively small number of other PEs.

Of course, this may vary in time as technology improves and as networks get 
larger and have greater use.

>> In general, this is not seen as a critical issue. There are several
>> possibilities to reduce the impact of TE advertisements if they become a
>> problem. For example, as implemented in some of our current IP network, 
>> each
>> router can impose a threshold (time and/or bandwidth delta) before which 
>> it
>> will not re-issue an advertisement.
>
> Effectively rate limiting the link state database flooding, which is the
> goal.
>
>> In networks that require IGP convergence (for IP data traffic) and TE
>> advertisement (for MPLS-TE traffic) there is some concern that the
>> distribution of TE information might impact the IGP convergence time. In
>> these cases, implementations may prioritise normal LSAs ahead of opaque
>> LSAs, or may use separate protocol instances.
>
> The former is more difficult in IS-IS, as TE information is typically
> distributed as part of the same LSP that carries the physical link
> information.  Separate protocol instances is of course possible, but it
> would seem like it would become more of a manageability issue (do you need
> identical topologies?) and would not obviate the need for CPU cycles.

Yes. The Gen-App work in IS-IS is specifically to address this issue, I 
believe. CPU cycles will remain an issue for everyone. But if you build a 
box for a specific environment, you had better buiold a big enough box!

>> 2) Speed of convergence of wavelength availability
>> In a TE network, the need for an up-to-date TED depends to a good degree 
>> on
>> the relative size of LSPs and residual bandwidth, and on the rate of 
>> arrival
>> of new LSPs. Increasingly, core TE LSPs may be quite large, but in 
>> general,
>> the rate of arrival of large LSPs is quite low, and the holding times are
>> quite high.
>>
>> So, the bottom line in a TE network is that when an LSP needs more 
>> bandwidth
>> than is actually available, it is crucial that the TED is up-to-date (or
>> "real-time" like some folks may call it).
>
> I'm not sure that I would characterize it as 'crucial'.  It would seem 
> like
> there is always going to be *some* window where remote nodes have 
> imperfect
> information, just due to speed of light delays.  Ergo, the head end must
> always be prepared for its path to be rejected during setup and then
> recompute the path based on new information.

Absolutely.

And the signaling protocols are specifically designed to handle this case.

Nevertheless, for customer experience (TM) we would hope to make this window 
relatively small.

And, indeed, the debate lower down the email is really about how likely we 
are to fall through the window. If it happens for every LSP setup attempt, 
something clearly needs to be done in the protocols. If it happens less than 
1% and only in really busy networks, this may be acceptable.

>> But as Igor has pointed out, this is impossible to achieve in a 
>> distributed
>> system. Indeed, it is impossible to achieve even in a centralised system
>> since network failures may occur. That means that there is always a
>> possibility that a computed path will be signaled and will fail to be
>> established. We should be familiar with this situation in scenarios such 
>> as
>> contention during restoration after network failure, and the signaling
>> protocols are designed to fail and try again (usually using "crankback"
>> information about the failed link, but also assuming that the IGP may 
>> have
>> converged in the mean time).
>
> Note that crankback (recomputing the path DURING setup) is not always
> necessary.  Sometimes recomputation at the head end will suffice.

Yes. It all depends on whether the TED has converged in the mean time. If 
so, then reporting the failure and triggering recomputation is needed. If 
not (or if you can't be sure) it is best to recompute with the knowledge of 
which link caused the failure in the original setup. That's crankback (RFC 
4920).

>> We can look at a couple of things:
>> - What is the arrival rate of lambda LSPs?
>> - What is the required setup time of lambda LSPs?
>>
>> With the exception of restoration LSPs, I think we may say that a 5-10
>> second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but 
>> you
>> may have a different experience.
>
> In my experience nearly static LSPs are perfectly acceptable, and setup 
> time
> is not an issue.  ;-)

Exactly.

What we find at the moment, however, is that there is a lot of discussion 
about moving the transport network from a "nearly static" animal to 
something that is semi-dynamic, or even "on-demand".

This changes the boundaries, but it is still not clear to me that 
"on-demand" means sub-second as I would expect all lambda LSPs to go through 
a testing phase before being put in service (even if this is an automatic 
phase). And I would expect such a phase to take a number of seconds.

That said, restoration is a different question.

> My concern however is simpler: limiting the rate of link state database
> flooding.  This is vital to ensure the stability of the IGP.

Agreed, but let's be careful to understand the size of the network, the 
amount of information, and the rate of change of that information. This is 
really what Dan's I-D is starting to look at, so contributions to helping 
with that understanding are welcome.

If, as you say, most of these LSPs are nearly static, we obviously don't 
have to worry about the amount of flooding. It is only when LSPs come and go 
(or when nodes/links come and go) that we will see a change in flooding. I 
think that what Dan said in this email points out that the amount of 
flooding (but not necessarily the amount of information flooded) is similar 
to what we already see in TE networks. We should certainly look to see what 
the stability experience is with those networks - my understanding is that 
they are deployed and functional.

Cheers,
Adrian 

Delivery-date: Wed, 20 Aug 2008 05:25:00 +0000
Reply-To: <[email-masked]>
From: "Tony Li" <[email-masked]>
To: "'Dan Li'" <[email-masked]>, "'Igor Bryskin'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Date: Tue, 19 Aug 2008 22:22:49 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C9024A.32CE8300
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Dan,

1) The amount of information advertised
The amount of information carried and the stability of that information is
similar to that used in TE networks today. In those networks, when a TE LSP
is set up or torn down, there is a change in the bandwidth availability on
all links traversed. This causes an update to the TE information advertised
in the IGP for those links. 

True.  However, typically the number of TE LSPs that are established is a
static number.  Even in extreme cases, folks typically use O(n^2) LSPs to
form a complete mesh of their nodes.
 
In the applications that I think that you're contemplating, there are many
more links, with the ability of end users to set up their own links
throughout the network.  Please correct me if I'm misunderstanding.

In general, this is not seen as a critical issue. There are several
possibilities to reduce the impact of TE advertisements if they become a
problem. For example, as implemented in some of our current IP network, each
router can impose a threshold (time and/or bandwidth delta) before which it
will not re-issue an advertisement. 

Effectively rate limiting the link state database flooding, which is the
goal.

 In networks that require IGP convergence (for IP data traffic) and TE
advertisement (for MPLS-TE traffic) there is some concern that the
distribution of TE information might impact the IGP convergence time. In
these cases, implementations may prioritise normal LSAs ahead of opaque
LSAs, or may use separate protocol instances. 

The former is more difficult in IS-IS, as TE information is typically
distributed as part of the same LSP that carries the physical link
information.  Separate protocol instances is of course possible, but it
would seem like it would become more of a manageability issue (do you need
identical topologies?) and would not obviate the need for CPU cycles.

 2) Speed of convergence of wavelength availability
In a TE network, the need for an up-to-date TED depends to a good degree on
the relative size of LSPs and residual bandwidth, and on the rate of arrival
of new LSPs. Increasingly, core TE LSPs may be quite large, but in general,
the rate of arrival of large LSPs is quite low, and the holding times are
quite high.

So, the bottom line in a TE network is that when an LSP needs more bandwidth
than is actually available, it is crucial that the TED is up-to-date (or
"real-time" like some folks may call it). 

I'm not sure that I would characterize it as 'crucial'.  It would seem like
there is always going to be *some* window where remote nodes have imperfect
information, just due to speed of light delays.  Ergo, the head end must
always be prepared for its path to be rejected during setup and then
recompute the path based on new information.

 But as Igor has pointed out, this is impossible to achieve in a distributed
system. Indeed, it is impossible to achieve even in a centralised system
since network failures may occur. That means that there is always a
possibility that a computed path will be signaled and will fail to be
established. We should be familiar with this situation in scenarios such as
contention during restoration after network failure, and the signaling
protocols are designed to fail and try again (usually using "crankback"
information about the failed link, but also assuming that the IGP may have
converged in the mean time). 

Note that crankback (recomputing the path DURING setup) is not always
necessary.  Sometimes recomputation at the head end will suffice.

 We can look at a couple of things:
- What is the arrival rate of lambda LSPs?
- What is the required setup time of lambda LSPs?

With the exception of restoration LSPs, I think we may say that a 5-10
second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you
may have a different experience. 

In my experience nearly static LSPs are perfectly acceptable, and setup time
is not an issue.  ;-)
 
My concern however is simpler: limiting the rate of link state database
flooding.  This is vital to ensure the stability of the IGP.
 
Regards,
Tony

------=_NextPart_000_0021_01C9024A.32CE8300
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>Hi=20
Dan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><U>1) The amount of information advertised</U><BR>The amount of=20
  information carried and the stability of that information is similar =
to that=20
  used in TE networks today. In those networks,&nbsp;when a TE LSP is =
set up or=20
  torn down, there is a change in the bandwidth availability on all =
links=20
  traversed. This causes an update to the TE information advertised in =
the IGP=20
  for those links.<SPAN class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff>True.&nbsp; However, typically the number of TE LSPs =
that are=20
established is a static number.&nbsp; Even in extreme cases, folks =
typically use=20
O(n^2) LSPs to form a complete mesh of their nodes.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>In=20
the applications that I think that you're contemplating, there are many =
more=20
links, with the ability of end users to set up their own links =
throughout the=20
network.&nbsp; Please correct me if I'm =
misunderstanding.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>In general, this is not seen as a critical issue. There are =
several=20
  possibilities to reduce the impact of TE advertisements if they become =
a=20
  problem. For example, as implemented in some of our current IP =
network, each=20
  router can impose a threshold (time and/or bandwidth delta) before =
which it=20
  will not re-issue an advertisement.<SPAN =
class=3D453510705-20082008><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff>Effectively rate limiting the link state database =
flooding, which=20
is the goal.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D453510705-20082008>&nbsp;</SPAN>In networks that =
require IGP=20
  convergence (for IP data traffic) and TE advertisement (for MPLS-TE =
traffic)=20
  there is some concern that the distribution of TE information might =
impact the=20
  IGP convergence time. In these cases, implementations may prioritise =
normal=20
  LSAs ahead of opaque LSAs, or may use separate protocol =
instances.<SPAN=20
  class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>The=20
former is more difficult in IS-IS, as TE information is typically =
distributed as=20
part of the same LSP that carries the physical link information.&nbsp; =
Separate=20
protocol instances is of course possible, but it would seem like it =
would become=20
more of a manageability issue (do you need identical topologies?) and =
would not=20
obviate the need for CPU cycles.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN><U>2) Speed of convergence of =
wavelength=20
  availability</U><BR>In a TE network, the need for an up-to-date TED =
depends to=20
  a good degree on the relative size of LSPs and residual bandwidth, and =
on the=20
  rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite =
large,=20
  but in general, the rate of arrival of large LSPs is quite low, and =
the=20
  holding times are quite high.<BR><BR>So, the bottom line in a TE =
network is=20
  that when an LSP needs more bandwidth than is actually available, it =
is=20
  crucial that the TED is up-to-date (or "real-time" like some folks may =
call=20
  it).<SPAN class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>I'm=20
not sure that I would characterize it as 'crucial'.&nbsp; It would seem =
like=20
there is always going to be *some* window where remote nodes have =
imperfect=20
information, just due to speed of light delays.&nbsp; Ergo, the head end =
must=20
always be prepared for its path to be rejected during setup and then =
recompute=20
the path based on new information.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D453510705-20082008>&nbsp;</SPAN>But as Igor has =
pointed out,=20
  this is impossible to achieve in a distributed system. Indeed, it is=20
  impossible to achieve even in a centralised system since network =
failures may=20
  occur. That means that there is always a possibility that a computed =
path will=20
  be signaled and will fail to be established. We should be familiar =
with this=20
  situation in scenarios such as contention during restoration after =
network=20
  failure, and the signaling protocols are designed to fail and try =
again=20
  (usually using "crankback"&nbsp; information about the failed link, =
but also=20
  assuming that the IGP may have converged in the mean time).<SPAN=20
  class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>Note=20
that crankback (recomputing the path DURING setup) is not always=20
necessary.&nbsp; Sometimes recomputation at the head end will=20
suffice.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D453510705-20082008>&nbsp;</SPAN>We can look at a =
couple of=20
  things:<BR>- What is the arrival rate of lambda LSPs?<BR>- What is the =

  required setup time of lambda LSPs?<BR><BR>With the exception of =
restoration=20
  LSPs, I think&nbsp;we may&nbsp;say that a 5-10 second delay in LSP =
setup time=20
  for 1 in 50 LSPs would be acceptable, but you may have a different=20
  experience.<SPAN class=3D453510705-20082008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D453510705-20082008></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>In my=20
experience nearly static LSPs are perfectly acceptable, and setup time =
is not an=20
issue.&nbsp; ;-)</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial =
color=3D#0000ff>My=20
concern however is simpler: limiting the rate of link state database=20
flooding.&nbsp; This is vital to ensure the stability of the=20
IGP.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008><FONT face=3DArial=20
color=3D#0000ff>Tony</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D453510705-20082008>&nbsp;</SPAN><SPAN=20
class=3D453510705-20082008>&nbsp;</SPAN></DIV></BODY></HTML>

------=_NextPart_000_0021_01C9024A.32CE8300--

Delivery-date: Wed, 20 Aug 2008 03:18:16 +0000
Date: Wed, 20 Aug 2008 11:15:53 +0800
From: Dan Li <[email-masked]>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
To: [email-masked], 'Igor Bryskin' <[email-masked]>, [email-masked], [email-masked], [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Tony, Igor,

I think we should separate two points for this discussion.

1) The amount of information advertised
The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links.

In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement.

In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances.

Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern.

2) Speed of convergence of wavelength availability
In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high.

So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it).

But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback"  information about the failed link, but also assuming that the IGP may have converged in the mean time).

As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation.

We can look at a couple of things:
- What is the arrival rate of lambda LSPs?
- What is the required setup time of lambda LSPs?

With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience.

Regards,

Dan

  ----- Original Message ----- 
  From: Tony Li 
  To: 'Igor Bryskin' ; 'Dan Li' ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, August 19, 2008 3:43 AM
  Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

  Igor, Dan,

  Perhaps there's an important distinction to be made here.  Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure.  Debouncing techniques should be used to prevent any connectivity oscillations.

  However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time.  Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale.  This of course won't match many folks' requirements for 'real-time'.

  Tony

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
    Sent: Monday, August 18, 2008 8:15 AM
    To: Dan Li; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

    Dan,

    That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

    Igor

    ----- Original Message ----
    From: Dan Li <[email-masked]>
    To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    Sent: Friday, August 15, 2008 1:55:04 AM
    Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

    Hi Igor,

    You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.

    Regards,

    Dan
      ----- Original Message ----- 
      From: Igor Bryskin 
      To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
      Sent: Tuesday, August 12, 2008 4:25 AM
      Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

      Hi,

      Please, see my comment in line. Look for IB>>

      Cheers,
      Igor

      ----- Original Message ----
      From: Adrian Farrel <[email-masked]>
      To: [email-masked]; [email-masked]; [email-masked]
      Sent: Monday, August 11, 2008 1:24:50 PM
      Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

      Hi,
        I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
        1. IGP usage in the context of traditional distributed solutions for WSON 
        [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

        IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

        [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
        [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
        [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
        I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
         
        2. IGP usage in the context of PCE solutions for WSON
        [Dan] It's a potential way for PCE to get the wavelength information.
        [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
        [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
        [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

        3. Flooding and refresh of static and dynamic link state updates
        [Dan] Try to figure out the impact to the performance of IGP.
        [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
        [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
        [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

        4. Data base sync-up during node restarts
        [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
        [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
        [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

        Could you please let me know if the above is within the current scope? I believe that these are important. 
        [Adrian] Very much in scope!

        Cheers,
        Adrian

--Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE type=text/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content="MSHTML 6.00.2800.1561" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV>Hi Tony, Igor,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think we should separate two points for this discussion.<BR><BR><U>1) The 
amount of information advertised</U><BR>The amount of information carried and 
the stability of that information is similar to that used in TE networks today. 
In those networks,&nbsp;when a TE LSP is set up or torn down, there is a change 
in the bandwidth availability on all links traversed. This causes an update to 
the TE information advertised in the IGP for those links.<BR><BR>In general, 
this is not seen as a critical issue. There are several possibilities to reduce 
the impact of TE advertisements if they become a problem. For example, as 
implemented in some of our current IP network, each router can impose a 
threshold (time and/or bandwidth delta) before which it will not re-issue an 
advertisement.<BR><BR>In networks that require IGP convergence (for IP data 
traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that 
the distribution of TE information might impact the IGP convergence time. In 
these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or 
may use separate protocol instances.<BR><BR>Note that in WSON networks the only 
likely use of the IGP except for TE/RWA information is for the DCN. In this 
case, distinguishing the two convergence times is less of a 
concern.<BR><BR><U>2) Speed of convergence of wavelength availability</U><BR>In 
a TE network, the need for an up-to-date TED depends to a good degree on the 
relative size of LSPs and residual bandwidth, and on the rate of arrival of new 
LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of 
arrival of large LSPs is quite low, and the holding times are quite 
high.<BR><BR>So, the bottom line in a TE network is that when an LSP needs more 
bandwidth than is actually available, it is crucial that the TED is up-to-date 
(or "real-time" like some folks may call it).<BR><BR>But as Igor has pointed 
out, this is impossible to achieve in a distributed system. Indeed, it is 
impossible to achieve even in a centralised system since network failures may 
occur. That means that there is always a possibility that a computed path will 
be signaled and will fail to be established. We should be familiar with this 
situation in scenarios such as contention during restoration after network 
failure, and the signaling protocols are designed to fail and try again (usually 
using "crankback"&nbsp; information about the failed link, but also assuming 
that the IGP may have converged in the mean time).<BR><BR>As Igor also points 
out, the situation in RWA is slightly more sensitive because a lambda is either 
there or not. Actually, this situation is just the same as the marginal 
bandwidth problem just desribed for TE networks. Since lambda availability 
information cannot be distributed instantly, there is always the chance that a 
computed path will fail because the lambda is not actually available. In the 
case of multiple points of computation, there is always the chance of contention 
for a lambda and so we must accept that some LSP setup attempt will fail - 
again, crankback and recomputation will normally ease the situation.<BR><BR>We 
can look at a couple of things:<BR>- What is the arrival rate of lambda 
LSPs?<BR>- What is the required setup time of lambda LSPs?<BR><BR>With the 
exception of restoration LSPs, I think&nbsp;we may&nbsp;say that a 5-10 second 
delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a 
different experience.<BR></DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt &#23435;&#20307;; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Tony Li</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">'Igor Bryskin'</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">'Dan Li'</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> 
  ; <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Sent:</B> Tuesday, August 19, 2008 3:43 AM</DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Subject:</B> RE: Comments on 
  'draft-li-ccamp-wson-igp-eval-01.txt'</DIV>
  <DIV><BR></DIV>
  <DIV dir=ltr align=left><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=500343719-18082008><FONT face=Arial 
  color=#0000ff>Igor, Dan,</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=500343719-18082008><FONT face=Arial 
  color=#0000ff></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=500343719-18082008></SPAN><FONT 
  face=Arial><FONT color=#0000ff>P<SPAN class=500343719-18082008>erhaps there's 
  an important distinction to be made here.&nbsp; Typically, having an IGP carry 
  lambda&nbsp;connectivity status&nbsp;isn't a significant issue, as that should 
  only change when there is a significant failure.&nbsp; Debouncing techniques 
  should be used to prevent any connectivity 
  oscillations.</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=500343719-18082008>However, carrying lambda utilization status in the 
  IGP is not going to prove practical, as the continued series of updates would 
  easily lead to IGP thrash if done at anything approaching real-time.&nbsp; 
  Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 
  minute) is probably not an issue for networks of reasonable scale.&nbsp; This 
  of course won't match many folks' requirements for 
  'real-time'.</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=500343719-18082008>Tony</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><BR></DIV>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
    [mailto:[email-masked]] <B>On Behalf Of </B>Igor 
    Bryskin<BR><B>Sent:</B> Monday, August 18, 2008 8:15 AM<BR><B>To:</B> Dan 
    Li; [email-masked]; [email-masked]; 
    [email-masked]<BR><B>Subject:</B> Re: Comments on 
    'draft-li-ccamp-wson-igp-eval-01.txt'<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV 
    style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
    <DIV>Dan,<BR><BR>That's the point. How does PCE maintain the lambda 
    availability status? PCE architecture shyly puts this problem out of its 
    scope, but the only known way today for the PCE is to participate in one or 
    more IGP-TEor BGP-TE routing protocols. So, in this respect it does not 
    matter whether paths are computed locally or via PCE 
    service.<BR><BR>Igor<BR></DIV>
    <DIV 
    style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif"><BR>
    <DIV 
    style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif">----- 
    Original Message ----<BR>From: Dan Li &lt;[email-masked]&gt;<BR>To: Igor 
    Bryskin &lt;[email-masked]&gt;; [email-masked]; 
    [email-masked]; [email-masked]<BR>Sent: Friday, August 
    15, 2008 1:55:04 AM<BR>Subject: Re: Comments on 
    'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR>
    <STYLE type=text/css>DIV {
	MARGIN: 0px
}
</STYLE>

    <DIV>Hi Igor,</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>You're right, when we doing the path computation,&nbsp;the TE link 
    lambda available status should be precise and real time updated. If we do 
    the path computation in distribute way, this would be a big problem because 
    of the TE link lambda available status may not be updated right away. But we 
    can do it in centralized way to minimized this problem. For example, using 
    PCE and if the PCE can maintain the TE link lambda available status, this 
    may not be a problem because all the path computation requests are in the 
    queue of PCE, and PCE knows which lambda is available.</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Regards,</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Dan</DIV>
    <BLOCKQUOTE 
    style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
      <DIV>----- Original Message ----- </DIV>
      <DIV 
      style="BACKGROUND: rgb(228,228,228); moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial"><B>From:</B> 
      <A title=[email-masked] href="mailto:[email-masked]" 
      target=_blank rel=nofollow ymailto="mailto:[email-masked]">Igor 
      Bryskin</A> </DIV>
      <DIV><B>To:</B> <A title=[email-masked] 
      href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A> ; <A 
      title=[email-masked] 
      href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A> 
      ; <A title=[email-masked] href="mailto:[email-masked]" 
      target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A> ; <A 
      title=[email-masked] href="mailto:[email-masked]" target=_blank 
      rel=nofollow ymailto="mailto:[email-masked]">[email-masked]</A> </DIV>
      <DIV><B>Sent:</B> Tuesday, August 12, 2008 4:25 AM</DIV>
      <DIV><B>Subject:</B> Re: Comments on 
      'draft-li-ccamp-wson-igp-eval-01.txt'</DIV>
      <DIV><BR></DIV>
      <DIV 
      style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif">
      <DIV>Hi,<BR><BR>Please, see my comment in line. Look for 
      IB&gt;&gt;<BR><BR>Cheers,<BR>Igor<BR></DIV>
      <DIV 
      style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif"><BR>
      <DIV 
      style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif">----- 
      Original Message ----<BR>From: Adrian Farrel &lt;<A 
      href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: <A 
      href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A>; 
      <A href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A>; <A 
      href="mailto:[email-masked]" target=_blank rel=nofollow 
      ymailto="mailto:[email-masked]">[email-masked]</A><BR>Sent: Monday, 
      August 11, 2008 1:24:50 PM<BR>Subject: Re: Comments on 
      'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR>
      <DIV>Hi,</DIV>
      <BLOCKQUOTE 
      style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(245,245,245) 2px solid; MARGIN-RIGHT: 0px">
        <DIV>I have the following comments on this draft. I was wondering what 
        were the objectives for the IGP evaluation. IMHO the evaluation from 
        WSON perspective should address the following:<BR>1. IGP usage in the 
        context of traditional distributed solutions for WSON <BR><FONT 
        color=#000080>[Dan] With the situation that TE information is already be 
        carried by IGP, it's nature to think that the wavelength information can 
        also be carried by IGP. I am not saying it should be, but it's worth to 
        look at.<BR><BR>IB&gt;&gt; There is an important difference in 
        requirements for advertising of TE link information vs. advertising TE 
        link lambda availability. When OSPF TE speaker advertises TE link info 
        it, apart from link statical information, is pretty much saying : "I 
        have 70% of bandwdith availbale on priority p". For the path computer 
        (say, PCE) it is almost always not important if the link has actually 
        75%, 70% or 60% of available bandwidth. However, lambda availability 
        (like pregnancy) is boolen: either it is there ot it is not. PCE which 
        perfoms path computation in terms of lambdas, unfortunately. must have 
        almost momentarily lambda availability states. With the speed of TE info 
        flooding current IGP-TE protocols have to offer, such mechanism will not 
        work on dynamic networks. And in any case one can never rely on PCE 
        during recovery path computations. These limitations. I think, should be 
        clearly stated in the document.<BR><BR></FONT><FONT 
        color=#808000>[Bardalai, Snigdho] Do you see any particular issues with 
        using the IGP for this purpose ?</FONT></DIV>
        <DIV><FONT color=#800000>[Dan] From the result of the 
        simulation,&nbsp;the OSPF convergency time&nbsp;takes a liitle bit 
        longer when the entire network restarts. Because&nbsp;the WSON 
        information is added in the OSPF LSA.&nbsp;During the network running 
        normally, the update of wavelength availability 
        information&nbsp;doesn't&nbsp;impact the IGP performance 
        obviously.</FONT></DIV>
        <DIV><FONT color=#cc0000>[Adrian] Certainly, from the point of view of 
        someone coming at this without an implementation (I used&nbsp;to have 
        one :-), the concern is that adding the RWA information to the IGP might 
        mean that there was simply too much information to be distributed. What 
        Dan's draft is trying to do is show the dimensions of the information 
        and&nbsp;how dynamic it is. From this, we can quickly see how things 
        will scale.</FONT></DIV>
        <DIV><FONT color=#800000><FONT color=#cc0000>I do not believe that there 
        is an issue with the interaction with IP routing, but I guess we should 
        consider that it is possible that the DCN will be a real IP network 
        carrying other traffic and that we need to not disrupt IGP convergence 
        in that network. Mechanisms exist (or are being developed) to make that 
        safe, and Dan's I-D should be able to tell us how important it is to use 
        them.</FONT><BR></FONT>&nbsp;<BR>2. IGP usage in the context of PCE 
        solutions for WSON<BR><FONT color=#000080>[Dan] It's a potential way for 
        PCE to get the wavelength information.<BR></FONT><FONT 
        color=#808000>[Bardalai, Snigdho] Since the PCE is the location where 
        path-computation takes place is it possible to limit LSA advertisements 
        from PCC to PCE neighbors, instead of to every PCC 
neighbor?</FONT></DIV>
        <DIV><FONT color=#800000>[Dan] You are right, PCC which doesn't do the 
        path-computation doesn't need this kind of information.</FONT></DIV>
        <DIV><FONT color=#800000><FONT color=#cc0000>[Adrian] This is an 
        important point which you raised in conversation with me in Dublin: it 
        is possible to consider using link-local scope flooding of RWA 
        information from PCC to PCE so that it goes no further. But there is a 
        clear trade-off... with how many PCCs will a PCE be required to maintain 
        an IGP association? There is also a quesiton to be answered about the 
        function required for restoration - how much information does the 
        head-end LSR need to perform rapid, "best-effort" path computation to 
        restore LSPs after a network failure? This information *does* need to be 
        flooded. The informaiton model I-D is intended to help with this 
        question.</FONT><BR></FONT><BR>3. Flooding and refresh of static and 
        dynamic link state updates<BR><FONT color=#000080>[Dan] Try to figure 
        out the impact to the performance of IGP.<BR></FONT><FONT 
        color=#808000>[Bardalai, Snigdho] Is it possible to limit refreshing of 
        static LSA? Ex. using the OSPF "do not age" concept?</FONT></DIV>
        <DIV><FONT color=#800000>[Dan] Yes, it's possible to take this way to 
        reduce the protocol traffic. But we should consider the scenario when a 
        node gets restart or goes down, so the HELLO message may still need to 
        be kept.</FONT></DIV>
        <DIV><FONT color=#800000><FONT color=#cc0000>[Adrian] Yes. You are both 
        right. We should treat "static" as truely static and not needing 
        refresh. We can handle node-down and link-down events without the need 
        to time out the LSAs containing the static data if we link the behavior 
        to the time-out of other node/link information. But we *do* need to 
        consider the amount of information that will be held in LSA DBs and need 
        to be flooded at start of day and in node restart as 
        below.</FONT><BR></FONT><BR>4. Data base sync-up during node 
        restarts<BR><FONT color=#000080>[Dan] Yes, this should be considered. 
        Especially the very large amount of data will be sent to the restarting 
        node. We may consider the point to point data exchange instead of 
        flooding the LSA updates. Or slice the big data packet into small 
        pieces.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] This is little 
        tricky, I would be interested to see if there is a clean 
        solution.</FONT></DIV>
        <DIV><FONT color=#cc0000>[Adrian] An important point to consider (in 
        OSPF) is what happens in a lossy environment if the LSA gets very large. 
        In this case it will be fragmented into very many IP packets and there 
        will be a good statistical likelihood of at least one packet being lost. 
        That means that the LSA might never get delivered whiled the DCN will 
        get hammered. One solution (thanks, Igor) is to break the information 
        down into smaller LSAs. Since the information is essentially lists or 
        matrices, this is quite easy to do.</FONT></DIV>
        <DIV><FONT color=#808000><BR></FONT>Could you please let me know if the 
        above is within the current scope? I believe that these are important. 
        <BR><FONT color=#cc0000>[Adrian] Very much in scope!</FONT></DIV>
        <DIV><FONT color=#cc0000></FONT>&nbsp;</DIV>
        <DIV><FONT color=#cc0000>Cheers,</FONT></DIV>
        <DIV><FONT 
      color=#cc0000>Adrian</FONT></DIV></BLOCKQUOTE><BR></DIV></DIV></DIV><BR></BLOCKQUOTE></DIV></DIV></DIV><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)--

Delivery-date: Mon, 18 Aug 2008 19:46:20 +0000
Reply-To: <[email-masked]>
From: "Tony Li" <[email-masked]>
To: "'Igor Bryskin'" <[email-masked]>, "'Dan Li'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Date: Mon, 18 Aug 2008 12:43:27 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0126_01C90130.10DE6C80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Igor, Dan,
 
Perhaps there's an important distinction to be made here.  Typically, having
an IGP carry lambda connectivity status isn't a significant issue, as that
should only change when there is a significant failure.  Debouncing
techniques should be used to prevent any connectivity oscillations.
 
However, carrying lambda utilization status in the IGP is not going to prove
practical, as the continued series of updates would easily lead to IGP
thrash if done at anything approaching real-time.  Note that carrying
utlization on a low-frequency basis (e.g., cycle time of 1 minute) is
probably not an issue for networks of reasonable scale.  This of course
won't match many folks' requirements for 'real-time'.
 
Tony

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: Dan Li; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Dan,

That's the point. How does PCE maintain the lambda availability status? PCE
architecture shyly puts this problem out of its scope, but the only known
way today for the PCE is to participate in one or more IGP-TEor BGP-TE
routing protocols. So, in this respect it does not matter whether paths are
computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <[email-masked]>
To: Igor Bryskin <[email-masked]>; [email-masked];
[email-masked]; [email-masked]
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda
available status should be precise and real time updated. If we do the path
computation in distribute way, this would be a big problem because of the TE
link lambda available status may not be updated right away. But we can do it
in centralized way to minimized this problem. For example, using PCE and if
the PCE can maintain the TE link lambda available status, this may not be a
problem because all the path computation requests are in the queue of PCE,
and PCE knows which lambda is available.
 
Regards,
 
Dan

----- Original Message ----- 
From: Igor Bryskin <mailto:[email-masked]>  
To: [email-masked] ; [email-masked] ;
[email-masked] ; [email-masked] 
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

I have the following comments on this draft. I was wondering what were the
objectives for the IGP evaluation. IMHO the evaluation from WSON perspective
should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON 
[Dan] With the situation that TE information is already be carried by IGP,
it's nature to think that the wavelength information can also be carried by
IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE
link information vs. advertising TE link lambda availability. When OSPF TE
speaker advertises TE link info it, apart from link statical information, is
pretty much saying : "I have 70% of bandwdith availbale on priority p". For
the path computer (say, PCE) it is almost always not important if the link
has actually 75%, 70% or 60% of available bandwidth. However, lambda
availability (like pregnancy) is boolen: either it is there ot it is not.
PCE which perfoms path computation in terms of lambdas, unfortunately. must
have almost momentarily lambda availability states. With the speed of TE
info flooding current IGP-TE protocols have to offer, such mechanism will
not work on dynamic networks. And in any case one can never rely on PCE
during recovery path computations. These limitations. I think, should be
clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for
this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a
liitle bit longer when the entire network restarts. Because the WSON
information is added in the OSPF LSA. During the network running normally,
the update of wavelength availability information doesn't impact the IGP
performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without
an implementation (I used to have one :-), the concern is that adding the
RWA information to the IGP might mean that there was simply too much
information to be distributed. What Dan's draft is trying to do is show the
dimensions of the information and how dynamic it is. From this, we can
quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP
routing, but I guess we should consider that it is possible that the DCN
will be a real IP network carrying other traffic and that we need to not
disrupt IGP convergence in that network. Mechanisms exist (or are being
developed) to make that safe, and Dan's I-D should be able to tell us how
important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation
takes place is it possible to limit LSA advertisements from PCC to PCE
neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need
this kind of information.
[Adrian] This is an important point which you raised in conversation with me
in Dublin: it is possible to consider using link-local scope flooding of RWA
information from PCC to PCE so that it goes no further. But there is a clear
trade-off... with how many PCCs will a PCE be required to maintain an IGP
association? There is also a quesiton to be answered about the function
required for restoration - how much information does the head-end LSR need
to perform rapid, "best-effort" path computation to restore LSPs after a
network failure? This information *does* need to be flooded. The informaiton
model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex.
using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic.
But we should consider the scenario when a node gets restart or goes down,
so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static
and not needing refresh. We can handle node-down and link-down events
without the need to time out the LSAs containing the static data if we link
the behavior to the time-out of other node/link information. But we *do*
need to consider the amount of information that will be held in LSA DBs and
need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of
data will be sent to the restarting node. We may consider the point to point
data exchange instead of flooding the LSA updates. Or slice the big data
packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if
there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy
environment if the LSA gets very large. In this case it will be fragmented
into very many IP packets and there will be a good statistical likelihood of
at least one packet being lost. That means that the LSA might never get
delivered whiled the DCN will get hammered. One solution (thanks, Igor) is
to break the information down into smaller LSAs. Since the information is
essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I
believe that these are important. 
[Adrian] Very much in scope!
 
Cheers,
Adrian

------=_NextPart_000_0126_01C90130.10DE6C80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial =
color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D500343719-18082008><FONT =
face=3DArial=20
color=3D#0000ff>Igor, Dan,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D500343719-18082008><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D500343719-18082008></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff>P<SPAN =
class=3D500343719-18082008>erhaps there's an=20
important distinction to be made here.&nbsp; Typically, having an IGP =
carry=20
lambda&nbsp;connectivity status&nbsp;isn't a significant issue, as that =
should=20
only change when there is a significant failure.&nbsp; Debouncing =
techniques=20
should be used to prevent any connectivity=20
oscillations.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D500343719-18082008>However, carrying lambda utilization status =
in the IGP=20
is not going to prove practical, as the continued series of updates =
would easily=20
lead to IGP thrash if done at anything approaching real-time.&nbsp; Note =
that=20
carrying utlization on a low-frequency basis (e.g., cycle time of 1 =
minute) is=20
probably not an issue for networks of reasonable scale.&nbsp; This of =
course=20
won't match many folks' requirements for =
'real-time'.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D500343719-18082008>Tony</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D500343719-18082008></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Igor=20
  Bryskin<BR><B>Sent:</B> Monday, August 18, 2008 8:15 AM<BR><B>To:</B> =
Dan Li;=20
  [email-masked]; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> Re: Comments on=20
  'draft-li-ccamp-wson-igp-eval-01.txt'<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, =
times, serif">
  <DIV>Dan,<BR><BR>That's the point. How does PCE maintain the lambda=20
  availability status? PCE architecture shyly puts this problem out of =
its=20
  scope, but the only known way today for the PCE is to participate in =
one or=20
  more IGP-TEor BGP-TE routing protocols. So, in this respect it does =
not matter=20
  whether paths are computed locally or via PCE =
service.<BR><BR>Igor<BR></DIV>
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><BR>
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">-----=20
  Original Message ----<BR>From: Dan Li &lt;[email-masked]&gt;<BR>To: =
Igor=20
  Bryskin &lt;[email-masked]&gt;; [email-masked];=20
  [email-masked]; [email-masked]<BR>Sent: Friday, =
August=20
  15, 2008 1:55:04 AM<BR>Subject: Re: Comments on=20
  'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR>
  <STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

  <DIV>Hi Igor,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>You're right, when we doing the path computation,&nbsp;the TE =
link lambda=20
  available status should be precise and real time updated. If we do the =
path=20
  computation in distribute way, this would be a big problem because of =
the TE=20
  link lambda available status may not be updated right away. But we can =
do it=20
  in centralized way to minimized this problem. For example, using PCE =
and if=20
  the PCE can maintain the TE link lambda available status, this may not =
be a=20
  problem because all the path computation requests are in the queue of =
PCE, and=20
  PCE knows which lambda is available.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Dan</DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
    <DIV>----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: rgb(228,228,228); -moz-background-clip: =
-moz-initial; -moz-background-origin: -moz-initial; =
-moz-background-inline-policy: -moz-initial"><B>From:</B>=20
    <A title=[email-masked] href=3D"mailto:[email-masked]" =
target=3D_blank=20
    rel=3Dnofollow ymailto=3D"mailto:[email-masked]">Igor =
Bryskin</A> </DIV>
    <DIV><B>To:</B> <A title=[email-masked]=20
    href=3D"mailto:[email-masked]" target=3D_blank rel=3Dnofollow=20
    ymailto=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]" target=3D_blank =
rel=3Dnofollow=20
    =
ymailto=3D"mailto:[email-masked]">[email-masked]=
jitsu.com</A>=20
    ; <A title=[email-masked] href=3D"mailto:[email-masked]" =
target=3D_blank=20
    rel=3Dnofollow =
ymailto=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
    title=[email-masked] href=3D"mailto:[email-masked]" =
target=3D_blank=20
    rel=3Dnofollow =
ymailto=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV><B>Sent:</B> Tuesday, August 12, 2008 4:25 AM</DIV>
    <DIV><B>Subject:</B> Re: Comments on=20
    'draft-li-ccamp-wson-igp-eval-01.txt'</DIV>
    <DIV><BR></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">
    <DIV>Hi,<BR><BR>Please, see my comment in line. Look for=20
    IB&gt;&gt;<BR><BR>Cheers,<BR>Igor<BR></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><BR>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">-----=20
    Original Message ----<BR>From: Adrian Farrel &lt;<A=20
    href=3D"mailto:[email-masked]" target=3D_blank rel=3Dnofollow=20
    =
ymailto=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>To:=
 <A=20
    href=3D"mailto:[email-masked]" target=3D_blank =
rel=3Dnofollow=20
    =
ymailto=3D"mailto:[email-masked]">[email-masked]=
jitsu.com</A>;=20
    <A href=3D"mailto:[email-masked]" target=3D_blank rel=3Dnofollow =

    ymailto=3D"mailto:[email-masked]">[email-masked]</A>; <A=20
    href=3D"mailto:[email-masked]" target=3D_blank rel=3Dnofollow=20
    ymailto=3D"mailto:[email-masked]">[email-masked]</A><BR>Sent: =
Monday,=20
    August 11, 2008 1:24:50 PM<BR>Subject: Re: Comments on=20
    'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR>
    <DIV>Hi,</DIV>
    <BLOCKQUOTE=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(245,245,245) 2px solid; MARGIN-RIGHT: 0px">
      <DIV>I have the following comments on this draft. I was wondering =
what=20
      were the objectives for the IGP evaluation. IMHO the evaluation =
from WSON=20
      perspective should address the following:<BR>1. IGP usage in the =
context=20
      of traditional distributed solutions for WSON <BR><FONT=20
      color=3D#000080>[Dan] With the situation that TE information is =
already be=20
      carried by IGP, it's nature to think that the wavelength =
information can=20
      also be carried by IGP. I am not saying it should be, but it's =
worth to=20
      look at.<BR><BR>IB&gt;&gt; There is an important difference in=20
      requirements for advertising of TE link information vs. =
advertising TE=20
      link lambda availability. When OSPF TE speaker advertises TE link =
info it,=20
      apart from link statical information, is pretty much saying : "I =
have 70%=20
      of bandwdith availbale on priority p". For the path computer (say, =
PCE) it=20
      is almost always not important if the link has actually 75%, 70% =
or 60% of=20
      available bandwidth. However, lambda availability (like pregnancy) =
is=20
      boolen: either it is there ot it is not. PCE which perfoms path=20
      computation in terms of lambdas, unfortunately. must have almost=20
      momentarily lambda availability states. With the speed of TE info =
flooding=20
      current IGP-TE protocols have to offer, such mechanism will not =
work on=20
      dynamic networks. And in any case one can never rely on PCE during =

      recovery path computations. These limitations. I think, should be =
clearly=20
      stated in the document.<BR><BR></FONT><FONT =
color=3D#808000>[Bardalai,=20
      Snigdho] Do you see any particular issues with using the IGP for =
this=20
      purpose ?</FONT></DIV>
      <DIV><FONT color=3D#800000>[Dan] From the result of the =
simulation,&nbsp;the=20
      OSPF convergency time&nbsp;takes a liitle bit longer when the =
entire=20
      network restarts. Because&nbsp;the WSON information is added in =
the OSPF=20
      LSA.&nbsp;During the network running normally, the update of =
wavelength=20
      availability information&nbsp;doesn't&nbsp;impact the IGP =
performance=20
      obviously.</FONT></DIV>
      <DIV><FONT color=3D#cc0000>[Adrian] Certainly, from the point of =
view of=20
      someone coming at this without an implementation (I used&nbsp;to =
have one=20
      :-), the concern is that adding the RWA information to the IGP =
might mean=20
      that there was simply too much information to be distributed. What =
Dan's=20
      draft is trying to do is show the dimensions of the information=20
      and&nbsp;how dynamic it is. From this, we can quickly see how =
things will=20
      scale.</FONT></DIV>
      <DIV><FONT color=3D#800000><FONT color=3D#cc0000>I do not believe =
that there=20
      is an issue with the interaction with IP routing, but I guess we =
should=20
      consider that it is possible that the DCN will be a real IP =
network=20
      carrying other traffic and that we need to not disrupt IGP =
convergence in=20
      that network. Mechanisms exist (or are being developed) to make =
that safe,=20
      and Dan's I-D should be able to tell us how important it is to use =

      them.</FONT><BR></FONT>&nbsp;<BR>2. IGP usage in the context of =
PCE=20
      solutions for WSON<BR><FONT color=3D#000080>[Dan] It's a potential =
way for=20
      PCE to get the wavelength information.<BR></FONT><FONT=20
      color=3D#808000>[Bardalai, Snigdho] Since the PCE is the location =
where=20
      path-computation takes place is it possible to limit LSA =
advertisements=20
      from PCC to PCE neighbors, instead of to every PCC =
neighbor?</FONT></DIV>
      <DIV><FONT color=3D#800000>[Dan] You are right, PCC which doesn't =
do the=20
      path-computation doesn't need this kind of =
information.</FONT></DIV>
      <DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] This is =
an important=20
      point which you raised in conversation with me in Dublin: it is =
possible=20
      to consider using link-local scope flooding of RWA information =
from PCC to=20
      PCE so that it goes no further. But there is a clear trade-off... =
with how=20
      many PCCs will a PCE be required to maintain an IGP association? =
There is=20
      also a quesiton to be answered about the function required for =
restoration=20
      - how much information does the head-end LSR need to perform =
rapid,=20
      "best-effort" path computation to restore LSPs after a network =
failure?=20
      This information *does* need to be flooded. The informaiton model =
I-D is=20
      intended to help with this question.</FONT><BR></FONT><BR>3. =
Flooding and=20
      refresh of static and dynamic link state updates<BR><FONT=20
      color=3D#000080>[Dan] Try to figure out the impact to the =
performance of=20
      IGP.<BR></FONT><FONT color=3D#808000>[Bardalai, Snigdho] Is it =
possible to=20
      limit refreshing of static LSA? Ex. using the OSPF "do not age"=20
      concept?</FONT></DIV>
      <DIV><FONT color=3D#800000>[Dan] Yes, it's possible to take this =
way to=20
      reduce the protocol traffic. But we should consider the scenario =
when a=20
      node gets restart or goes down, so the HELLO message may still =
need to be=20
      kept.</FONT></DIV>
      <DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] Yes. You =
are both=20
      right. We should treat "static" as truely static and not needing =
refresh.=20
      We can handle node-down and link-down events without the need to =
time out=20
      the LSAs containing the static data if we link the behavior to the =

      time-out of other node/link information. But we *do* need to =
consider the=20
      amount of information that will be held in LSA DBs and need to be =
flooded=20
      at start of day and in node restart as =
below.</FONT><BR></FONT><BR>4. Data=20
      base sync-up during node restarts<BR><FONT color=3D#000080>[Dan] =
Yes, this=20
      should be considered. Especially the very large amount of data =
will be=20
      sent to the restarting node. We may consider the point to point =
data=20
      exchange instead of flooding the LSA updates. Or slice the big =
data packet=20
      into small pieces.<BR></FONT><FONT color=3D#808000>[Bardalai, =
Snigdho] This=20
      is little tricky, I would be interested to see if there is a clean =

      solution.</FONT></DIV>
      <DIV><FONT color=3D#cc0000>[Adrian] An important point to consider =
(in OSPF)=20
      is what happens in a lossy environment if the LSA gets very large. =
In this=20
      case it will be fragmented into very many IP packets and there =
will be a=20
      good statistical likelihood of at least one packet being lost. =
That means=20
      that the LSA might never get delivered whiled the DCN will get =
hammered.=20
      One solution (thanks, Igor) is to break the information down into =
smaller=20
      LSAs. Since the information is essentially lists or matrices, this =
is=20
      quite easy to do.</FONT></DIV>
      <DIV><FONT color=3D#808000><BR></FONT>Could you please let me know =
if the=20
      above is within the current scope? I believe that these are =
important.=20
      <BR><FONT color=3D#cc0000>[Adrian] Very much in =
scope!</FONT></DIV>
      <DIV><FONT color=3D#cc0000></FONT>&nbsp;</DIV>
      <DIV><FONT color=3D#cc0000>Cheers,</FONT></DIV>
      <DIV><FONT=20
    =
color=3D#cc0000>Adrian</FONT></DIV></BLOCKQUOTE><BR></DIV></DIV></DIV><BR=
></BLOCKQUOTE></DIV></DIV></DIV><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0126_01C90130.10DE6C80--

Delivery-date: Mon, 18 Aug 2008 15:17:13 +0000
Date: Mon, 18 Aug 2008 08:15:26 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
To: Dan Li <[email-masked]>, [email-masked], [email-masked], [email-masked]

--0-391644484-1219072526=:51910
Content-Type: text/plain; charset=us-ascii

Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <[email-masked]>
To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda 
available status should be precise and real time updated. If we do the path 
computation in distribute way, this would be a big problem because of the TE 
link lambda available status may not be updated right away. But we can do it in 
centralized way to minimized this problem. For example, using PCE and if the PCE 
can maintain the TE link lambda available status, this may not be a problem 
because all the path computation requests are in the queue of PCE, and PCE knows 
which lambda is available.
 
Regards,
 
Dan
----- Original Message ----- 
From: Igor  Bryskin 
To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on  'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for  IB>>

Cheers,
Igor

-----  Original Message ----
From: Adrian Farrel <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, August  11, 2008 1:24:50 PM
Subject: Re: Comments on  'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were  the objectives for the IGP evaluation. IMHO the evaluation from WSON  perspective should address the following:
1. IGP usage in the context of  traditional distributed solutions for WSON 
[Dan]  With the situation that TE information is already be carried by IGP, it's  nature to think that the wavelength information can also be carried by IGP.  I am not saying it should be, but it's worth to look at.

IB>>  There is an important difference in requirements for advertising of TE link  information vs. advertising TE link lambda availability. When OSPF TE  speaker advertises TE link info it, apart from link statical information, is  pretty much saying : "I have 70% of bandwdith availbale on priority p". For  the path computer (say, PCE) it is almost always not important if the link  has actually 75%, 70% or 60% of available bandwidth. However, lambda  availability (like pregnancy) is boolen: either it is there ot it is not.  PCE which perfoms path computation in terms of lambdas, unfortunately. must  have almost momentarily lambda availability states. With the speed of TE  info flooding current IGP-TE protocols have to offer, such mechanism will  not work on dynamic networks. And in any case one can never rely on PCE  during recovery path computations. These limitations. I think, should be  clearly stated in the document.

[Bardalai,  Snigdho] Do you see any particular issues with using the IGP for this  purpose ?
[Dan] From the result of the simulation, the  OSPF convergency time takes a liitle bit longer when the entire network  restarts. Because the WSON information is added in the OSPF  LSA. During the network running normally, the update of wavelength  availability information doesn't impact the IGP performance  obviously.
[Adrian] Certainly, from the point of view of  someone coming at this without an implementation (I used to have one  :-), the concern is that adding the RWA information to the IGP might mean  that there was simply too much information to be distributed. What Dan's  draft is trying to do is show the dimensions of the information and how  dynamic it is. From this, we can quickly see how things will  scale.
I do not believe that there is  an issue with the interaction with IP routing, but I guess we should  consider that it is possible that the DCN will be a real IP network carrying  other traffic and that we need to not disrupt IGP convergence in that  network. Mechanisms exist (or are being developed) to make that safe, and  Dan's I-D should be able to tell us how important it is to use  them.
 
2. IGP usage in the context of PCE  solutions for WSON
[Dan] It's a potential way for PCE  to get the wavelength information.
[Bardalai,  Snigdho] Since the PCE is the location where path-computation takes place is  it possible to limit LSA advertisements from PCC to PCE neighbors, instead  of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the  path-computation doesn't need this kind of information.
[Adrian] This is an important  point which you raised in conversation with me in Dublin: it is possible to  consider using link-local scope flooding of RWA information from PCC to PCE  so that it goes no further. But there is a clear trade-off... with how many  PCCs will a PCE be required to maintain an IGP association? There is also a  quesiton to be answered about the function required for restoration - how  much information does the head-end LSR need to perform rapid, "best-effort"  path computation to restore LSPs after a network failure? This information  *does* need to be flooded. The informaiton model I-D is intended to help  with this question.

3. Flooding and refresh of static  and dynamic link state updates
[Dan] Try to figure  out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of  static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce  the protocol traffic. But we should consider the scenario when a node gets  restart or goes down, so the HELLO message may still need to be  kept.
[Adrian] Yes. You are both  right. We should treat "static" as truely static and not needing refresh. We  can handle node-down and link-down events without the need to time out the  LSAs containing the static data if we link the behavior to the time-out of  other node/link information. But we *do* need to consider the amount of  information that will be held in LSA DBs and need to be flooded at start of  day and in node restart as below.

4. Data base sync-up  during node restarts
[Dan] Yes, this should be  considered. Especially the very large amount of data will be sent to the  restarting node. We may consider the point to point data exchange instead of  flooding the LSA updates. Or slice the big data packet into small  pieces.
[Bardalai, Snigdho] This is little  tricky, I would be interested to see if there is a clean  solution.
[Adrian] An important point to consider (in OSPF)  is what happens in a lossy environment if the LSA gets very large. In this  case it will be fragmented into very many IP packets and there will be a  good statistical likelihood of at least one packet being lost. That means  that the LSA might never get delivered whiled the DCN will get hammered. One  solution (thanks, Igor) is to break the information down into smaller LSAs.  Since the information is essentially lists or matrices, this is quite easy  to do.

Could you please let me know if the  above is within the current scope? I believe that these are important. 
[Adrian] Very much in scope!
 
Cheers,
Adrian

--0-391644484-1219072526=:51910
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Dan,<br><br>That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.<br><br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Dan Li &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; [email-masked]; [email-masked]; [email-masked]<br>Sent: Friday, August 15, 2008 1:55:04 AM<br>Subject: Re: Comments on
 'draft-li-ccamp-wson-igp-eval-01.txt'<br><br><style type="text/css">DIV {
MARGIN:0px;}
</style> 

<div>Hi Igor,</div><div>&nbsp;</div><div>You're right, when we doing the path computation,&nbsp;the TE link lambda 
available status should be precise and real time updated. If we do the path 
computation in distribute way, this would be a big problem because of the TE 
link lambda available status may not be updated right away. But we can do it in 
centralized way to minimized this problem. For example, using PCE and if the PCE 
can maintain the TE link lambda available status, this may not be a problem 
because all the path computation requests are in the queue of PCE, and PCE knows 
which lambda is available.</div><div>&nbsp;</div><div>Regards,</div><div>&nbsp;</div><div>Dan</div><blockquote style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;"><div style="">----- Original Message ----- </div><div style="background: rgb(228, 228, 228) none repeat scroll 0% 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><b>From:</b>  <a rel="nofollow" title="[email-masked]" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">Igor 
  Bryskin</a> </div><div style=""><b>To:</b> <a rel="nofollow" title="[email-masked]" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> ; <a rel="nofollow" title="[email-masked]" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> 
  ; <a rel="nofollow" title="[email-masked]" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> ; <a rel="nofollow" title="[email-masked]" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>  </div><div style=""><b>Sent:</b> Tuesday, August 12, 2008 4:25 AM</div><div style=""><b>Subject:</b> Re: Comments on 
  'draft-li-ccamp-wson-igp-eval-01.txt'</div><div><br></div><div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><div>Hi,<br><br>Please, see my comment in line. Look for 
  IB&gt;&gt;<br><br>Cheers,<br>Igor<br></div><div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><br><div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">----- 
  Original Message ----<br>From: Adrian Farrel &lt;<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>To: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>; 
  <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a><br>Sent: Monday, August 
  11, 2008 1:24:50 PM<br>Subject: Re: Comments on 
  'draft-li-ccamp-wson-igp-eval-01.txt'<br><br><div>Hi,</div><blockquote style="border-left: 2px solid rgb(245, 245, 245); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;"><div>I have the following comments on this draft. I was wondering what were 
    the objectives for the IGP evaluation. IMHO the evaluation from WSON 
    perspective should address the following:<br>1. IGP usage in the context of 
    traditional distributed solutions for WSON <br><font color="#000080">[Dan] 
    With the situation that TE information is already be carried by IGP, it's 
    nature to think that the wavelength information can also be carried by IGP. 
    I am not saying it should be, but it's worth to look at.<br><br>IB&gt;&gt; 
    There is an important difference in requirements for advertising of TE link 
    information vs. advertising TE link lambda availability. When OSPF TE 
    speaker advertises TE link info it, apart from link statical information, is 
    pretty much saying : "I have 70% of bandwdith availbale on priority p". For 
    the path computer (say, PCE) it is almost always not important if the link 
    has actually 75%, 70% or 60% of available bandwidth. However, lambda 
    availability (like pregnancy) is boolen: either it is there ot it is not. 
    PCE which perfoms path computation in terms of lambdas, unfortunately. must 
    have almost momentarily lambda availability states. With the speed of TE 
    info flooding current IGP-TE protocols have to offer, such mechanism will 
    not work on dynamic networks. And in any case one can never rely on PCE 
    during recovery path computations. These limitations. I think, should be 
    clearly stated in the document.<br><br></font><font color="#808000">[Bardalai, 
    Snigdho] Do you see any particular issues with using the IGP for this 
    purpose ?</font></div><div><font color="#800000">[Dan] From the result of the simulation,&nbsp;the 
    OSPF convergency time&nbsp;takes a liitle bit longer when the entire network 
    restarts. Because&nbsp;the WSON information is added in the OSPF 
    LSA.&nbsp;During the network running normally, the update of wavelength 
    availability information&nbsp;doesn't&nbsp;impact the IGP performance 
    obviously.</font></div><div><font color="#cc0000">[Adrian] Certainly, from the point of view of 
    someone coming at this without an implementation (I used&nbsp;to have one 
    :-), the concern is that adding the RWA information to the IGP might mean 
    that there was simply too much information to be distributed. What Dan's 
    draft is trying to do is show the dimensions of the information and&nbsp;how 
    dynamic it is. From this, we can quickly see how things will 
    scale.</font></div><div><font color="#800000"><font color="#cc0000">I do not believe that there is 
    an issue with the interaction with IP routing, but I guess we should 
    consider that it is possible that the DCN will be a real IP network carrying 
    other traffic and that we need to not disrupt IGP convergence in that 
    network. Mechanisms exist (or are being developed) to make that safe, and 
    Dan's I-D should be able to tell us how important it is to use 
    them.</font><br></font>&nbsp;<br>2. IGP usage in the context of PCE 
    solutions for WSON<br><font color="#000080">[Dan] It's a potential way for PCE 
    to get the wavelength information.<br></font><font color="#808000">[Bardalai, 
    Snigdho] Since the PCE is the location where path-computation takes place is 
    it possible to limit LSA advertisements from PCC to PCE neighbors, instead 
    of to every PCC neighbor?</font></div><div><font color="#800000">[Dan] You are right, PCC which doesn't do the 
    path-computation doesn't need this kind of information.</font></div><div><font color="#800000"><font color="#cc0000">[Adrian] This is an important 
    point which you raised in conversation with me in Dublin: it is possible to 
    consider using link-local scope flooding of RWA information from PCC to PCE 
    so that it goes no further. But there is a clear trade-off... with how many 
    PCCs will a PCE be required to maintain an IGP association? There is also a 
    quesiton to be answered about the function required for restoration - how 
    much information does the head-end LSR need to perform rapid, "best-effort" 
    path computation to restore LSPs after a network failure? This information 
    *does* need to be flooded. The informaiton model I-D is intended to help 
    with this question.</font><br></font><br>3. Flooding and refresh of static 
    and dynamic link state updates<br><font color="#000080">[Dan] Try to figure 
    out the impact to the performance of IGP.<br></font><font color="#808000">[Bardalai, Snigdho] Is it possible to limit refreshing of 
    static LSA? Ex. using the OSPF "do not age" concept?</font></div><div><font color="#800000">[Dan] Yes, it's possible to take this way to reduce 
    the protocol traffic. But we should consider the scenario when a node gets 
    restart or goes down, so the HELLO message may still need to be 
    kept.</font></div><div><font color="#800000"><font color="#cc0000">[Adrian] Yes. You are both 
    right. We should treat "static" as truely static and not needing refresh. We 
    can handle node-down and link-down events without the need to time out the 
    LSAs containing the static data if we link the behavior to the time-out of 
    other node/link information. But we *do* need to consider the amount of 
    information that will be held in LSA DBs and need to be flooded at start of 
    day and in node restart as below.</font><br></font><br>4. Data base sync-up 
    during node restarts<br><font color="#000080">[Dan] Yes, this should be 
    considered. Especially the very large amount of data will be sent to the 
    restarting node. We may consider the point to point data exchange instead of 
    flooding the LSA updates. Or slice the big data packet into small 
    pieces.<br></font><font color="#808000">[Bardalai, Snigdho] This is little 
    tricky, I would be interested to see if there is a clean 
    solution.</font></div><div><font color="#cc0000">[Adrian] An important point to consider (in OSPF) 
    is what happens in a lossy environment if the LSA gets very large. In this 
    case it will be fragmented into very many IP packets and there will be a 
    good statistical likelihood of at least one packet being lost. That means 
    that the LSA might never get delivered whiled the DCN will get hammered. One 
    solution (thanks, Igor) is to break the information down into smaller LSAs. 
    Since the information is essentially lists or matrices, this is quite easy 
    to do.</font></div><div><font color="#808000"><br></font>Could you please let me know if the 
    above is within the current scope? I believe that these are important. 
    <br><font color="#cc0000">[Adrian] Very much in scope!</font></div><div><font color="#cc0000"></font>&nbsp;</div><div><font color="#cc0000">Cheers,</font></div><div><font color="#cc0000">Adrian</font></div></blockquote><br></div></div></div><br></blockquote></div></div></div><br>

      </body></html>
--0-391644484-1219072526=:51910--

Delivery-date: Fri, 15 Aug 2008 15:17:07 +0000
Content-class: urn:content-classes:message
Subject: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was  MPLS over OTN)
Date: Fri, 15 Aug 2008 17:15:58 +0200
From: "Diego Caviglia" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Diego Caviglia" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Stewart,
           I think i agree here.

Even if i'm coming from sdh i don'e see the need to hane osi capability
in brand new mpls-tp boxes.

Br

Diego

Delivery-date: Fri, 15 Aug 2008 13:45:32 +0000
Date: Fri, 15 Aug 2008 14:43:22 +0100
Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was  MPLS over OTN)
From: Ben Niven-Jenkins <[email-masked]>
To: Maarten Vissers <[email-masked]>, <[email-masked]>, 'Adrian Farrel' <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, 'Italo Busi' <[email-masked]>

Maarten,

I agree that OSI is still present in many transport network elements and
therefore DCN support for OSI will be required for some DCNs.

However, does this lead to a requirement that MPLS-TP equipment *must*
support OSI?

Modern transport gear also supports IP for DCN and this is the direction
many operators are choosing to move.

So it would appear to me that the requirements placed on DCN design in
general are different to the requirements placed on the transport equipment
itself (which will be controlled via the DCN).

Let me use BT's transmission DCN as an example - we have a significant sized
DCN consisting of several thousand routers/switches (just for the
transmission DCN itself).  It supports both OSI and IP.  Therefore we are
able to accommodate new transport equipment control via IP while maintaining
control of old transport equipment via OSI.

Ben

On 15/08/2008 00:27, "Maarten Vissers" <[email-masked]> wrote:

> Do routers today only support IPv6, or are there still many of the older
> protocols supported? I assume it is the latter case, as it is difficult to
> switch off support for older protocols as long as its original equipment is
> still present at some places in the network. I.e. wouldn't it be in the long
> term economic interest of the customer to migrate to IPv6 only? When do you
> think you can switch of support for IPv4 and older protocols in the routers?
> 
> With OSI in the DCN we have a similar situation. It is still present in many
> network elements and must as such be supported within the existing and
> future DCN.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: 11 August 2008 13:52
> To: Adrian Farrel
> Cc: Maarten Vissers; 'Diego Caviglia'; 'Italo Busi'; 'Francesco Fondelli';
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)
> 
> These control channels are the last vestige of OSI in modern networks (apart
> from ISIS which is alive and well). Surely it is in the long term economic
> interests of the customer (infrastructure equipment costs, training,
> commonality etc)  to migrate to IP?
> 
> Stewart
>> 
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Fri, 15 Aug 2008 05:57:17 +0000
Date: Fri, 15 Aug 2008 13:55:04 +0800
From: Dan Li <[email-masked]>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
To: Igor Bryskin <[email-masked]>, [email-masked], [email-masked], [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Igor,

You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.

Regards,

Dan
  ----- Original Message ----- 
  From: Igor Bryskin 
  To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, August 12, 2008 4:25 AM
  Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

  Hi,

  Please, see my comment in line. Look for IB>>

  Cheers,
  Igor

  ----- Original Message ----
  From: Adrian Farrel <[email-masked]>
  To: [email-masked]; [email-masked]; [email-masked]
  Sent: Monday, August 11, 2008 1:24:50 PM
  Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

  Hi,
    I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
    1. IGP usage in the context of traditional distributed solutions for WSON 
    [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

    IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

    [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
    [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
    [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
    I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
     
    2. IGP usage in the context of PCE solutions for WSON
    [Dan] It's a potential way for PCE to get the wavelength information.
    [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
    [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
    [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

    3. Flooding and refresh of static and dynamic link state updates
    [Dan] Try to figure out the impact to the performance of IGP.
    [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
    [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
    [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

    4. Data base sync-up during node restarts
    [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
    [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
    [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

    Could you please let me know if the above is within the current scope? I believe that these are important. 
    [Adrian] Very much in scope!

    Cheers,
    Adrian

--Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE type=text/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content="MSHTML 6.00.2800.1561" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV>Hi Igor,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You're right, when we doing the path computation,&nbsp;the TE link lambda 
available status should be precise and real time updated. If we do the path 
computation in distribute way, this would be a big problem because of the TE 
link lambda available status may not be updated right away. But we can do it in 
centralized way to minimized this problem. For example, using PCE and if the PCE 
can maintain the TE link lambda available status, this may not be a problem 
because all the path computation requests are in the queue of PCE, and PCE knows 
which lambda is available.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt &#23435;&#20307;; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Igor 
  Bryskin</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> 
  ; <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">[email-masked]</A> 
  </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Sent:</B> Tuesday, August 12, 2008 4:25 AM</DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Subject:</B> Re: Comments on 
  'draft-li-ccamp-wson-igp-eval-01.txt'</DIV>
  <DIV><BR></DIV>
  <DIV 
  style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
  <DIV>Hi,<BR><BR>Please, see my comment in line. Look for 
  IB&gt;&gt;<BR><BR>Cheers,<BR>Igor<BR></DIV>
  <DIV 
  style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif"><BR>
  <DIV 
  style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new york,times,serif">----- 
  Original Message ----<BR>From: Adrian Farrel &lt;<A 
  href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: <A 
  href="mailto:[email-masked]">[email-masked]</A>; 
  <A href="mailto:[email-masked]">[email-masked]</A>; <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>Sent: Monday, August 
  11, 2008 1:24:50 PM<BR>Subject: Re: Comments on 
  'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR>
  <DIV>Hi,</DIV>
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(245,245,245) 2px solid; MARGIN-RIGHT: 0px">
    <DIV>I have the following comments on this draft. I was wondering what were 
    the objectives for the IGP evaluation. IMHO the evaluation from WSON 
    perspective should address the following:<BR>1. IGP usage in the context of 
    traditional distributed solutions for WSON <BR><FONT color=#000080>[Dan] 
    With the situation that TE information is already be carried by IGP, it's 
    nature to think that the wavelength information can also be carried by IGP. 
    I am not saying it should be, but it's worth to look at.<BR><BR>IB&gt;&gt; 
    There is an important difference in requirements for advertising of TE link 
    information vs. advertising TE link lambda availability. When OSPF TE 
    speaker advertises TE link info it, apart from link statical information, is 
    pretty much saying : "I have 70% of bandwdith availbale on priority p". For 
    the path computer (say, PCE) it is almost always not important if the link 
    has actually 75%, 70% or 60% of available bandwidth. However, lambda 
    availability (like pregnancy) is boolen: either it is there ot it is not. 
    PCE which perfoms path computation in terms of lambdas, unfortunately. must 
    have almost momentarily lambda availability states. With the speed of TE 
    info flooding current IGP-TE protocols have to offer, such mechanism will 
    not work on dynamic networks. And in any case one can never rely on PCE 
    during recovery path computations. These limitations. I think, should be 
    clearly stated in the document.<BR><BR></FONT><FONT color=#808000>[Bardalai, 
    Snigdho] Do you see any particular issues with using the IGP for this 
    purpose ?</FONT></DIV>
    <DIV><FONT color=#800000>[Dan] From the result of the simulation,&nbsp;the 
    OSPF convergency time&nbsp;takes a liitle bit longer when the entire network 
    restarts. Because&nbsp;the WSON information is added in the OSPF 
    LSA.&nbsp;During the network running normally, the update of wavelength 
    availability information&nbsp;doesn't&nbsp;impact the IGP performance 
    obviously.</FONT></DIV>
    <DIV><FONT color=#cc0000>[Adrian] Certainly, from the point of view of 
    someone coming at this without an implementation (I used&nbsp;to have one 
    :-), the concern is that adding the RWA information to the IGP might mean 
    that there was simply too much information to be distributed. What Dan's 
    draft is trying to do is show the dimensions of the information and&nbsp;how 
    dynamic it is. From this, we can quickly see how things will 
    scale.</FONT></DIV>
    <DIV><FONT color=#800000><FONT color=#cc0000>I do not believe that there is 
    an issue with the interaction with IP routing, but I guess we should 
    consider that it is possible that the DCN will be a real IP network carrying 
    other traffic and that we need to not disrupt IGP convergence in that 
    network. Mechanisms exist (or are being developed) to make that safe, and 
    Dan's I-D should be able to tell us how important it is to use 
    them.</FONT><BR></FONT>&nbsp;<BR>2. IGP usage in the context of PCE 
    solutions for WSON<BR><FONT color=#000080>[Dan] It's a potential way for PCE 
    to get the wavelength information.<BR></FONT><FONT color=#808000>[Bardalai, 
    Snigdho] Since the PCE is the location where path-computation takes place is 
    it possible to limit LSA advertisements from PCC to PCE neighbors, instead 
    of to every PCC neighbor?</FONT></DIV>
    <DIV><FONT color=#800000>[Dan] You are right, PCC which doesn't do the 
    path-computation doesn't need this kind of information.</FONT></DIV>
    <DIV><FONT color=#800000><FONT color=#cc0000>[Adrian] This is an important 
    point which you raised in conversation with me in Dublin: it is possible to 
    consider using link-local scope flooding of RWA information from PCC to PCE 
    so that it goes no further. But there is a clear trade-off... with how many 
    PCCs will a PCE be required to maintain an IGP association? There is also a 
    quesiton to be answered about the function required for restoration - how 
    much information does the head-end LSR need to perform rapid, "best-effort" 
    path computation to restore LSPs after a network failure? This information 
    *does* need to be flooded. The informaiton model I-D is intended to help 
    with this question.</FONT><BR></FONT><BR>3. Flooding and refresh of static 
    and dynamic link state updates<BR><FONT color=#000080>[Dan] Try to figure 
    out the impact to the performance of IGP.<BR></FONT><FONT 
    color=#808000>[Bardalai, Snigdho] Is it possible to limit refreshing of 
    static LSA? Ex. using the OSPF "do not age" concept?</FONT></DIV>
    <DIV><FONT color=#800000>[Dan] Yes, it's possible to take this way to reduce 
    the protocol traffic. But we should consider the scenario when a node gets 
    restart or goes down, so the HELLO message may still need to be 
    kept.</FONT></DIV>
    <DIV><FONT color=#800000><FONT color=#cc0000>[Adrian] Yes. You are both 
    right. We should treat "static" as truely static and not needing refresh. We 
    can handle node-down and link-down events without the need to time out the 
    LSAs containing the static data if we link the behavior to the time-out of 
    other node/link information. But we *do* need to consider the amount of 
    information that will be held in LSA DBs and need to be flooded at start of 
    day and in node restart as below.</FONT><BR></FONT><BR>4. Data base sync-up 
    during node restarts<BR><FONT color=#000080>[Dan] Yes, this should be 
    considered. Especially the very large amount of data will be sent to the 
    restarting node. We may consider the point to point data exchange instead of 
    flooding the LSA updates. Or slice the big data packet into small 
    pieces.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] This is little 
    tricky, I would be interested to see if there is a clean 
    solution.</FONT></DIV>
    <DIV><FONT color=#cc0000>[Adrian] An important point to consider (in OSPF) 
    is what happens in a lossy environment if the LSA gets very large. In this 
    case it will be fragmented into very many IP packets and there will be a 
    good statistical likelihood of at least one packet being lost. That means 
    that the LSA might never get delivered whiled the DCN will get hammered. One 
    solution (thanks, Igor) is to break the information down into smaller LSAs. 
    Since the information is essentially lists or matrices, this is quite easy 
    to do.</FONT></DIV>
    <DIV><FONT color=#808000><BR></FONT>Could you please let me know if the 
    above is within the current scope? I believe that these are important. 
    <BR><FONT color=#cc0000>[Adrian] Very much in scope!</FONT></DIV>
    <DIV><FONT color=#cc0000></FONT>&nbsp;</DIV>
    <DIV><FONT color=#cc0000>Cheers,</FONT></DIV>
    <DIV><FONT 
  color=#cc0000>Adrian</FONT></DIV></BLOCKQUOTE><BR></DIV></DIV></DIV><BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)--

Delivery-date: Wed, 13 Aug 2008 09:05:25 +0000
From: Adrian Farrel <[email-masked]>
To: [email-masked]
Subject: BGP TE attr last call by softwires WG
Reply-To: [email-masked]
Date: Wed, 13 Aug 2008 10:02:08 +0100
Cc: [email-masked], [email-masked], [email-masked]

[Forwarding to the correct CCAMP mailing address]=0D
=0D
From: David Ward <[email-masked]> =0D
To: David Ward <[email-masked]>, =0D
Alain Durand <[email-masked]>, [email-masked] =0D
Sent: Tue Aug 12 23:48 =0D
Subject: BGP TE attr last call by softwires WG =0D
=0D
The softwire WG has LC'ed =0D
=0D
http://www.ietf.org/internet-drafts/draft-ietf-softwire-bgp-te- =0D
attribute-01.txt =0D
=0D
We will keep open an additional two-week period for wider review =0D
before moving forward in the publication process. Please have any =0D
comments to the authors and softwires WG by Aug 26, 2008. =0D
=0D
-DWard, Alain Durand =0D
=0D
bcc: [email-masked], [email-masked], [email-masked], [email-masked], =0D
[email-masked], [email-masked], [email-masked] =0D

Delivery-date: Tue, 12 Aug 2008 17:02:01 +0000
Date: Tue, 12 Aug 2008 17:59:47 +0100
Subject: Re: [mpls-tp] MPLS over OTN
From: Ben Niven-Jenkins <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>

Catching up on mails...

On 04/08/2008 16:48, "[email-masked]"
<[email-masked]> wrote:

> Hi Francesco.
> 
> I guess I understand your concern. I believe the original intention was
> to say implicitely "It MUST be possible to operate and configure the
> MPLS-TP data (transport) plane without any IP functionality *in the data
> plane*." My interpretation of these requirements is indeed that they
> apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment,
> nor the MPLS-TP control plane...

Correct.

> Anyway you're right, this could be confusing and it deserves a small
> rewording.

I have reworded to:
"It MUST be possible to operate and configure the MPLS-TP data (transport)
plane without any IP functionality in the MPLS-TP data plane."

Ben

Delivery-date: Tue, 12 Aug 2008 08:53:35 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt 
Date: Fri,  8 Aug 2008 07:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]

--NextPart

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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-ether-svcs-02.txt
	Pages           : 17
	Date            : 2008-08-08

This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS).  This document supports the types of switching implied by
the Ethernet services that have been defined in the context of the
Metro Ethernet Forum (MEF) and International Telecommunication Union
(ITU) G.8011.  Specifically, switching in support of Ethernet private
line service and Ethernet virtual private line service.  Support for
MEF and ITU defined parameters are also covered.  Some of the
extensions defined in this document are generic in nature and not
specific to Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

Delivery-date: Tue, 12 Aug 2008 08:39:53 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt 
Date: Fri,  8 Aug 2008 07:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]

--NextPart

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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-mef-uni-01.txt
	Pages           : 11
	Date            : 2008-08-08

This document describes a method for controlling two specific types
of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI).  This document
supports the types of switching required to implied by the Ethernet
services that have been defined in the context of the Metro Ethernet
Forum (MEF) and International Telecommunication Union (ITU) G.8011.
This document is the UNI companion to "Generalized MPLS (GMPLS)
Support For Metro Ethernet Forum and G.8011 Ethernet Service
Switching".  This document does not define or limit the underlying
intra-domain or Internal NNI (I-NNI) technology used to support the
UNI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mef-uni-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

Delivery-date: Mon, 11 Aug 2008 20:26:58 +0000
Date: Mon, 11 Aug 2008 13:25:39 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
To: [email-masked], [email-masked], [email-masked], [email-masked]

--0-2020219236-1218486339=:64307
Content-Type: text/plain; charset=us-ascii

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON 
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important. 
[Adrian] Very much in scope!
 
Cheers,
Adrian

--0-2020219236-1218486339=:64307
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Hi,<br><br>Please, see my comment in line. Look for IB&gt;&gt;<br><br>Cheers,<br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Adrian Farrel &lt;[email-masked]&gt;<br>To: [email-masked]; [email-masked]; [email-masked]<br>Sent: Monday, August 11, 2008 1:24:50 PM<br>Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'<br><br><div>Hi,</div><blockquote style="border-left: 2px solid rgb(245, 245, 245); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;"><div>I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation.
 IMHO the evaluation from WSON perspective should address the following:<br>
1. IGP usage in the context of traditional distributed solutions for WSON <br><font color="#000080">[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.<br><br>IB&gt;&gt; There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability
 states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.<br><br></font><font color="#808000">[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?</font></div><div><font color="#800000">[Dan] From the result of the simulation,&nbsp;the OSPF convergency time&nbsp;takes a liitle bit longer when the entire network restarts. Because&nbsp;the WSON information is added in the OSPF LSA.&nbsp;During the network running normally, the update of wavelength availability information&nbsp;doesn't&nbsp;impact the IGP performance obviously.</font></div><div><font color="#cc0000">[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used&nbsp;to have one :-), the concern
 is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and&nbsp;how dynamic it is. From this, we can quickly see how things will scale.</font></div><div><font color="#800000"><font color="#cc0000">I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.</font><br></font>&nbsp;<br>
2. IGP usage in the context of PCE solutions for WSON<br><font color="#000080">[Dan] It's a potential way for PCE to get the wavelength information.<br></font><font color="#808000">[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?</font></div><div><font color="#800000">[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.</font></div><div><font color="#800000"><font color="#cc0000">[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for
 restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.</font><br></font><br>
3. Flooding and refresh of static and dynamic link state updates<br><font color="#000080">[Dan] Try to figure out the impact to the performance of IGP.<br></font><font color="#808000">[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?</font></div><div><font color="#800000">[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.</font></div><div><font color="#800000"><font color="#cc0000">[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need
 to be flooded at start of day and in node restart as below.</font><br></font><br>
4. Data base sync-up during node restarts<br><font color="#000080">[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.<br></font><font color="#808000">[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.</font></div><div><font color="#cc0000">[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or
 matrices, this is quite easy to do.</font></div><div><font color="#808000"><br></font>Could you please let me know if the above is within the current scope? I believe that these are important. <br><font color="#cc0000">[Adrian] Very much in scope!</font></div><div><font color="#cc0000"></font>&nbsp;</div><div><font color="#cc0000">Cheers,</font></div><div><font color="#cc0000">Adrian</font></div></blockquote><br></div></div></div><br>

      </body></html>
--0-2020219236-1218486339=:64307--

Delivery-date: Mon, 11 Aug 2008 17:42:57 +0000
Date: Mon, 11 Aug 2008 15:33:01 +0800
From: Dan Li <[email-masked]>
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
To: "Bardalai, Snigdho" <[email-masked]>
Cc: "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho,

I copied the original text here for easy read. See my comments below.

=====
Hi Adrian and Dan, 

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON 
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
=====

Thanks,

Dan

--Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Comments on "draft-li-ccamp-wson-igp-eval-01.txt"</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
<DIV>Hi Snigdho,<BR><BR>I copied the original text here for easy read. See my 
comments below.<BR></DIV>
<DIV>=====<BR>Hi Adrian and Dan, </DIV>
<DIV><BR>I have the following comments on this draft. I was wondering what were 
the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective 
should address the following:<BR>1. IGP usage in the context of traditional 
distributed solutions for WSON <BR><FONT color=#000080>[Dan] With the situation 
that TE information is already be carried by IGP, it's nature to think that the 
wavelength information can also be carried by IGP. I am not saying it should be, 
but it's worth to look at.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Do 
you see any particular issues with using the IGP for this purpose ?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] From the result of the simulation,&nbsp;the OSPF 
convergency time&nbsp;takes a liitle bit longer when the entire network 
restarts. Because&nbsp;the WSON information is added in the OSPF 
LSA.&nbsp;During the network running normally, the update of wavelength 
availability information&nbsp;doesn't&nbsp;impact the IGP performance 
obviously.<BR></FONT>&nbsp;<BR>2. IGP usage in the context of PCE solutions for 
WSON<BR><FONT color=#000080>[Dan] It's a potential way for PCE to get the 
wavelength information.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Since 
the PCE is the location where path-computation takes place is it possible to 
limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC 
neighbor?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] You are right, PCC which doesn't do the 
path-computation doesn't need this kind of information.<BR></FONT><BR>3. 
Flooding and refresh of static and dynamic link state updates<BR><FONT 
color=#000080>[Dan] Try to figure out the impact to the performance of 
IGP.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Is it possible to limit 
refreshing of static LSA? Ex. using the OSPF "do not age" concept?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] Yes, it's possible to take this way to reduce the 
protocol traffic. But we should consider the scenario when a node gets restart 
or goes down, so the HELLO message may still need to be kept.<BR></FONT><BR>4. 
Data base sync-up during node restarts<BR><FONT color=#000080>[Dan] Yes, this 
should be considered. Especially the very large amount of data will be sent to 
the restarting node. We may consider the point to point data exchange instead of 
flooding the LSA updates. Or slice the big data packet into small 
pieces.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] This is little tricky, 
I would be interested to see if there is a clean solution.</FONT></DIV><FONT 
color=#808000>
<DIV><FONT color=#000000>=====</FONT></DIV>
<DIV><BR></FONT><FONT color=#000000>Thanks,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan</DIV></DIV></BODY></HTML>

--Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)--

Delivery-date: Mon, 11 Aug 2008 17:37:45 +0000
From: Anders Gavler <[email-masked]>
To: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 11 Aug 2008 14:10:18 +0200
Subject: RE: Poll for RWA Info model as WG I-D
Accept-Language: sv-SE, en-US
acceptlanguage: sv-SE, en-US

Yes.

Regards,
 Anders

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behal=
f
> Of Adrian Farrel
> Sent: den 5 augusti 2008 18:24
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
>
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed
> to
> be pretty mature.
>
> Note that despite the file name, the content of this document is
> consistent
> with its title: "Routing and Wavelength Assignment Information Model for
> Wavelength Switched Optical Networks." That is, the scope is limited to
> the
> information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready to be
> adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
>

Delivery-date: Mon, 11 Aug 2008 17:25:58 +0000
From: Adrian Farrel <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Reply-To: [email-masked]
Date: Mon, 11 Aug 2008 18:24:50 +0100

<html>=0D
=0D
<DIV>Hi,</DIV>=0D
<BLOCKQUOTE style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5p=
x; BORDER-LEFT: #f5f5f5 2px solid; MARGIN-RIGHT: 0px">=0D
<DIV>I have the following comments on this draft. I was wondering what were=
 the objectives for the IGP evaluation. IMHO the evaluation from WSON persp=
ective should address the following:<BR>
1. IGP usage in the context of traditional distributed solutions for WSON <=
BR>
<FONT color=3D#000080>[Dan] With the situation that TE information is alrea=
dy be carried by IGP, it's nature to think that the wavelength information =
can also be carried by IGP. I am not saying it should be, but it's worth to=
 look at.<BR>
</FONT><FONT color=3D#808000>[Bardalai, Snigdho] Do you see any particular =
issues with using the IGP for this purpose ?</FONT></DIV>=0D
<DIV><FONT color=3D#800000>[Dan] From the result of the simulation,&nbsp;th=
e OSPF convergency time&nbsp;takes a liitle bit longer when the entire netw=
ork restarts. Because&nbsp;the WSON information is added in the OSPF LSA.&n=
bsp;During the network running normally, the update of wavelength availabil=
ity information&nbsp;doesn't&nbsp;impact the IGP performance obviously.</FO=
NT></DIV>=0D
<DIV><FONT color=3D#cc0000>[Adrian] Certainly, from the point of view of so=
meone coming at this without an implementation (I used&nbsp;to have one :-)=
, the concern is that adding the RWA information to the IGP might mean that=
 there was simply too much information to be distributed. What Dan's draft =
is trying to do is show the dimensions of the information and&nbsp;how dyna=
mic it is. From this, we can quickly see how things will scale.</FONT></DIV=
>=0D
<DIV><FONT color=3D#800000><FONT color=3D#cc0000>I do not believe that ther=
e is an issue with the interaction with IP routing, but I guess we should c=
onsider that it is possible that the DCN will be a real IP network carrying=
 other traffic and that we need to not disrupt IGP convergence in that netw=
ork. Mechanisms exist (or are being developed) to make that safe, and Dan's=
 I-D should be able to tell us how important it is to use them.</FONT><BR>
</FONT>&nbsp;<BR>
2. IGP usage in the context of PCE solutions for WSON<BR>
<FONT color=3D#000080>[Dan] It's a potential way for PCE to get the wavelen=
gth information.<BR>
</FONT><FONT color=3D#808000>[Bardalai, Snigdho] Since the PCE is the locat=
ion where path-computation takes place is it possible to limit LSA advertis=
ements from PCC to PCE neighbors, instead of to every PCC neighbor?</FONT><=
/DIV>=0D
<DIV><FONT color=3D#800000>[Dan] You are right, PCC which doesn't do the pa=
th-computation doesn't need this kind of information.</FONT></DIV>=0D
<DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] This is an import=
ant point which you raised in conversation with me in Dublin: it is possibl=
e to consider using link-local scope flooding of RWA information from PCC t=
o PCE so that it goes no further. But there is a clear trade-off... with ho=
w many PCCs will a PCE be required to maintain an IGP association? There is=
 also a quesiton to be answered about the function required for restoration=
 - how much information does the head-end LSR need to perform rapid, "best-=
effort" path computation to restore LSPs after a network failure? This info=
rmation *does* need to be flooded. The informaiton model I-D is intended to=
 help with this question.</FONT><BR>
</FONT><BR>
3. Flooding and refresh of static and dynamic link state updates<BR>
<FONT color=3D#000080>[Dan] Try to figure out the impact to the performance=
 of IGP.<BR>
</FONT><FONT color=3D#808000>[Bardalai, Snigdho] Is it possible to limit re=
freshing of static LSA? Ex. using the OSPF "do not age" concept?</FONT></DI=
V>=0D
<DIV><FONT color=3D#800000>[Dan] Yes, it's possible to take this way to red=
uce the protocol traffic. But we should consider the scenario when a node g=
ets restart or goes down, so the HELLO message may still need to be kept.</=
FONT></DIV>=0D
<DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] Yes. You are both=
 right. We should treat "static" as truely static and not needing refresh. =
We can handle node-down and link-down events without the need to time out t=
he LSAs containing the static data if we link the behavior to the time-out =
of other node/link information. But we *do* need to consider the amount of =
information that will be held in LSA DBs and need to be flooded at start of=
 day and in node restart as below.</FONT><BR>
</FONT><BR>
4. Data base sync-up during node restarts<BR>
<FONT color=3D#000080>[Dan] Yes, this should be considered. Especially the =
very large amount of data will be sent to the restarting node. We may consi=
der the point to point data exchange instead of flooding the LSA updates. O=
r slice the big data packet into small pieces.<BR>
</FONT><FONT color=3D#808000>[Bardalai, Snigdho] This is little tricky, I w=
ould be interested to see if there is a clean solution.</FONT></DIV>=0D
<DIV><FONT color=3D#cc0000>[Adrian] An important point to consider (in OSPF=
) is what happens in a lossy environment if the LSA gets very large. In thi=
s case it will be fragmented into very many IP packets and there will be a =
good statistical likelihood of at least one packet being lost. That means t=
hat the LSA might never get delivered whiled the DCN will get hammered. One=
 solution (thanks, Igor) is to break the information down into smaller LSAs=
. Since the information is essentially lists or matrices, this is quite eas=
y to do.</FONT></DIV>=0D
<DIV><FONT color=3D#808000><BR>
</FONT>Could you please let me know if the above is within the current scop=
e? I believe that these are important. <BR>
<FONT color=3D#cc0000>[Adrian] Very much in scope!</FONT></DIV>=0D
<DIV><FONT color=3D#cc0000></FONT>&nbsp;</DIV>=0D
<DIV><FONT color=3D#cc0000>Cheers,</FONT></DIV>=0D
<DIV><FONT color=3D#cc0000>Adrian</FONT></DIV></BLOCKQUOTE>=0D
<META content=3DTYUWAMWXFN name=3DSKYPE_FRAMEID>=0D
</html><BR>

Delivery-date: Mon, 11 Aug 2008 16:27:03 +0000
Date: Mon, 11 Aug 2008 09:48:59 +0800
From: Dan Li <[email-masked]>
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
To: "Bardalai, Snigdho" <[email-masked]>, "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho,

I copied the original text here for easy read. See my comments below.

=====
Hi Adrian and Dan, 

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON 
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.

Could you please let me know if the above is within the current scope? I believe that these are important. 
Thanks, 
Snigdho 

--Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Comments on "draft-li-ccamp-wson-igp-eval-01.txt"</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff background="">
<DIV>Hi Snigdho,<BR><BR>I copied the original text here for easy read. See my 
comments below.<BR></DIV>
<DIV>=====<BR>Hi Adrian and Dan, </DIV>
<DIV><BR>I have the following comments on this draft. I was wondering what were 
the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective 
should address the following:<BR>1. IGP usage in the context of traditional 
distributed solutions for WSON <BR><FONT color=#000080>[Dan] With the situation 
that TE information is already be carried by IGP, it's nature to think that the 
wavelength information can also be carried by IGP. I am not saying it should be, 
but it's worth to look at.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Do 
you see any particular issues with using the IGP for this purpose ?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] From the result of the simulation,&nbsp;the OSPF 
convergency time&nbsp;takes a liitle bit longer when the entire network 
restarts. Because&nbsp;the WSON information is added in the OSPF 
LSA.&nbsp;During the network running normally, the update of wavelength 
availability information&nbsp;doesn't&nbsp;impact the IGP performance 
obviously.<BR></FONT>&nbsp;<BR>2. IGP usage in the context of PCE solutions for 
WSON<BR><FONT color=#000080>[Dan] It's a potential way for PCE to get the 
wavelength information.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Since 
the PCE is the location where path-computation takes place is it possible to 
limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC 
neighbor?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] You are right, PCC which doesn't do the 
path-computation doesn't need this kind of information.<BR></FONT><BR>3. 
Flooding and refresh of static and dynamic link state updates<BR><FONT 
color=#000080>[Dan] Try to figure out the impact to the performance of 
IGP.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] Is it possible to limit 
refreshing of static LSA? Ex. using the OSPF "do not age" concept?</FONT></DIV>
<DIV><FONT color=#800000>[Dan] Yes, it's possible to take this way to reduce the 
protocol traffic. But we should consider the scenario when a node gets restart 
or goes down, so the HELLO message may still need to be kept.<BR></FONT><BR>4. 
Data base sync-up during node restarts<BR><FONT color=#000080>[Dan] Yes, this 
should be considered. Especially the very large amount of data will be sent to 
the restarting node. We may consider the point to point data exchange instead of 
flooding the LSA updates. Or slice the big data packet into small 
pieces.<BR></FONT><FONT color=#808000>[Bardalai, Snigdho] This is little tricky, 
I would be interested to see if there is a clean solution.</FONT></DIV>
<DIV><FONT color=#808000><BR></FONT>Could you please let me know if the above is 
within the current scope? I believe that these are important. <BR>Thanks, 
<BR>Snigdho </DIV></BODY></HTML>

--Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)--

Delivery-date: Fri, 08 Aug 2008 17:32:17 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt 
Date: Fri,  8 Aug 2008 10:30:01 -0700 (PDT)

--NextPart

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           : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt
	Pages           : 11
	Date            : 2008-08-08

This document describes two technology independent extensions to
Generalized Multi-Protocol Label Switching.  The first extension
defines the new switching type Data Channel Switching Capable.  Data
Channel Switching Capable interfaces are able to support switching of
the whole digital channel presented on single channel interfaces.
The second extension defines a new type of generalized label and
updates related objects.  The new label is called the Generalized
Channel_Set Label and allows more than one data plane label to be
controlled as part of an LSP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 08 Aug 2008 15:43:44 +0000
From: [email-masked]
To: [email-masked]
Date: Fri,  8 Aug 2008 07:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt

--NextPart

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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-ether-svcs-02.txt
	Pages           : 17
	Date            : 2008-08-08

This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS).  This document supports the types of switching implied by
the Ethernet services that have been defined in the context of the
Metro Ethernet Forum (MEF) and International Telecommunication Union
(ITU) G.8011.  Specifically, switching in support of Ethernet private
line service and Ethernet virtual private line service.  Support for
MEF and ITU defined parameters are also covered.  Some of the
extensions defined in this document are generic in nature and not
specific to Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

Delivery-date: Fri, 08 Aug 2008 14:34:58 +0000
Content-class: urn:content-classes:message
Subject: IETF 72 Draft CCAMP Minutes
Date: Fri, 8 Aug 2008 10:34:13 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F963.D441DBD9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here's the draft meeting minutes - please take a look and mail the
chairs if there are changes (or additions/corrections on the names for
folks at the mike):
http://www.ietf.org/proceedings/08jul/minutes/ccamp.htm
=20
Much thanks to our minute takers - Dan King, Dave Walters, and Wouter
Tavernier!
=20
Adrian and Deborah
=20

------_=_NextPart_001_01C8F963.D441DBD9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010012914-08082008>Here's =
the draft=20
meeting minutes - please take a look and mail the chairs if there are =
changes=20
(or additions/corrections on the names for folks at the=20
mike):</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010012914-08082008><A=20
href=3D"http://www.ietf.org/proceedings/08jul/minutes/ccamp.htm">http://w=
ww.ietf.org/proceedings/08jul/minutes/ccamp.htm</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010012914-08082008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010012914-08082008>Much =
thanks to our=20
minute takers - Dan King, Dave Walters, and Wouter=20
Tavernier!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010012914-08082008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010012914-08082008>Adrian =
and=20
Deborah</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010012914-08082008></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C8F963.D441DBD9--

Delivery-date: Fri, 08 Aug 2008 14:32:02 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt 
Date: Fri,  8 Aug 2008 07:30:01 -0700 (PDT)

--NextPart

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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-ether-svcs-02.txt
	Pages           : 17
	Date            : 2008-08-08

This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS).  This document supports the types of switching implied by
the Ethernet services that have been defined in the context of the
Metro Ethernet Forum (MEF) and International Telecommunication Union
(ITU) G.8011.  Specifically, switching in support of Ethernet private
line service and Ethernet virtual private line service.  Support for
MEF and ITU defined parameters are also covered.  Some of the
extensions defined in this document are generic in nature and not
specific to Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 08 Aug 2008 14:31:54 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt 
Date: Fri,  8 Aug 2008 07:30:01 -0700 (PDT)

--NextPart

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           : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)
	Author(s)       : L. Berger, D. Fedyk
	Filename        : draft-ietf-ccamp-gmpls-mef-uni-01.txt
	Pages           : 11
	Date            : 2008-08-08

This document describes a method for controlling two specific types
of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI).  This document
supports the types of switching required to implied by the Ethernet
services that have been defined in the context of the Metro Ethernet
Forum (MEF) and International Telecommunication Union (ITU) G.8011.
This document is the UNI companion to "Generalized MPLS (GMPLS)
Support For Metro Ethernet Forum and G.8011 Ethernet Service
Switching".  This document does not define or limit the underlying
intra-domain or Internal NNI (I-NNI) technology used to support the
UNI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mef-uni-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 07 Aug 2008 11:09:37 +0000
Date: Thu, 07 Aug 2008 20:04:06 +0900
From: Kohei Shiomoto <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D

Yes. I agree that the draft is ready to be adopted as a working group I-D.

Kohei

Adrian Farrel さんは書きました:
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and 
> seemed to be pretty mature.
>
> Note that despite the file name, the content of this document is 
> consistent with its title: "Routing and Wavelength Assignment 
> Information Model for Wavelength Switched Optical Networks." That is, 
> the scope is limited to the information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready to 
> be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
>
>

Delivery-date: Thu, 07 Aug 2008 07:35:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for RWA Info model as WG I-D
Date: Thu, 7 Aug 2008 09:35:04 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi.

In favor of WG topic.

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel

Hi,

draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and =
seemed to=20
be pretty mature.

Note that despite the file name, the content of this document is =
consistent=20
with its title: "Routing and Wavelength Assignment Information Model for =

Wavelength Switched Optical Networks." That is, the scope is limited to =
the=20
information model for RWA.

Can we have your opinion, please, on whether this document is ready to =
be=20
adopted as a working group I-D.

Thanks,
Adrian and Deborah

Delivery-date: Thu, 07 Aug 2008 07:23:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for RWA Info model as WG I-D
Date: Thu, 7 Aug 2008 09:19:15 +0200
From: "Daniele Ceccarelli" <[email-masked]>
To: <[email-masked]>

I am in favor of this document being adopted.

Cheers,
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
Sent: marted=EC 5 agosto 2008 18.24
To: [email-masked]
Subject: Poll for RWA Info model as WG I-D

Hi,

draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and =
seemed to=20
be pretty mature.

Note that despite the file name, the content of this document is =
consistent=20
with its title: "Routing and Wavelength Assignment Information Model for =

Wavelength Switched Optical Networks." That is, the scope is limited to =
the=20
information model for RWA.

Can we have your opinion, please, on whether this document is ready to =
be=20
adopted as a working group I-D.

Thanks,
Adrian and Deborah

Delivery-date: Thu, 07 Aug 2008 04:10:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Date: Wed, 6 Aug 2008 23:09:16 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Dan Li" <[email-masked]>, "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F843.5BB78328
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dan,
=20
Please see my response below.
=20
Thanks,
Snigdho

-----Original Message-----
From: Dan Li [mailto:[email-masked]]
Sent: Friday, August 01, 2008 4:10 AM
To: Bardalai, Snigdho; Ccamp (E-mail)
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Snigdho,
=20
Very good question! See my comments below.
=20
Thanks,
=20
Dan

----- Original Message -----=20
From: Bardalai, Snigdho <mailto:[email-masked]> =20
To: Ccamp (E-mail) <mailto:[email-masked]> =20
Sent: Friday, August 01, 2008 4:26 AM
Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Adrian and Dan,=20

I have the following comments on this draft. I was wondering what were =
the objectives for the IGP evaluation. IMHO the evaluation from WSON =
perspective should address the following:

1. IGP usage in the context of traditional distributed solutions for =
WSON=20

[Dan] With the situation that TE information is already be carried by =
IGP, it's nature to think that the wavelength information can also be =
carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP =
for this purpose ?=20

2. IGP usage in the context of PCE solutions for WSON

[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation =
takes place is it possible to limit LSA advertisements from PCC to PCE =
neighbors, instead of to every PCC neighbor?

3. Flooding and refresh of static and dynamic link state updates

[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? =
Ex. using the OSPF "do not age" concept?

4. Data base sync-up during node restarts

[Dan] Yes, this should be considered. Especially the very large amount =
of data will be sent to the restarting node. We may consider the point =
to point data exchange instead of flooding the LSA updates. Or slice the =
big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see =
if there is a clean solution.

Could you please let me know if the above is within the current scope? I =
believe that these are important.=20

Thanks,=20
Snigdho=20

------_=_NextPart_001_01C8F843.5BB78328
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Comments on "draft-li-ccamp-wson-igp-eval-01.txt"</TITLE>

<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D196014303-07082008>Hi=20
Dan,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D196014303-07082008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D196014303-07082008>Please=20
see my response below.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D196014303-07082008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D196014303-07082008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D196014303-07082008>Snigdho</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Dan Li=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, August 01, 2008 4:10 =

  AM<BR><B>To:</B> Bardalai, Snigdho; Ccamp (E-mail)<BR><B>Subject:</B> =
Re:=20
  Comments on "draft-li-ccamp-wson-igp-eval-01.txt"<BR><BR></FONT></DIV>
  <DIV><FONT face=3D"Times New Roman">Hi Snigdho,</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Times New Roman">Very good question! </FONT><FONT=20
  face=3D"Times New Roman">See my comments below.</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Times New Roman">Thanks,</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Times New Roman">Dan</FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Bardalai, =
Snigdho</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">Ccamp (E-mail)</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, August 01, 2008 =
4:26=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Comments on=20
    "draft-li-ccamp-wson-igp-eval-01.txt"</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><BR></DIV><!-- Converted from =
text/rtf format -->
    <P><FONT face=3DArial size=3D2>Hi Adrian and Dan,</FONT> </P>
    <P><FONT face=3DArial size=3D2>I have the following comments on this =
draft. I=20
    was wondering what were the objectives for the IGP evaluation. IMHO =
the=20
    evaluation from WSON perspective should address the =
following:</FONT></P>
    <P><FONT face=3DArial size=3D2>1. IGP usage in the context of =
traditional=20
    distributed solutions for WSON</FONT> </P>
    <P><FONT color=3D#000080><FONT size=3D2>[Dan] With the situation =
that TE=20
    information is already be carried by IGP, it's nature to think that =
the=20
    wavelength information can also be carried by IGP. I am not saying =
it should=20
    be, but it's worth to look at.<BR><SPAN =
class=3D196014303-07082008><FONT=20
    face=3DArial color=3D#0000ff>[Bardalai, Snigdho]&nbsp;Do you see=20
    any&nbsp;particular issues with using the IGP for this&nbsp;purpose=20
    ?&nbsp;</FONT></SPAN></FONT></FONT></P><FONT size=3D2></FONT>
    <P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><BR><FONT face=3DArial size=3D2>2. =
IGP usage in the=20
    context of PCE solutions for WSON</FONT></P>
    <P><FONT color=3D#000080><FONT face=3DArial><FONT size=3D2>[Dan] =
It's a potential=20
    way for PCE to get the wavelength information.<BR><SPAN=20
    class=3D196014303-07082008><FONT color=3D#0000ff>[Bardalai, =
Snigdho]&nbsp;Since=20
    the PCE is the location where path-computation takes place is it =
possible to=20
    limit LSA advertisements from PCC to PCE neighbors, instead of to =
every PCC=20
    neighbor?</FONT></SPAN></FONT></FONT></FONT></P>
    <P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><BR><FONT face=3DArial size=3D2>3. =
Flooding and=20
    refresh of static and dynamic link state updates</FONT></P>
    <P><FONT color=3D#000080><FONT size=3D2>[Dan] Try to figure out the =
impact to=20
    the performance of IGP.<BR><SPAN class=3D196014303-07082008><FONT =
face=3DArial=20
    color=3D#0000ff>[Bardalai, Snigdho]&nbsp;Is it possible to limit =
refreshing of=20
    static LSA? Ex.&nbsp;using the OSPF "do not age"=20
    concept?</FONT></SPAN></FONT></FONT></P>
    <P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR><FONT=20
    face=3DArial size=3D2>4. Data base sync-up during node =
restarts</FONT></P>
    <P><FONT color=3D#000080><FONT size=3D2>[Dan] Yes, this should be=20
    considered.</FONT>&nbsp;<FONT size=3D2>Especially the very large =
amount of=20
    data will be sent to the restarting node. We may consider the point =
to point=20
    data exchange instead of flooding the LSA updates. Or slice the big =
data=20
    packet into small pieces.<BR><SPAN class=3D196014303-07082008><FONT =
face=3DArial=20
    color=3D#0000ff>[Bardalai, Snigdho]&nbsp;This is little tricky, I =
would be=20
    interested to see if there is a clean=20
    solution.</FONT></SPAN></FONT></FONT></P>
    <P><FONT face=3DArial size=3D2>Could you please let me know if the =
above is=20
    within the current scope? I believe that these are important.</FONT> =
</P>
    <P><FONT face=3DArial size=3D2>Thanks,</FONT> <BR><FONT face=3DArial =

    size=3D2>Snigdho</FONT>=20
</P><BR><BR><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8F843.5BB78328--

Delivery-date: Thu, 07 Aug 2008 01:43:36 +0000
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D
From: [email-masked]
Date: Thu, 7 Aug 2008 09:44:43 +0800

This is a multipart message in MIME format.
--=_related 00094E9C4825749E_=
Content-Type: multipart/alternative; boundary="=_alternative 00094E9C4825749E_="

--=_alternative 00094E9C4825749E_=
Content-Type: text/plain; charset="US-ASCII"

Yes, I support this draft to be a WG I-D.

Best regard,
Feng Gao

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, August 06, 2008 1:24 AM
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
> 
> Hi,
> 
> draft-bernstein-ccamp-wson-info-03.txt was discussed in 
> Dublin and seemed to be pretty mature.
> 
> Note that despite the file name, the content of this document 
> is consistent with its title: "Routing and Wavelength 
> Assignment Information Model for Wavelength Switched Optical 
> Networks." That is, the scope is limited to the information 
> model for RWA.
> 
> Can we have your opinion, please, on whether this document is 
> ready to be adopted as a working group I-D.
> 
> Thanks,
> Adrian and Deborah
> 
> 
> 
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00094E9C4825749E_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Yes, I support this draft to be a WG
I-D.</font>
<br>
<br><font size=2 face="sans-serif">Best regard,</font>
<br><font size=2 face="sans-serif">Feng Gao</font>
<br>
<br>
<br><font size=2><tt>&gt; -----Original Message-----<br>
&gt; From: [email-masked] <br>
&gt; [mailto:[email-masked]] On Behalf Of Adrian Farrel<br>
&gt; Sent: Wednesday, August 06, 2008 1:24 AM<br>
&gt; To: [email-masked]<br>
&gt; Subject: Poll for RWA Info model as WG I-D<br>
&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; draft-bernstein-ccamp-wson-info-03.txt was discussed in <br>
&gt; Dublin and seemed to be pretty mature.<br>
&gt; <br>
&gt; Note that despite the file name, the content of this document <br>
&gt; is consistent with its title: &quot;Routing and Wavelength <br>
&gt; Assignment Information Model for Wavelength Switched Optical <br>
&gt; Networks.&quot; That is, the scope is limited to the information <br>
&gt; model for RWA.<br>
&gt; <br>
&gt; Can we have your opinion, please, on whether this document is <br>
&gt; ready to be adopted as a working group I-D.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; Adrian and Deborah<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; </tt></font>
<br><font size=2 face="sans-serif"><br>
</font><img src=cid:_1_07AA7B1007AA78E800094E9A4825749E><br><pre>
--------------------------------------------------------
ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;organization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nbsp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&nbsp;to&nbsp;others.
This&nbsp;email&nbsp;and&nbsp;any&nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nbsp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;email&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp;sender.
This&nbsp;message&nbsp;has&nbsp;been&nbsp;scanned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Spam&nbsp;system.
</pre>
--=_alternative 00094E9C4825749E_=--

--=_related 00094E9C4825749E_=
Content-Type: image/gif
Content-ID: <_1_07AA7B1007AA78E800094E9A4825749E>
Content-Transfer-Encoding: base64

--=_related 00094E9C4825749E_=--

Delivery-date: Thu, 07 Aug 2008 00:37:14 +0000
Reply-To: <[email-masked]>
From: "Itaru Nishioka" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Poll for RWA Info model as WG I-D
Date: Thu, 7 Aug 2008 09:36:24 +0900
Organization: nec

Yes, good.

Itaru

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, August 06, 2008 1:24 AM
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
> 
> Hi,
> 
> draft-bernstein-ccamp-wson-info-03.txt was discussed in 
> Dublin and seemed to be pretty mature.
> 
> Note that despite the file name, the content of this document 
> is consistent with its title: "Routing and Wavelength 
> Assignment Information Model for Wavelength Switched Optical 
> Networks." That is, the scope is limited to the information 
> model for RWA.
> 
> Can we have your opinion, please, on whether this document is 
> ready to be adopted as a working group I-D.
> 
> Thanks,
> Adrian and Deborah
> 
> 
> 
> 
> 

Delivery-date: Thu, 07 Aug 2008 00:17:12 +0000
Date: Thu, 07 Aug 2008 08:16:33 +0800
From: Dan Li <[email-masked]>
Subject: Re: Poll for RWA Info model as WG I-D
To: Adrian Farrel <[email-masked]>, [email-masked]

Yes.

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 06, 2008 12:24 AM
Subject: Poll for RWA Info model as WG I-D

> Hi,
> 
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to 
> be pretty mature.
> 
> Note that despite the file name, the content of this document is consistent 
> with its title: "Routing and Wavelength Assignment Information Model for 
> Wavelength Switched Optical Networks." That is, the scope is limited to the 
> information model for RWA.
> 
> Can we have your opinion, please, on whether this document is ready to be 
> adopted as a working group I-D.
> 
> Thanks,
> Adrian and Deborah
> 
> 
> 
> 
> 

Delivery-date: Thu, 07 Aug 2008 00:00:30 +0000
Date: Thu, 07 Aug 2008 09:00:00 +0900
From: Sugang XU <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D

Hi,
In favor of the draft to be a WG draft.

Best Regards,
Sugang

Adrian Farrel wrote:
> Hi,
> 
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and 
> seemed to be pretty mature.
> 
> Note that despite the file name, the content of this document is 
> consistent with its title: "Routing and Wavelength Assignment 
> Information Model for Wavelength Switched Optical Networks." That is, 
> the scope is limited to the information model for RWA.
> 
> Can we have your opinion, please, on whether this document is ready to 
> be adopted as a working group I-D.
> 
> Thanks,
> Adrian and Deborah
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 06 Aug 2008 23:55:02 +0000
Date: Thu, 07 Aug 2008 08:52:23 +0900
From: Tomohiro Otani <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D

Hi Adrian,

I support this being adopted as a WG document.

Regards,

tomo

Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=
=97=E3=81=9F:
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and=20
> seemed to be pretty mature.
>
> Note that despite the file name, the content of this document is=20
> consistent with its title: "Routing and Wavelength Assignment=20
> Information Model for Wavelength Switched Optical Networks." That is,=20
> the scope is limited to the information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready to=20
> be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
>
>

Delivery-date: Wed, 06 Aug 2008 17:38:18 +0000
From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= <[email-masked]>
To: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Aug 2008 19:36:33 +0200
Subject: RE: Poll for RWA Info model as WG I-D
Accept-Language: en-US
acceptlanguage: en-US

Yes.

Regards,
Jonas

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: den 5 augusti 2008 18:24
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
>
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in
> Dublin and seemed to be pretty mature.
>
> Note that despite the file name, the content of this document
> is consistent with its title: "Routing and Wavelength
> Assignment Information Model for Wavelength Switched Optical
> Networks." That is, the scope is limited to the information
> model for RWA.
>
> Can we have your opinion, please, on whether this document is
> ready to be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
>
>
>

Delivery-date: Wed, 06 Aug 2008 15:14:10 +0000
Date: Thu, 07 Aug 2008 00:10:09 +0900
From: Tomonori TAKEDA <[email-masked]>
To: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D

Yes

Tomonori

Adrian Farrel wrote:
> Hi,
> 
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and 
> seemed to be pretty mature.
> 
> Note that despite the file name, the content of this document is 
> consistent with its title: "Routing and Wavelength Assignment 
> Information Model for Wavelength Switched Optical Networks." That is, 
> the scope is limited to the information model for RWA.
> 
> Can we have your opinion, please, on whether this document is ready to 
> be adopted as a working group I-D.
> 
> Thanks,
> Adrian and Deborah
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 06 Aug 2008 14:46:52 +0000
From: Dirk Schroetter <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Subject: Re: Poll for RWA Info model as WG I-D
Date: Wed, 6 Aug 2008 16:45:36 +0200
Cc: <[email-masked]>

I am in favor of this document being adopted as a working group I-D.

Best Regards,

/Dirk

Am 05.08.2008 um 18:24 schrieb Adrian Farrel:

> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and  
> seemed to be pretty mature.
>
> Note that despite the file name, the content of this document is  
> consistent with its title: "Routing and Wavelength Assignment  
> Information Model for Wavelength Switched Optical Networks." That  
> is, the scope is limited to the information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready  
> to be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>

Delivery-date: Wed, 06 Aug 2008 12:53:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for RWA Info model as WG I-D
Date: Wed, 6 Aug 2008 14:51:10 +0200
From: "Howard Green" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

 yes

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 05 August 2008 18:24
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
>=20
> Hi,
>=20
> draft-bernstein-ccamp-wson-info-03.txt was discussed in=20
> Dublin and seemed to be pretty mature.
>=20
> Note that despite the file name, the content of this document=20
> is consistent with its title: "Routing and Wavelength=20
> Assignment Information Model for Wavelength Switched Optical=20
> Networks." That is, the scope is limited to the information=20
> model for RWA.
>=20
> Can we have your opinion, please, on whether this document is=20
> ready to be adopted as a working group I-D.
>=20
> Thanks,
> Adrian and Deborah
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 06 Aug 2008 09:06:21 +0000
Content-class: urn:content-classes:message
Subject: draft-rhodes-rsvp-recovery-signaling-00
Date: Wed, 6 Aug 2008 10:04:59 +0100
From: "David McWalter" <[email-masked]>
To: <[email-masked]>
Cc: "Andrew Rhodes" <[email-masked]>, "Nic Neate" <[email-masked]>

Dear all,

We would welcome comments on this draft.

Andrew Rhodes, Nic Neate, David McWalter.

http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling
-00.txt

Title:
Problems observed with RSVP recovery signaling

Abstract:
Implementation experience with RSVP-TE recovery signaling has uncovered
some problems.  Associations between LSPs in different sessions are
forbidden.  Protecting LSPs cannot themselves be protected.  Overlapping
repairs cause loss of traffic.  This draft provides details of these
problems for the community to consider.

Delivery-date: Wed, 06 Aug 2008 06:48:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for RWA Info model as WG I-D
Date: Wed, 6 Aug 2008 08:46:16 +0200
From: "Diego Caviglia" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi all,
        Yes (from a contributor).

BR

Ciao

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Adrian Farrel
> Sent: marted=EC 5 agosto 2008 18.24
> To: [email-masked]
> Subject: Poll for RWA Info model as WG I-D
>=20
> Hi,
>=20
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and =
seemed
> to
> be pretty mature.
>=20
> Note that despite the file name, the content of this document is
> consistent
> with its title: "Routing and Wavelength Assignment Information Model =
for
> Wavelength Switched Optical Networks." That is, the scope is limited =
to
> the
> information model for RWA.
>=20
> Can we have your opinion, please, on whether this document is ready to =
be
> adopted as a working group I-D.
>=20
> Thanks,
> Adrian and Deborah
>=20
>=20
>=20
>=20

Delivery-date: Tue, 05 Aug 2008 18:32:30 +0000
Date: Tue, 05 Aug 2008 13:31:13 -0500
From: Young Lee <[email-masked]>
Subject: RE: Poll for RWA Info model as WG I-D
To: [email-masked]

In favor of the draft to be WG draft. 

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Tuesday, August 05, 2008 11:24 AM
To: [email-masked]
Subject: Poll for RWA Info model as WG I-D

Hi,

draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to

be pretty mature.

Note that despite the file name, the content of this document is consistent 
with its title: "Routing and Wavelength Assignment Information Model for 
Wavelength Switched Optical Networks." That is, the scope is limited to the 
information model for RWA.

Can we have your opinion, please, on whether this document is ready to be 
adopted as a working group I-D.

Thanks,
Adrian and Deborah

Delivery-date: Tue, 05 Aug 2008 16:47:03 +0000
Date: Tue, 05 Aug 2008 09:46:24 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Poll for RWA Info model as WG I-D

Yes.  (from one of the authors).

Regards

Greg B.

Adrian Farrel wrote:
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and 
> seemed to be pretty mature.
>
> Note that despite the file name, the content of this document is 
> consistent with its title: "Routing and Wavelength Assignment 
> Information Model for Wavelength Switched Optical Networks." That is, 
> the scope is limited to the information model for RWA.
>
> Can we have your opinion, please, on whether this document is ready to 
> be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Tue, 05 Aug 2008 16:30:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Poll for RWA Info model as WG I-D
Date: Tue, 5 Aug 2008 17:24:05 +0100

Hi,

draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to 
be pretty mature.

Note that despite the file name, the content of this document is consistent 
with its title: "Routing and Wavelength Assignment Information Model for 
Wavelength Switched Optical Networks." That is, the scope is limited to the 
information model for RWA.

Can we have your opinion, please, on whether this document is ready to be 
adopted as a working group I-D.

Thanks,
Adrian and Deborah

Delivery-date: Tue, 05 Aug 2008 09:33:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>, "'Diego Caviglia'" <[email-masked]>, "'Italo Busi'" <[email-masked]>, "'Francesco Fondelli'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was  MPLS over OTN)
Date: Tue, 5 Aug 2008 09:54:46 +0100

Maarten,

I think you need to get off this OSI thing.

Nothing the IETF does will require the use of IP in the DCN for an MPLS-TP 
stack. However, the IETF will only work on DCN protocols that are based on 
IP.

It will remain possible to manage MPLS-TP functionality using a DCN based on 
OSI, SNA, PNNI, or bluetak.

Since IP stacks are freely available and pretty small, and since it has 
already been established that IP forwarding is not necessarily required in 
the NEs, I don't know why this thread continues.

A

----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Diego Caviglia'" <[email-masked]>; "'Italo Busi'" 
<[email-masked]>; "'Francesco Fondelli'" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 05, 2008 9:23 AM
Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)

Diego,

The MPLS-TP functionality may be in equipment with e.g. SDH and OTN
functions. If such equipment uses MS-DCC to connect to the DCN, then it is
very likely that OSI is used. The MPLS-TP functions in this equipment should
**not** require that this equipment has to be equipped with two more DCN
connections supporting IP. I.e. it should be posible to manage MPLS-TP
functionality in equipment also via an OSI type DCN connection.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Diego Caviglia
Sent: 05 August 2008 09:38
To: Italo Busi; Francesco Fondelli; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)

Hi all,
       So we are at the point where we agreed that Ip forwarding is not
needed in the data plane nevertheless Ip is needed for sure for GMPLS
protocols (if used).

Now in this thread we mentioned several times the DCN, are there any
requirement about the protocol to be used for the DCN? Do we think that the
DCN should support both OSI and Ip?

Given that we are in IETF I think the answer is that the DCN and
configuration protocol must be Ip based, but may be could be useful state
that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is the right
place.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Italo Busi
> Sent: luned� 4 agosto 2008 20.14
> To: 'Francesco Fondelli'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>
> I think that Julien's proposed rephrase better describes the
> requirement so I support it.
>
> It is worth noticing that in case of static configuration and OSI
> based DCN, the MPLS-TP data (transport) plane is actually configured
> without any IP functionality.
>
> However I think that DCN requirements should be described in
> draft-gray-mpls-tp-nm-req-00.txt.
>
> For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I
> think that it is more appropriate to rephrase the requirement as
> proposed by Julien.
>
> Italo
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Francesco Fondelli
> > Sent: Monday, August 04, 2008 6:00 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] MPLS over OTN
> >
> > On Mon, Aug 4, 2008 at 5:48 PM,
> > <[email-masked]> wrote:
> > > Hi Francesco.
> >
> > Hi Julien,
> >
> > > I guess I understand your concern. I believe the original
> > intention was
> > > to say implicitely "It MUST be possible to operate and configure
> > > the MPLS-TP data (transport) plane without any IP functionality
> > *in the data
> > > plane*." My interpretation of these requirements is indeed that
> > > they apply to the MPLS-TP data plane only, not the
> > MPLS-TP-capable equipment,
> > > nor the MPLS-TP control plane...
> > >
> > > Anyway you're right, this could be confusing and it deserves a
> > > small rewording.
> >
> > Nice, thanks a lot.
> >
> > > Regards,
> > >
> > > Julien
> >
> > Ciao
> > FF
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Tue, 05 Aug 2008 09:17:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>, "'Howard Green'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Nit in Maarten's definition of the DCN
Date: Tue, 5 Aug 2008 10:15:52 +0100

Maarten had...

> A transport network element is connected to the DCN via two or more
> interfaces. 

This needs to read "one or more".

A

Delivery-date: Tue, 05 Aug 2008 07:43:19 +0000
Content-class: urn:content-classes:message
Subject: mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over OTN)
Date: Tue, 5 Aug 2008 09:38:04 +0200
From: "Diego Caviglia" <[email-masked]>
To: "Italo Busi" <[email-masked]>, "Francesco Fondelli" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi all,
       So we are at the point where we agreed that Ip forwarding is not =
needed in the data plane nevertheless Ip is needed for sure for GMPLS =
protocols (if used).

Now in this thread we mentioned several times the DCN, are there any =
requirement about the protocol to be used for the DCN? Do we think that =
the DCN should support both OSI and Ip?

Given that we are in IETF I think the answer is that the DCN and =
configuration protocol must be Ip based, but may be could be useful =
state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is =
the right place.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Italo Busi
> Sent: luned=EC 4 agosto 2008 20.14
> To: 'Francesco Fondelli'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>=20
> I think that Julien's proposed rephrase better describes the =
requirement
> so I
> support it.
>=20
> It is worth noticing that in case of static configuration and OSI =
based
> DCN, the
> MPLS-TP data (transport) plane is actually configured without any IP
> functionality.
>=20
> However I think that DCN requirements should be described in
> draft-gray-mpls-tp-nm-req-00.txt.
>=20
> For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I =
think
> that it
> is more appropriate to rephrase the requirement as proposed by Julien.
>=20
> Italo
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Francesco Fondelli
> > Sent: Monday, August 04, 2008 6:00 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] MPLS over OTN
> >
> > On Mon, Aug 4, 2008 at 5:48 PM,
> > <[email-masked]> wrote:
> > > Hi Francesco.
> >
> > Hi Julien,
> >
> > > I guess I understand your concern. I believe the original
> > intention was
> > > to say implicitely "It MUST be possible to operate and configure =
the
> > > MPLS-TP data (transport) plane without any IP functionality
> > *in the data
> > > plane*." My interpretation of these requirements is indeed that =
they
> > > apply to the MPLS-TP data plane only, not the
> > MPLS-TP-capable equipment,
> > > nor the MPLS-TP control plane...
> > >
> > > Anyway you're right, this could be confusing and it deserves a =
small
> > > rewording.
> >
> > Nice, thanks a lot.
> >
> > > Regards,
> > >
> > > Julien
> >
> > Ciao
> > FF
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
>=20
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Mon, 04 Aug 2008 21:31:33 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-04.txt 
Date: Mon,  4 Aug 2008 14:30:01 -0700 (PDT)

--NextPart

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		: Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS
	Author(s)	: T. Nadeau
	Filename	: draft-ietf-ccamp-gmpls-ted-mib-04.txt
	Pages		: 26
	Date		: 2008-8-4
	
This memo defines the Management Information Base (MIB) objects in 
   order to manage traffic engineering database (TED) information with 
   extension in support of Multi-Protocol Label Switching (MPLS) with 
   traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use 
   with network management protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-04.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ted-mib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Delivery-date: Mon, 04 Aug 2008 18:32:25 +0000
Content-class: urn:content-classes:message
Subject: RE: [mpls-tp] MPLS over OTN
Date: Mon, 4 Aug 2008 13:31:24 -0500
From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
To: "Italo Busi" <[email-masked]>, "Francesco Fondelli" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Dear all,

Julien's proposed rephrase is good.

By the way, DCN requirements (more specifically Management Communication
Network (MCN) requirements) are already described in
draft-gray-mpls-tp-nm-req-00.txt. Of course comments for improvement are
always welcome.

Regards,
Kam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Italo Busi
Sent: Monday, August 04, 2008 2:14 PM
To: 'Francesco Fondelli'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS over OTN

I think that Julien's proposed rephrase better describes the requirement
so I
support it.

It is worth noticing that in case of static configuration and OSI based
DCN, the
MPLS-TP data (transport) plane is actually configured without any IP
functionality.

However I think that DCN requirements should be described in
draft-gray-mpls-tp-nm-req-00.txt.

For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I think
that it
is more appropriate to rephrase the requirement as proposed by Julien.

Italo

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Francesco Fondelli
> Sent: Monday, August 04, 2008 6:00 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>=20
> On Mon, Aug 4, 2008 at 5:48 PM, =20
> <[email-masked]> wrote:
> > Hi Francesco.
>=20
> Hi Julien,
>=20
> > I guess I understand your concern. I believe the original=20
> intention was
> > to say implicitely "It MUST be possible to operate and configure the
> > MPLS-TP data (transport) plane without any IP functionality=20
> *in the data
> > plane*." My interpretation of these requirements is indeed that they
> > apply to the MPLS-TP data plane only, not the=20
> MPLS-TP-capable equipment,
> > nor the MPLS-TP control plane...
> >
> > Anyway you're right, this could be confusing and it deserves a small
> > rewording.
>=20
> Nice, thanks a lot.
>=20
> > Regards,
> >
> > Julien
>=20
> Ciao
> FF
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>=20

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Mon, 04 Aug 2008 18:08:53 +0000
Content-class: urn:content-classes:message
Subject: NomCom-volunteer 
Date: Mon, 4 Aug 2008 14:07:28 -0400
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

Volunteers needed...=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of NomCom Chair
Sent: Sunday, August 03, 2008 10:43 AM
To: Working Group Chairs
Subject: Please ask your WG...=20

To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
    =
https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1617
Whether you copy that message, or reference is probably up to you and
the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
    =
https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1618

Thank you,
Joel M. Halpern
Nomcom Chair
[email-masked]
[email-masked]

Delivery-date: Mon, 04 Aug 2008 16:35:22 +0000
Date: Mon, 04 Aug 2008 18:33:52 +0200
Reply-To: [email-masked]
To: Francesco Fondelli <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [mpls-tp] MPLS over OTN
From: Huub van Helvoort <[email-masked]>

Hi Francesco,

You replied:

>> This requirement defines that the MPLS-TP data (transport) plane operates in
>> the absence of an IP data (transport) plane. This requirement does not say
>> anything about the DCN, and the technologies deployed in this DCN.
> 
> I agree with you, but I think that "and configure" should be removed.
> 
> How can you *configure* MPLS-TP data plane without IP (or OSI)?
> Am I the only one that feel uncomfortable with this piece of text?

By using the same NMS that is used to configure the OTN node.

Ciao, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Mon, 04 Aug 2008 15:49:55 +0000
Content-class: urn:content-classes:message
Subject: RE: [mpls-tp] MPLS over OTN
Date: Mon, 4 Aug 2008 17:48:57 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Francesco.

I guess I understand your concern. I believe the original intention was
to say implicitely "It MUST be possible to operate and configure the
MPLS-TP data (transport) plane without any IP functionality *in the data
plane*." My interpretation of these requirements is indeed that they
apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment,
nor the MPLS-TP control plane...

Anyway you're right, this could be confusing and it deserves a small
rewording.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francesco Fondelli

On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers
<[email-masked]> wrote:
> Francesco,

Hi Maarten,

> This requirement defines that the MPLS-TP data (transport) plane
operates in
> the absence of an IP data (transport) plane. This requirement does not
say
> anything about the DCN, and the technologies deployed in this DCN.

I agree with you, but I think that "and configure" should be removed.

How can you *configure* MPLS-TP data plane without IP (or OSI)?
Am I the only one that feel uncomfortable with this piece of text?

> Regards,
> Maarten

Ciao
FF
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Mon, 04 Aug 2008 15:36:53 +0000
Content-class: urn:content-classes:message
Subject: RE: [mpls-tp] MPLS over OTN
Date: Mon, 4 Aug 2008 17:35:37 +0200
From: "Diego Caviglia" <[email-masked]>
To: "Francesco Fondelli" <[email-masked]>, "Maarten Vissers" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Opsss you are right!

I've missed the term configure! I was focused on the fact that an =
MPLS-TP equipment doesn't need to be able to perform IP forwarding at =
the data plane.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Francesco Fondelli
> Sent: luned=EC 4 agosto 2008 17.32
> To: Maarten Vissers
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>=20
> On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers
> <[email-masked]> wrote:
> > Francesco,
>=20
> Hi Maarten,
>=20
> > This requirement defines that the MPLS-TP data (transport) plane
> operates in
> > the absence of an IP data (transport) plane. This requirement does =
not
> say
> > anything about the DCN, and the technologies deployed in this DCN.
>=20
> I agree with you, but I think that "and configure" should be removed.
>=20
> How can you *configure* MPLS-TP data plane without IP (or OSI)?
> Am I the only one that feel uncomfortable with this piece of text?
>=20
> > Regards,
> > Maarten
>=20
> Ciao
> FF
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Mon, 04 Aug 2008 15:26:43 +0000
Content-class: urn:content-classes:message
Subject: RE: [mpls-tp] MPLS over OTN
Date: Mon, 4 Aug 2008 17:23:25 +0200
From: "Diego Caviglia" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>, "Francesco Fondelli" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi,
   I think that the Maarten interpretation is correct.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Maarten Vissers
> Sent: luned=EC 4 agosto 2008 16.28
> To: 'Francesco Fondelli'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>=20
> Francesco,
>=20
> This requirement defines that the MPLS-TP data (transport) plane =
operates
> in
> the absence of an IP data (transport) plane. This requirement does not =
say
> anything about the DCN, and the technologies deployed in this DCN.
>=20
> Regards,
> Maarten
>=20
> -----Original Message-----
> From: Francesco Fondelli [mailto:[email-masked]]
> Sent: 04 August 2008 15:00
> To: Maarten Vissers
> Cc: Adrian Farrel; Howard Green; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS over OTN
>=20
> On Mon, Aug 4, 2008 at 2:50 PM, Maarten Vissers
> <[email-masked]>
> wrote:
> > Adrian, Howard,
> >
> > The transport network has a DCN, and this DCN inlcudes today a mix =
of
> > OSI and IP technologies.
>=20
> Hi,
>=20
> --- draft-jenkins-mpls-mpls-tp-requirements-00
>=20
>    o  It MUST be possible to operate and configure the MPLS-TP data
>       (transport) plane without any IP functionality.
>=20
> ---
>=20
> So what do you think about this requirement?
>=20
> Ciao
> FF
>=20
>=20
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

Delivery-date: Mon, 04 Aug 2008 08:44:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Howard Green" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: MPLS over OTN
Date: Mon, 4 Aug 2008 09:42:53 +0100

Hi again Howard,

So, to pick apart the control plane in an MPLS network ( I think I am 
agreeing with you fully)...

In band
This could only happen using the sort of mechanisms being proposed for ACH.
That is, each control plane message is packaged as an MPLS packet and 
labelled as for the LSP that it is controlling. The TTL is set to one (or 
more to allow non-adjacent signalling). A secondary label on the stack might 
be used to identify the control plane when the top-level label expires. We 
already have the Router Alert label defined.
However, such a mechanism would only work for existing LSPs meaning that we 
could never set up new ones!

Out of band in fibre
(Bear in mind that the nature of MPLS means that this is very similar to in 
band except within the switching fabric)
To make this work we simply need a reserved label to identify control plane 
traffic. The Router Alert label already provides this.
However, we lack a mechanism for non-adjacent signalling. There are two use 
cases in GMPLS...
1. Hierarchical and stitched LSPs
  In this case, we can use the hierarchical or stitched LSP to carry
  the control traffic. For hierarchical, it is simple since we can put the
  Router Alert label second on the stack where it will be discovered
  when the top label is popped. For stitching, we must also set the
  TTL to expire at the end of the stitching segment.
2. Notify messages
  These messages may be exchanged between non-adjacent nodes.
  Normally they rely on IP routing, but there is an option to get them
  forwarded hop-by-hop by the control planes of the nodes along the
  LSP - this is NOT IP-based forwarding, but relies on each node on
  the path of an LSP knowing the next control plane node in each
  direction (something that is required by RSVP-TE anyway).
  An alternative is to use the LSP that is being notified, and to set the
  TTL as necessary also using a Router Alert label just as for stitching.
A further alternative (sufficient but not necessary) approach would be to 
set up a mesh of LSPs to support the control plane.

Out of band out of fibre
I am inclined to agree that there may often be good reasons to operate this 
way.
Using an IP network as a DCN makes a lot of sense and it should be noted 
that this does not require that the NEs have IP forwarding capabilities.

Cheers,
Adrian

----- Original Message ----- 
From: "Howard Green" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 04, 2008 9:23 AM
Subject: RE: MPLS over OTN

Adrian
Thanks (for the homily as well!)
My apologies for some lack of clarity.
As you say, GMPLS control of OTN is what it is. The use of a G-PID
describing an MPLS payload does, presumably, allow an OTN path to be
advertised (with suitable policy constraints) as an MPLS forwarding
adjacency. In the MPLS layer above this OTN, it is not so obvious how to
carry IP "in band", and therefore the GMPLS mechanics seem to be
required. As you say, the control plane could be "OOB but in fiber" (or
here, in OTN path) or out of fibre. Thus there would seem to be utility
in an optional associated channel mechanism for the control plane. I
wonder whether there may be a requirement of the reverse kind (maximum
diversity between data plane and control plane) in some circumstances.
/Howard

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 01 August 2008 10:53
> To: Howard Green; [email-masked]
> Cc: [email-masked]
> Subject: Re: MPLS over OTN
>
> Hi Howard,
>
> [adding MPLS-TP mailing list]
>
> Accurate representation of our conversation.
> That is, in GMPLS we have label type, switching type,
> encoding type, and G-PID.
> G-PID identifies the payload and re-uses the Ethertype
> codepoints. Thus we can carry MPLS.
> If GFP is used for framing, it must also identify the payload
> and, as you point out, GFP has an MPLS codepoint.
>
> That the GFP codepoint for MPLS is the same as that for
> "T-MPLS" is good for Option 1 (which is where we are) since
> there is no practical difference between MPLS and MPLS-TP.
>
> Now, the operation of MPLS over OTN that you describe is
> actually the operation of an OTN. So the issues of control
> channels in OTN are exactly as you describe, but have nothing
> to do with the payload protocol. This is simply GMPLS control
> of OTN. Period.
>
> GMPLS control of MPLS-TP is a different kettle of ball games.
> Here the switching type is PSC: the same switching type as
> for MPLS. A feature of GMPLS is that there is *logical*
> separation of control plane and data plane.
> This means that the control plane can be in-band (MPLS-TE),
> out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre.
>
> MPLS-TP requirements say that it must be possible to operate
> the network "in the absence of IP." I have taken this to mean
> "in the absence of IP routing and forwarding" (but this is my
> opinion and there is no explicit evidence in the requirements
> I-D). With this view...
> - We can use IP identifiers (addresses) in the data plane and
> the control plane
> - We can use IP-based control protocols (GMPLS)
> - We can use an IP-based control network if available, but we cannot
>    mandate it
> - Control entities that need to communicate must be allowed to be
>    IP-adjacent so that there is no requirement for
> IP-forwarding in the
>    network
>
> I believe we can do all of the above, and often do in GMPLS networks.
> The crunch questions are:
> 1. What is the physical technology for the data links in the
> control plane?
> 2. How do we identify control plane traffic when it arrives at a node?
> 3. How do we exchange control plane messages between nodes that
>    do not have a common data link in the control plane?
>
> Answers are:
> 1. We don't care :-)
>     But a possible answer in MPLS-TP is an LSP (e.g. a
> reserved label) 2. From the data link (since there is no need
> to disambiguate the control
>    plane traffic from any other traffic on the data link) 3.
> This is a more tricky question. However nearly all of the messages
>    are exchanged only between data-plane-adjacent nodes. This can be
>    the case in the IGP-TE protocols, and is true for all messages in
>    RSVP-TE with a couple of exceptions (below). It is also
> the case for
>    LMP. So IP forwarding is not required in the control plane.
>    The tricky cases are:
>    - echo response in LSP Ping (we are rebuilding the OAM)
>    - Notify message in RSVP-TE (we are considering OAM approaches
>      for the uses of Notify where IP forwarding is not available)
>    - "Targeted Path messages" used in hierarchical LSPs (and LSP
>       stitching). In these cases we are effectively building a virtual
>       data plane adjacency and should build a parallel virtual control
>       plane link between the end points (e.g. an LSP).
>
> We should note that the output of the JWT *appears* to be
> that "GMPLS meets the requirements of a control plane for MPLS-TP."
>
> We should also note that management plane operation of
> MPLS-TP is a requirement, and we must assume that management
> plane messages may need to be exchanged between management
> stations and network nodes using some protocol and connectivity.
>
> </homily>
>
> Adrian
> ----- Original Message -----
> From: "Howard Green" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, July 31, 2008 5:55 PM
> Subject: MPLS over OTN
>
>
> Just to record for the list a chat with Adrian and Lou Berger. I
> discover from reading G.7041 Amendment 2 that there is a codepoint
> defined to allow unicast MPLS frames to be carried over OTN (ODUx)
> channels by way of GFP encoding. Reading RFC 4328, there is
> an encoding
> type for ODUx, and the switching type is TDM. There is no
> specific G-PID
> value defined for the MPLS codepoint (which was probably defined
> concurrently with the writing of RFC 4328). Adrian and Lou
> took the view
> that in this situation, the use of the unicast MPLS ethertype (#8847)
> would define for signalling this bearer type (as described in
> RFC 3471).
>
> This is relevant partly because G.7041 amendment 2 defines
> the codepoint
> to be for "MPLS or T-MPLS". I assume that this usage carries over to
> MPLS-TP. In this situation,interestingly, there is no
> prospect of inband
> IP control, and so GMPLS is the only control plane option.
> Is this correct?
> Regards Howard
>
>
>
>

Delivery-date: Mon, 04 Aug 2008 08:27:19 +0000
Content-class: urn:content-classes:message
Subject: RE: MPLS over OTN
Date: Mon, 4 Aug 2008 10:23:54 +0200
From: "Howard Green" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Adrian
Thanks (for the homily as well!)
My apologies for some lack of clarity.
As you say, GMPLS control of OTN is what it is. The use of a G-PID
describing an MPLS payload does, presumably, allow an OTN path to be
advertised (with suitable policy constraints) as an MPLS forwarding
adjacency. In the MPLS layer above this OTN, it is not so obvious how to
carry IP "in band", and therefore the GMPLS mechanics seem to be
required. As you say, the control plane could be "OOB but in fiber" (or
here, in OTN path) or out of fibre. Thus there would seem to be utility
in an optional associated channel mechanism for the control plane. I
wonder whether there may be a requirement of the reverse kind (maximum
diversity between data plane and control plane) in some circumstances.
/Howard

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]=20
> Sent: 01 August 2008 10:53
> To: Howard Green; [email-masked]
> Cc: [email-masked]
> Subject: Re: MPLS over OTN
>=20
> Hi Howard,
>=20
> [adding MPLS-TP mailing list]
>=20
> Accurate representation of our conversation.
> That is, in GMPLS we have label type, switching type,=20
> encoding type, and G-PID.
> G-PID identifies the payload and re-uses the Ethertype=20
> codepoints. Thus we can carry MPLS.
> If GFP is used for framing, it must also identify the payload=20
> and, as you point out, GFP has an MPLS codepoint.
>=20
> That the GFP codepoint for MPLS is the same as that for=20
> "T-MPLS" is good for Option 1 (which is where we are) since=20
> there is no practical difference between MPLS and MPLS-TP.
>=20
> Now, the operation of MPLS over OTN that you describe is=20
> actually the operation of an OTN. So the issues of control=20
> channels in OTN are exactly as you describe, but have nothing=20
> to do with the payload protocol. This is simply GMPLS control=20
> of OTN. Period.
>=20
> GMPLS control of MPLS-TP is a different kettle of ball games.=20
> Here the switching type is PSC: the same switching type as=20
> for MPLS. A feature of GMPLS is that there is *logical*=20
> separation of control plane and data plane.=20
> This means that the control plane can be in-band (MPLS-TE),=20
> out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre.
>=20
> MPLS-TP requirements say that it must be possible to operate=20
> the network "in the absence of IP." I have taken this to mean=20
> "in the absence of IP routing and forwarding" (but this is my=20
> opinion and there is no explicit evidence in the requirements=20
> I-D). With this view...
> - We can use IP identifiers (addresses) in the data plane and=20
> the control plane
> - We can use IP-based control protocols (GMPLS)
> - We can use an IP-based control network if available, but we cannot
>    mandate it
> - Control entities that need to communicate must be allowed to be
>    IP-adjacent so that there is no requirement for=20
> IP-forwarding in the
>    network
>=20
> I believe we can do all of the above, and often do in GMPLS networks.
> The crunch questions are:
> 1. What is the physical technology for the data links in the=20
> control plane?
> 2. How do we identify control plane traffic when it arrives at a node?
> 3. How do we exchange control plane messages between nodes that
>    do not have a common data link in the control plane?
>=20
> Answers are:
> 1. We don't care :-)
>     But a possible answer in MPLS-TP is an LSP (e.g. a=20
> reserved label) 2. From the data link (since there is no need=20
> to disambiguate the control
>    plane traffic from any other traffic on the data link) 3.=20
> This is a more tricky question. However nearly all of the messages
>    are exchanged only between data-plane-adjacent nodes. This can be
>    the case in the IGP-TE protocols, and is true for all messages in
>    RSVP-TE with a couple of exceptions (below). It is also=20
> the case for
>    LMP. So IP forwarding is not required in the control plane.
>    The tricky cases are:
>    - echo response in LSP Ping (we are rebuilding the OAM)
>    - Notify message in RSVP-TE (we are considering OAM approaches
>      for the uses of Notify where IP forwarding is not available)
>    - "Targeted Path messages" used in hierarchical LSPs (and LSP
>       stitching). In these cases we are effectively building a virtual
>       data plane adjacency and should build a parallel virtual control
>       plane link between the end points (e.g. an LSP).
>=20
> We should note that the output of the JWT *appears* to be=20
> that "GMPLS meets the requirements of a control plane for MPLS-TP."
>=20
> We should also note that management plane operation of=20
> MPLS-TP is a requirement, and we must assume that management=20
> plane messages may need to be exchanged between management=20
> stations and network nodes using some protocol and connectivity.
>=20
> </homily>
>=20
> Adrian
> ----- Original Message -----
> From: "Howard Green" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, July 31, 2008 5:55 PM
> Subject: MPLS over OTN
>=20
>=20
> Just to record for the list a chat with Adrian and Lou Berger. I
> discover from reading G.7041 Amendment 2 that there is a codepoint
> defined to allow unicast MPLS frames to be carried over OTN (ODUx)
> channels by way of GFP encoding. Reading RFC 4328, there is=20
> an encoding
> type for ODUx, and the switching type is TDM. There is no=20
> specific G-PID
> value defined for the MPLS codepoint (which was probably defined
> concurrently with the writing of RFC 4328). Adrian and Lou=20
> took the view
> that in this situation, the use of the unicast MPLS ethertype (#8847)
> would define for signalling this bearer type (as described in=20
> RFC 3471).
>=20
> This is relevant partly because G.7041 amendment 2 defines=20
> the codepoint
> to be for "MPLS or T-MPLS". I assume that this usage carries over to
> MPLS-TP. In this situation,interestingly, there is no=20
> prospect of inband
> IP control, and so GMPLS is the only control plane option.
> Is this correct?
> Regards Howard
>=20
>=20
>=20
>=20

Delivery-date: Fri, 01 Aug 2008 09:09:37 +0000
Date: Fri, 01 Aug 2008 17:09:57 +0800
From: Dan Li <[email-masked]>
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
To: "Bardalai, Snigdho" <[email-masked]>, "Ccamp (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho,

Very good question! See my comments below.

Thanks,

Dan
  ----- Original Message ----- 
  From: Bardalai, Snigdho 
  To: Ccamp (E-mail) 
  Sent: Friday, August 01, 2008 4:26 AM
  Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

  Hi Adrian and Dan, 

  I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:

  1. IGP usage in the context of traditional distributed solutions for WSON 

  [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

  2. IGP usage in the context of PCE solutions for WSON

  [Dan] It's a potential way for PCE to get the wavelength information.

  3. Flooding and refresh of static and dynamic link state updates

  [Dan] Try to figure out the impact to the performance of IGP.

  4. Data base sync-up during node restarts

  [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.

  Could you please let me know if the above is within the current scope? I believe that these are important. 

  Thanks, 
  Snigdho 

--Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Comments on "draft-li-ccamp-wson-igp-eval-01.txt"</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Times New Roman">Hi Snigdho,</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Very good question! </FONT><FONT 
face="Times New Roman">See my comments below.</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Thanks,</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Dan</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Bardalai, Snigdho</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">Ccamp (E-mail)</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, August 01, 2008 4:26 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Comments on 
  "draft-li-ccamp-wson-igp-eval-01.txt"</DIV>
  <DIV><BR></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=Arial size=2>Hi Adrian and Dan,</FONT> </P>
  <P><FONT face=Arial size=2>I have the following comments on this draft. I was 
  wondering what were the objectives for the IGP evaluation. IMHO the evaluation 
  from WSON perspective should address the following:</FONT></P>
  <P><FONT face=Arial size=2>1. IGP usage in the context of traditional 
  distributed solutions for WSON</FONT> </P>
  <P><FONT color=#000080 size=2>[Dan] With the situation that TE information is 
  already be carried by IGP, it's nature to think that the wavelength 
  information can also be carried by IGP. I am not saying it should be, but it's 
  worth to look at.</FONT></P><FONT size=2></FONT>
  <P><BR><FONT face=Arial size=2>2. IGP usage in the context of PCE solutions 
  for WSON</FONT></P>
  <P><FONT face=Arial color=#000080 size=2>[Dan] It's a potential way for PCE to 
  get the wavelength information.</FONT></P>
  <P>&nbsp;<BR><FONT face=Arial size=2>3. Flooding and refresh of static and 
  dynamic link state updates</FONT></P>
  <P><FONT color=#000080 size=2>[Dan] Try to figure out the impact to the 
  performance of IGP.</FONT></P>
  <P>&nbsp;<BR><FONT face=Arial size=2>4. Data base sync-up during node 
  restarts</FONT></P>
  <P><FONT color=#000080><FONT size=2>[Dan] Yes, this should be 
  considered.</FONT>&nbsp;<FONT size=2>Especially the very large amount of data 
  will be sent to the restarting node. We may consider the point to point data 
  exchange instead of flooding the LSA updates. Or slice the big data packet 
  into small pieces.</FONT></FONT></P>
  <P><FONT face=Arial size=2>Could you please let me know if the above is within 
  the current scope? I believe that these are important.</FONT> </P>
  <P><FONT face=Arial size=2>Thanks,</FONT> <BR><FONT face=Arial 
  size=2>Snigdho</FONT> </P><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)--

Delivery-date: Fri, 01 Aug 2008 08:55:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Howard Green" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: MPLS over OTN
Date: Fri, 1 Aug 2008 09:53:24 +0100

Hi Howard,

[adding MPLS-TP mailing list]

Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and 
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we 
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you 
point out, GFP has an MPLS codepoint.

That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for 
Option 1 (which is where we are) since there is no practical difference 
between MPLS and MPLS-TP.

Now, the operation of MPLS over OTN that you describe is actually the 
operation of an OTN. So the issues of control channels in OTN are exactly as 
you describe, but have nothing to do with the payload protocol. This is 
simply GMPLS control of OTN. Period.

GMPLS control of MPLS-TP is a different kettle of ball games. Here the 
switching type is PSC: the same switching type as for MPLS. A feature of 
GMPLS is that there is *logical* separation of control plane and data plane. 
This means that the control plane can be in-band (MPLS-TE), out-of-band but 
in-fibre (SONET/SDH or OSC), or out-of-fibre.

MPLS-TP requirements say that it must be possible to operate the network "in 
the absence of IP." I have taken this to mean "in the absence of IP routing 
and forwarding" (but this is my opinion and there is no explicit evidence in 
the requirements I-D). With this view...
- We can use IP identifiers (addresses) in the data plane and the control 
plane
- We can use IP-based control protocols (GMPLS)
- We can use an IP-based control network if available, but we cannot
   mandate it
- Control entities that need to communicate must be allowed to be
   IP-adjacent so that there is no requirement for IP-forwarding in the
   network

I believe we can do all of the above, and often do in GMPLS networks.
The crunch questions are:
1. What is the physical technology for the data links in the control plane?
2. How do we identify control plane traffic when it arrives at a node?
3. How do we exchange control plane messages between nodes that
   do not have a common data link in the control plane?

Answers are:
1. We don't care :-)
    But a possible answer in MPLS-TP is an LSP (e.g. a reserved label)
2. From the data link (since there is no need to disambiguate the control
   plane traffic from any other traffic on the data link)
3. This is a more tricky question. However nearly all of the messages
   are exchanged only between data-plane-adjacent nodes. This can be
   the case in the IGP-TE protocols, and is true for all messages in
   RSVP-TE with a couple of exceptions (below). It is also the case for
   LMP. So IP forwarding is not required in the control plane.
   The tricky cases are:
   - echo response in LSP Ping (we are rebuilding the OAM)
   - Notify message in RSVP-TE (we are considering OAM approaches
     for the uses of Notify where IP forwarding is not available)
   - "Targeted Path messages" used in hierarchical LSPs (and LSP
      stitching). In these cases we are effectively building a virtual
      data plane adjacency and should build a parallel virtual control
      plane link between the end points (e.g. an LSP).

We should note that the output of the JWT *appears* to be that "GMPLS meets 
the requirements of a control plane for MPLS-TP."

We should also note that management plane operation of MPLS-TP is a 
requirement, and we must assume that management plane messages may need to 
be exchanged between management stations and network nodes using some 
protocol and connectivity.

</homily>

Adrian
----- Original Message ----- 
From: "Howard Green" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2008 5:55 PM
Subject: MPLS over OTN

Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).

This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard

Delivery-date: Fri, 01 Aug 2008 07:36:40 +0000
Date: Fri, 01 Aug 2008 09:34:41 +0200
From: Loa Andersson <[email-masked]>
To: Attila Takacs <[email-masked]>
CC: ccamp <[email-masked]>
Subject: some comments on I-D Action:draft-takacs-ccamp-revertive-ps-00.txt

Attila,

I have planned respond to this for same time, but did not really
had time to get around to it.

Attila Takacs wrote:
> Hi Loa,
> 
> I assume a part of your comment/question relates to problems with
> reversion if LSP setup and holding priorities are mismatched.

that would be one case, but not really what i was thinking of

> In this
> case the worker may be already deleted before the reversion would take
> place. This is certainly an interesting question...

sure
> 
> ...at a first thought an explicit revertive bit may be used to override
> the priorities for LSPs with revertive protection.

I've two questions:

1. If revertiveness is the normal procedure, wouldn't it be better to
    let indicate LSPs that *shouldn't* revert?

2. What I really thought about was, how does revertiveness work with
traffic placement policies?

Assume that you have a policy that that says you want to optimize the
chances to successfully set up an LSP that make a maximum share of some
constraints. It could be any constraints, but thinking of it as bw
wouldn't wrong.

Assume also that you have three different routes form A to B, through
C, D and E respectively.

Assume that each of the nodes C, D and E has interfaces with constraint
of 100. This is of course a very simplified model just to illustrate my
point.

In order the follow your policy you place traffic on C and E, and leave
D free, if there is a request for an LSP that requires 100. So the
situation could be:

C = 40 occupied, 60 free
D = 100 free
E = 40 occupied, 60 free

now if C fails it makes sense to move the traffic to E:

C = failed
D = 100 free
E = 80 occupied, 20 free

If the failure takes some time to repair, there might be a request
for a LSP that requires 60, the only possibility is to place on D:

C = failed
D = 60 occupied, 40 free
E = 80 occupied, 20 free

Now C comes back up:

C = 100 free
D = 60 occupied, 40 free
E = 80 occupied, 20 free

This situation is in accordance with your policy, but if you
revert you loose the ability to place any LSPs which requires
more than 60

C = 40 occupied, 60 free
D = 60 occupied, 40 free
E = 40 occupied, 60 free

Why would you want to revert in this case?

Now there might be some optimization program working in the background,
that might move traffic from any of nodes to any of the other, possibly
from C to E.

I seems to me that running an optimization program is more efficient.

/Loa
> Best regards,
> Attila

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]