RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

["Don Fedyk" <[e-mail]>]

Hi Dimitri

It escapes me why the second case cannot be related to a VPN service as
viewed by the provider.  I'm not trying to link the current draft to a
VPN BTW.  There are no references to anything but the edge to edge model
in the draft.

Regards,
Don 

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> hi don - i would say that the GELS models are of two categories
> 
> o) edge to edge (SPC or SPVC model)
> 
> o) end-to-end (SC or SVC model) with two sub flavors one 
> where the end-node is not Ethernet device and one where the 
> end-node is an Ethernet device
> 
> i would not make any direct relationship between these models 
> and any VPN model simply because the latter refers to the 
> service while GELS is specifically linked to the "network 
> connectivity"
> 
> much thanks,
> - dimitri.
>  
> 
<snip>





Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 22:08:22 +0000
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], "Igor Bryskin" <[e-mail]>, "Lucy Yong" <[e-mail]>
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 1 Jul 2006 00:08:01 +0200
Content-Type: text/plain; charset="US-ASCII"

hi don - i would say that the GELS models are of two categories

o) edge to edge (SPC or SPVC model)

o) end-to-end (SC or SVC model) with two sub flavors one where the 
end-node is not Ethernet device and one where the end-node is an Ethernet 
device

i would not make any direct relationship between these models and any VPN 
model simply because the latter refers to the service while GELS is 
specifically linked to the "network connectivity"

much thanks,
- dimitri.
 




"Don Fedyk" <[e-mail]>
Sent by: [e-mail]
30/06/2006 20:29
 
        To:     "Lucy Yong" <[e-mail]>, "Igor Bryskin" 
<[e-mail]>, <[e-mail]>, <[e-mail]>
        cc: 
        Subject:        RE: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi Lucy 

See comments inline.
> -----Original Message-----
> From: Lucy Yong [mailto:[e-mail]] 
> 
> Don,
> 
> Thank you for writing this draft. It is very informative.
> 
> PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) 
> without a Spanning tree control plane.  As a result, this 
> data plane does not have knowledge of how to forwarding the 
> traffic anymore. The purpose of the draft is to suggest 
> building a new control plane which can build forwarding path 
> for all kinds of service requests as mentioned in document.
> 
Correct

> Building a new control plane for Ethernet network sounds 
> great!! The draft mentions in several places a desire of some 
> level of administrative management in building forwarding 
> path. I would like to ask a basic
> question:
> 
> The network with this new control plane should have the 
> intelligence of routing and traffic engineering to allow the 
> network building forwarding path automatically; or The 
> network should not have that intelligence, forwarding path 
> should be selected by the network management system, network 
> only needs signaling capability to build forwarding path.
> 
> Which model do you pursue for PBT, why?
Either model is appropriate. It comes down to a Network providers
requirements to manage the network and the resources. For many reasons
initial PBT services are static from a source/destination view point.
In some cases we will be starting from a centralized management system.
However, the aspects of GMPLS signaling and control allow a range of
static to dynamic paths even though the endpoints are static. The real
issues related to dynamic control are much like L1VPNs and some of
Igor's comments.  If the service has an identifiable UNI a more dynamic
model may be developed but right now we specifying the provider
operations. 

Regards,
Don 

> 
> Best Regards,
> Lucy Yong
> 

_______________________________________________
gels mailing list
[e-mail]
https://rtg.ietf.org/mailman/listinfo/gels





Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 21:59:57 +0000
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail], [e-mail], "Igor Bryskin" <[e-mail]>, "Lucy Yong" <[e-mail]>, [e-mail]
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 30 Jun 2006 23:58:30 +0200
Content-Type: text/plain; charset="US-ASCII"

hi don

when you write

> BTW centralized path control may need a PCE system not necessarily a 
management system. 

Path Control and Path Computation - are two different functions - 

i know that the acronym PCx could be misleading but hope not until that 
point

thanks;
- dimitri.





"Don Fedyk" <[e-mail]>
Sent by: [e-mail]
30/06/2006 21:44
 
        To:     "Lucy Yong" <[e-mail]>, "Igor Bryskin" 
<[e-mail]>, <[e-mail]>, <[e-mail]>
        cc: 
        Subject:        RE: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi Lucy 

<snip>
> > 
> > Which model do you pursue for PBT, why?
> Either model is appropriate. It comes down to a Network 
> providers requirements to manage the network and the 
> resources. For many reasons initial PBT services are static 
> from a source/destination view point.
> In some cases we will be starting from a centralized 
> management system.
> However, the aspects of GMPLS signaling and control allow a 
> range of static to dynamic paths even though the endpoints 
> are static. The real issues related to dynamic control are 
> much like L1VPNs and some of Igor's comments.  If the service 
> has an identifiable UNI a more dynamic model may be developed 
> but right now we specifying the provider operations. 
> 
> [Lucy] On demand request from customer space could be 
> implemented in two ways also, embedded network intelligence 
> or management plane driven.
> Somehow, I think this is the architecture design issue not 
> strictly related to on demand request from customer. 
> Basically, how we want to build an end to end forwarding 
> path, rely on network intelligence or network management system?

Let me paraphrase your comment. Does the network have the intelligence
for path creation or does the intelligent lie in the management system? 
I assume by network intelligence you meant he typical TE database? 
Well, this is just my opinion, we know when path holding times are long
and network fill is a concern that centralized management systems can
add extra policy type operations that we do not have in today's typical
TE network database. 
We also know that when path turnaround times are short or there is ample
bandwidth that any reasonable path will do network intelligence of today
TE database is quite adequate. This leads me to believe that initial
path requests will have  more centralized path control but path
maintenance operations are logically handled be the network (eg
rerouting, reversion etc). BTW centralized path control  may need a PCE
system not necessarily a management system. 

Of course the other interpretation of your question is do we augment the
network with more intelligence? In some ways we proposed to do this for
optical systems but uptake on augmenting the TE database has been slow
going. 

I don't think that PBT is special in this regard I think that generally
these questions are applicable to any of the GMPLS systems. 

Regards,
Don 
> 
> Regards,
> Don 
> 
> > 
> > Best Regards,
> > Lucy Yong
> > 
> 
> 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 19:45:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Fri, 30 Jun 2006 15:44:06 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAAKhQ4AAEdQNgAACJYhAFrom: "Don Fedyk" <[e-mail]>
To: "Lucy Yong" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Lucy 

<snip>
> > 
> > Which model do you pursue for PBT, why?
> Either model is appropriate. It comes down to a Network 
> providers requirements to manage the network and the 
> resources. For many reasons initial PBT services are static 
> from a source/destination view point.
> In some cases we will be starting from a centralized 
> management system.
> However, the aspects of GMPLS signaling and control allow a 
> range of static to dynamic paths even though the endpoints 
> are static. The real issues related to dynamic control are 
> much like L1VPNs and some of Igor's comments.  If the service 
> has an identifiable UNI a more dynamic model may be developed 
> but right now we specifying the provider operations. 
> 
> [Lucy] On demand request from customer space could be 
> implemented in two ways also, embedded network intelligence 
> or management plane driven.
> Somehow, I think this is the architecture design issue not 
> strictly related to on demand request from customer. 
> Basically, how we want to build an end to end forwarding 
> path, rely on network intelligence or network management system?

Let me paraphrase your comment. Does the network have the intelligence
for path creation or does the intelligent lie in the management system? 
I assume by network intelligence you meant he typical TE database? 
Well, this is just my opinion, we know when path holding times are long
and network fill is a concern that centralized management systems can
add extra policy type operations that we do not have in today's typical
TE network database.   
We also know that when path turnaround times are short or there is ample
bandwidth that any reasonable path will do network intelligence of today
TE database is quite adequate. This leads me to believe that initial
path requests will have  more centralized path control but path
maintenance operations are logically handled be the network (eg
rerouting, reversion etc). BTW centralized path control  may need a PCE
system not necessarily a management system. 

Of course the other interpretation of your question is do we augment the
network with more intelligence? In some ways we proposed to do this for
optical systems but uptake on augmenting the TE database has been slow
going.  

I don't think that PBT is special in this regard I think that generally
these questions are applicable to any of the GMPLS systems. 

Regards,
Don 
> 
> Regards,
> Don 
> 
> > 
> > Best Regards,
> > Lucy Yong
> >  
> 
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 18:52:49 +0000
Date: Fri, 30 Jun 2006 13:52:19 -0500
From: Lucy Yong <[e-mail]>
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
To: 'Don Fedyk' <[e-mail]>, 'Igor Bryskin' <[e-mail]>, [e-mail], [e-mail]
Message-id: <01d701c69c76$50635940$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAAKhQ4AAEdQNg

Hi Don,

See Below.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Don Fedyk
Sent: Friday, June 30, 2006 1:29 PM
To: Lucy Yong; Igor Bryskin; [e-mail]; [e-mail]
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

Hi Lucy 

See comments inline.
> -----Original Message-----
> From: Lucy Yong [mailto:[e-mail]] 
> 
> Don,
> 
> Thank you for writing this draft. It is very informative.
> 
> PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) 
> without a Spanning tree control plane.  As a result, this 
> data plane does not have knowledge of how to forwarding the 
> traffic anymore. The purpose of the draft is to suggest 
> building a new control plane which can build forwarding path 
> for all kinds of service requests as mentioned in document.
> 
Correct

> Building a new control plane for Ethernet network sounds 
> great!! The draft mentions in several places a desire of some 
> level of administrative management in building forwarding 
> path. I would like to ask a basic
> question:
> 
> The network with this new control plane should have the 
> intelligence of routing and traffic engineering to allow the 
> network building forwarding path automatically; or The 
> network should not have that intelligence, forwarding path 
> should be selected by the network management system, network 
> only needs signaling capability to build forwarding path.
> 
> Which model do you pursue for PBT, why?
Either model is appropriate. It comes down to a Network providers
requirements to manage the network and the resources. For many reasons
initial PBT services are static from a source/destination view point.
In some cases we will be starting from a centralized management system.
However, the aspects of GMPLS signaling and control allow a range of
static to dynamic paths even though the endpoints are static. The real
issues related to dynamic control are much like L1VPNs and some of
Igor's comments.  If the service has an identifiable UNI a more dynamic
model may be developed but right now we specifying the provider
operations. 

[Lucy] On demand request from customer space could be implemented in two
ways also, embedded network intelligence or management plane driven.
Somehow, I think this is the architecture design issue not strictly related
to on demand request from customer. Basically, how we want to build an end
to end forwarding path, rely on network intelligence or network management
system?

Regards,
Don 

> 
> Best Regards,
> Lucy Yong
>  






Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 18:29:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Fri, 30 Jun 2006 14:29:17 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAAKhQ4A=
From: "Don Fedyk" <[e-mail]>
To: "Lucy Yong" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Lucy 

See comments inline.
> -----Original Message-----
> From: Lucy Yong [mailto:[e-mail]] 
> 
> Don,
> 
> Thank you for writing this draft. It is very informative.
> 
> PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) 
> without a Spanning tree control plane.  As a result, this 
> data plane does not have knowledge of how to forwarding the 
> traffic anymore. The purpose of the draft is to suggest 
> building a new control plane which can build forwarding path 
> for all kinds of service requests as mentioned in document.
> 
Correct

> Building a new control plane for Ethernet network sounds 
> great!! The draft mentions in several places a desire of some 
> level of administrative management in building forwarding 
> path. I would like to ask a basic
> question:
> 
> The network with this new control plane should have the 
> intelligence of routing and traffic engineering to allow the 
> network building forwarding path automatically; or The 
> network should not have that intelligence, forwarding path 
> should be selected by the network management system, network 
> only needs signaling capability to build forwarding path.
> 
> Which model do you pursue for PBT, why?
Either model is appropriate. It comes down to a Network providers
requirements to manage the network and the resources. For many reasons
initial PBT services are static from a source/destination view point.
In some cases we will be starting from a centralized management system.
However, the aspects of GMPLS signaling and control allow a range of
static to dynamic paths even though the endpoints are static. The real
issues related to dynamic control are much like L1VPNs and some of
Igor's comments.  If the service has an identifiable UNI a more dynamic
model may be developed but right now we specifying the provider
operations. 

Regards,
Don 

> 
> Best Regards,
> Lucy Yong
>  



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 18:27:24 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C72.B6126739"
Subject: Updates to Graceful Shutdown ID... 
Date: Fri, 30 Jun 2006 14:26:31 -0400
Message-ID: <[e-mail]>
Thread-Topic: Updates to Graceful Shutdown ID... 
Thread-Index: AcaccrVi8+gAwfBiSp6IYeRkDqPlFg=
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "ccamp" <[e-mail]>
Cc: <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>, "Jean Philippe Vasseur \(jvasseur\)" <[e-mail]>, "Kireeti Kompella" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C69C72.B6126739
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all, 
 
Please note that we have posted a newer version for Graceful Shutdown ID
(http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutd
own-04.txt
<http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutd
own-04.txt> ). In this version we have addressed comments from Dimitri,
Adrian, Kireeti, and all during the WG meeting and have removed use of
link-attribute sub-TLV from this ID. The ID makes use of (MAX-METRIC, 0
bandwidth) for communicating graceful shutdown condition in IGP, like
RFC4203/ RFC4205 uses for graceful restarts.
 
We believe that we have addressed all comments we have received in past.
Please let us know if you have any further comments. 
 
Thanks
 
Regards... Zafar  
 

------_=_NextPart_001_01C69C72.B6126739
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=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1543" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=455465513-30062006>Hi all, 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial size=2>Please note that we 
have posted a newer version for Graceful Shutdown ID (</FONT><A 
href="http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt"><FONT 
face=Arial color=#000000 
size=2>http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt</FONT></A><FONT 
face=Arial size=2>). </FONT></SPAN><FONT face=Arial><FONT size=2>In this version 
we have addressed comments from Dimitri, Adrian,&nbsp;<SPAN 
class=455465513-30062006>Kireeti, </SPAN><SPAN class=455465513-30062006>and all 
</SPAN>during the WG meeting and have removed use of link-attribute sub-TLV from 
this ID. The ID makes use of (MAX-METRIC, 0 bandwidth) for communicating 
graceful shutdown condition in IGP<SPAN class=455465513-30062006>, like RFC4203/ 
RFC4205 uses for graceful restarts.</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial size=2>We believe that we 
have addressed all comments we have received in past. Please let us know if you 
have any further comments. </FONT></SPAN></DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial 
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=455465513-30062006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=455465513-30062006><FONT size=2><FONT face=Arial>Regards... 
Zafar</FONT> &nbsp;</FONT></SPAN></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C69C72.B6126739--



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 16:31:47 +0000
Date: Fri, 30 Jun 2006 11:30:31 -0500
From: Lucy Yong <[e-mail]>
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
To: 'Don Fedyk' <[e-mail]>, 'Igor Bryskin' <[e-mail]>, [e-mail], [e-mail]
Message-id: <01ba01c69c62$8145ef50$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpA
Don,

Thank you for writing this draft. It is very informative.

PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) without a
Spanning tree control plane.  As a result, this data plane does not have
knowledge of how to forwarding the traffic anymore. The purpose of the draft
is to suggest building a new control plane which can build forwarding path
for all kinds of service requests as mentioned in document.

Building a new control plane for Ethernet network sounds great!! The draft
mentions in several places a desire of some level of administrative
management in building forwarding path. I would like to ask a basic
question:

The network with this new control plane should have the intelligence of
routing and traffic engineering to allow the network building forwarding
path automatically; or
The network should not have that intelligence, forwarding path should be
selected by the network management system, network only needs signaling
capability to build forwarding path.

Which model do you pursue for PBT, why?

Best Regards,
Lucy Yong
 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Don Fedyk
Sent: Monday, June 26, 2006 10:50 AM
To: Igor Bryskin; [e-mail]; [e-mail]
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Igor Bryskin
>
> Thanks Don,
> 
> See in-line.
> 
> Igor
> 
> ----- Original Message -----
> From: "Don Fedyk" <[e-mail]>
> 
<snip>
> 
> So you have two questions: Do we need Auto-discovery; and if so should
> it be IGP based or BGP based.
> In the simple mode we have specified so far MAC Learning on 
> the edge is
> all we need.  So no auto discovery.
> 
> 
> IB>> Well, MAC Learning tells edge switch which port an 
> Ethernet packet
> destined to a particular D-MAC should be sent out. However, 
> it does not tell
> the TE name of the edge switch (on the opposite side of the network)
> supporting this D-MAC. So how the ingress switch can tell (without
> auto-discovery or configuration) which of (new or existing) 
> Eth-LSPs could
> be used for the packet forwarding?
> 
> Thanks,
> Igor
> 
To be clear on this the association is made statically up front in the
current document. No new Eth-LSPs are set up due to the arrival of an
new D-MAC. There is a static binding of a Customer Port to a Ethernet
LSP. There is a static binding of the Eth-LSP to a destination switch.
At the ingress provider node and a destination provider node typically a
PW identifier or a PPB I-SID is used to mux/demux the packet on the
Eth-LSP. You could also have a dedicated Eth-LSP with no multiplexer.

Regards,
Don 

(text below is consistent with this if we do what you are alluding to in
the future)

> However if we ever get to on demand
> signaling on the connections from the customer space then an auto
> discovery function would be desirable.
> 
> As to IGP or BGP, very similar to the L1VPN case. We have discussed
> keeping the Optical code base and the Ethernet code base development
> based on the same architecture.  I don't see much difference here we
> could develop either it depends on customer demand for such a feature.
> Currently out of scope for us.
> 
> Regards,
> Don
> 
> >
> > It would be good if your draft would provide some of your
> > views on such mechanism and, more generally, on which routing
> > protocols should be supported by GMPLS controllers managing
> > Ethernet switches. Obviously, IGP-TE is going to be required
> > to enable path computation. But how about BGP?
> >
> > Thanks,
> > Igor
> >
> <snip>
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 08:05:46 +0000
Date: Fri, 30 Jun 2006 10:04:54 +0200
From: Dan Li <[e-mail]>
Subject: New I-D: draft-li-ccamp-confirm-data-channel-status-00.txt
To: ccamp <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: Xu Huiying <[e-mail]>, [e-mail]
Message-id: <009a01c69c1b$f49826e0$a76d5ec2@dan>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_kvx2ZpABc5lT09D4KuXdRQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_kvx2ZpABc5lT09D4KuXdRQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_XQE6nVQDfu+L5hLqVsxilw)"


--Boundary_(ID_XQE6nVQDfu+L5hLqVsxilw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Dear,

We just posted a new I-D: draft-li-ccamp-confirm-data-channel-status-00.txt for which your comments are very welcome! The following is the abstract of this new I-D, please check out the attachment for details.

There still have some issues have not been resolved in this draft, such as how to handle the bidirectional LSP case etc. So your comments are very helpful to this draft.

Abstract 

   This document defines simple additions to the Link Management 
   Protocol (LMP) to provide a control plane tool that can assist in the 
   location of stranded resources by allowing adjacent LSRs to confirm 
   data channel statuses, and provides procedures for notifying the 
   management plane if any discrepancies are found. 

Best regards,


Dan Li

--Boundary_(ID_XQE6nVQDfu+L5hLqVsxilw)
Content-type: text/html; charset=gb2312
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=gb2312">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Times New Roman">
<DIV><FONT face="Times New Roman">Dear,</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">We just posted a new I-D: 
draft-li-ccamp-confirm-data-channel-status-00.txt for which your comments are 
very welcome! The following is the abstract of this new I-D, please check out 
the attachment for details.</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV>There still have some issues have not been resolved in this draft, such as 
how to handle the bidirectional LSP case etc. So your comments are very helpful 
to this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Abstract </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; This document defines simple additions to the Link Management 
<BR>&nbsp;&nbsp; Protocol (LMP) to provide a control plane tool that can assist 
in the <BR>&nbsp;&nbsp; location of stranded resources by allowing adjacent LSRs 
to confirm </DIV>
<DIV>&nbsp;&nbsp; data channel statuses, and provides procedures for notifying 
the <BR>&nbsp;&nbsp; management plane if any discrepancies are found. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Best regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV><FONT face="Times New Roman">Dan Li<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_XQE6nVQDfu+L5hLqVsxilw)--

--Boundary_(ID_kvx2ZpABc5lT09D4KuXdRQ)
Content-type: text/plain; name=draft-li-ccamp-confirm-data-channel-status-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-li-ccamp-confirm-data-channel-status-00.txt

Network Working Group                                          Dan Li 
                                                             Huiying Xu 
Internet Draft 
Category: Standards Track                                      Huawei 
                                                                       
Expires: December 2006                                     June, 2006 
 
                                      
                Data Channel Status Confirmation Extensions 
                     for the Link Management Protocol 


             draft-li-ccamp-confirm-data-channel-status-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

    

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html 

    

Abstract 

   This document defines simple additions to the Link Management 
   Protocol (LMP) to provide a control plane tool that can assist in the 
   location of stranded resources by allowing adjacent LSRs to confirm 

 
 
 
Li                     Expires December 2006                 [Page 1] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   data channel statuses, and provides procedures for notifying the 
   management plane if any discrepancies are found. 

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 [RFC2119]. 

Table of Contents 

    
   1. Introduction................................................2 
   2. Problem Explanation.........................................3 
   3. Extensions to LMP...........................................5 
      3.1. Confirm Data Channel Status Messages....................5 
         3.1.1. ConfirmDataChannelStatus Messages (Msg Type = 21)...5 
         3.1.2. ConfirmDataChannelStatusAck Messages (Msg Type = 22)5 
         3.1.3. ConfirmDataChannelStatusNack Messages (Msg Type = 23)6 
      3.2. Data Channel Status Subobject...........................7 
   4. Procedures..................................................8 
   5. Security Considerations......................................9 
   6. IANA Considerations.........................................9 
   7. Acknowledgments.............................................9 
   8. References..................................................9 
      8.1. Normative References....................................9 
      8.2. Informative References.................................10 
   9. Author's Addresses.........................................10 
   10. Full Copyright Statement...................................11 
   11. Intellectual Property Statement............................11 
    
1. Introduction 

   A data channel status mismatch exists if one end of a TE link 
   believes that the data channel is assigned to carry data, but the 
   other end does not. The term "ready to carry data" means cross-
   connected, or bound to an end-point for the receipt or delivery of 
   data.  

   Data channel mismatches cannot be detected from the TE information 
   advertised by the routing protocols [RFC4203], [RFC4205]. A data 
   channel in this context corresponds to a resource label in a non-
   packet technology (such as a timeslot or a lambda), and this 
   information is not part of the TE information advertised by the 
   routing protocols. 

 
 
Li                     Expires December 2006                 [Page 2] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   If a data channel mismatch exists, any attempt to use the data 
   channel for a new LSP will fail. One end of the TE link may attempt 
   to assign the TE link for use, but the other end will report the data 
   channel as unavailable when the control plane or management plane 
   attempts to assign it to an LSP. 

   Although such a situation can be resolved through the use of the 
   Acceptable Label Set object in GMPLS signaling [RFC3473], such a 
   procedure is inefficient since it may require an additional signaling 
   exchange for each LSP that is set up. When many LSPs are to be set up, 
   and when there are many data channel mismatches, such inefficiencies 
   become significant. It is desirable to avoid the additional signaling 
   overhead, and to report the problems to the management plane so that 
   they can be resolved to improve the efficiency of LSP setup. 

   Correspondingly, such a mismatch situation may give rise to 
   misconnections in the data plane especially when LSPs are set up 
   using management plane operations. 

   Resources (data channels) that are in a mismatched state are often 
   described as "stranded resources". They are not in use for any LSP, 
   but they cannot be assigned for use by a new LSP because they appear 
   to be in use. Although it is theoretically possible for management 
   plane applications to audit all network resources to locate stranded 
   resources and to release them, this process is rarely performed 
   because of the difficulty of coordinating different Element 
   Management Systems (EMSs), and the associated risks of accidentally 
   releasing in-use resources. It is desirable to have a control plane 
   mechanism that detects and reports stranded resources. 

   This document defines simple additions to the Link Management 
   Protocol (LMP) [RFC4204] to provide a control plane tool that can 
   assist in the location of stranded resources by allowing adjacent 
   LSRs to confirm data channel statuses, and provides procedures for 
   notifying the management plane if any discrepancies are found. 

2. Problem Explanation 

   An example of a data channel mismatch is described as the following 
   two scenarios. 

   Scenario 1: Mismatch caused by manual configuration 




 
 
Li                     Expires December 2006                 [Page 3] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   The operator may have configured a cross-connection at only one end 
   of a TE link using an EMS. The resource of one end of a data channel 
   is allocated, but the corresponding resource is still available at 
   the other end of the same data channel. In this case, the data 
   channel may appear to be available for use by the control plane when 
   viewed from one end of the TE link, but will be considered to be 
   unavailable by the other end of the TE link. Alternatively, the 
   available end of the data channel may be cross-connected by the 
   management plane and a misconnection may result from the fact that 
   the other end of the data channel is already cross-connected. 

   Figure 1 shows a data channel between nodes A and B. Only the 
   resource at A end is allocated by manual configuration, while the 
   resource at B end is available, so the data channel status is 
   mismatched. 

                    allocated      available 
                       +-+------------+-+ 
                    A  |x|            | |  B 
                       +-+------------+-+ 
                            data channel              
         Figure 1. Mismatch caused by manual configuration 
    
   Scenario 2: Mismatch caused by LSP deletion 

   The channel status of a data link may become mismatched during the 
   LSP deletion process. If the LSP deletion process is aborted in the 
   middle of the process (perhaps because of a temporary control plane 
   failure), the cross-connection at the upstream node may be removed 
   while the downstream node still keeps its cross-connection.  

   For example, in Figure 2 an LSP traverses nodes A, B, and C. Node B 
   resets abnormally when the LSP is being deleted, which results in the 
   cross-connections of node A and C being removed, but the cross-
   connection of node B is still in use. So the data channel status 
   between nodes A and B, and between nodes B and C are both mismatched. 

                       <---------LSP---------> 
                       +-+-------+-+-------+-+          
                       | |       |X|       | |            
                       +-+-------+-+-------+-+     
                        A         B         C  
             Figure 2. Mismatch caused by LSP deletion  

 
 
Li                     Expires December 2006                 [Page 4] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   In both scenarios described above, the specific channel resource of a 
   data link will be unavailable because of the data channel status 
   mismatch, and this channel resource will be wasted. Furthermore, a 
   data channel status mismatch may reduce the possibility of successful 
   LSP establishment, because a data channel status mismatch may result 
   in failure when establishing an LSP.  

   So it is desirable to confirm the data channel statuses as early as 
   possible. 

3. Extensions to LMP 

   A control plane tool is provided by simple additions to the Link 
   Management Protocol (LMP) [RFC4204]. It can assist in the location of 
   stranded resources by allowing adjacent LSRs to confirm data channel 
   statuses. 

   Outline procedures are described in this section. More detailed 
   procedures are found in Section 4. 

3.1. Confirm Data Channel Status Messages  

   Extensions to LMP to confirm a data channel status are described 
   below. In order to confirm a data channel status, the new LMP 
   messages are sent between adjacent nodes periodically or driven by 
   some events. 

   Three new messages are defined to check data channel status. 

3.1.1. ConfirmDataChannelStatus Messages (Msg Type = TBA) 

   The ConfirmDataChannelStatus message is used to tell the remote end 
   what the local end data channel status is, and to ask for the data 
   channel status at the remote end. The message may report on (and 
   request information about) more than one data channel. 

   <ConfirmDataChannelStatus Message> ::= <Common Header> 
                                          <LOCAL_LINK_ID> 
                                          <MESSAGE_ID> 
                                          <DATA_LINK>[<DATA_LINK>...] 
 
3.1.2. ConfirmDataChannelStatusAck Messages (Msg Type = TBA) 

   When a node receives the ConfirmDataChannelStatus message, and the 
   data channel status confirmation procedure is supported at the node, 

 
 
Li                     Expires December 2006                 [Page 5] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   the node gets all the data channel statuses of the remote end from 
   the ConfirmDataChannelStatus message and compares with its data 
   channel statuses. If a data channel status mismatch is found, this 
   mismatch result SHOULD be reported to the management plane for 
   further action. Management plane reporting procedures and actions are 
   outside the scope of this document. 

   The ConfirmDataChannelStatusAck message which contains the requested 
   data channel statuses is sent back to the node which originated the 
   ConfirmDataChannelStatus message. 

   If the ConfirmDataChannelStatusAck message is received, the node 
   compares the received data channel statuses at the remote end with 
   those at the local end. If a data channel status mismatch is found, 
   the mismatch result SHOULD be reported to the management plane for 
   further action. 

   <ConfirmDataChannelStatusAck Message> ::= <Common Header> 
                                             <MESSAGE_ID_ACK> 
                                             <DATA_LINK>[<DATA_LINK>...] 
    

   The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 
   ConfirmDataChannelStatus message being acknowledged. 

   Note that the ConfirmDataChannelStatus message is used both when the 
   data channel statuses match and when they do not match. 

3.1.3. ConfirmDataChannelStatusNack Messages (Msg Type = TBA) 

   When a node receives the ConfirmDataChannelStatus message, if the 
   data channel status Confirmation procedure is not supported but the 
   message is recognised, the ConfirmDataChannelStatusNack message which 
   contains the ERROR_CODE indicating "Channel Status Confirmation 
   Procedure not supported" MUST be responded. 

   If the data channel status Confirmation procedure is supported, but 
   the node is unable to begin the procedure, the ERROR_CODE MUST 
   indicate "Unwilling to Confirm".  

   If a ConfirmDataChannelStatusNack message is received with such an 
   ERROR_CODE, the node which originates the ConfirmDataChannelStatus 
   message SHOULD schedule the ConfirmDataChannelStatus message 
   retransmission after the configured time. 


 
 
Li                     Expires December 2006                 [Page 6] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   <ConfirmDataChannelStatusNack Message> ::= <Common Header> 
                                              [<LOCAL_LINK_ID>] 
                                              <MESSAGE_ID_ACK> 
                                              <ERROR_CODE> 
     
   The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 
   ConfirmDataChannelStatus message being acknowledged. 

3.2. Data Channel Status Subobject 

   A new Data Channel Status subobject type is introduced to the DATA 
   LINK object to hold the data channel status and Data Channel 
   Identification. 

   Subobject Type TBA: Data Channel Status 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Type       |    Length     |     Data Channel Status       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                      Data Channel ID                        // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Data Channel Status: 

   This is a series of bit flags to indicate the status of the data 
   channel. The following values are defined. 

   0x0001 : The channel is available/free. 
   0x0002 : The channel is allocated. 
   0x0004 : The channel is cross-connected. 
    
   Data Channel ID 

   This identifies the data channel. The length of this field can be 
   deduced from the Length field in the subobject. Note that all 
   subobjects must be padded to a four byte boundary with trailing zeros. 
   If such padding is required, the Length field MUST indicate the 
   length of the subobject up to, but not including, the first byte of 
   padding. Thus, the amount of padding is deduced and not represented 
   in the Length field. 


 
 
Li                     Expires December 2006                 [Page 7] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   Note that the Data Channel ID is given in the context of the sender 
   of the ConfirmChannelStatus message. 

4. Procedures 

   The data channel status confirmation related LMP messages are sent 
   between adjacent nodes periodically or driven by some events to 
   confirm the channel status for the data links. The procedure is 
   described below: 

   . The SENDER constructs a ConfirmDataChannelStatus message which 
      contains one or more DATA_LINK objects. Each DATA_LINK object 
      contains one or more Data Channel Status subobject. The Data 
      Channel ID field in the Data Channel Status subobject indicates 
      which data channel needs to be confirmed, and reports the data 
      channel status at the SENDER. The ConfirmDataChannelStatus message 
      is sent to the RECEIVER. 

   . The RECEIVER extracts the data channel statuses from the 
      ConfirmDataChannelStatus message, and compares these with its data 
      channel statuses for the reported data channels. If a data channel 
      status mismatch is found, the mismatch result SHOULD be reported 
      to the management plane for further action. The RECEIVER also 
      sends the ConfirmDataChannelStatusAck message which carries all 
      the local end statuses of the requested data channels to the 
      SENDER. 

   . If the RECEIVER is not able to support or to begin the 
      confirmation procedure, the ConfirmDataChannelStatusNack message 
      MUST be responded with the ERROR_CODE which indicates the reason 
      of rejection. 

   . The SENDER receives the response ConfirmDataChannelStatusAck 
      message, and compares the received data channel statuses at the 
      remote end with the data channel statuses at the local end. If a 
      data channel status mismatch is found, the mismatch result SHOULD 
      be reported to the management plane for further action. 

   . The ConfirmDataChannelStatus message SHOULD be resent, if the 
      ConfirmDataChannelStatusNack message is received or no response 
      message is received in the configured time by the SENDER. 

   The data channel status mismatch results MAY be stored, and this 
   information MAY be queried in the future.  


 
 
Li                     Expires December 2006                 [Page 8] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

5. Security Considerations 

   Security considerations for this new procedure and considerations of 
   the interactions with security measures defined in [RFC4204] are for 
   further study. 

6. IANA Considerations 

   [RFC4204] defines the LMP message type name spaces which have been 
   assigned by IANA. The document introduces three new LMP message types 
   which are TBA by IANA: 

   o ConfirmDataChannelStatus message     (Message type = TBA) 

   A value of 21 is suggested for ConfirmDataChannelStatus message type. 

   o ConfirmDataChannelStatusAck message   (Message type = TBA) 

   A value of 22 is suggested for ConfirmDataChannelStatusAck message 
   type. 

   o ConfirmDataChannelStatusNack message  (Message type = TBA) 

   A value of 23 is suggested for ConfirmDataChannelStatusNack message 
   type. 

   A new subobject type is also introduced in DATA_LINK object, the 
   subobject type is TBA by IANA: 

   o Subobject type TBA: data channel status 

   A value of 3 is suggested for data channel status subobject type. 

7. Acknowledgments 

   We would like to thank Adrian Farrel for his useful comments. 

8. References 

8.1. Normative References 

   [RFC4204]   J. Lang, Ed., "Link Management Protocol (LMP) ", RFC 4204, 
               October 2005. 



 
 
Li                     Expires December 2006                 [Page 9] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

8.2. Informative References 

   [RFC3473]  L. Berger, Ed., "Generalized Multi-Protocol Label 
               Switching (GMPLS) Signaling Resource ReserVation 
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 
               3473, January 2003 

   [RFC4203]  K. Kompella, Ed., "OSPF Extensions in Support of 
               Generalized Multi-Protocol Label Switching (GMPLS)", RFC 
               4203, October 2005 

   [RFC4205]  K. Kompella, Ed., "Intermediate System to Intermediate 
               System (IS-IS) Extensions in Support of Generalized 
               Multi-Protocol Label Switching (GMPLS)", RFC 4205, 
               October 2005 

9. Author's Addresses 

   Dan Li 
   Huawei Technologies Co., Ltd. 
   F3-5-B R&D Center, Huawei Base, 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: [phone] 
   Email: [e-mail] 
    

   Huiying Xu 
   Huawei Technologies Co., Ltd. 
   F3-5-B R&D Center, Huawei Base, 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: [phone] 
   Email: [e-mail] 
    








 
 
Li                     Expires December 2006                [Page 10] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   Fatai Zhang 
   Huawei Technologies Co., Ltd. 
   F3-5-B R&D Center, Huawei Base, 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
      
   Phone: [phone] 
   Email: [e-mail] 
    

10. Full Copyright Statement 

   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

11. Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 

 
 
Li                     Expires December 2006                [Page 11] 

Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt   June 
2006 
    

   this standard.  Please address the information to the IETF at 
   [e-mail]. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet- Drafts. 

   Internet-Drafts are draft documents valid for a maximum  of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress". 

    

































 
 
Li                     Expires December 2006                [Page 12] 


--Boundary_(ID_kvx2ZpABc5lT09D4KuXdRQ)--



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jun 2006 07:58:38 +0000
Date: Fri, 30 Jun 2006 09:56:17 +0200
From: Dan Li <[e-mail]>
Subject: New draft: draft-li-ccamp-multinodes-gr-proc-00.txt
To: "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>
Cc: Gao Jianhua <[e-mail]>
Message-id: <008601c69c1a$c058b6c0$a76d5ec2@dan>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_y+uTfdgjF0ycezUr+p0C7Q)"

This is a multi-part message in MIME format.

--Boundary_(ID_y+uTfdgjF0ycezUr+p0C7Q)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_fL47Hkayj5cKjMGGndeIWQ)"


--Boundary_(ID_fL47Hkayj5cKjMGGndeIWQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Dear,

We just posted a new I-D: draft-li-ccamp-multinodes-gr-proc-00.txt for which your comments are very welcome! The following is the abstract of this new I-D, please check out the attachment for details.

This document only clarifies the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart. We know there still have some issues which we have not awared of, so we strongly encourage you to send your comments to this mailing list.



Abstract 

   The Hello message for the Resource Reservation Protocol (RSVP) has 
   been defined to establish and maintain basic signaling node 
   adjacencies for Label Switching Routers (LSRs) participating in a 
   Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. 
   The Hello message has been extended for use in Generalized MPLS 
   (GMPLS) network for state recovery of control channel or nodal faults.    

   GMPLS protocol definitions for RSVP also allow a restarting node to 
   learn the label that it previously allocated for use on a Label 
   Switching Path (LSP). 

   Further RSVP protocol extensions have been defined to enable a 
   restarting node to recover full control plane state by exchanging 
   RSVP messages with its upstream and downstream neighbors. 

   This document clarifies the control plane procedures for a GMPLS 
   network when there are multiple node failures, and describes how full 
   control plane state can be recovered depending on the order in which 
   the nodes restart. 


Best regards,


Dan Li

--Boundary_(ID_fL47Hkayj5cKjMGGndeIWQ)
Content-type: text/html; charset=gb2312
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=gb2312">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Times New Roman">Dear,</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">We just posted a new I-D: 
draft-li-ccamp-multinodes-gr-proc-00.txt for which your comments are very 
welcome! The following is the abstract of this new I-D, please check out the 
attachment for details.</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">This document only clarifies the control plane 
procedures for a GMPLS&nbsp;network when there are multiple node failures, and 
describes how full control plane state can be recovered depending on the order 
in which&nbsp;the nodes restart. We know there still have some issues which we 
have not awared of, so we strongly encourage you to send your comments to this 
mailing list.</FONT></DIV>
<DIV><FONT face="Times New Roman"><BR></FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Abstract <BR><BR>&nbsp;&nbsp; The Hello 
message for the Resource Reservation Protocol (RSVP) has <BR>&nbsp;&nbsp; been 
defined to establish and maintain basic signaling node <BR>&nbsp;&nbsp; 
adjacencies for Label Switching Routers (LSRs) participating in a 
<BR>&nbsp;&nbsp; Multiprotocol Label Switching (MPLS) traffic engineered (TE) 
network. <BR>&nbsp;&nbsp; The Hello message has been extended for use in 
Generalized MPLS <BR>&nbsp;&nbsp; (GMPLS) network for state recovery of control 
channel or nodal faults.&nbsp;&nbsp;&nbsp;&nbsp;<BR><BR>&nbsp;&nbsp; GMPLS 
protocol definitions for RSVP also allow a restarting node to <BR>&nbsp;&nbsp; 
learn the label that it previously allocated for use on a Label <BR>&nbsp;&nbsp; 
Switching Path (LSP). <BR><BR>&nbsp;&nbsp; Further RSVP protocol extensions have 
been defined to enable a <BR>&nbsp;&nbsp; restarting node to recover full 
control plane state by exchanging <BR>&nbsp;&nbsp; RSVP messages with its 
upstream and downstream neighbors. <BR><BR>&nbsp;&nbsp; This document clarifies 
the control plane procedures for a GMPLS <BR>&nbsp;&nbsp; network when there are 
multiple node failures, and describes how full <BR>&nbsp;&nbsp; control plane 
state can be recovered depending on the order in which <BR>&nbsp;&nbsp; the 
nodes restart. </FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Best regards,</FONT><FONT 
face="Times New Roman"></DIV>
<DIV><BR></DIV></FONT>
<DIV><FONT face="Times New Roman">Dan Li<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_fL47Hkayj5cKjMGGndeIWQ)--

--Boundary_(ID_y+uTfdgjF0ycezUr+p0C7Q)
Content-type: text/plain; name=draft-li-ccamp-multinodes-gr-proc-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-li-ccamp-multinodes-gr-proc-00.txt

Network Working Group                                          Dan Li 
Internet Draft                                            Jianhua Gao 
                                                                 Huawei 
Proposed Status: Informational 
Expires: December 2006                                     June, 2006 
 
                                      
               Procedure for Multiple Node Graceful Restart 
                 draft-li-ccamp-multinodes-gr-proc-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

    

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html 

    

Abstract 

   The Hello message for the Resource Reservation Protocol (RSVP) has 
   been defined to establish and maintain basic signaling node 
   adjacencies for Label Switching Routers (LSRs) participating in a 
   Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. 
   The Hello message has been extended for use in Generalized MPLS 
   (GMPLS) network for state recovery of control channel or nodal faults. 


 
 
 
Li                     Expires December 2006                 [Page 1] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   GMPLS protocol definitions for RSVP also allow a restarting node to 
   learn the label that it previously allocated for use on a Label 
   Switching Path (LSP). 

   Further RSVP protocol extensions have been defined to enable a 
   restarting node to recover full control plane state by exchanging 
   RSVP messages with its upstream and downstream neighbors. 

   This document clarifies the control plane procedures for a GMPLS 
   network when there are multiple node failures, and describes how full 
   control plane state can be recovered depending on the order in which 
   the nodes restart. 

    

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 [RFC2119]. 

Table of Contents 

    
   1. Introduction................................................3 
   2. Existing Procedures.........................................4 
      2.1. Procedures defined in [RFC3473].........................4 
      2.2. Procedures defined in [GR-EXT]..........................4 
   3. Multiple Node Restart Scenarios..............................5 
   4. RSVP state..................................................6 
   5. Procedures..................................................7 
      5.1. Procedures for the Normal Node..........................7 
      5.2. Procedures for the Restarting Node......................7 
         5.2.1. Procedures for Scenario 1..........................7 
         5.2.2. Procedures for Scenario 2..........................8 
         5.2.3. Procedures for scenario 3.........................10 
         5.2.4. Procedures for scenario 4.........................11 
         5.2.5. Procedures for scenario 5.........................11 
      5.3. Consideration of Re-Use of Data Plane Resources.........11 
      5.4. Consideration of Management Plane Intervention..........12 
   6. Security Considerations.....................................12 
   7. IANA Considerations........................................12 
   8. Acknowledgments............................................12 
   9. References.................................................12 
      9.1. Normative References...................................12 
   10. Author's Addresses........................................13 
   11. Full Copyright Statement...................................13 
 
 
Li                     Expires December 2006                 [Page 2] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   12. Intellectual Property Statement............................14 
    
1. Introduction 

   The Hello message for the Resource Reservation Protocol (RSVP) has 
   been defined to establish and maintain basic signaling node 
   adjacencies for Label Switching Routers (LSRs) participating in a 
   Multiprotocol Label Switching (MPLS) traffic engineered (TE) network 
   [RFC3209]. The Hello message has been extended for use in Generalized 
   MPLS (GMPLS) network for state recovery of control channel or nodal 
   faults through the exchange of the Restart Capabilities object 
   [RFC3473]. 

   GMPLS protocol definitions for RSVP [RFC3473] also allow a restarting 
   node to learn the label that it previously allocated for use on a 
   Label Switching Path (LSP) through the Recovery Label object carried 
   on a Path message sent to a restarting node from its upstream 
   neighbor. 

   Further RSVP protocol extensions have been defined [GR-EXT] to 
   perform graceful restart and to enable a restarting node to recover 
   full control plane state by exchanging RSVP messages with its 
   upstream and downstream neighbors. State previously transmitted to 
   the upstream neighbor (principally the downstream label) is recovered 
   from the upstream neighbor on a Path message (using the Recovery 
   Label object as described in [RFC3473]). State previously transmitted 
   to the downstream neighbor (including the upstream label, interface 
   identifiers, and the explicit route) is recovered from the downstream 
   neighbor using a RecoveryPath message. 

   [GR-EXT] also extends the Hello message to exchange information about 
   the ability to support the RecoveryPath message. 

   The examples and procedures in [GR-EXT] focus on the description of a 
   single node restart when adjacent network nodes are operative. 
   Although the procedures are equally applicable to multi-node restarts, 
   no detailed explanation is provided. 

   This document clarifies the control plane procedures for a GMPLS 
   network when there are multiple node failures, and describes how full 
   control plane state can be recovered depending on the order in which 
   the nodes restart. 





 
 
Li                     Expires December 2006                 [Page 3] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

2. Existing Procedures 

2.1. Procedures defined in [RFC3473] 

   In the case of nodal faults, the procedures for the restarting node 
   and the procedures for the neighbor of a restarting node are applied 
   to the corresponding nodes. These procedures described in [RFC3473] 
   are summarized as follows: 

   For the Restarting Node: 

   1. Tells its neighbours that state recovery is supported using the 
      Hello message; 

   2. Recovers its RSVP state with the help of a Path message received 
      from its upstream neighbor carrying the Recovery_Label Object; 

   3. For bidirectional LSPs, the Upstream_Label Object on the received 
      Path message is used to recover the corresponding RSVP state; 

   For the Neighbor of a restarting node: 

   1. Sends the Path message with Recovery_Label Object containing a 
      label value corresponding to the label value received in the most 
      recently received corresponding Resv message;  

   2. Resumes refreshing Path state with the restarting node; 

   3. Resumes refreshing Resv state with the restarting node. 

2.2. Procedures defined in [GR-EXT] 

   A new message is introduced in [GR-EXT] which is called the 
   RecoveryPath message. The message is sent by the downstream neighbor 
   of a restarting node to convey the contents of the last received Path 
   message back to the restarting node.  

   The restarting node will receive the Path message with the Recovery 
   Label object from its upstream neighbor, and/or the RecoveryPath 
   message from its downstream neighbor. The full RSVP state of the 
   restarting node can be recovered from these two messages. 

   From the received Path message the following state can be recovered: 

   o Upstream data interface (from RSVP HOP) 

   o Label on the upstream data interface (from Recovery Label Object) 
 
 
Li                     Expires December 2006                 [Page 4] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   o Upstream label for bidirectional LSP (from Upstream Label Object) 

   From the received RecoveryPath message the following state can be 
   recovered: 

   o Downstream data interface (from RSVP HOP) 

   o Label on the downstream data interface (from Recovery Label Object) 

   o Upstream direction label for bidirectional LSP (from Upstream 
      Label Object) 

   The other objects also can be recovered either by regular Path 
   message or RecoveryPath message, and Resv message. 

3. Multiple Node Restart Scenarios 

   We define the following terms for the different node types: 

   Restarting - The node has restarted; communication with its neighbor 
   nodes is restored, its RSVP state is under recovery. 

   Delayed Restarting - The node has restarted, but the communication 
   with a neighbor node is interrupted (for example, the neighbor node 
   needs to restart). 

   Normal - The normal node is the neighbor of a restarting or delayed 
   restarting node. 

   There are five scenarios for multi-node restart. We will focus on the 
   different positions of a restarting node. As shown in Figure 1, an 
   LSP starts from Node A, traverses Nodes B and C, and stops at Node D. 

          +-----+  Path  +-----+  Path  +-----+  Path  +-----+ 
          | PSB |------->| PSB |------->| PSB |------->| PSB | 
          |     |        |     |        |     |        |     | 
          | RSB |<-------| RSB |<-------| RSB |<-------| RSB | 
          +-----+  Resv  +-----+  Resv  +-----+  Resv  +-----+ 
          Node A         Node B         Node C         Node D    
                    Figure 1 Two neighbor nodes restart 

   1. A Restarting node with downstream Delayed Restarting node. For 
      example, as shown in Figure 1, Nodes A and D are Normal nodes, 
      Node B is a Restarting node, and Node C is a Delayed Restarting 
      node.  


 
 
Li                     Expires December 2006                 [Page 5] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   2. A Restarting node with upstream Delayed Restarting node. For 
      example, as shown in Figure 1, Nodes A and D are Normal nodes, 
      Node B is a Delayed Restarting node, and Node C is a Restarting 
      node. 

   3. A Restarting node with downstream and upstream Delayed Restarting 
      nodes. For example, as shown in Figure 1, Node A is a Normal node, 
      Nodes B and D are Delayed Restarting nodes, and Node C is a 
      Restarting node. 

   4. A restarting Ingress node with downstream Delayed Restarting node. 
      For example, as shown in Figure 1, Node A is a Restarting node, 
      and Node B is a Delayed Restarting node. Nodes C and D are Normal 
      nodes. 

   5. A restarting Egress node with upstream Delayed Restarting node. 
      For example, as shown in Figure 1, Nodes A and B are Normal nodes, 
      Node C is a Delayed Restarting node, and Node D is a Restarting 
      node. 

   If the communication between two nodes is interrupted, the upstream 
   node may think the downstream node is a Delayed Restarting node, or 
   vice versa. 

4. RSVP state 

   For each scenario, the RSVP state needs to be recovered at the 
   restarting nodes are Path State Block (PSB) and Resv State Block 
   (RSB), which are created when the node receives the corresponding 
   Path message and Resv message. 

   According to [RFC2209], how to construct the PSB and RSB is really an 
   implementation issue. In fact, there is no requirement to maintain 
   separate PSB and RSB data structures. And in GMPLS, there is a much 
   closer tie between Path and Resv state so it is possible to combine 
   the information into a single state block (the LSP state block). On 
   the other hand, if P2MP is supported, it may be convenient to 
   maintain separate upstream and downstream state. Note that the PSB 
   and RSB are not upstream and downstream state since the PSB is 
   responsible for receiving a Path from upstream and sending a Path to 
   downstream. 

   Regardless of how the RSVP state is implemented, on recovery there 
   are two logical pieces of state to be recovered, and these correspond 
   to the PSB and RSB. 


 
 
Li                     Expires December 2006                 [Page 6] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

5. Procedures 

   In this document, all the nodes are assumed to have the graceful 
   restart capabilities which are described in [RFC3473] and [GR-EXT]. 

5.1. Procedures for the Normal Node 

   When the downstream Normal node detects its neighbor restarting, it 
   MUST send a RecoveryPath message for each LSP associated with the 
   restarting node for which it has previously sent a Resv message and 
   which has not been torn down. 

   When the upstream Normal node detects its neighbor restarting, it 
   MUST send a Path message with Recovery_Label Object containing a 
   label value corresponding to the label value received in the most 
   recently received corresponding Resv message. 

   This document does not modify the procedures for the Normal node 
   which are described in [RFC3473] and [GR-EXT]. 

5.2. Procedures for the Restarting Node 

5.2.1. Procedures for Scenario 1 

   After the Restarting node restarts, set a Recovery Timer. Any RSVP 
   state that cannot be resynchronized before the Recovery Timer expires 
   SHOULD be cleared.  

   At the Restarting node (Node B), full resynchronization with the 
   upstream neighbor (Node A) is possible because Node A is a Normal 
   node. The upstream Path information is recovered from  the Path 
   message received from Node A. Node B also recovers the upstream Resv 
   information from the Recovery_Label object carried in the Path 
   message received from Node A, but, obviously, some information (like 
   the Recorded Route Object) will be missing from the Resv message, and 
   can not be supplied until the downstream Delayed Restarting node 
   (Node C) restarts and sends a Resv. 

    

   As per [GR-EXT], the Restarting node (Node B) would normally expect 
   to receive a RecoveryPath message from its downstream neighbor (Node 
   C). It would use this to recover the downstream Path and Resv 
   information. But in this scenario, because the downstream neighbor  
   has not restarted yet, Node B detects the communication with Node C 
   is interrupted and must wait before resynchronizing with its 
   downstream neighbor.  
 
 
Li                     Expires December 2006                 [Page 7] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   In this case, the Restarting node (Node B) follows the procedures in 
   section 9.3 of [RFC3473] and MAY run a Restart Timer to wait for the 
   downstream neighbor (Node C) to restart. If its downstream neighbor 
   (Node C) has not restarted before the timer expires the corresponding 
   LSPs MAY be torn down according to local policy [RFC3473]. Note, 
   however, that the Restart Time value suggested in [RFC3473] is based 
   on the previous Hello message exchanged with the node that has not 
   restarted yet (Node C). Since this time value is unlikely to be 
   available to the restarting node (Node B), a configured time value 
   MUST be used if the timer is operated. 

    

   The RSVP state MUST be reconciled with the retained data plane state 
   if the cross-connect information can be retrieved from the data plane. 
   In the event of any mismatches, local policy will dictate the action 
   that must be taken which could include: 

   - reprogramming the data plane 

   - sending an alert to the management plane 

   - tearing down the control plane state for the LSP. 

   In the case that the Delayed Restarting node never comes back, and 
   where a Restart Timer is not used to automatically tear down LSPs, 
   the LSPs can be tidied up through the control plane using a PathTear 
   from the upstream node (Node A). Note that if Node C restarts after 
   this operation, the RecoveryPath message that it sends to Node B will 
   not be matched with any state on Node B and will receive a PathTear 
   as its response resulting in the teardown of the LSP at all 
   downstream nodes. 

    

5.2.2. Procedures for Scenario 2 

   In this case, the Restarting node (Node C) can recover full 
   downstream state from its downstream neighbor (Node D) which is a 
   Normal node. The downstream Path state can be recovered from the 
   RecoveryPath message which is sent by Node D. This allows Node C to 
   send a Path refresh message to Node D, and Node D will respond with a 
   Resv message from which Node C can reconstruct the downstream Resv 
   state.  

    

 
 
Li                     Expires December 2006                 [Page 8] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   The Restarting node would normally expect to resynchronize with its 
   upstream neighbor to re-learn the upstream Path and Resv state, but 
   in this scenario, because the upstream neighbour (Node B) has not 
   restarted yet, the Restarting node (Node C) detects that the 
   communication with upstream neighbor (Node B) is interrupted. The 
   Restarting node (Node C) follows the procedures in section 9.3 of 
   [RFC3473] and MAY run a Restart Timer to wait the upstream neighbor 
   (Node B) to restart. If its upstream neighbor (Node B) has not 
   restarted before the Restart Timer expires, the corresponding LSPs 
   MAY be torn down according to local policy [RFC3473]. Note, however, 
   that the Restart Time value suggested in [RFC3473] is based on the 
   previous Hello message exchanged with the node that has not restarted 
   yet (Node B). Since this time value is unlikely to be available to 
   the restarting node (Node C), a configured time value MUST be used if 
   the timer is operated. 

   Note that no Resv message is sent to the upstream neighbor (Node B) 
   because it has not restarted.  

   The RSVP state MUST reconcile with the retained data plane state if 
   the cross-connect information can be retrieved from the data plane. 

   In the event of any mismatches, local policy will dictate the action 
   that must be taken which could include: 

   - reprogramming the data plane 

   - sending an alert to the management plane 

   - tearing down the control plane state for the LSP. 

   In the case that the Delayed Restarting node never comes back, and 
   where a Restart Timer is not used to automatically tear down LSPs, 
   the LSPs cannot be tidied up through the control plane using a 
   PathTear from the upstream node (Node A) because there is no control 
   plane connectivity to Node C from the upstream direction. There are 
   two possibilities in [RFC3473]: 

   - Management action may be taken at the Restarting node to tear the 
   LSP. This will result in the LSP being removed from Node C, and a 
   PathTear being sent downstream to Node D. 

   - Management action may be taken at any downstream node (for example, 
   Node D) resulting in a PathErr message with the Path_State_Reomved 
   flag set being sent to Node C to tear the LSP state. 


 
 
Li                     Expires December 2006                 [Page 9] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

   Note that if Node B restarts after this operation, the Path message 
   that it sends to Node C will not be matched with any state on Node C 
   and will be treated as a new Path message resulting in LSP setup. 
   Node C SHOULD use the labels carried in the Path message (in the 
   Upstream_Label object and in the Recovery_Label object) to drive its 
   label allocation, but MAY use other labels according to normal LSP 
   setup rules. 

5.2.3. Procedures for scenario 3 

   In this example, the Restarting node (Node C) is isolated. It's 
   upstream and downstream neighbors have not restarted. 

   The Restarting node (Node C) follows the procedures in section 9.3 of 
   [RFC3473] and MAY run a Restart Timer for each of its neighbors 
   (Nodes B and D). If a neighbor has not restarted before its Restart 
   Timer expires, the corresponding LSPs MAY be torn down according to 
   local policy [RFC3473]. Note, however, that the Restart Time values 
   suggested in [RFC3473] are based on the previous Hello message 
   exchanged with the nodes that have not restarted yet. Since these 
   time values are unlikely to be available to the restarting node (Node 
   C), a configured time value MUST be used if the timer is operated. 

   During the Recovery Time, if the upstream Delayed Restarting node has 
   restarted, the procedure for scenario 1 can be applied. 

   During the Recovery Time, if the downstream Delayed Restarting node 
   has restarted, the procedure for scenario 2 can be applied. 

   In the case that neither Delayed Restarting node ever comes back, and 
   where a Restart Timer is not used to automatically tear down LSPs, 
   management intervention is required to tidy up the control plane and 
   the data plane on the nodes that are waiting for the failed device to 
   restart. 

   If the downstream Delayed Restarting node restarts after the cleanup 
   of LSPs at Node C, the RecoveryPath message from Node D will be 
   responded with a PathTear message. If the upstream Delayed Restarting 
   node restarts after the cleanup of LSPs at Node C, the Path message 
   from Node B will be treated as a new LSP setup request, but the setup 
   will fail because Node D cannot be reached - Node C will respond with 
   a PathErr message. Since this happens to Node B during its restart 
   processing, it SHOULD follow the rules of [GR-EXT] and tear the LSP 
   down. 



 
 
Li                     Expires December 2006                [Page 10] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

5.2.4. Procedures for scenario 4 

   When the Ingress node (Node A) restarts, it does not know which LSPs 
   it caused to be created. Usually, however, this information is 
   retrieved from the management plane or from the configuration 
   requests stored in non-volatile form in the node the in order to 
   recover the LSP state.  

   Further, if the downstream node (Node B) has is a Normal node, 
   according to [GR-EXT] that the ingress will receive a RecoveryPath 
   message and will understand that it was the ingress of the LSP. 

   However, in this scenario, the downstream node is a Delayed 
   Restarting node, so node A must rely on the information from the 
   management plane or stored configuration, or it must wait for node B 
   to restart. 

   In the event that node B never restarts, management plane 
   intervention may be used at node A to clean up any LSP state restored 
   from the management plane or from local configuration. 

5.2.5. Procedures for scenario 5 

   In this scenario the Egress node (Node D) restarts, and its upstream 
   neighbor (Node C) has not restarted. In this case, the Egress node is 
   completely unaware of the LSPs. It has no downstream neighbor to help 
   it, and no management plane or configuration information. The Egress 
   node must simply wait until its upstream neighbor restarts and gives 
   it the information as Path messages carrying Recovery_Label objects. 

5.3. Consideration of Re-Use of Data Plane Resources 

   Fundamental to the processes described above is an understanding that 
   data plane resources may remain in use (allocated and cross-connected) 
   when control plane state has not been fully resynchronized because 
   some control plane nodes have not restarted. 

   It is assumed that these data plane resources might be carrying 
   traffic and SHOULD NOT be reconfigured except through application of 
   operator-configured policy, or as a direct result of operator action. 

   In particular, new LSP setup requests from the control plane or the 
   management plane SHOULD NOT be allowed to use data plane resources 
   that are still in use. Specific action MUST first be taken to release 
   the use of resources. 


 
 
Li                     Expires December 2006                [Page 11] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

5.4. Consideration of Management Plane Intervention 

   The management plane MUST always retain the ability to control data 
   plane resources and to over-ride the control plane. In this context, 
   the management plane MUST always be able to release data plane 
   resources that were previously in place for use by control-plane 
   established LSPs. Further, the management plane MUST always be able 
   to instruct any control plane node to tear down any LSP. 

   Operators should be aware of the risks of misconnection that could be 
   caused by careless manipulation from the management plane of in-use 
   data plane resources. 

6. Security Considerations 

   This document clarifies the procedures to be performed on RSVP agents 
   that neighbor one or more restarting RSVP agents. In the case of the 
   control plane in general, and the RSVP agent in particular, where one 
   or more nodes carrying one or more LSPs are restarted due to external 
   attacks, the procedures described in this document provide the 
   ability for the restarting RSVP agents to recover the RSVP state in 
   each restarting node corresponding to the LSPs, with the least 
   possible perturbation to the rest of the network. Ideally, only the 
   neighboring RSVP agents should notice the restart and hence need to 
   perform additional processing. This allows for a network with active 
   LSPs to recover LSP state gracefully from an external attack, without 
   perturbing the data/forwarding plane state. 

7. IANA Considerations 

   This document defines no new protocols or extensions and makes no 
   requests to IANA for registry management. 

8. Acknowledgments 

   We would like to thank Adrian Farrel for his useful comments. 

9. References 

9.1. Normative References 

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
               Requirement Levels", BCP 14, RFC 2119, March 1997. 

    [RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP) 
               -- Version 1 Message Processing Rules", RFC 2209,  
               September 1997. 
 
 
Li                     Expires December 2006                [Page 12] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

    [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 
               Tunnels", RFC 3209, December 2001. 

    [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching 
               (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
               Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 

    [GR-EXT]   A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP 
               Graceful Restart", Internet Draft, work in progress, 
               draft-ietf-ccamp-rsvp-restart-ext-05.txt, October 2005 

10. Author's Addresses 

   Dan Li 
   Huawei Technologies Co., Ltd. 
   F3-5-B R&D Center, Huawei Base, 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
      
   Phone: [phone] 
   Email: [e-mail] 
    
    
   Jianhua Gao 
   Huawei Technologies Co., Ltd. 
   F3-5-B R&D Center, Huawei Base, 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
      
   Phone: [phone] 
   Email: [e-mail] 
    

11. Full Copyright Statement 

   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
 
Li                     Expires December 2006                [Page 13] 

Internet-Draft  draft-li-ccamp-multinodes-gr-proc-00.txt      June 2006 
    

12. Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   [e-mail]. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet- Drafts. 

   Internet-Drafts are draft documents valid for a maximum  of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress". 

    












 
 
Li                     Expires December 2006                [Page 14] 


--Boundary_(ID_y+uTfdgjF0ycezUr+p0C7Q)--



Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jun 2006 18:59:53 +0000
Message-ID: <[e-mail]>
Date: Thu, 29 Jun 2006 11:58:46 -0700
From: Richard Rabbat <[e-mail]>
Organization: Fujitsu Labs of America
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: [e-mail]
Subject: Update to VCAT/LCAS draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Please check out the update to the VCAT/LCAS draft and GMPLS support for 
diversely routed VCAT. This is a much more polished revision than -02 
that we plan to discuss in Montreal.

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-03.txt

Thanks,
Richard, Diego, Greg and Huub





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jun 2006 15:35:45 +0000
Message-ID: <01e001c69b91$a02a5590$9a6d5ec2@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Draft agenda for Montreal
Date: Thu, 29 Jun 2006 16:34:18 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Draft agenda has been uploaded to 
http://www3.ietf.org/proceedings/06jul/agenda/ccamp.htm

Thanks to Deborah for the leg work.

As usual, your flames are cordially invited.

Adrian and Deborah 





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jun 2006 14:51:15 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-04.txt 
Message-Id: <[e-mail]>
Date: Thu, 29 Jun 2006 10:50:01 -0400

--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		: Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-addressing-04.txt
	Pages		: 26
	Date		: 2006-6-29
	
This document explains and clarifies the use of addresses in 
Generalized Multi-Protocol Label Switching (GMPLS) networks.  The aim 
of this document is to facilitate and ensure better interworking of 
GMPLS-capable Label Switching Routers (LSRs) based on experience 
gained in deployments and interoperability testing and proper 
interpretation of published RFCs. 

The document recommends a proper approach for the interpretation and 
choice of address and identifier fields within GMPLS protocols and 
references specific control plane usage models.  It also examines 
some common GMPLS Resource Reservation Protocol-Traffic Engineering 
(RSVP-TE) signaling message processing issues and recommends 
solutions.  Finally, it discusses how to handle IPv6 sources and 
destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB 
(Management Information Base) modules.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-addressing-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-04.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jun 2006 09:30:41 +0000
Date: Thu, 29 Jun 2006 17:22:15 +0800
From: Zheng Hewen <[e-mail]>
Subject: RE: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically
To: "'S.Matsushima'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <001c01c69b5d$834a5b70$[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Thread-index: AcaZmzex2RuLvlXPQ6uWho+5IaCvhQBwidmQ

Hi,

   Is your solution inside draft-satoru-mpls-bgp-multipoint-01.txt?
   If so, it is applicable for inter-area/domain applications.

Best regards,
Hewen

-----Original Message-----
From: S.Matsushima [mailto:[e-mail]]
Sent: 2006$BG/(B6$B7n(B27$BF|(B 11:37
To: Zheng Hewen
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically

Hi,


Agreed.
I think that it is good point.
Dynamic discover and membership distribution of p2mp LSP will be needed to operate p2mp LSP in real networks.

Also, I would say that policy-based mechanism to establish p2mp LSP in per LSP basis is needed.

In BGP P2MP solution, you can see some ideas to achieve above requirements. Your interest and comment are welcome.


http://www3.ietf.org/proceedings/05nov/slides/mpls-3/sld1.htm


-03 version of this draft will appear soon.

--
Satoru Matsushima


Zheng Hewen wrote:
> Hi,
>
> The signaling solution for the construction of P2MP MPLS-TE LSPs
> defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that the
> ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by
which it can discover the identities of those receivers.
>
> In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it
> is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided
whereby the receivers can discover that information.
>
> In order to successfully operate P2MP MPLS, and to consider extending
> MPLS to support MP2MP it is necessary to examine the requirements for
> exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover and distribute
multicast membership information dynamically.
>
> Currently some work is in progress. For L3VPN applications, it is one
> choice to carry and distribute multicast membership information
> through auto-discovery mechanism based on extended BGP defined in the
> draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE
> applications, one effort is to extend IGP-TE for such purpose using
> one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport network basing
on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy those requirements
directly if possible.
>
> It is desired to clear the requirements for that mechanism. Is there
> any interest for this? I want to do something about it and hope to receive advices.
>
>
> Best Regards,
> Heaven
>
>
>
>
>
>
>







Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jun 2006 08:59:55 +0000
Message-ID: <006201c69b5a$381351f0$9a6d5ec2@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Infomral status presented to ITU
Date: Thu, 29 Jun 2006 09:54:59 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I am at the Study Group 15, Question 14 interim meeting, and I was asked to 
present the status of IETF work related to the control plane for optical 
networks.

Below is my text. Note that is was not a formal liaison, but an informal 
communication.

Thanks,
Adrian

=
Introduction

In response to several requests, this contribution provides an interim and 
unofficial status of the activities within the IETF that are pertinent to 
optical networking.

Overview

Work continues to progress within the IETF in many working groups that are 
relevant to the activities of Study Group 15. Of most direct relevance to 
Question 14/15 are the activities in the Common Control and Measurement 
Plane (CCAMP) working group, the Path Computation Element (PCE) working 
group, and the Layer One Virtual Private Network (L1VPN) working group.

CCAMP is responsible for the development and maintenance of the GMPLS family 
of protocols including signaling extensions for RSVP-TE, and routing 
extensions for OSPF and IS-IS. It also looks after LMP and LMP-WDM. CCAMP is 
also working on the frameworks and protocol extensions for multi-domain and 
multi-layer networks.

The PCE working group is developing the architecture, requirements, 
protocols, and applicability for the Path Computation Element - a functional 
element responsible for determining paths (routes) that may span multiple 
domains.
The L1VPN working group is responsible for the development of GMPLS protocol 
extensions and applicabilities in support of a service model that involves 
the supply by a service provider of layer one connectivity between customer 
sites.

Recent Activity

Control of TDM Switches

a.       Revision of RFC 3946

RFC 3946 is titled Generalized Multi-Protocol Label Switching (GMPLS) 
Extensions for Synchronous Optical Network (SONET) and Synchronous Digital 
Hierarchy (SDH) Control. This RFC was published in October 2004, is stable, 
has been implemented by multiple vendors, and is deployed with live traffic. 
Recent exchanges with the OIF exposed some issues of clarity, and a minor 
editorial revision (equivalent to an
Amendment within the ITU-T) was published as 
draft-ietf-ccamp-rfc3946-bis-01.txt in December 2005. This draft has now 
been fully reviewed by the IETF community and has been accepted for 
publication as an RFC. It is expected that it will be published within the 
next few months.

b.      Diversely routed VCAT groups

RFC 3946 provides mechanisms for establishing and maintaining LSPs in 
support of virtual concatenation where the members of a VCG are co-routed; 
that is, where all group members follow the same path through the network. 
Recently, hardware vendors have become confident in their technical 
solutions to support diversely routed VCG members and have asked for 
protocol solutions to be developed. Members of the CCAMP working group are 
currently specifying the requirements for this work including the use of 
LCAS, and it is anticipated that this will soon become official CCAMP work. 
The development of appropriate protocol solutions has already been discussed 
and will most likely follow quickly after the requirements work.

ASON Signaling

a.       Requirements

Following from the completion of RFC 4139 (Requirements for Generalized MPLS 
(GMPLS) Signaling Usage and Extensions for Automatically Switched Optical 
Network (ASON)) which was the product of successful cooperation and liaison 
between SG15 and CCAMP, CCAMP has also published RFC 4397 (A Lexicography 
for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) 
Terminology within the
Context of the ITU-T's Automatically Switched Optical Network (ASON) 
Architecture).

RFC 4397 required extensive liaisons, discussion, and face-to-face meetings 
before both the CCAMP working group and SG15 were satisfied with its 
contents. This RFC provides the tools necessary to assess the GMPLS 
signaling protocol RFCs and determine how they may be used to satisfy the 
requirements set out in RFC 4139.

b.      Toolkit

The CCAMP working group has just completed work on an important item in the 
protocol toolkit. Although not aimed directly at the ASON environment, 
draft-ietf-ccamp-gmpls-rsvp-te-call (Generalized MPLS (GMPLS) RSVP-TE 
Signaling Extensions in support of Calls) has clear applicability to ASON. 
This work has completed working group last call and will receive a few minor 
editorial changes before advancing for wider IETF review and publication as 
an RFC.

c.       Solutions

The CCAMP working group believes that all building blocks are now in place 
to use GMPLS signaling protocols to satisfy the ASON signaling requirements 
as expressed in RFC 4139. In particular, this includes the provision of 
signaling at the UNI, E-NNI, and I-NNI. CCAMP will soon start work on an 
Applicability Statement to document how the requirements are met, and it is 
anticipated that this will be liaised to Q14/15 as work in progress.

d.      Inter-working

CCAMP recognizes that an important concern for some people is how they can 
achieve inter-working of G.7713.x (x = 1, 2, or 3) or OIF UNI reference 
points on either side of a domain where the I-NNI is achieved using GMPLS 
signaling protocols. Clearly this needs to be achieved using a standardized 
approach so that I-NNI nodes will not be disrupted, and so that UNI-N 
implementations can cooperate. It is also CCAMP's intention to produce an 
Applicability Statement for this situation, and it is anticipated that this 
work will be liaised to Q14/15 as work in progress.

ASON Routing

a.       Requirements

RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching 
(GMPLS) Routing for the Automatically Switched Optical Network (ASON)) is 
the best evidence we have that the IETF, ITU-T, and OIF communities can work 
together. This document, finally published in November 2005, concentrates on 
the routing requirements placed on the GMPLS suite of protocols in order to 
support the capabilities and functionalities of an Automatically Switched 
Optical Network (ASON) as defined by the ITU-T. It was produced by a joint 
team of people from (although not representing) there three bodies, and was 
agreed only after careful liaison with Q14/15.

b.      Evaluation of Existing Routing Protocols

draft-ietf-ccamp-gmpls-ason-routing-eval was also a collaborative effort 
and, as well as experts from the OIF and SG15, the team included IETF 
routing protocol experts. The draft which has been reviewed by the IESG and 
the IETF community, and is ready for publication as an RFC, examines the 
requirements set out in RFC 4258 and compares them against the capabilities 
of the IETF routing protocols. Some small lacunae are identified as 
requiring protocol extensions.

c.       Solutions

Design of the necessary protocol extensions to complete a solution that 
meets the requirements laid out in RFC 4258 (i.e. to supply the missing 
pieces identified in draft-ietf-ccamp-gmpls-ason-routing-eval) is well 
progressed in the IETF. draft-dimitri-ccamp-gmpls-ason-routing-sol-01 
published in March proposes protocol solutions, and has just been split into 
separate work items for OSPF and IS-IS. Discussions are well advanced with 
the appropriate IGP working groups so that CCAMP will be able to adopt this 
work soon, and we have received indications that the OIF is looking to the 
completion of this work in order to determine a final E-NNI routing 
solution.

d.      PCE

The Path Computation Element (PCE) is receiving attention in Q14/15 through 
the work on G.7715.2. The PCE working group has made good advances in the 
determination of an architecture and requirements statements. These have 
completed work in the working group and have been reviewed by the IESG.
While work continues to develop a suitable communications protocol for path 
queries, the working group is also examining the applicability of PCE to 
inter-layer scenarios. Some clarification  from SG15 of whether such 
scenarios are within the scope of the ASON model may be beneficial to the 
work in the PCE working group.

Control-Plane / Management-Plane Migration

A recent liaison from SG15 to CCAMP highlighted some of the problems with 
the concept of migrating an existing LSP between the control plane and the 
management plane. This has proven to be extremely useful to CCAMP members in 
developing a concise set of requirements for this function within specific 
and limited environments. There appears to be significant support from 
carriers for this work, and it is likely to progress within the CCAMP 
working group first as a requirements statement and then with the addition 
of simple signaling protocol extensions.

Future Cooperation

The CCAMP working group co-chairs plan to send a formal liaison to SG15 to 
communicate about CCAMP progress shortly after the IETF meeting that will be 
held in Montreal at the start of July.

The CCAMP, L1VPN and PCE working groups always welcome questions and 
contributions from all sources on their mailing lists which have open access 
to everyone. More substantial contributions are welcomed in the form of 
Internet-Drafts.





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 22:50:38 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-01.txt 
Message-Id: <[e-mail]>
Date: Wed, 28 Jun 2006 18:50:02 -0400

--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		: Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
	Author(s)	: J. Le Roux, et al.
	Filename	: draft-ietf-ccamp-gmpls-mln-eval-01.txt
	Pages		: 16
	Date		: 2006-6-28
	
This document provides an evaluation of Generalized Multi-Protocol 
Label Switching (GMPLS) protocols and mechanisms against the 
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks 
(MRN). In addition, this document identifies areas where additional 
protocol extensions or procedures are needed to satisfy these 
requirements, and provides guidelines for potential extensions.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-mln-eval-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 22:11:28 +0000
Message-Id: <[e-mail]>
Date: Wed, 28 Jun 2006 18:10:03 -0400
To: George Swallow <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Yakov Rekhter <[e-mail]>,Lou Berger <[e-mail]>, Rahul Aggarwal <[e-mail]>,[e-mail],[e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

George,
         Glad to see I'm not the only one who holds this opinion!

Lou

At 03:11 PM 6/28/2006, George Swallow wrote:

> > Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
> > the tunnel, the same tuple is sufficient to identify the set of
> > destinations of the tunnel. Therefore, the Tunnel ID is not
> > needed to identify the set of destinations of the tunnel.
>
>I really don't understand this drive to change semantics that have been
>stable since we began working on this draft, and that are consistent
>with 3209 this late in the game.  I am TOTALLY opposed to it.
>
>...George
>
>====================================
>George Swallow             Cisco Systems                  [phone]
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719




Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 21:00:46 +0000
Date: Wed, 28 Jun 2006 14:00:25 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: George Swallow <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Rahul Aggarwal: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi George,

On Wed, 28 Jun 2006, George Swallow wrote:

> The text below should not be changed (at least not to what has been
> proposed!)
>
>
>  >
>  > 19.2.1
>  >
>  > " IPv4 tunnel sender address
>  >             See [RFC3209]"
>  >
>  > to"
>  >
>  > "IPv4 tunnel sender address. This address MUST be the same as the address
>  > in the Extended Tunnel ID field of the SESSION object."
>  >
>  > 8.
>  >
>  > 19.2.2
>  >
>  > "IPv6 tunnel sender address
>  >            See [RFC3209]"
>  >
>  > to
>  >
>  > "IPv6 tunnel sender address. This address MUST be the same as the address
>  > in the Extended Tunnel ID field of the SESSION object."
>
> These changes bill break bypass FRR.  When a node want to establish a
> fast reroute LSP that merges back in over a bypass tunnel, the Sender
> address is set to its own IP address (which in most cases would be some
> midpoint node).
>

Agreed.

rahul

> Further i think that we should only RECOMMEND that the Extended tunnel
> ID be used to carry the tunnel headend address.  So we couldn't say MUST
> here anyway.
>
> ...George
>
> ====================================
> George Swallow             Cisco Systems                  [phone]
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
>



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 20:57:16 +0000
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Rahul Aggarwal: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] 
From: George Swallow <[e-mail]>
Date: Wed, 28 Jun 2006 16:57:27 -0400
Message-Id: <[e-mail]>

The text below should not be changed (at least not to what has been
proposed!)


 > 
 > 19.2.1
 > 
 > " IPv4 tunnel sender address
 >             See [RFC3209]"
 > 
 > to"
 > 
 > "IPv4 tunnel sender address. This address MUST be the same as the address
 > in the Extended Tunnel ID field of the SESSION object."
 > 
 > 8.
 > 
 > 19.2.2
 > 
 > "IPv6 tunnel sender address
 >            See [RFC3209]"
 > 
 > to
 > 
 > "IPv6 tunnel sender address. This address MUST be the same as the address
 > in the Extended Tunnel ID field of the SESSION object."

These changes bill break bypass FRR.  When a node want to establish a
fast reroute LSP that merges back in over a bypass tunnel, the Sender
address is set to its own IP address (which in most cases would be some
midpoint node).

Further i think that we should only RECOMMEND that the Extended tunnel
ID be used to carry the tunnel headend address.  So we couldn't say MUST
here anyway.

...George

====================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 20:07:10 +0000
To: Yakov Rekhter <[e-mail]>
Cc: Lou Berger <[e-mail]>, Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
From: George Swallow <[e-mail]>
Date: Wed, 28 Jun 2006 16:07:09 -0400
Message-Id: <[e-mail]>

>       A combination of this address and P2MP ID
>       provides a globally unique identifier for the P2MP tunnel.

I want this to be the full tuple:

<P2MP ID, Tunnel ID, Extended Tunnel ID>

Further we should only be calling this a globally unique identifier of a
tunnel since the set of endpoint can change over the lifetime of the
tunnel.

...George



====================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 19:11:24 +0000
To: Yakov Rekhter <[e-mail]>
Cc: Lou Berger <[e-mail]>, Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
From: George Swallow <[e-mail]>
Date: Wed, 28 Jun 2006 15:11:24 -0400
Message-Id: <[e-mail]>

> Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
> the tunnel, the same tuple is sufficient to identify the set of
> destinations of the tunnel. Therefore, the Tunnel ID is not
> needed to identify the set of destinations of the tunnel.

I really don't understand this drive to change semantics that have been
stable since we began working on this draft, and that are consistent
with 3209 this late in the game.  I am TOTALLY opposed to it.

...George

====================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 13:08:57 +0000
Message-ID: <091501c69ab3$d40eefd0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Lou Berger" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Wed, 28 Jun 2006 14:07:31 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Just FWIW

   P2MP-ID (P2ID):
      A unique identifier of a P2MP TE LSP, which is constant for the
      whole LSP regardless of the number of branches and/or leaves.

Extracted from RFC4461.
We do not have to use that description in the protocol fields, but if we 
choose not to, I suggest that we change the name of the field to avoid 
confusion.

Historically, the reason for the text "The P2MP ID provides an identifier 
for the set of destinations of the P2MP TE Tunnel." is that some folk hoped 
to use something akin to a group address in this space. Thus the tunnel 
would be identified by tunnel ID, extended tunnel ID and group destination 
address. Multiple tunnels to the same destination group address would have 
different tunnel IDs (if from the same sender) and could have different 
extended tunnel IDs (if the senders made that choice).

Adrian

----- Original Message ----- 
From: "Lou Berger" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, June 28, 2006 3:01 AM
Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]


> Yakov,
>         See below.
>
> At 05:59 PM 6/27/2006, Yakov Rekhter wrote:
>
>>Lou,
>>
>>[clipped...]
>>
>> > > > > > >    The P2MP ID provides an identifier for the set of
>> > > > > > >    destinations of the P2MP TE Tunnel.
>> > > > > > >
>> > > > > > >The last sentence above has to be deleted.
>> > > > > >
>> > > > > > why, what's incorrect about it?
>> > > > >
>> > > > >To begin with, the last sentence states that the P2MP ID, *by 
>> > > > >itself*
>> > > > >"provides an identifier for the set of destinations of a given 
>> > > > >P2MP
>> > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
>> > > > >be unique, how could it unambiguously identify the set of 
>> > > > >destinations
>> > > > >of such tunnel ?
>> > > >
>> > > > You are 100% correct, how about fixing it by saying:
>> > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an
>> > > > identifier for the set of destinations of the P2MP TE Tunnel."
>> > >
>> > >Given that P2MP ID is unique within the scope of the root, why a
>> > >tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
>> > >the set of destinations of a P2MP tunnel ? After all, you agreed
>> > >further down that such a tuple identifies a P2MP tunnel.
>> >
>> > Because this would preclude the use of tunnel ID to further partition
>> > the session space (as is done today for P2P-TE.)  The tuple I
>> > mentioned included all three.
>>
>>You, yourself agreed that "A combination of this address and P2MP
>>ID provides a globally unique identifier for the P2MP tunnel."
>
> Well actually my point was: "... the uniqueness of the tuple <P2MP ID, 
> Tunnel ID, Extended Tunnel ID>. "
>
>>Since the set of destinations of a P2MP tunnel is just a part of
>>the tunnel, identifying the tunnel should be sufficient in order
>>to identify the set of destinations.
>
> right, and all three fields are needed.
>
>>Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
>>the tunnel, the same tuple is sufficient to identify the set of
>>destinations of the tunnel. Therefore, the Tunnel ID is not
>>needed to identify the set of destinations of the tunnel.
>
> we disagree.
>
>>Yakov.
>>
>>P.S. I would also caution against trying to draw too much analogy
>>with the P2P tunnels. As I explained to you in one of my previous
>>e-mails, the semantics of some of the fields carried in the Session
>>object in P2MP tunnels is quite different from the semantics of
>>their counterparts in P2P tunnels.
>
> Sure, but you've not stated any reason or need to change the semantics wrt 
> tunnel ID...
>
> Lou
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 04:29:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: RE: draft-otani-ccamp-cspf-constrains-03
Date: Wed, 28 Jun 2006 12:28:12 +0800
Message-ID: <[e-mail]>
Thread-Topic: draft-otani-ccamp-cspf-constrains-03
Thread-Index: AcaaUVPExfMJQzipSsK2RO1qWxyQogAGDJdR
From: "Hidet Sugiyama" <[e-mail]>
To: "ogaki" <[e-mail]>, <[e-mail]>

Kenichi,
 
Please update the draft.
Also I like to see OTN case in transport network.
 
Thanks,
Hidet
 

________________________________

From: [e-mail] $BBeM}(J ogaki
Sent: 2006/06/28 ($B?e(J) 10:20
To: [e-mail]
Subject: Re: draft-otani-ccamp-cspf-constrains-03



Hi Hidet,

-03 seems to omit following cases when I divided the table.
In -03, I intended to correct the bandwidth constraint from exact
match(=) to below(<=) in lambda encoding cases of table 2(-02).

Sorry,
Kenichi Ogaki

Hidet Sugiyama wrote:

>Hi,
>
>I would like to confirm how Ingress node(Router1) computes GMPLS LSC LSP on the following multi encoding scenario.
>
>A)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)--Router2
>B)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)--Router2
>C)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)---OXC1---(Lambda)---OXC2--(Ethernet)--Router2
>D)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)---OXC1---(Lambda)---OXC2--(SONET)--Router2
>*  ( ) Encoding type
>*  ROADM and OXC are provided by different vendor.
>
>I read draft-otani-ccamp-cspf-constrains-03 and -02.
>I think, draft-otani-ccamp-cspf-constrains-02 (table 2) has covered all above case.
>but, draft-otani-ccamp-cspf-constrains-03 (table 2.2) is not covered yet.
>
>Any advice is appreciated.
>
>Thanks,
>Hidet Sugiyama
>
>
> 
>





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 02:02:14 +0000
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 22:01:37 -0400
To: Yakov Rekhter <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[e-mail]>,Rahul Aggarwal <[e-mail]>, [e-mail],[e-mail],[e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,
         See below.

At 05:59 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
>[clipped...]
>
> > > > > > >    The P2MP ID provides an identifier for the set of
> > > > > > >    destinations of the P2MP TE Tunnel.
> > > > > > >
> > > > > > >The last sentence above has to be deleted.
> > > > > >
> > > > > > why, what's incorrect about it?
> > > > >
> > > > >To begin with, the last sentence states that the P2MP ID, *by itself*
> > > > >"provides an identifier for the set of destinations of a given P2MP
> > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
> > > > >be unique, how could it unambiguously identify the set of destinations
> > > > >of such tunnel ?
> > > >
> > > > You are 100% correct, how about fixing it by saying:
> > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an
> > > > identifier for the set of destinations of the P2MP TE Tunnel."
> > >
> > >Given that P2MP ID is unique within the scope of the root, why a
> > >tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
> > >the set of destinations of a P2MP tunnel ? After all, you agreed
> > >further down that such a tuple identifies a P2MP tunnel.
> >
> > Because this would preclude the use of tunnel ID to further partition
> > the session space (as is done today for P2P-TE.)  The tuple I
> > mentioned included all three.
>
>You, yourself agreed that "A combination of this address and P2MP
>ID provides a globally unique identifier for the P2MP tunnel."

Well actually my point was: "... the uniqueness of the tuple <P2MP 
ID, Tunnel ID, Extended Tunnel ID>. "

>Since the set of destinations of a P2MP tunnel is just a part of
>the tunnel, identifying the tunnel should be sufficient in order
>to identify the set of destinations.

right, and all three fields are needed.

>Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
>the tunnel, the same tuple is sufficient to identify the set of
>destinations of the tunnel. Therefore, the Tunnel ID is not
>needed to identify the set of destinations of the tunnel.

we disagree.

>Yakov.
>
>P.S. I would also caution against trying to draw too much analogy
>with the P2P tunnels. As I explained to you in one of my previous
>e-mails, the semantics of some of the fields carried in the Session
>object in P2MP tunnels is quite different from the semantics of
>their counterparts in P2P tunnels.

Sure, but you've not stated any reason or need to change the 
semantics wrt tunnel ID...

Lou 




Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jun 2006 01:21:42 +0000
Message-ID: <[e-mail]>
Date: Wed, 28 Jun 2006 10:20:19 +0900
From: ogaki <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-otani-ccamp-cspf-constrains-03
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Hidet,

-03 seems to omit following cases when I divided the table.
In -03, I intended to correct the bandwidth constraint from exact
match(=) to below(<=) in lambda encoding cases of table 2(-02).

Sorry,
Kenichi Ogaki

Hidet Sugiyama wrote:

>Hi,
> 
>I would like to confirm how Ingress node(Router1) computes GMPLS LSC LSP on the following multi encoding scenario.
> 
>A)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)--Router2
>B)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)--Router2
>C)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)---OXC1---(Lambda)---OXC2--(Ethernet)--Router2
>D)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)---OXC1---(Lambda)---OXC2--(SONET)--Router2
>*  ( ) Encoding type
>*  ROADM and OXC are provided by different vendor.
> 
>I read draft-otani-ccamp-cspf-constrains-03 and -02.
>I think, draft-otani-ccamp-cspf-constrains-02 (table 2) has covered all above case.
>but, draft-otani-ccamp-cspf-constrains-03 (table 2.2) is not covered yet.
> 
>Any advice is appreciated.
> 
>Thanks,
>Hidet Sugiyama
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 22:00:12 +0000
Message-Id: <[e-mail]>
To: Lou Berger <[e-mail]>
cc: Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 14:59:21 -0700
From: Yakov Rekhter <[e-mail]>

Lou,

[clipped...]

> > > > > >    The P2MP ID provides an identifier for the set of 
> > > > > >    destinations of the P2MP TE Tunnel.
> > > > > >
> > > > > >The last sentence above has to be deleted.
> > > > >
> > > > > why, what's incorrect about it?
> > > >
> > > >To begin with, the last sentence states that the P2MP ID, *by itself*
> > > >"provides an identifier for the set of destinations of a given P2MP
> > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
> > > >be unique, how could it unambiguously identify the set of destinations
> > > >of such tunnel ?
> > >
> > > You are 100% correct, how about fixing it by saying:
> > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an
> > > identifier for the set of destinations of the P2MP TE Tunnel."
> >
> >Given that P2MP ID is unique within the scope of the root, why a
> >tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
> >the set of destinations of a P2MP tunnel ? After all, you agreed
> >further down that such a tuple identifies a P2MP tunnel.
> 
> Because this would preclude the use of tunnel ID to further partition 
> the session space (as is done today for P2P-TE.)  The tuple I 
> mentioned included all three.

You, yourself agreed that "A combination of this address and P2MP
ID provides a globally unique identifier for the P2MP tunnel."

Since the set of destinations of a P2MP tunnel is just a part of
the tunnel, identifying the tunnel should be sufficient in order
to identify the set of destinations.

Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
the tunnel, the same tuple is sufficient to identify the set of
destinations of the tunnel. Therefore, the Tunnel ID is not
needed to identify the set of destinations of the tunnel.

Yakov.

P.S. I would also caution against trying to draw too much analogy
with the P2P tunnels. As I explained to you in one of my previous
e-mails, the semantics of some of the fields carried in the Session
object in P2MP tunnels is quite different from the semantics of
their counterparts in P2P tunnels.



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 20:52:27 +0000
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 16:51:32 -0400
To: Yakov Rekhter <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[e-mail]>,Rahul Aggarwal <[e-mail]>, [e-mail],[e-mail],[e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,

At 04:37 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
>[clipped...]
>
> > > > > > It seems to me that the -05 text covered the issue you raised.  So
> > > > > > now we come to the heart of the matter:  Why is a change in the -05
> > > > > > definition of the IDs needed?
> > > > > >
> > > > > > It seems to me that at most the text needs to replace a 
> "may" with a
> > > > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > > > > > SESSION to the ingress-PID pair MUST place their..."
> > > > >
> > > > >That is necessary, but not sufficient. Here are the changes that
> > > > >need to be made:
> > > > >
> > > > >1. Section 4.1:
> > > > >
> > > > >    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP 
> TE Tunnel is
> > > > >    identified by a P2MP SESSION object. This object contains the
> > > > >    identifier of the P2MP Session which includes the P2MP 
> ID, a tunnel
> > > > >    ID and an extended tunnel ID.
> > > > >
> > > > >    The fields of a P2MP SESSION object are identical to those of the
> > > > >    SESSION object defined in [RFC3209] except that the 
> Tunnel Endpoint
> > > > >    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> > > > >
> > > > >    The P2MP ID provides an identifier for the set of 
> destinations of the
> > > > >    P2MP TE Tunnel.
> > > > >
> > > > >The last sentence above has to be deleted.
> > > >
> > > > why, what's incorrect about it?
> > >
> > >To begin with, the last sentence states that the P2MP ID, *by itself*
> > >"provides an identifier for the set of destinations of a given P2MP
> > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
> > >be unique, how could it unambiguously identify the set of destinations
> > >of such tunnel ?
> >
> > You are 100% correct, how about fixing it by saying:
> > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an
> > identifier for the set of destinations of the P2MP TE Tunnel."
>
>Given that P2MP ID is unique within the scope of the root, why a
>tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
>the set of destinations of a P2MP tunnel ? After all, you agreed
>further down that such a tuple identifies a P2MP tunnel.

Because this would preclude the use of tunnel ID to further partition 
the session space (as is done today for P2P-TE.)  The tuple I 
mentioned included all three.


> > > > >2. Section 19.1.1 replace:
> > > > >
> > > > >  P2MP ID
> > > > >
> > > > >       A 32-bit identifier used in the SESSION object that remains
> > > > >       constant over the life of the P2MP tunnel. It encodes the
> > > > >       P2MP ID and identifies the set of destinations of the P2MP
> > > > >       Tunnel."
> > > > >
> > > > >with the following:
> > > > >
> > > > >  P2MP ID
> > > > >
> > > > >       A 32-bit identifier used in the SESSION object that remains
> > > > >       constant over the life of the P2MP tunnel. It encodes the
> > > > >       P2MP Identifier that is unique within the scope of the Ingress
> > > > >       LSR whose IP address is carried in the Extended Tunnel ID.
> > > >
> > > > Why not, just "Identifier that is unique within the scope of the
> > > > Ingress LSR."?
> > >
> > >That would be fine with me.
> >
> > great.
> >
> > >
> > > > >3. Section 19.1.1 replace
> > > > >
> > > > >   Extended Tunnel ID
> > > > >
> > > > >        A 32-bit identifier used in the SESSION object that remains
> > > > >        constant over the life of the P2MP tunnel.  Normally set to
> > > > >        all zeros. Ingress nodes that wish to narrow the scope of a
> > > > >        SESSION to the ingress-PID pair may place their IPv4 address
> > > > >        here as a globally unique identifier [RFC3209]."
> > > > >
> > > > >with the following:
> > > > >
> > > > >   Extended Tunnel ID
> > > > >
> > > > >        A 32-bit identifier used in the SESSION object that remains
> > > > >        constant over the life of the P2MP tunnel.  Ingress nodes
> > > > >        that use the locally scoped  P2MP ID MUST place their IPv4
> > > > >        address here; a combination of this address and P2MP ID
> > > > >        provides a globally unique identifier for the P2MP tunnel.
> > > >
> > > > How about:
> > > >
> > > >          A 32-bit identifier used in the SESSION object that remains
> > > >          constant over the life of the P2MP tunnel.  Ingress nodes
> > > >          that wish to a globally unique identifier for the P2MP tunnel
> > > >          MUST place their tunnel sender address here.
> > >
> > >The above will be ok if we'll add the following to spell out
> > >what constitutes this (globally unique) identifier.
> > >
> > >       A combination of this address and P2MP ID
> > >       provides a globally unique identifier for the P2MP tunnel.
> >
> > Agreed!
>
>Good, so we are in agreement that a combination of root node address
>and P2MP ID forms a (globally unique) identifier for the P2MP tunnel.
>
> > Much thanks,
> > Lou
> >
> > PS I assume there is no need to change the definition of Tunnel 
> ID, correct?
>
>Correct.

Much thanks,
Lou


>Yakov.




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 20:37:22 +0000
Message-Id: <[e-mail]>
To: Lou Berger <[e-mail]>
cc: Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 13:37:01 -0700
From: Yakov Rekhter <[e-mail]>

Lou,

[clipped...]

> > > > > It seems to me that the -05 text covered the issue you raised.  So
> > > > > now we come to the heart of the matter:  Why is a change in the -05
> > > > > definition of the IDs needed?
> > > > >
> > > > > It seems to me that at most the text needs to replace a "may" with a
> > > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > > > > SESSION to the ingress-PID pair MUST place their..."
> > > >
> > > >That is necessary, but not sufficient. Here are the changes that
> > > >need to be made:
> > > >
> > > >1. Section 4.1:
> > > >
> > > >    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
> > > >    identified by a P2MP SESSION object. This object contains the
> > > >    identifier of the P2MP Session which includes the P2MP ID, a tunnel
> > > >    ID and an extended tunnel ID.
> > > >
> > > >    The fields of a P2MP SESSION object are identical to those of the
> > > >    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
> > > >    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> > > >
> > > >    The P2MP ID provides an identifier for the set of destinations of the
> > > >    P2MP TE Tunnel.
> > > >
> > > >The last sentence above has to be deleted.
> > >
> > > why, what's incorrect about it?
> >
> >To begin with, the last sentence states that the P2MP ID, *by itself*
> >"provides an identifier for the set of destinations of a given P2MP
> >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
> >be unique, how could it unambiguously identify the set of destinations
> >of such tunnel ?
> 
> You are 100% correct, how about fixing it by saying:
> "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an 
> identifier for the set of destinations of the P2MP TE Tunnel."

Given that P2MP ID is unique within the scope of the root, why a
tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
the set of destinations of a P2MP tunnel ? After all, you agreed
further down that such a tuple identifies a P2MP tunnel.

> > > >2. Section 19.1.1 replace:
> > > >
> > > >  P2MP ID
> > > >
> > > >       A 32-bit identifier used in the SESSION object that remains
> > > >       constant over the life of the P2MP tunnel. It encodes the
> > > >       P2MP ID and identifies the set of destinations of the P2MP
> > > >       Tunnel."
> > > >
> > > >with the following:
> > > >
> > > >  P2MP ID
> > > >
> > > >       A 32-bit identifier used in the SESSION object that remains
> > > >       constant over the life of the P2MP tunnel. It encodes the
> > > >       P2MP Identifier that is unique within the scope of the Ingress
> > > >       LSR whose IP address is carried in the Extended Tunnel ID.
> > >
> > > Why not, just "Identifier that is unique within the scope of the
> > > Ingress LSR."?
> >
> >That would be fine with me.
> 
> great.
> 
> >
> > > >3. Section 19.1.1 replace
> > > >
> > > >   Extended Tunnel ID
> > > >
> > > >        A 32-bit identifier used in the SESSION object that remains
> > > >        constant over the life of the P2MP tunnel.  Normally set to
> > > >        all zeros. Ingress nodes that wish to narrow the scope of a
> > > >        SESSION to the ingress-PID pair may place their IPv4 address
> > > >        here as a globally unique identifier [RFC3209]."
> > > >
> > > >with the following:
> > > >
> > > >   Extended Tunnel ID
> > > >
> > > >        A 32-bit identifier used in the SESSION object that remains
> > > >        constant over the life of the P2MP tunnel.  Ingress nodes
> > > >        that use the locally scoped  P2MP ID MUST place their IPv4
> > > >        address here; a combination of this address and P2MP ID
> > > >        provides a globally unique identifier for the P2MP tunnel.
> > >
> > > How about:
> > >
> > >          A 32-bit identifier used in the SESSION object that remains
> > >          constant over the life of the P2MP tunnel.  Ingress nodes
> > >          that wish to a globally unique identifier for the P2MP tunnel
> > >          MUST place their tunnel sender address here.
> >
> >The above will be ok if we'll add the following to spell out
> >what constitutes this (globally unique) identifier.
> >
> >       A combination of this address and P2MP ID
> >       provides a globally unique identifier for the P2MP tunnel.
> 
> Agreed!

Good, so we are in agreement that a combination of root node address
and P2MP ID forms a (globally unique) identifier for the P2MP tunnel.

> Much thanks,
> Lou
> 
> PS I assume there is no need to change the definition of Tunnel ID, correct?

Correct.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 20:08:53 +0000
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 16:08:21 -0400
To: Yakov Rekhter <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[e-mail]>,Yakov Rekhter <[e-mail]>, Rahul Aggarwal <[e-mail]>,[e-mail],[e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,
         See below, I think we're almost there.

At 03:26 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
> > > > 2) Extended Tunnel ID
> > > > [again from rahul's mail]
> > > >
> > > >   > 5.
> > > >   >
> > > >   > "Extended Tunnel ID
> > > >   >
> > > >   >  A 32-bit identifier used in the SESSION object that remains
> > > >   >       constant over the life of the P2MP tunnel.  Normally set to
> > > >   >       all zeros. Ingress nodes that wish to narrow the scope of a
> > > >   >       SESSION to the ingress-PID pair may place their IPv4 address
> > > >   >       here as a globally unique identifier [RFC3209]."
> > > >   >
> > > >   > to
> > > >   >
> > > >   > "Extended Tunnel ID
> > > >   >
> > > >   >       A 32-bit identifier used in the SESSION object that remains
> > > >   >       constant over the life of the P2MP tunnel. This identifier
> > > >   >       MUST be set to the ingress LSR's IPv4 address."
> > > >
> > > > So the original text, allowed for global uniqueness and included a
> > > > "well-established procedures for assigning (globally) unique" P2MP IDs.
> > >
> > >Could you please point me to the text that spells out procedures
> > >for assigning P2MP IDs that are globally unique *on their own* (not
> > >in a combination with the Extended Tunnel ID).
> >
> > Ahh, good point, I was referring to the uniqueness of the tuple <P2MP
> > ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the
> > assumption that this is what you cared about for uniqueness.
>
>That is precisely what I care about.
>
> > Is this
> > not the case?  If not, why is uniqueness of the tuple insufficient?
>
>Uniqueness of the tuple is sufficient.
>
> > > > It seems to me that the -05 text covered the issue you raised.  So
> > > > now we come to the heart of the matter:  Why is a change in the -05
> > > > definition of the IDs needed?
> > > >
> > > > It seems to me that at most the text needs to replace a "may" with a
> > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > > > SESSION to the ingress-PID pair MUST place their..."
> > >
> > >That is necessary, but not sufficient. Here are the changes that
> > >need to be made:
> > >
> > >1. Section 4.1:
> > >
> > >    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
> > >    identified by a P2MP SESSION object. This object contains the
> > >    identifier of the P2MP Session which includes the P2MP ID, a tunnel
> > >    ID and an extended tunnel ID.
> > >
> > >    The fields of a P2MP SESSION object are identical to those of the
> > >    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
> > >    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> > >
> > >    The P2MP ID provides an identifier for the set of destinations of the
> > >    P2MP TE Tunnel.
> > >
> > >The last sentence above has to be deleted.
> >
> > why, what's incorrect about it?
>
>To begin with, the last sentence states that the P2MP ID, *by itself*
>"provides an identifier for the set of destinations of a given P2MP
>TE Tunnel". However, since a given P2MP ID, *by itself*, may not
>be unique, how could it unambiguously identify the set of destinations
>of such tunnel ?

You are 100% correct, how about fixing it by saying:
"The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an 
identifier for the set of destinations of the P2MP TE Tunnel."

> > >2. Section 19.1.1 replace:
> > >
> > >  P2MP ID
> > >
> > >       A 32-bit identifier used in the SESSION object that remains
> > >       constant over the life of the P2MP tunnel. It encodes the
> > >       P2MP ID and identifies the set of destinations of the P2MP
> > >       Tunnel."
> > >
> > >with the following:
> > >
> > >  P2MP ID
> > >
> > >       A 32-bit identifier used in the SESSION object that remains
> > >       constant over the life of the P2MP tunnel. It encodes the
> > >       P2MP Identifier that is unique within the scope of the Ingress LSR
> > >       whose IP address is carried in the Extended Tunnel ID.
> >
> > Why not, just "Identifier that is unique within the scope of the
> > Ingress LSR."?
>
>That would be fine with me.

great.

>
> > >3. Section 19.1.1 replace
> > >
> > >   Extended Tunnel ID
> > >
> > >        A 32-bit identifier used in the SESSION object that remains
> > >        constant over the life of the P2MP tunnel.  Normally set to
> > >        all zeros. Ingress nodes that wish to narrow the scope of a
> > >        SESSION to the ingress-PID pair may place their IPv4 address
> > >        here as a globally unique identifier [RFC3209]."
> > >
> > >with the following:
> > >
> > >   Extended Tunnel ID
> > >
> > >        A 32-bit identifier used in the SESSION object that remains
> > >        constant over the life of the P2MP tunnel.  Ingress nodes
> > >        that use the locally scoped  P2MP ID MUST place their IPv4
> > >        address here; a combination of this address and P2MP ID
> > >        provides a globally unique identifier for the P2MP tunnel.
> >
> > How about:
> >
> >          A 32-bit identifier used in the SESSION object that remains
> >          constant over the life of the P2MP tunnel.  Ingress nodes
> >          that wish to a globally unique identifier for the P2MP tunnel
> >          MUST place their tunnel sender address here.
>
>The above will be ok if we'll add the following to spell out
>what constitutes this (globally unique) identifier.
>
>       A combination of this address and P2MP ID
>       provides a globally unique identifier for the P2MP tunnel.

Agreed!

Much thanks,
Lou

PS I assume there is no need to change the definition of Tunnel ID, correct?

>Yakov.




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 19:52:24 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-01.txt 
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 15:50:02 -0400

--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		: Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-mln-reqs-01.txt
	Pages		: 21
	Date		: 2006-6-27
	
Most of the initial efforts on Generalized MPLS (GMPLS) have been 
related to environments hosting devices with a single switching 
capability. The complexity raised by the control of such data 
planes is similar to that seen in classical IP/MPLS networks. 

By extending MPLS to support multiple switching technologies, GMPLS 
provides a comprehensive framework for the control of a multi-
layered network of either a single switching technology or multiple 
switching technologies. In GMPLS, a switching technology domain 
defines a region, and a network of multiple switching types is 
referenced in this document as a multi-region network (MRN). When 
referring in general to a layered network, which may consist of 
either a single or multiple regions, this document uses the term, 
Multi-layer Network (MLN). This draft defines a framework for GMPLS 
based multi-region/multi-layer networks and lists a set of 
functional requirements.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-mln-reqs-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 19:26:56 +0000
Message-Id: <[e-mail]>
To: Lou Berger <[e-mail]>
cc: Yakov Rekhter <[e-mail]>, Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 12:26:02 -0700
From: Yakov Rekhter <[e-mail]>

Lou,

> > > 2) Extended Tunnel ID
> > > [again from rahul's mail]
> > >
> > >   > 5.
> > >   >
> > >   > "Extended Tunnel ID
> > >   >
> > >   >  A 32-bit identifier used in the SESSION object that remains
> > >   >       constant over the life of the P2MP tunnel.  Normally set to
> > >   >       all zeros. Ingress nodes that wish to narrow the scope of a
> > >   >       SESSION to the ingress-PID pair may place their IPv4 address
> > >   >       here as a globally unique identifier [RFC3209]."
> > >   >
> > >   > to
> > >   >
> > >   > "Extended Tunnel ID
> > >   >
> > >   >       A 32-bit identifier used in the SESSION object that remains
> > >   >       constant over the life of the P2MP tunnel. This identifier
> > >   >       MUST be set to the ingress LSR's IPv4 address."
> > >
> > > So the original text, allowed for global uniqueness and included a
> > > "well-established procedures for assigning (globally) unique" P2MP IDs.
> >
> >Could you please point me to the text that spells out procedures
> >for assigning P2MP IDs that are globally unique *on their own* (not
> >in a combination with the Extended Tunnel ID).
> 
> Ahh, good point, I was referring to the uniqueness of the tuple <P2MP 
> ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the 
> assumption that this is what you cared about for uniqueness.  

That is precisely what I care about. 

> Is this 
> not the case?  If not, why is uniqueness of the tuple insufficient?

Uniqueness of the tuple is sufficient.
  
> > > It seems to me that the -05 text covered the issue you raised.  So
> > > now we come to the heart of the matter:  Why is a change in the -05
> > > definition of the IDs needed?
> > >
> > > It seems to me that at most the text needs to replace a "may" with a
> > > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > > SESSION to the ingress-PID pair MUST place their..."
> >
> >That is necessary, but not sufficient. Here are the changes that
> >need to be made:
> >
> >1. Section 4.1:
> >
> >    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
> >    identified by a P2MP SESSION object. This object contains the
> >    identifier of the P2MP Session which includes the P2MP ID, a tunnel
> >    ID and an extended tunnel ID.
> >
> >    The fields of a P2MP SESSION object are identical to those of the
> >    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
> >    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> >
> >    The P2MP ID provides an identifier for the set of destinations of the
> >    P2MP TE Tunnel.
> >
> >The last sentence above has to be deleted.
> 
> why, what's incorrect about it?

To begin with, the last sentence states that the P2MP ID, *by itself*
"provides an identifier for the set of destinations of a given P2MP
TE Tunnel". However, since a given P2MP ID, *by itself*, may not
be unique, how could it unambiguously identify the set of destinations
of such tunnel ?

> >2. Section 19.1.1 replace:
> >
> >  P2MP ID
> >
> >       A 32-bit identifier used in the SESSION object that remains
> >       constant over the life of the P2MP tunnel. It encodes the
> >       P2MP ID and identifies the set of destinations of the P2MP
> >       Tunnel."
> >
> >with the following:
> >
> >  P2MP ID
> >
> >       A 32-bit identifier used in the SESSION object that remains
> >       constant over the life of the P2MP tunnel. It encodes the
> >       P2MP Identifier that is unique within the scope of the Ingress LSR
> >       whose IP address is carried in the Extended Tunnel ID.
> 
> Why not, just "Identifier that is unique within the scope of the 
> Ingress LSR."?

That would be fine with me.
  
> >3. Section 19.1.1 replace
> >
> >   Extended Tunnel ID
> >
> >        A 32-bit identifier used in the SESSION object that remains
> >        constant over the life of the P2MP tunnel.  Normally set to
> >        all zeros. Ingress nodes that wish to narrow the scope of a
> >        SESSION to the ingress-PID pair may place their IPv4 address
> >        here as a globally unique identifier [RFC3209]."
> >
> >with the following:
> >
> >   Extended Tunnel ID
> >
> >        A 32-bit identifier used in the SESSION object that remains
> >        constant over the life of the P2MP tunnel.  Ingress nodes
> >        that use the locally scoped  P2MP ID MUST place their IPv4
> >        address here; a combination of this address and P2MP ID
> >        provides a globally unique identifier for the P2MP tunnel.
> 
> How about:
>
>          A 32-bit identifier used in the SESSION object that remains
>          constant over the life of the P2MP tunnel.  Ingress nodes
>          that wish to a globally unique identifier for the P2MP tunnel
>          MUST place their tunnel sender address here.

The above will be ok if we'll add the following to spell out
what constitutes this (globally unique) identifier.

      A combination of this address and P2MP ID
      provides a globally unique identifier for the P2MP tunnel.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 18:22:46 +0000
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 14:21:40 -0400
To: Yakov Rekhter <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[e-mail]>,Yakov Rekhter <[e-mail]>, Rahul Aggarwal <[e-mail]>,[e-mail],[e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,
         See below.

At 12:28 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
> > Yakov,
> >          Thank you for the concise response to a question that has
> > been outstanding for some time.  Now there are two specific aspects
> > to the proposed response (Rahul's) to the issues you raise below:
> >
> > 1) Tunnel ID
> > [From rahul's mail]
> >   > 4.
> >   > 19.1.1
> >   >
> >   > "Tunnel ID
> >   >
> >   >       A 16-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel."
> >   >
> >   > to
> >   >
> >   > "Tunnel ID
> >   >
> >   >       A 16-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel. It SHOULD be set to 0
> >   >       by the ingress LSR and be ignored on receipt."
> >   >
> >
> > I don't see how this change, setting the ID to zero, relates to the
> > issue you raise.  Can  justify why this change is required?
>
>This is orthogonal to the issue of P2MP ID uniqueness scope.

okay, that's not how it's been presented.  What *is* the reason for 
this change?

>
> > 2) Extended Tunnel ID
> > [again from rahul's mail]
> >
> >   > 5.
> >   >
> >   > "Extended Tunnel ID
> >   >
> >   >  A 32-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel.  Normally set to
> >   >       all zeros. Ingress nodes that wish to narrow the scope of a
> >   >       SESSION to the ingress-PID pair may place their IPv4 address
> >   >       here as a globally unique identifier [RFC3209]."
> >   >
> >   > to
> >   >
> >   > "Extended Tunnel ID
> >   >
> >   >       A 32-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel. This identifier
> >   >       MUST be set to the ingress LSR's IPv4 address."
> >
> > So the original text, allowed for global uniqueness and included a
> > "well-established procedures for assigning (globally) unique" P2MP IDs.
>
>Could you please point me to the text that spells out procedures
>for assigning P2MP IDs that are globally unique *on their own* (not
>in a combination with the Extended Tunnel ID).

Ahh, good point, I was referring to the uniqueness of the tuple <P2MP 
ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the 
assumption that this is what you cared about for uniqueness.  Is this 
not the case?  If not, why is uniqueness of the tuple insufficient?

> > It seems to me that the -05 text covered the issue you raised.  So
> > now we come to the heart of the matter:  Why is a change in the -05
> > definition of the IDs needed?
> >
> > It seems to me that at most the text needs to replace a "may" with a
> > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > SESSION to the ingress-PID pair MUST place their..."
>
>That is necessary, but not sufficient. Here are the changes that
>need to be made:
>
>1. Section 4.1:
>
>    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
>    identified by a P2MP SESSION object. This object contains the
>    identifier of the P2MP Session which includes the P2MP ID, a tunnel
>    ID and an extended tunnel ID.
>
>    The fields of a P2MP SESSION object are identical to those of the
>    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>    Address field is replaced by the P2MP Identifier (P2MP ID) field.
>
>    The P2MP ID provides an identifier for the set of destinations of the
>    P2MP TE Tunnel.
>
>The last sentence above has to be deleted.

why, what's incorrect about it?

>2. Section 19.1.1 replace:
>
>  P2MP ID
>
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP ID and identifies the set of destinations of the P2MP
>       Tunnel."
>
>with the following:
>
>  P2MP ID
>
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP Identifier that is unique within the scope of the Ingress LSR
>       whose IP address is carried in the Extended Tunnel ID.

Why not, just "Identifier that is unique within the scope of the Ingress LSR."?

>3. Section 19.1.1 replace
>
>   Extended Tunnel ID
>
>        A 32-bit identifier used in the SESSION object that remains
>        constant over the life of the P2MP tunnel.  Normally set to
>        all zeros. Ingress nodes that wish to narrow the scope of a
>        SESSION to the ingress-PID pair may place their IPv4 address
>        here as a globally unique identifier [RFC3209]."
>
>with the following:
>
>   Extended Tunnel ID
>
>        A 32-bit identifier used in the SESSION object that remains
>        constant over the life of the P2MP tunnel.  Ingress nodes
>        that use the locally scoped  P2MP ID MUST place their IPv4
>        address here; a combination of this address and P2MP ID
>        provides a globally unique identifier for the P2MP tunnel.

How about:
>A 32-bit identifier used in the SESSION object that remains
>        constant over the life of the P2MP tunnel.  Ingress nodes
>        that wish to a globally unique identifier for the P2MP tunnel
>MUST place their tunnel sender address here.


>
>4. Make similar changes in 19.1.2

yes.

Lou


>Yakov.




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 16:29:06 +0000
Message-Id: <[e-mail]>
To: Lou Berger <[e-mail]>
cc: Yakov Rekhter <[e-mail]>, Rahul Aggarwal <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 09:28:19 -0700
From: Yakov Rekhter <[e-mail]>

Lou,

> Yakov,
>          Thank you for the concise response to a question that has 
> been outstanding for some time.  Now there are two specific aspects 
> to the proposed response (Rahul's) to the issues you raise below:
> 
> 1) Tunnel ID
> [From rahul's mail]
>   > 4.
>   > 19.1.1
>   >
>   > "Tunnel ID
>   >
>   >       A 16-bit identifier used in the SESSION object that remains
>   >       constant over the life of the P2MP tunnel."
>   >
>   > to
>   >
>   > "Tunnel ID
>   >
>   >       A 16-bit identifier used in the SESSION object that remains
>   >       constant over the life of the P2MP tunnel. It SHOULD be set to 0
>   >       by the ingress LSR and be ignored on receipt."
>   >
> 
> I don't see how this change, setting the ID to zero, relates to the 
> issue you raise.  Can  justify why this change is required?

This is orthogonal to the issue of P2MP ID uniqueness scope. 
  
> 2) Extended Tunnel ID
> [again from rahul's mail]
> 
>   > 5.
>   >
>   > "Extended Tunnel ID
>   >
>   >  A 32-bit identifier used in the SESSION object that remains
>   >       constant over the life of the P2MP tunnel.  Normally set to
>   >       all zeros. Ingress nodes that wish to narrow the scope of a
>   >       SESSION to the ingress-PID pair may place their IPv4 address
>   >       here as a globally unique identifier [RFC3209]."
>   >
>   > to
>   >
>   > "Extended Tunnel ID
>   >
>   >       A 32-bit identifier used in the SESSION object that remains
>   >       constant over the life of the P2MP tunnel. This identifier
>   >       MUST be set to the ingress LSR's IPv4 address."
> 
> So the original text, allowed for global uniqueness and included a 
> "well-established procedures for assigning (globally) unique" P2MP IDs.

Could you please point me to the text that spells out procedures
for assigning P2MP IDs that are globally unique *on their own* (not
in a combination with the Extended Tunnel ID).

> It seems to me that the -05 text covered the issue you raised.  So 
> now we come to the heart of the matter:  Why is a change in the -05 
> definition of the IDs needed?
> 
> It seems to me that at most the text needs to replace a "may" with a 
> "MUST", as in "Ingress nodes that wish to narrow the scope of a 
> SESSION to the ingress-PID pair MUST place their..."

That is necessary, but not sufficient. Here are the changes that
need to be made:

1. Section 4.1:

   A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
   identified by a P2MP SESSION object. This object contains the
   identifier of the P2MP Session which includes the P2MP ID, a tunnel
   ID and an extended tunnel ID.

   The fields of a P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP Identifier (P2MP ID) field.

   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel.

The last sentence above has to be deleted.

2. Section 19.1.1 replace:

 P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP ID and identifies the set of destinations of the P2MP
      Tunnel."

with the following:

 P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP Identifier that is unique within the scope of the Ingress LSR
      whose IP address is carried in the Extended Tunnel ID.

3. Section 19.1.1 replace

  Extended Tunnel ID
 
       A 32-bit identifier used in the SESSION object that remains
       constant over the life of the P2MP tunnel.  Normally set to
       all zeros. Ingress nodes that wish to narrow the scope of a
       SESSION to the ingress-PID pair may place their IPv4 address
       here as a globally unique identifier [RFC3209]."

with the following:
 
  Extended Tunnel ID
 
       A 32-bit identifier used in the SESSION object that remains
       constant over the life of the P2MP tunnel.  Ingress nodes
       that use the locally scoped  P2MP ID MUST place their IPv4
       address here; a combination of this address and P2MP ID
       provides a globally unique identifier for the P2MP tunnel.
  
4. Make similar changes in 19.1.2

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 15:03:58 +0000
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 11:03:03 -0400
To: Yakov Rekhter <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[e-mail]>,Rahul Aggarwal <[e-mail]>, Yakov Rekhter <[e-mail]>,[e-mail],[e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,
         Thank you for the concise response to a question that has 
been outstanding for some time.  Now there are two specific aspects 
to the proposed response (Rahul's) to the issues you raise below:

1) Tunnel ID
[From rahul's mail]
  > 4.
  > 19.1.1
  >
  > "Tunnel ID
  >
  >       A 16-bit identifier used in the SESSION object that remains
  >       constant over the life of the P2MP tunnel."
  >
  > to
  >
  > "Tunnel ID
  >
  >       A 16-bit identifier used in the SESSION object that remains
  >       constant over the life of the P2MP tunnel. It SHOULD be set to 0
  >       by the ingress LSR and be ignored on receipt."
  >

I don't see how this change, setting the ID to zero, relates to the 
issue you raise.  Can  justify why this change is required?

2) Extended Tunnel ID
[again from rahul's mail]

  > 5.
  >
  > "Extended Tunnel ID
  >
  >  A 32-bit identifier used in the SESSION object that remains
  >       constant over the life of the P2MP tunnel.  Normally set to
  >       all zeros. Ingress nodes that wish to narrow the scope of a
  >       SESSION to the ingress-PID pair may place their IPv4 address
  >       here as a globally unique identifier [RFC3209]."
  >
  > to
  >
  > "Extended Tunnel ID
  >
  >       A 32-bit identifier used in the SESSION object that remains
  >       constant over the life of the P2MP tunnel. This identifier
  >       MUST be set to the ingress LSR's IPv4 address."
  >

So the original text, allowed for global uniqueness and included a 
"well-established procedures for assigning (globally) unique" P2MP IDs.

It seems to me that the -05 text covered the issue you raised.  So 
now we come to the heart of the matter:  Why is a change in the -05 
definition of the IDs needed?

It seems to me that at most the text needs to replace a "may" with a 
"MUST", as in "Ingress nodes that wish to narrow the scope of a 
SESSION to the ingress-PID pair MUST place their..."

Lou

At 10:43 AM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
>[since the answer to the question you posed below may benefit
>other folks, I added mpls and ccamp mailing list to the cc:]

a bit unusual to redirect private mail, but whatever...

> > Rahul,
> >          Okay, so I'm just a bit slow.  Can you explain why the
> > semantics of P2MP-TE needs to be different than P2P-TE?
> >
> > Yakov,
> >
> > Perhaps you should answer this?
> >
> > Lou
>
>To answer your question observe that in P2P-TE the Session object
>carries IPv4 tunnel end point address, while in P2MP-TE the Session
>object carried P2MP-ID.
>
>Here are some of the reason(s) semantics of IPv4 tunnel end point
>address needs to be different than P2MP-ID:
>
>1. IPv4 tunnel end point address is a unicast address. P2MP-ID
>is not.
>
>2. IPv4 tunnel end point address is suitable for hierarchical routing
>(e.g., CIDR). P2MP-ID is not.
>
>3. There are well-established procedures for assigining (globally)
>unique unicast IP addresses. There are no such procedures for
>assigining (globally) unique P2MP IDs.
>
>Yakov.




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 14:44:57 +0000
Message-Id: <[e-mail]>
To: Lou Berger <[e-mail]>
cc: Rahul Aggarwal <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 07:43:21 -0700
From: Yakov Rekhter <[e-mail]>

Lou,

[since the answer to the question you posed below may benefit
other folks, I added mpls and ccamp mailing list to the cc:]

> Rahul,
>          Okay, so I'm just a bit slow.  Can you explain why the 
> semantics of P2MP-TE needs to be different than P2P-TE?
> 
> Yakov,
> 
> Perhaps you should answer this?
>
> Lou

To answer your question observe that in P2P-TE the Session object
carries IPv4 tunnel end point address, while in P2MP-TE the Session
object carried P2MP-ID.

Here are some of the reason(s) semantics of IPv4 tunnel end point
address needs to be different than P2MP-ID:

1. IPv4 tunnel end point address is a unicast address. P2MP-ID
is not. 

2. IPv4 tunnel end point address is suitable for hierarchical routing
(e.g., CIDR). P2MP-ID is not.

3. There are well-established procedures for assigining (globally)
unique unicast IP addresses. There are no such procedures for
assigining (globally) unique P2MP IDs.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 12:48:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: draft-otani-ccamp-cspf-constrains-03
Date: Tue, 27 Jun 2006 20:47:25 +0800
Message-ID: <[e-mail]>
Thread-Topic: draft-otani-ccamp-cspf-constrains-03
Thread-Index: AcaZ59cGo8qF8vLiRT2AH/lLhEIySg=
From: "Hidet Sugiyama" <[e-mail]>
To: <[e-mail]>

Hi,
 
I would like to confirm how Ingress node(Router1) computes GMPLS LSC LSP on the following multi encoding scenario.
 
A)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)--Router2
B)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)--Router2
C)  Router1--(Ethernet)---ROADM1---(Lambda)---ROADM2---(Ethernet)---OXC1---(Lambda)---OXC2--(Ethernet)--Router2
D)  Router1--(SONET)---ROADM1---(Lambda)---ROADM2---(SONET)---OXC1---(Lambda)---OXC2--(SONET)--Router2
*  ( ) Encoding type
*  ROADM and OXC are provided by different vendor.
 
I read draft-otani-ccamp-cspf-constrains-03 and -02.
I think, draft-otani-ccamp-cspf-constrains-02 (table 2) has covered all above case.
but, draft-otani-ccamp-cspf-constrains-03 (table 2.2) is not covered yet.
 
Any advice is appreciated.
 
Thanks,
Hidet Sugiyama



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 08:13:05 +0000
Message-ID: <04e701c699c1$4b2854b0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: IETF-66 meeting agenda confirmed
Date: Tue, 27 Jun 2006 09:10:11 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

The final agenda is at 
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_numf

Deborah and I are working on the WG agenda at the same time.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 03:56:19 +0000
Date: Tue, 27 Jun 2006 11:53:36 +0800
From: Zheng Hewen <[e-mail]>
Subject: RE: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically
To: "'S.Matsushima'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <000001c6999d$44c82380$[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Thread-index: AcaZmzex2RuLvlXPQ6uWho+5IaCvhQAARVng

Hi,

I wrote one draft about those requirements, your comments are appreciated.
 http://tools.ietf.org/wg/mpls/draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt

To Extend BGP to achieve those requirements is one good choice, especially for policy-based mechanism.
There is also another choice to extend IGP to achieve those requirements from J.L. Le Roux.
http://tools.ietf.org/wg/mpls/draft-leroux-mpls-p2mp-te-autoleaf-00.txt


-----Original Message-----
From: S.Matsushima [mailto:[e-mail]]
Sent: 2006$BG/(B6$B7n(B27$BF|(B 11:37
To: Zheng Hewen
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically

Hi,


Agreed.
I think that it is good point.
Dynamic discover and membership distribution of p2mp LSP will be needed to operate p2mp LSP in real networks.

Also, I would say that policy-based mechanism to establish p2mp LSP in per LSP basis is needed.

In BGP P2MP solution, you can see some ideas to achieve above requirements. Your interest and comment are welcome.


http://www3.ietf.org/proceedings/05nov/slides/mpls-3/sld1.htm


-03 version of this draft will appear soon.

--
Satoru Matsushima


Zheng Hewen wrote:
> Hi,
>
> The signaling solution for the construction of P2MP MPLS-TE LSPs
> defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that the
> ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by
which it can discover the identities of those receivers.
>
> In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it
> is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided
whereby the receivers can discover that information.
>
> In order to successfully operate P2MP MPLS, and to consider extending
> MPLS to support MP2MP it is necessary to examine the requirements for
> exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover and distribute
multicast membership information dynamically.
>
> Currently some work is in progress. For L3VPN applications, it is one
> choice to carry and distribute multicast membership information
> through auto-discovery mechanism based on extended BGP defined in the
> draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE
> applications, one effort is to extend IGP-TE for such purpose using
> one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport network basing
on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy those requirements
directly if possible.
>
> It is desired to clear the requirements for that mechanism. Is there
> any interest for this? I want to do something about it and hope to receive advices.
>
>
> Best Regards,
> Heaven
>
>
>
>
>
>
>







Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jun 2006 01:55:21 +0000
Message-Id: <[e-mail]>
To: "Zafar Ali \(zali\)" <[e-mail]>
cc: "Adrian Farrel" <[e-mail]>, "Loa Andersson" <[e-mail]>, [e-mail], "ccamp" <[e-mail]>, "George Swallow \(swallow\)" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 26 Jun 2006 18:53:14 -0700
From: Yakov Rekhter <[e-mail]>

Zafar,

[clipped...]

> Yakov, Adrian, et al
> 
> I think global scoping will be a bad idea. Furthermore, we cannot force
> it to come from multicast IP address space. So Ingress node scoping is
> quite obvious and IMHO suffices. 

Agreed. What I am asking is to explicitly spell this out in the document
(see the e-mail I sent today).
  
Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 26 Jun 2006 15:50:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Mon, 26 Jun 2006 11:49:51 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0Q
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Igor Bryskin
>
> Thanks Don,
> 
> See in-line.
> 
> Igor
> 
> ----- Original Message -----
> From: "Don Fedyk" <[e-mail]>
> 
<snip>
> 
> So you have two questions: Do we need Auto-discovery; and if so should
> it be IGP based or BGP based.
> In the simple mode we have specified so far MAC Learning on 
> the edge is
> all we need.  So no auto discovery.
> 
> 
> IB>> Well, MAC Learning tells edge switch which port an 
> Ethernet packet
> destined to a particular D-MAC should be sent out. However, 
> it does not tell
> the TE name of the edge switch (on the opposite side of the network)
> supporting this D-MAC. So how the ingress switch can tell (without
> auto-discovery or configuration) which of (new or existing) 
> Eth-LSPs could
> be used for the packet forwarding?
> 
> Thanks,
> Igor
> 
To be clear on this the association is made statically up front in the
current document. No new Eth-LSPs are set up due to the arrival of an
new D-MAC. There is a static binding of a Customer Port to a Ethernet
LSP. There is a static binding of the Eth-LSP to a destination switch.
At the ingress provider node and a destination provider node typically a
PW identifier or a PPB I-SID is used to mux/demux the packet on the
Eth-LSP. You could also have a dedicated Eth-LSP with no multiplexer.

Regards,
Don 

(text below is consistent with this if we do what you are alluding to in
the future)

> However if we ever get to on demand
> signaling on the connections from the customer space then an auto
> discovery function would be desirable.
> 
> As to IGP or BGP, very similar to the L1VPN case. We have discussed
> keeping the Optical code base and the Ethernet code base development
> based on the same architecture.  I don't see much difference here we
> could develop either it depends on customer demand for such a feature.
> Currently out of scope for us.
> 
> Regards,
> Don
> 
> >
> > It would be good if your draft would provide some of your
> > views on such mechanism and, more generally, on which routing
> > protocols should be supported by GMPLS controllers managing
> > Ethernet switches. Obviously, IGP-TE is going to be required
> > to enable path computation. But how about BGP?
> >
> > Thanks,
> > Igor
> >
> <snip>
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 26 Jun 2006 15:44:29 +0000
Message-ID: <042501c69937$522252f0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, <[e-mail]>
Subject: Response to your questions on 1:n protection
Date: Mon, 26 Jun 2006 16:43:30 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Dear Jim,

Thank you for your communication to CCAMP on the use of GMPLS to provide
1:n protection at the OIF UNI and the OIF E-NNI dated 20th May 2006 and
for your updates received on 2nd June 2006.

We are grateful for this opportunity to comment, but we note that this
type of communication requesting clarifications is better suited to a
mailing list discussion than to official communications that, by their
nature, have a slow turn-around. This opinion is considerably
reinforced by the process we have gone through here with a revision to
the OIF communication being generated while CCAMP is trying to draft
its response. It seems to us that if official lines of communication
are to be followed then they have to be adhered to, but if iterative
discussions are needed (as has proved to be the case here) then it would
be possible to respond far more dynamically using mailing lists.

The appropriate place for discussions of GMPLS protocols is the CCAMP
working group mailing list. Details of how to subscribe to the mailing
list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Anyway, the CCAMP chairs are keen to ensure smooth communications with
the OIF and have consulted as widely as they could in the short time in
order to update the response that we had already drafted to your
original enquiries.

We hope that our answers are satisfactory.

In the remainder of our response we have quoted extracts from your two
communications as:

>1> For a quote from the first communication dated 20th May 2006

>2> For a quote from your second communication dated 2nd June 2006

>1> Future updates to OIF UNI and E-NNI signaling may include a feature
>1> for 1:N connection protection. The attached document presents
>1> requirements for these features. Recently a review was completed
>1> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>1> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>1> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>1> It appears that the abstract messages from RFC 4426 provide much
>1> of this functionality, however several questions resulted from this
>1> review. OIF would appreciate review and comments from IETF
>1> CCAMP on the following items.
>1>
>1> 1.) OIF would appreciate knowing if there are protocol features in
>1> other IETF documents relevant to 1:N protection .

We would like to suggest that, in order to utilize advanced features of
the GMPLS control plane protocol, engineers should be familiar with the
full set of GMPLS RFCs and Internet-Drafts. These are listed on the
CCAMP charter page and can be downloaded free of charge by clicking on
the links.

Although not all of this work is directly related to protection and
restoration, it should be noted that any protocol aspect present for a
working path may also be required for a protection path. Protocol
engineers must, therefore, be familiar with the details of the protocol
before attempting to provide advanced functions like protection.

>2> 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has
>2> defined standards for any similar form of restoration, i.e., one
>2> that protects a group of LSPs at once over a local span, by
>2> shifting these LSPs from their original link within the span over
>2> to a backup link.  It should be noted that
>2> - the backup link may be a different type than the original
>2> (e.g., OC192 rather than OC48), so that GMPLS signaling rather
>2> than underlying SONET/SDH link protection is used to perform
>2> the switchover; and
>2>
>2> - it is intended that the affected LSPs be shifted using a
>2> single signaling interaction rather than separate interactions
>2> per individual LSP in order to reduce the signaling overhead
>2> required.
>2>
>2> We believe that some of the existing work, especially for segment
>2> recovery, may be helpful, but may not meet the exact requirements
>2> of the service that has been proposed within OIF. Any pointers to
>2> existing drafts or RFCs, however, would be greatly appreciated.

There are two principal ways in which the objectives you cite can be
met, and both of these techniques are, to our certain knowledge,
implemented and successfully deployed.

a) Link-level protection. This technique relies on the protection
  of the underlying link outside the scope of GMPLS. Thus, the
  TE link over which one or more LSPs are provisioned is actually
  supported by more than one underlying link. When one link fails,
  the traffic that it was carrying (the LSPs) is transferred to
  another link. This type of protection is transparent to GMPLS
  although it could leverage GMPLS fault notification procedures.

  You can learn some more about link-level protection by reading
  RFC3945 and RFC4426 (where it is referred to as Span Protection).

  Please note that the links used in this mode do not need to be
  of the same type. This is not link bundling.

b) LSP Hierarchies. This technique relies on nesting multiple LSPs
  within another LSP. Most familiar in packet technologies, this
  process is also applicable to non-packet technologies where
  appropriate adaptation is available.

  By nesting multiple LSPs within another LSP, it is possible to
  reroute them all simply by rerouting the nesting LSP. Thus any
  protection scheme that can be applied to the nesting LSP can be
  applied to the nested LSPs in a single stage. Such procedures
  are, therefore, fully available for GMPLS control.

  You can read more about LSP hierarchies in RFC4206.

You will also want to note that the Notify message [RFC3473] defines a 
single signaling message capable of providing a bulk notification procedure. 
Refer to section 12 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling for 
further descriptions, and note that this technique is also applicable in 
segment protection.

Excellent though the procedures documented in
draft-ietf-ccamp-gmpls-segment-recovery are, we are unsure as to
the "exact requirements of the service that has been proposed
within OIF" and so cannot be sure which procedures to advise for
the problem as you have described it.

>2> 2) Reviewing some of the existing RFC text, we note that RFC 4426
>2> section 2.5.2 states "it MAY be possible for the LSPs on the working
>2> link to be mapped to the protection link without re-signaling each
>2> individual LSP" and "it MAY be possible to change the component
>2> links without needing to re-signal each individual LSP".
>2> This text appears to refer to the use of SONET/SDH link protection
>2> in such a way that the labels for each LSP remain the same. Does
>2> this imply, however, that an action that changes the local
>2> labels for the affected LSPs then requires re-signaling of each
>2> individual LSP, or is there a "bulk" mechanism to change labels
>2> for a group of LSPs simultaneously?

Your question is confusing in the light of the referenced section. The
section describes the messages required to achieve span protection.
Clearly, if a span is protected, then all LSPs carried over that span
may be transparently protected. This is how normal link protection
operates and there is nothing clever going on.

Obviously (hopefully this is obvious) if you change the label in use on
a link for a particular LSP then the NEs at each end of the link need
to know that information since both the sender and the receiver need to
use the correct label. This applies for each LSP whose label you change.
The accepted mechanism in the control plane for exchanging labels is the
signaling protocol, so it follows that, if you wish to change the label
in use for an LSP on a link, you must engage signaling.

You should observe that an NE may change the label in use on a link at
any time using the RSVP-TE protocol. All that is required (assuming a
unidirectional LSP) is a trigger Resv message carrying a new label.
Considerations of the impact to user traffic are left as an exercise for
the reader.

It is unclear how the "bulk" mechanism you propose could operate unless
it was well-known that all labels are going to change in the same way.
So perhaps you are suggesting that a single signaling message might
itemise all of the LSPs and show each new label. If this is really a
significant issue (i.e., you feel it is absolutely imperative to reduce
the number of signaling messages) then you should consider RSVP message
bundling.

Otherwise, as mentioned above, the Notify message provides a bulk mechanism.

>2> 3) RFC 4426 describes the sending of the Failure Indication
>2> Message upon detection of failure by a slave device.  It is
>2> our belief that the same mechanism could also be used when
>2> the slave device is triggered to send an indication due to
>2> management system intervention (cases are mentioned in RFC
>2> 4427 but not in 4426), and we would like to know if CCAMP
>2> concurs with this.
>2> An example of where this might occur is where the master
>2> and slave devices are in different management domains.

As you correctly observe, RFC4427 section 4.13 describes exactly this
case where management plane intervention causes a Failure Indication,
and it is useful for forced or controlled switch-over.

You should note that RFC4426 section 2.5.1 says of the Failure
Indication message...
  This message is sent from the slave to the master to indicate the
  identities of one or more failed working links.  This message MAY not
  be necessary when the transport plane technology itself provides for
  such a notification.

It could also be the case that the message MAY not be necessary in the
case where the failure indication is conveyed to the master node by the
management plane. That is to say, there is no specific requirement (in
the case of management plane intervention) for the intervention to be
to the slave and causing a Failure Indication message to be sent to the
master - the management plane intervention could consist of a
notification sent to both the slave and the master from the management
plane.

The absence of this discussion within the GMPLS RFCs owes much to the
fact that they are largely control plane specifications with some notes
about the management plane for additional helpfulness.

Your final example about the use of this technique where the master and
slave are in different management domains is interesting, but the use of
a control plane means that you should consider the control plane
domains, not just the management domains.

>1> 4.) A goal of the 1:N protection is to use a bulk notification and
>1> recovery procedure, based on RFC 4427 section 4.15. However, that
>1> RFC states the corresponding recovery switching actions are
>1> performed at the LSP level. It would be useful to know if bulk
>1> processing could be applied to recovery of individual connection
>1> segments on the failed span, not entire LSPs.

>2> 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span,
>2> and suggests that the recovery switching message to recovered LSP
>2> ratio may be 1 or greater.  OIF would like to know if it is possible
>2> to define procedures such that the ratio is much less than 1, 2> i.e., a 
>message that causes bulk recovery actions on a number of
>2> LSPs.

We believe that you have missed the point of section 4.15 of RFC4427.
This section is describing the case where all or only some of the LSPs
carried on a span are protected by a single recovery message exchange
(full or partial span protection). In the case of partial span
protection it is possible that not all LSPs on the span will be
protected. Thus, the discussion of message to LSP ratios refers to the
number of recovery messages needed to protect the LSPs on a span.

The expression of the ratios is probably unclear, but the subsequent
text explains the situation.

Let us assume that there are S LSPs on the span, and s LSPs protected by
a protection message. Consider the ratio S/s.

If S/s = 1, one message has been used to protect all LSPs on the span.
(Full recovery)

If S/s > 1, more than one message is used to protect all of the LSPs on
the span OR not all LSPs on the span are protected. (Partial recovery)

Clearly a ratio of less than one would be particularly odd !

It should be obvious from wider reading of the RFCs (4436, 4427, and
3473) that the whole point of the Failure Indication is to be able to
report on more than one LSP failure at a time.

>2> 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1
>2> and 1:1 span protection and a "source" and "destination" role for
>2> control of end-to-end restoration and for reversion.  We believe
>2> that "source" and "destination" mean the initiator and receiver
>2> of the LSP (as opposed to the source and destination of data
>2> in-band).

The terms "source" and "destination" are standard.

For unidirectional LSPs, the "source" is the source of data on the LSP,
also known as he ingress. Where a control plane is used, signaling
progresses from the source (also known as the head-end).

Similarly, the "destination" is the destination of data on the LSP, also
known as the egress. Where a control plane is used, signaling progresses
from the source to the destination (also known as the tail-end).

By common convention, for bidirectional LSPs set up by the control
plane, the "source" remains the signaling source (ingress) and the
"destination" is the signaling destination (egress). Traffic flowing
in the reverse direction is referred to as reverse direction traffic
and flows from destination to source.

Very probably there is an ITU-T architectural term for these end points
of LSPs.

Note that RFC 4426 is very careful to state:
  The end-to-end recovery models discussed in this
  document apply to segment protection where the source and destination
  refer to the protected segment rather than the entire LSP.

Should this still be unclear to you, RFC4426 section 1 states
  Consider the control plane message flow during the establishment of
  an LSP.  This message flow proceeds from an initiating (or source)
  node to a terminating (or destination) node, via a sequence of
  intermediate nodes.  A node along the LSP is said to be "upstream"
  from another node if the former occurs first in the sequence.  The
  latter node is said to be "downstream" from the former node.  That
  is, an "upstream" node is closer to the initiating node than a node
  further "downstream".  Unless otherwise stated, all references to
  "upstream" and "downstream" are in terms of the control plane message
  flow.

The terms "master" and "slave" are introduced to describe the trigger
points for protection activity and are defined clearly in section 2.3
of RFC4426.
  Consider two adjacent nodes, A and B.  Under 1:1 protection, a
  dedicated link j between A and B is pre-assigned to protect working
  link i.  Link j may be carrying (pre-emptable) Extra Traffic.  A
  failure affecting link i results in the corresponding LSP(s) being
  restored to link j.  Extra Traffic being routed over link j may need
  to be pre-empted to accommodate the LSPs that have to be restored.

  Once a fault is isolated/localized, the affected LSP(s) must be moved
  to the protection link.  The process of moving an LSP from a failed
  (working) link to a protection link must be initiated by one of the
  nodes, A or B.  This node is referred to as the "master".  The other
  node is called the "slave".  The determination of the master and the
  slave may be based on configured information or protocol specific
  requirements.

Thus, the "master" is responsible for initiating the switchover, and the
slave is responsible for keeping up with the state changes.

>1> Further, it would be helpful to understand why the actions are
>1> performed by source and destination nodes rather than master and
>1> slave nodes. It may be appropriate to reuse the master/slave roles
>1> in the reversion process just as is done in the switchover process.

>2> We are not clear on the rationale for when control
>2> plane roles are based on master/slave vs. source/destination:
>2> it appears that local span actions are controlled using
>2> master/slave while remote actions are controlled using
>2> source/destination, however the reasoning for control of
>2> reversion is less clear to us.  Any clarification of the
>2> rationale for using master/slave vs. source/destination
>2> control would be appreciated.

As explained by the definitions of the terms, there is a distinction
between the node that invokes a switchover process (the master) and a
node that performs the process. For example, a Bridge and Switch Request
message is sent by the source node after it has bridged traffic back to
both working and protection links simply because the source node has
performed the bridging and is the only node that can know this fact.

In other words, whether the source is master or slave depends on the
protection scheme in use and the nature of the operation. It should be
a simple matter when considering a protection scheme and the necessary
protocol exchanges and switchover actions to determine which of the
source and destination must play the master or slave role.

>1> In addition, RFC 4426 does not include an abstract message similar
>1> to the Failure Indication Message to request the beginning of the
>1> reversion procedure. It may be beneficial to include a message from
>1> the slave device to initiate reversion, just as there is a Failure
>1> Indication Message to initiate switchover. (RFC 4426 states that the
>1> Failure Indication Message may not be needed when the transport 1> plane 
>technology itself provides such a notification. The same may
>1> apply when a failure is cleared; however, there should still be an
>1> optional message to trigger the reversion process.)

>2> 6) We believe that it may be useful in some cases of reversion to
>2> allow a "slave" device to request reversion using an abstract 2> message 
>similar to the Failure Indication Message.  An example
>2> case is (again) when the "master" and "slave" devices are in
>2> different management domains, such that reversion is initiated from
>2> the management domain of the "slave" device.  We request CCAMP 2> 
>comment on this suggestion.

Reversion is described as an administrative procedure in RFC4426 and
RFC4427 quite deliberately. In our view it should not be a rapid
response to a specific situation triggered through the control plane
by the 'master', but should be a considered operation under the control
of administrative policy. The trigger is, therefore, outside the scope
of the control plane. This discussion can be seen in section 4.13 of
RFC4427.

We believe that your suggestion does not change this view, but that you
are proposing that the control plane be used as a transport for a
management plane request. You are suggesting that a management station
in the management domain that contains the slave sends the request to
the slave, the slave would then deliver the request through the control
plane to the master. In the absence of any specific control plane
requirement for this message, we believe that the correct architectural
approach is for management plane messages to be delivered in the
management plane. Thus, if there is a need for management plane
coordination between separate management plane domains, this should be
arranged through an appropriate management plane peering point where
the correct policies can be applied.


We hope this answers your questions, and we would be happy to enter into
further dialog on these topics.

In conclusion, it may be helpful to the OIF to know the status of two
CCAMP drafts related to recovery.
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and
draft-ietf-ccamp-gmpls-segment-recovery-02 both completed CCAMP
working group last call in early 2005. Since then they have been
implemented and tested. The drafts are stable and complete, and are
queued in the IETF process waiting to become RFCs

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs 





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Jun 2006 14:36:28 +0000
Message-ID: <006c01c6992d$d816aaa0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Mon, 26 Jun 2006 10:36:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks Don,

See in-line.

Igor

----- Original Message ----- 
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Monday, June 26, 2006 9:52 AM
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi Igor

Please see inline text.
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
>
> Hi Don,
>
> I think the authors put a very good effort to clarify some of
> the issues wrt using GMPLS control plane for dynamic
> provisioning of the TE Ethernet tunnels.
>
> I have a question though. GMPLS requires 32-bit TE names
> (e.g. TE RTR IDs) as part of identifies of tunnel edges. So,
> one needs to resolve MAC addresses to TE names  to figure out
> what new tunnels must be established or existing could be
> used in order to forward Ethernet traffic between a S-MAC:
> D-MAC pair.
The short answer is we have not specified this.

Here is the long answer:
We have two name spaces Provider and Customer.

GMPLS and IP addressing allows us to specify a provider port connection
using the Control plane to resolve the Connection.  The ports also have
Provider MAC addresses. You are quite right in that this is highly
analogous to the L1VPN where we have Provider Port Indexes(PPI) and
VPN-Provider port indexes(VPN-PPI). The labels assigned to the
connection provider tunnel are associated with the PPI and we can
multiplex multiple PPIs on a particular tunnel.  (I don't think your
question is about this.)

In the customer space Equivalent to the Customer port Index(CPI) in
L1VPN, we have native Ethernet MAC addresses. We also have a provider
Mac address that is analogous to a VPN-PPI.  However this part of our
table is all MAC addresses. We have not specified the service aspects.
The options are:

-A simple point to point connection that is analogous to L1VPN Basic
mode.

-A more dynamic service that signals a MAC address and resolves it to a
Provider PBT connection or establishes a provider connection.  (I
believe this is your question. )

One difference in the Ethernet case point to point is that a provider
node can behave as an E-Wire or an (E-LAN point to point segment in out
case) so the provider is a wire but it optionally supports MAC learning
as an edge function.
I'll make a note to clarify this next iteration.

> In other words, each edge controller needs to
> maintain a table providing an association between TE names
> and MAC addresses supported by them.
> One attractive way is to
> use some auto-discovery mechanism for populating such tables.
> In fact, this problem looks to me identical to one that we
> have, for example, in L1VPNs, where there is a need to
> maintain a table associating PE TE names with the port
> information supported by them.
True that had occurred to us as well. But given there is an in band
mechanism in 802.1 (unknown broadcast and mac learning) we have a
mechanism that is inherent in the Customer LAN/VLAN.

> We have agreed that some auto-discovery mechanism is a MUST,
> and we are arguing whether it should be BGP-based or
> OSPF-based or any of them.

So you have two questions: Do we need Auto-discovery; and if so should
it be IGP based or BGP based.
In the simple mode we have specified so far MAC Learning on the edge is
all we need.  So no auto discovery.


IB>> Well, MAC Learning tells edge switch which port an Ethernet packet
destined to a particular D-MAC should be sent out. However, it does not tell
the TE name of the edge switch (on the opposite side of the network)
supporting this D-MAC. So how the ingress switch can tell (without
auto-discovery or configuration) which of (new or existing) Eth-LSPs could
be used for the packet forwarding?

Thanks,
Igor

However if we ever get to on demand
signaling on the connections from the customer space then an auto
discovery function would be desirable.

As to IGP or BGP, very similar to the L1VPN case. We have discussed
keeping the Optical code base and the Ethernet code base development
based on the same architecture.  I don't see much difference here we
could develop either it depends on customer demand for such a feature.
Currently out of scope for us.

Regards,
Don

>
> It would be good if your draft would provide some of your
> views on such mechanism and, more generally, on which routing
> protocols should be supported by GMPLS controllers managing
> Ethernet switches. Obviously, IGP-TE is going to be required
> to enable path computation. But how about BGP?
>
> Thanks,
> Igor
>
<snip>




Envelope-to: [e-mail]
Delivery-date: Mon, 26 Jun 2006 13:52:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Mon, 26 Jun 2006 09:52:06 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaX4Zpl7rgRk88wQDa6pcCkXLUNgAA7mM6Q
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Igor 

Please see inline text. 
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]] 
> 
> Hi Don,
> 
> I think the authors put a very good effort to clarify some of 
> the issues wrt using GMPLS control plane for dynamic 
> provisioning of the TE Ethernet tunnels.
> 
> I have a question though. GMPLS requires 32-bit TE names 
> (e.g. TE RTR IDs) as part of identifies of tunnel edges. So, 
> one needs to resolve MAC addresses to TE names  to figure out 
> what new tunnels must be established or existing could be 
> used in order to forward Ethernet traffic between a S-MAC:
> D-MAC pair.
The short answer is we have not specified this.

Here is the long answer: 
We have two name spaces Provider and Customer. 

GMPLS and IP addressing allows us to specify a provider port connection
using the Control plane to resolve the Connection.  The ports also have
Provider MAC addresses. You are quite right in that this is highly
analogous to the L1VPN where we have Provider Port Indexes(PPI) and
VPN-Provider port indexes(VPN-PPI). The labels assigned to the
connection provider tunnel are associated with the PPI and we can
multiplex multiple PPIs on a particular tunnel.  (I don't think your
question is about this.) 

In the customer space Equivalent to the Customer port Index(CPI) in
L1VPN, we have native Ethernet MAC addresses. We also have a provider
Mac address that is analogous to a VPN-PPI.  However this part of our
table is all MAC addresses. We have not specified the service aspects.
The options are:

-A simple point to point connection that is analogous to L1VPN Basic
mode. 

-A more dynamic service that signals a MAC address and resolves it to a
Provider PBT connection or establishes a provider connection.  (I
believe this is your question. ) 

One difference in the Ethernet case point to point is that a provider
node can behave as an E-Wire or an (E-LAN point to point segment in out
case) so the provider is a wire but it optionally supports MAC learning
as an edge function. 
I'll make a note to clarify this next iteration.

> In other words, each edge controller needs to 
> maintain a table providing an association between TE names 
> and MAC addresses supported by them. 
> One attractive way is to 
> use some auto-discovery mechanism for populating such tables. 
> In fact, this problem looks to me identical to one that we 
> have, for example, in L1VPNs, where there is a need to 
> maintain a table associating PE TE names with the port 
> information supported by them.
True that had occurred to us as well. But given there is an in band
mechanism in 802.1 (unknown broadcast and mac learning) we have a
mechanism that is inherent in the Customer LAN/VLAN. 

> We have agreed that some auto-discovery mechanism is a MUST, 
> and we are arguing whether it should be BGP-based or 
> OSPF-based or any of them.

So you have two questions: Do we need Auto-discovery; and if so should
it be IGP based or BGP based. 
In the simple mode we have specified so far MAC Learning on the edge is
all we need.  So no auto discovery. However if we ever get to on demand
signaling on the connections from the customer space then an auto
discovery function would be desirable. 

As to IGP or BGP, very similar to the L1VPN case. We have discussed
keeping the Optical code base and the Ethernet code base development
based on the same architecture.  I don't see much difference here we
could develop either it depends on customer demand for such a feature.
Currently out of scope for us. 

Regards,
Don 

> 
> It would be good if your draft would provide some of your 
> views on such mechanism and, more generally, on which routing 
> protocols should be supported by GMPLS controllers managing 
> Ethernet switches. Obviously, IGP-TE is going to be required 
> to enable path computation. But how about BGP?
> 
> Thanks,
> Igor
> 
<snip>



Envelope-to: [e-mail]
Delivery-date: Mon, 26 Jun 2006 13:51:19 +0000
Message-Id: <[e-mail]>
To: [e-mail]
cc: Lou Berger <[e-mail]>, ccamp <[e-mail]>, [e-mail], [e-mail], Rahul Aggarwal <[e-mail]>, [e-mail]
Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 26 Jun 2006 06:49:34 -0700
From: Yakov Rekhter <[e-mail]>

Dimitri,

[clipped...]

> > now there is a more fundamental issue: what is the purpose of the initial
> > comment, i think it is first to clarify  processing of Tunnel ID and
> > Extended Tunnel ID but i don't think i have seen any specific issue in
> > keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473

The purpose of the initial comment is to clarify the definition
of P2MP ID.

The current spec said the following (Section 19.1.1):

 P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP ID and identifies the set of destinations of the P2MP
      Tunnel.

What is the uniqueness scope of this 32 bit identifier ? Is it the
root node scope, or a global scope ?

At the minimum the spec should spell out support for the root node 
uniqueness scope.

If some folks want the spec to support global scope, then it has
to be an option (in which case the root node scope will be another
option), *and* the spec has to spell out the procedures for assigining
such globally unique P2MP IDs (in the absence of such procedures
the spec should just have the root node uniqueness scope).

Yakov.



Envelope-to: [e-mail]
Delivery-date: Sat, 24 Jun 2006 22:59:26 +0000
Message-ID: <014e01c697e1$8eb68580$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Sat, 24 Jun 2006 18:56:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Don,

I think the authors put a very good effort to clarify some of the issues wrt
using GMPLS control plane for dynamic provisioning of the TE Ethernet
tunnels.

I have a question though. GMPLS requires 32-bit TE names (e.g. TE RTR IDs)
as part of identifies of tunnel edges. So, one needs to resolve MAC
addresses to TE names  to figure out what new tunnels must be established or
existing could be used in order to forward Ethernet traffic between a S-MAC:
D-MAC pair. In other words, each edge controller needs to maintain a table
providing an association between TE names and MAC addresses supported by
them. One attractive way is to use some auto-discovery mechanism for
populating such tables. In fact, this problem looks to me identical to one
that we have, for example, in L1VPNs, where there is a need to maintain a
table associating PE TE names with the port information supported by them.
We have agreed that some auto-discovery mechanism is a MUST, and we are
arguing whether it should be BGP-based or OSPF-based or any of them.

It would be good if your draft would provide some of your views on such
mechanism and, more generally, on which routing protocols should be
supported by GMPLS controllers managing Ethernet switches. Obviously, IGP-TE
is going to be required to enable path computation. But how about BGP?

Thanks,
Igor

----- Original Message ----- 
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Friday, June 23, 2006 8:02 AM
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi

We've posted a new version of our draft on GMPLS control of Ethernet,
http://www.ietf.org/internet-drafts/draft-fedyk-gmpls-ethernet-pbt-00.tx
t

We believe this draft to be of interest to the CCAMP community in
addition to those that follow GELS, hence this posting.
The draft has a fairly detailed explanation of the data plane aspects to
be clear on what aspects of Ethernet we were proposing to apply GMPLS
to. This will be removed as we move closer to a true control plane
specification.

So please have a look at the draft and send us comments. We will be
happy to clarify any data plane aspects but would prefer
critique/commentary be constrained to the control plane aspects in line
with the IETF scope.

Thanks,
Don & co.




Envelope-to: [e-mail]
Delivery-date: Fri, 23 Jun 2006 12:03:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Fri, 23 Jun 2006 08:02:31 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaWvOd9y81ywYHDSAe5yz9VcgGN2w=
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Hi

We've posted a new version of our draft on GMPLS control of Ethernet,
http://www.ietf.org/internet-drafts/draft-fedyk-gmpls-ethernet-pbt-00.tx
t

We believe this draft to be of interest to the CCAMP community in
addition to those that follow GELS, hence this posting. 
The draft has a fairly detailed explanation of the data plane aspects to
be clear on what aspects of Ethernet we were proposing to apply GMPLS
to. This will be removed as we move closer to a true control plane
specification.

So please have a look at the draft and send us comments. We will be
happy to clarify any data plane aspects but would prefer
critique/commentary be constrained to the control plane aspects in line
with the IETF scope. 

Thanks,
Don & co. 



Envelope-to: [e-mail]
Delivery-date: Fri, 23 Jun 2006 11:44:51 +0000
To: Lou Berger <[e-mail]>
Cc: ccamp <[e-mail]>, [e-mail], [e-mail], Rahul Aggarwal <[e-mail]>, [e-mail]
Subject: Re: [mpls] Identifier Semantics [Re: working group last call	on draft-ietf-mpls-rsvp-te-p2mp-05.txt]
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 23 Jun 2006 13:43:47 +0200
Content-Type: text/plain; charset="US-ASCII"

lou, all, see in-line




Lou Berger <[e-mail]>
22/06/2006 21:10
 
        To:     Rahul Aggarwal <[e-mail]>
        cc:     [e-mail], [e-mail], 
[e-mail], ccamp <[e-mail]>
        Subject:        Re: [mpls] Identifier Semantics [Re: working group 
last call       on draft-ietf-mpls-rsvp-te-p2mp-05.txt]


> All,
>
> Here's one (but not the only) comment that was made off list.  Also 
> there were already several comments made on these points on the list.
>
> My comment still applies, and please consider this as an "objection" 
> to the proposed text:
> 
> At 01:20 PM 6/22/2006, Lou Berger wrote:
>>[...]
>>At 05:23 PM 6/20/2006, Rahul Aggarwal wrote:
>>>Hi All,
>>>
>>>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates 
changes
>>>to address Last call comments.
>>>
>>>Please let me know if you have any comments on *only the changes made 
to
>>>address LC comments* i.e. diff of v05 and v06 by this Friday.
>>>
>>>A brief summary of changes:
>>>
>>>1. Editorial changes requested by Benjamin Niven - see MPLS mailing 
list.
>>>2. Several editorial and non editorial changes requestd by Adrian 
Farrel -
>>>see MPLS mailing list for Adrian's comments and my response. There may 
be
>>>one or two open items here. Once Adrian looks at my response these 
should
>>>be resolved quickly.
>>>3. Several editorial and non-editorial changes requestd by JL - see 
MPLS
>>>mailing list for JL's comments and my response.
>>>4. Clarification of tunnel ID and extended Tunnel ID semantics as
>>>requested by Yakov Rekhter and follow on comments by Zafar Ali and 
George
>>>Swallow.
>
>The objection:
>
>>I don't have any issues with the changes mentioned by Zafer and 
>>George, but I didn't see closure on the issue debated by Adrian and 
>>Yakov.  Specifically on the issue of if extended tunnel ID had to 
>>equal the node ID of the sender.  I did see a position state, that I 
>>too agree with, i.e., that  it should be permitted and may be 
>>required in some environments (e.g., FRR) but may not be required in 
>>all environments so should be left as before.  Also, as I read the 
>>mails most were in favor of leaving tunnel ID as is, i.e., not 
>>requiring it to be set to zero.  This doesn't match what was done in 
>>this past rev.
>
>In summary, my position is:
>1) That the extended tunnel ID remain as defined in the previous 
>version, i.e., retain the semantics from rfc3209/rfc3473.  I think 
>adding a restriction for environments where FRR is used is 
>acceptable.  (This spec covers GMPLS and non-packet environments too!)
>2) That Tunnel ID remain as defined in previous version, i.e., retain 
>the semantics from rfc3209/rfc3473.
>
>The specifics of the text below is dependent on consensus on these 
points.

[dp] if there is no Tunnel ID (or a single fixed value for the Tunnel ID), 
there is no possibility to instantiate multiple trunks per destination 
(set of destinations)

now there is a more fundamental issue: what is the purpose of the initial 
comment, i think it is first to clarify  processing of Tunnel ID and 
Extended Tunnel ID but i don't think i have seen any specific issue in 
keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473

i am deeply concerned about having moving definition departing from base 
RSVP-TE on objects that are fundamental for the stability of the protocol

thanks,
- dimitri.

 

 
 






Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jun 2006 19:51:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] Identifier Semantics [Re: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt]
Date: Thu, 22 Jun 2006 20:40:28 +0200
Message-ID: <[e-mail]>
Thread-Topic: [mpls] Identifier Semantics [Re: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt]
Thread-Index: AcaWKFFhqonqB7HmTHulU4cFRIjdSgAANfKg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>, "ccamp" <[e-mail]>, <[e-mail]>

Hi Rahul,

One minor point,


> 
> "IPv4 tunnel sender address. This address MUST be the same as 
> the address in the Extended Tunnel ID field of the SESSION
>object."

This is not inlined with the FRR sender-template specific method.
You should remove the second sentence.

Regards,

JL




> -----Message d'origine-----
> De : Rahul Aggarwal [mailto:[e-mail]] 
> Envoyé : jeudi 22 juin 2006 20:18
> À : [e-mail]; Yakov Rekhter
> Cc : [e-mail]; ccamp; [e-mail]
> Objet : [mpls] Identifier Semantics [Re: working group last 
> call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt]
> 
> 
> Hi Folks,
> 
> Yakov brought up the issue of P2MP ID, Tunnel ID, Extended 
> Tunnel ID semantics as part of the last call and a discussion 
> followed on this list.
> 
> In order to resolve this discussion I had proposed some text. 
> I have received some comments on this offline and want to 
> move this discussion to a broader audience.
> 
> Please comment on the text changes below, if you have 
> objections or suggestions. Else this will be incorporated in 
> the next version of the spec.
> 
> How about the following rephrasing:
> 
> 1.
> 
> Section 4.1:
> 
> " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE 
> Tunnel is
>    identified by a P2MP SESSION object. This object contains the
>    identifier of the P2MP Session which includes the P2MP ID, a tunnel
>    ID and an extended tunnel ID.
> 
>    The fields of a P2MP SESSION object are identical to those of the
>    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> 
>    The P2MP ID provides an identifier for the set of 
> destinations of the
>    P2MP TE Tunnel."
> 
> to
> 
> " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE 
> Tunnel is identified by a P2MP SESSION object. This object 
> contains the identifier of the P2MP Session which includes a 
> tuple <Ingress LSR IP address, P2MP Identifier>, where the 
> P2MP Identifier (P2MP
> ID) is unique within the scope of the IP address of the 
> ingress LSR. The Ingress LSR IP address is encoded in the 
> Extended Tunnel ID. Th P2MP Tunnel identifier, carried in the 
> P2MP SESSION object, is unique within the same scope as the 
> ingress LSR IP address.
> 
> The fields of the P2MP SESSION object are identical to those 
> of the SESSION object defined in [RFC3209] except that the 
> Tunnel Endpoint Address field is replaced by the P2MP ID field."
> 
> 2.
> 
> Section 4.2.
> 
> "   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
>    ID, and Extended Tunnel ID that are part of the P2MP 
> SESSION object,
>    and the tunnel sender address and LSP ID fields of the P2MP
>    SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
>    defined in section 20.2."
> 
> to
> 
> "   A P2MP LSP is identified by the combination of the P2MP ID,
> Extended Tunnel ID that are part of the P2MP SESSION object, 
> and the tunnel sender address and LSP ID fields of the P2MP 
> SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object 
> is defined in section 20.2."
> 
> 3.
> 
> 19.1.1
> 
> "P2MP ID
> 
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP ID and identifies the set of destinations of the P2MP
>       Tunnel."
> 
> to
> 
> "P2MP ID
> 
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP Identifier that is unique within the scope of the 
> Ingress LSR
>       IP address carried in the Extended Tunnel ID.
> 
> 4.
> 19.1.1
> 
> "Tunnel ID
> 
>       A 16-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel."
> 
> to
> 
> "Tunnel ID
> 
>       A 16-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It SHOULD be set to 0
>       by the ingress LSR and be ignored on receipt."
> 
> 
> 5.
> 
> "Extended Tunnel ID
> 
>  A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel.  Normally set to
>       all zeros. Ingress nodes that wish to narrow the scope of a
>       SESSION to the ingress-PID pair may place their IPv4 address
>       here as a globally unique identifier [RFC3209]."
> 
> to
> 
> "Extended Tunnel ID
> 
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. This identifier
>       MUST be set to the ingress LSR's IPv4 address."
> 
> 6.
> 
> 19.1.2
> 
> "This is same as the P2MP IPv4 LSP SESSION Object with the difference
>    that the extended tunnel ID may be set to a 16 byte identifier
>    [RFC3209]."
> 
> to
> 
> "This is same as the P2MP IPv4 LSP SESSION Object with the difference
>    that the extended tunnel ID MUST be set to a 16 byte 
> identifier that is the ingress LSR's IPv6 address."
> 
> 7.
> 
> 19.2.1
> 
> " IPv4 tunnel sender address
>             See [RFC3209]"
> 
> to"
> 
> "IPv4 tunnel sender address. This address MUST be the same as 
> the address in the Extended Tunnel ID field of the SESSION object."
> 
> 8.
> 
> 19.2.2
> 
> "IPv6 tunnel sender address
>            See [RFC3209]"
> 
> to
> 
> "IPv6 tunnel sender address. This address MUST be the same as 
> the address in the Extended Tunnel ID field of the SESSION object."
> 
> Thanks,
> rahul
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jun 2006 19:10:51 +0000
Message-Id: <[e-mail]>
Date: Thu, 22 Jun 2006 15:10:18 -0400
To: Rahul Aggarwal <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt]
Cc: [e-mail],Yakov Rekhter <[e-mail]>,[e-mail], ccamp <[e-mail]>,[e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

All,

Here's one (but not the only) comment that was made off list.  Also 
there were already several comments made on these points on the list.

My comment still applies, and please consider this as an "objection" 
to the proposed text:

At 01:20 PM 6/22/2006, Lou Berger wrote:
>[...]
>At 05:23 PM 6/20/2006, Rahul Aggarwal wrote:
>>Hi All,
>>
>>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates changes
>>to address Last call comments.
>>
>>Please let me know if you have any comments on *only the changes made to
>>address LC comments* i.e. diff of v05 and v06 by this Friday.
>>
>>A brief summary of changes:
>>
>>1. Editorial changes requested by Benjamin Niven - see MPLS mailing list.
>>2. Several editorial and non editorial changes requestd by Adrian Farrel -
>>see MPLS mailing list for Adrian's comments and my response. There may be
>>one or two open items here. Once Adrian looks at my response these should
>>be resolved quickly.
>>3. Several editorial and non-editorial changes requestd by JL - see MPLS
>>mailing list for JL's comments and my response.
>>4. Clarification of tunnel ID and extended Tunnel ID semantics as
>>requested by Yakov Rekhter and follow on comments by Zafar Ali and George
>>Swallow.
>

The objection:

>I don't have any issues with the changes mentioned by Zafer and 
>George, but I didn't see closure on the issue debated by Adrian and 
>Yakov.  Specifically on the issue of if extended tunnel ID had to 
>equal the node ID of the sender.  I did see a position state, that I 
>too agree with, i.e., that  it should be permitted and may be 
>required in some environments (e.g., FRR) but may not be required in 
>all environments so should be left as before.  Also, as I read the 
>mails most were in favor of leaving tunnel ID as is, i.e., not 
>requiring it to be set to zero.  This doesn't match what was done in 
>this past rev.

In summary, my position is:
1) That the extended tunnel ID remain as defined in the previous 
version, i.e., retain the semantics from rfc3209/rfc3473.  I think 
adding a restriction for environments where FRR is used is 
acceptable.  (This spec covers GMPLS and non-packet environments too!)
2) That Tunnel ID remain as defined in previous version, i.e., retain 
the semantics from rfc3209/rfc3473.

The specifics of the text below is dependent on consensus on these points.

Lou

At 02:18 PM 6/22/2006, Rahul Aggarwal wrote:


>Hi Folks,
>
>Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID
>semantics as part of the last call and a discussion followed on this list.
>
>In order to resolve this discussion I had proposed some text. I have
>received some comments on this offline and want to move this discussion to
>a broader audience.
>
>Please comment on the text changes below, if you have objections or
>suggestions. Else this will be incorporated in the next version of the
>spec.
>
>How about the following rephrasing:
>
>1.
>
>Section 4.1:
>
>" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
>    identified by a P2MP SESSION object. This object contains the
>    identifier of the P2MP Session which includes the P2MP ID, a tunnel
>    ID and an extended tunnel ID.
>
>    The fields of a P2MP SESSION object are identical to those of the
>    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>    Address field is replaced by the P2MP Identifier (P2MP ID) field.
>
>    The P2MP ID provides an identifier for the set of destinations of the
>    P2MP TE Tunnel."
>
>to
>
>" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
>identified by a P2MP SESSION object. This object contains the
>identifier of the P2MP Session which includes a tuple
><Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP
>ID) is unique within the scope of the IP address of the ingress LSR. The
>Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP
>Tunnel identifier, carried in the P2MP SESSION object, is unique within
>the same scope as the ingress LSR IP address.
>
>The fields of the P2MP SESSION object are identical to those of the
>SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>Address field is replaced by the P2MP ID field."
>
>2.
>
>Section 4.2.
>
>"   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
>    ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
>    and the tunnel sender address and LSP ID fields of the P2MP
>    SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
>    defined in section 20.2."
>
>to
>
>"   A P2MP LSP is identified by the combination of the P2MP ID,
>Extended Tunnel ID that are part of the P2MP SESSION object,
>and the tunnel sender address and LSP ID fields of the P2MP
>SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
>defined in section 20.2."
>
>3.
>
>19.1.1
>
>"P2MP ID
>
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP ID and identifies the set of destinations of the P2MP
>       Tunnel."
>
>to
>
>"P2MP ID
>
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It encodes the
>       P2MP Identifier that is unique within the scope of the Ingress LSR
>       IP address carried in the Extended Tunnel ID.
>
>4.
>19.1.1
>
>"Tunnel ID
>
>       A 16-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel."
>
>to
>
>"Tunnel ID
>
>       A 16-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. It SHOULD be set to 0
>       by the ingress LSR and be ignored on receipt."
>
>
>5.
>
>"Extended Tunnel ID
>
>  A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel.  Normally set to
>       all zeros. Ingress nodes that wish to narrow the scope of a
>       SESSION to the ingress-PID pair may place their IPv4 address
>       here as a globally unique identifier [RFC3209]."
>
>to
>
>"Extended Tunnel ID
>
>       A 32-bit identifier used in the SESSION object that remains
>       constant over the life of the P2MP tunnel. This identifier
>       MUST be set to the ingress LSR's IPv4 address."
>
>6.
>
>19.1.2
>
>"This is same as the P2MP IPv4 LSP SESSION Object with the difference
>    that the extended tunnel ID may be set to a 16 byte identifier
>    [RFC3209]."
>
>to
>
>"This is same as the P2MP IPv4 LSP SESSION Object with the difference
>    that the extended tunnel ID MUST be set to a 16 byte identifier that is
>the ingress LSR's IPv6 address."
>
>7.
>
>19.2.1
>
>" IPv4 tunnel sender address
>             See [RFC3209]"
>
>to"
>
>"IPv4 tunnel sender address. This address MUST be the same as the address
>in the Extended Tunnel ID field of the SESSION object."
>
>8.
>
>19.2.2
>
>"IPv6 tunnel sender address
>            See [RFC3209]"
>
>to
>
>"IPv6 tunnel sender address. This address MUST be the same as the address
>in the Extended Tunnel ID field of the SESSION object."
>
>Thanks,
>rahul
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/mpls




Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jun 2006 18:19:38 +0000
Date: Thu, 22 Jun 2006 11:18:22 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: [e-mail], Yakov Rekhter <[e-mail]>
cc: Loa Andersson <[e-mail]>, ccamp <[e-mail]>, [e-mail],  [e-mail], [e-mail], [e-mail],  [e-mail]
Subject: Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Folks,

Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID
semantics as part of the last call and a discussion followed on this list.

In order to resolve this discussion I had proposed some text. I have
received some comments on this offline and want to move this discussion to
a broader audience.

Please comment on the text changes below, if you have objections or
suggestions. Else this will be incorporated in the next version of the
spec.

How about the following rephrasing:

1.

Section 4.1:

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
   identified by a P2MP SESSION object. This object contains the
   identifier of the P2MP Session which includes the P2MP ID, a tunnel
   ID and an extended tunnel ID.

   The fields of a P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP Identifier (P2MP ID) field.

   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel."

to

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
identified by a P2MP SESSION object. This object contains the
identifier of the P2MP Session which includes a tuple
<Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP
ID) is unique within the scope of the IP address of the ingress LSR. The
Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP
Tunnel identifier, carried in the P2MP SESSION object, is unique within
the same scope as the ingress LSR IP address.

The fields of the P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP ID field."

2.

Section 4.2.

"   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
   ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
   and the tunnel sender address and LSP ID fields of the P2MP
   SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
   defined in section 20.2."

to

"   A P2MP LSP is identified by the combination of the P2MP ID,
Extended Tunnel ID that are part of the P2MP SESSION object,
and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2."

3.

19.1.1

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP ID and identifies the set of destinations of the P2MP
      Tunnel."

to

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP Identifier that is unique within the scope of the Ingress LSR
      IP address carried in the Extended Tunnel ID.

4.
19.1.1

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel."

to

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It SHOULD be set to 0
      by the ingress LSR and be ignored on receipt."


5.

"Extended Tunnel ID

 A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Normally set to
      all zeros. Ingress nodes that wish to narrow the scope of a
      SESSION to the ingress-PID pair may place their IPv4 address
      here as a globally unique identifier [RFC3209]."

to

"Extended Tunnel ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. This identifier
      MUST be set to the ingress LSR's IPv4 address."

6.

19.1.2

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID may be set to a 16 byte identifier
   [RFC3209]."

to

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID MUST be set to a 16 byte identifier that is
the ingress LSR's IPv6 address."

7.

19.2.1

" IPv4 tunnel sender address
            See [RFC3209]"

to"

"IPv4 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

8.

19.2.2

"IPv6 tunnel sender address
           See [RFC3209]"

to

"IPv6 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

Thanks,
rahul



Envelope-to: [e-mail]
Delivery-date: Wed, 21 Jun 2006 17:52:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6955B.48892404"
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Wed, 21 Jun 2006 12:51:10 -0500
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaI5F2W4YawH5vOSeW8BFFL//gd9wMdkKSg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>

This is a multi-part message in MIME format.

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

All,
 
The Working Group Last Call has closed on this document.
 
Authors/editors please summarize the comments and document how they will
be addressed.
 
Thanks,
Deborah

________________________________

From: Brungard, Deborah A, ALABS 
Sent: Monday, June 05, 2006 5:10 PM
To: [e-mail]
Cc: Adrian Farrel; Brungard, Deborah A, ALABS
Subject: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


All,
 
As discussed at the last CCAMP meeting, the authors of this draft would
like the draft to be considered for WG Last Call. Although it appears to
be a 00 draft, the material was previously in
draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one implementation
exists.
 
This email begins a two week Working Group Last Call on the draft:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00
.txt
 
The last call will complete on June 19th at 9PM EST.
 
Comments should be addressed to the mailing list or, if anonymity is
preferred, to me. On a point of procedure, as both Adrian and myself are
co-authors, anyone who has an issue with this draft going to WG Last
Call should contact one of our ADs, Ross ([e-mail]) or Bill
([e-mail]).
 
Thanks,
Deborah
 

------_=_NextPart_001_01C6955B.48892404
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=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2914" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2>All,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2>The Working Group Last Call has closed on this 
document.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2>Authors/editors please summarize the comments and document 
how they will be addressed.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352294617-21062006><FONT face=Arial 
color=#0000ff size=2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Brungard, Deborah A, ALABS 
<BR><B>Sent:</B> Monday, June 05, 2006 5:10 PM<BR><B>To:</B> 
[e-mail]<BR><B>Cc:</B> Adrian Farrel; Brungard, Deborah A, 
ALABS<BR><B>Subject:</B> Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>As discussed at the 
last CCAMP meeting, the authors of this draft would like the draft to be 
considered for WG Last Call. Although&nbsp;it appears to be a 00 draft, the 
material was previously in draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one 
implementation exists.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>This email begins a 
two week Working Group Last Call on the draft:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006><A 
href="ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>The last call will 
complete on June 19th at 9PM EST.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>Comments should be 
addressed to the mailing list or, if anonymity is preferred, to me. On a point 
of procedure, as both Adrian and myself are co-authors, anyone who has an issue 
with this draft&nbsp;going to WG Last Call should&nbsp;contact one of our ADs, 
Ross (<A href="mailto:[e-mail]">[e-mail]</A>) or Bill (<A 
href="mailto:[e-mail]">[e-mail]</A>).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>Deborah</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6955B.48892404--



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 21:38:43 +0000
Date: Tue, 20 Jun 2006 14:37:48 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail], ccamp <[e-mail]>,  George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>,  Deborah Brungard <[e-mail]>, Ross Callon <[e-mail]>,  Bill Fenner <[e-mail]>
Subject: Re: Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Loa,

On Mon, 29 May 2006, Loa Andersson wrote:

> All,
>
> this closes the working group Last Call on
> draft-ietf-mpls-rsvp-te-p2mp-05.txt
>
> Could the authors/editors please summarize the comments and
> document how they will be addressed.
>

Finally getting around to this. The authors are reviewing a revised
version of the document that addresses the LC comments. Hopefully we can
post version-06 before the deadline to address the LC comments.

Here is a summary of the LC comments and how they are being addressed:

1. Benjamin made editorial comments. Revised text was posted on this list
to address his comments.

2. Adrian made editorial and non-editorial comments along with suggested
revisions in several places. Most of his revisions seemed fine and I
responded his comments on the list, with any further suggested
revisions of the text. A handful of his comments may require more discussion on this list.

3. Jean Louis made editorial and non-editorial comments along with
suggested text. I responded to his comments on this list with proposed
revised text in some places. In most places the suggested text seemed
fine.

4. Yakov asked clarification on tunnel ID and extended Tunnel ID semantics
and identification of P2MP tunnels/LSPs in the text. There was quite a bit
of discussion on this. I posted an email with suggested revised text to
address his comments and haven't heard any opposition to that yet.

5. I made two LC comments and proposed text to clarify the hop-object and
clarify a remerge nit.

rahul


>
>
> Loa Andersson wrote:
> > Working Group,
> >
> > this initiates a two week working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > please send comments to the MPLS working group mailling
> > list and/or working co-chairs.
> >
> > The last call ends eob May 28th.
> >
> > The ccamp mailing list copied as this is a work that has
> > an overlap between the working groups.
> >
> > Loa and George
> >
> >
> >
>
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
>



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 18:22:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on  draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Tue, 20 Jun 2006 14:21:59 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on  draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaUlY+iO43+LDUlRqG2bV9KoscgdgAAB+mQ
From: "Ong, Lyndon" <[e-mail]>
To: "Lou Berger" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Lou,

Thanks for the clarification, thought maybe there was
some ulterior motive since it is the only subfield given
that label (as opposed to "Reserved").  

Still think a separate object would be cleaner, though.

Cheers,

Lyndon 

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, June 20, 2006 11:15 AM
To: Ong, Lyndon
Cc: Adrian Farrel; Ong, Lyndon; [e-mail];
[e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

At 01:50 PM 6/20/2006, Ong, Lyndon wrote:
>One concern, though, is
>whether there were strong reasons for originally requiring that the 
>field be set to zero.

Lyndon,
         There is a long standing protocol design approach to set unused
fields to zero.  This is done precisely to enable future use of the
field.  IMO (and if my memory holds) this was so well accepted by the
3209 authors it didn't occur to us to enumerate all the implications of
"MUST be zero".  I think we did a bit better in rfc3473, but the change
was only in response to the brain damage that was seen in 3209
interpretations...

Lou



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 18:16:03 +0000
Message-Id: <[e-mail]>
Date: Tue, 20 Jun 2006 14:15:28 -0400
To: "Ong, Lyndon" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Cc: "Adrian Farrel" <[e-mail]>,"Ong, Lyndon" <[e-mail]>, <[e-mail]>,<[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:50 PM 6/20/2006, Ong, Lyndon wrote:
>One concern, though, is
>whether there were strong reasons for originally requiring that
>the field be set to zero.

Lyndon,
         There is a long standing protocol design approach to set 
unused fields to zero.  This is done precisely to enable future use 
of the field.  IMO (and if my memory holds) this was so well accepted 
by the 3209 authors it didn't occur to us to enumerate all the 
implications of "MUST be zero".  I think we did a bit better in 
rfc3473, but the change was only in response to the brain damage that 
was seen in 3209 interpretations...

Lou




Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 17:51:28 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Tue, 20 Jun 2006 13:50:01 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaToAlmiqMzLBOcSNmMp6BN58pH8wA7P9/Q
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi Adrian,

I can think of a number of advantages for a separate object:
-- avoids the errant processing issue we've been discussing
-- separates this more completely from RSVP Session processing
(right now, the draft has to have a separate statement that 
 the Call ID subfield must not be used in normal session processing.)
-- architecturally separates call and LSP information further

As far as the document is concerned, perhaps instead of removing
the description, there needs to be a stronger statement about
the "correct" processing of the field.  One concern, though, is
whether there were strong reasons for originally requiring that
the field be set to zero.

In RFC 2205, the same subfield is used in the IPv4 and IPv6 Session
objects
as a Protocol ID field, with the requirement that this is never all
zero,
plus a Flag field.  Was the requirement for all zero in RFC 3209
intended
to avoid confusion with the older use of the same bits in RFC 2205?

Cheers,

Lyndon


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Monday, June 19, 2006 5:56 AM
To: Ong, Lyndon; [e-mail]
Cc: [e-mail]
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Lyndon,

> As far as the Association Object, I understand from the definition 
> that this is serving a different purpose, however a separate object 
> (different from the Association Object) could still have some 
> advantage compared to using an existing field in the Session object.

You are right that using a separate object to carry the *short* call ID
was a possibility. And we did consider it. However, the motivation for
introducing a new object was not strong - it seems to be limited to
handling broken implementations, and we shouldn't let that particular
tail wag the dog.

In retrospect, perhaps we should not have included the description of
how broken implementations might behave. After all, we clearly don't
want to describe every possible broken implementation.

Adrian 




Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 13:41:16 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Diego Caviglia" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 20 Jun 2006 15:40:41 +0200
Content-Type: text/plain; charset="US-ASCII"

hi adrian - see in line




"Adrian Farrel" <[e-mail]>
20/06/2006 02:34
Please respond to "Adrian Farrel"
 
        To:     "Diego Caviglia" <[e-mail]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>, "Dino Bramanti" 
<[e-mail]>
        Subject:        Re: New version of 
draft-caviglia-ccamp-pc-and-sc-reqs available on repository


Hi Dimitri,


> the doc enters in a discussion in section 1.1 which is the kernel of 
many
> discussions we have had on this list
>
> from this perspective i'd like to know what you are referring to when
> stating
>
> "A Label Switched Path (LSP) has different semantics depending on the
> plane in which it the term is used"
>                                           ^^^^^^^^^

A bit tricky to determine what is underlined here.

[dp] i meant "semantics"

Anyway, you have highlighted and important issue.

Sometimes, when people say "LSP" they mean the data plane state. That is 
the 
sequence of data plane resources (links, labels, cross-connects) that 
achieve end-to-end data transport.

Sometimes people mean the control plane state created to manage the LSP in 

the data plane.

Sometime people mean the management plane/configuration information for 
the 
LSP in the data plane.

So the I-D needs to be clear what it is talking about.

[dp] agreed, my question is more is there really something different from 
base 
MPLS once we assume that a label can have multiple semantics (label, 
timeslot, 
VLAN, etc.) 

> ps: looking at the terms used for LSP in the MP/CP, the corr. paragraphs
> just speak about representation of the data path

Not sure. The authors will probably comment.

Seems to me that the I-D is talking about maintaining the data plane state 

while exchanging the control state between the control and management 
planes. This could probably be clearer in the draft.

[dp] agreed

Adrian








Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 13:14:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Tue, 20 Jun 2006 08:12:51 -0500
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaTowNUssFG/2uQTiml3K/qBYAwNgAZIO9Q
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

I apologize for responding on the last day, but my schedule kept me from
looking at this sooner.

Some responses in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, June 19, 2006 9:19 AM
> To: Mack-Crane, T. Benjamin; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
> 
> Hi Ben,
> 
> Welcome to the debate.
> 
> > I looked over this draft over the weekend and I have some
> > comments and questions.
> 
> Many thanks.
> Responses in line.
> 
> > 1)       It is hard to understand why a new feature (call control)
> > is being designed as an extension to a notification message.
> > The resulting protocol design obscures the function of the
> > protocol and creates special case processing that may lead
> > to problems.  Is there a reason that new message types were
> > not specified for call request and response?
> 
> Strong words!
> Actually we did discuss defining a new message following the model of
> G.7713.3, but we decided that the scope of the Notify message already
> includes end-to-end communication, negotiation and notification, and
that
> this was consequently within scope of the Notify message.

OK.  I was just commenting, as an outsider, on the relatively confusing
semantics of the result.

> 
> Speaking as an author of this work, it is a little frustrating to have
you
> wait until the last day of the working group last call to comment in
this
> way on a protocol process that has been around the working group for a
> considerable time. In my view (speaking as an author) I don't think
that
> WG
> last call should be used in this way.
> 
> > 2)       Given the stated intent of maintaining strict independence
> > between call and connection control, were other (existing) call
> > control protocols considered (rather than beginning a new call
> > control protocol specification)?
> 
> Yes. Very much so.
> But, the title of the I-D is "Generalized MPLS (GMPLS) RSVP-TE
Signaling
> Extensions in support of Calls" so obviously this draft wouldn't
discuss
> that sort of thing.
> If you have other proposals for handling calls through other
protocols,
> I'm
> sure that you could write an applicability I-D in CCAMP if no
> modifications
> to the protocol are required, or take your proposals for changes to
the WG
> that owns the proposed protocol.
> 
> > 3)       The network models being used in section 4.3 and section 7
are
> > not clear.  In particular the relationships between the call
> > controllers, network boundaries, ingress/egress nodes, and
> > ingress/egress links are not clear.  Figures would be very helpful
here.
> 
> Figures are always helpful, and usually (but not always) better than
> words.
> 
> In order to be sure to clarify the network models that you are finding
> confusing, it would be helpful if you asked specific questions or
proposed
> text.

It is not clear how the form of initiation of a call affects the
information available about the egress link. In part this may be
affected by whether the ingress node is inside or outside the network
(IGP) boundary.  It would seem that the situation at the egress would
have something to do with this as well.  It is unclear where the egress
trail termination point is expected to be, e.g. inside or outside the
network boundary, and, if inside, at the near or far side of the egress
node's matrix.

This may just be me having trouble parsing the text, which is why I
thought a picture would help (e.g. showing the ingress/egress nodes,
location of trail terminations, location of network boundary or
reference points, like UNI or NNI or unsignaled interface, etc.).  I
can't propose text or figures because I am unsure what point is being
made here.

> 
> > 4)       Simultaneous Call and connection establishment can
> > be very handy in the common case of a call with a single
> > connection.  This model should be supported (and in fact
> >  it is in the case of so called "connection setup without a
> > call").
> 
> Two points:
> 
> a. "Connection setup without a call" cannot, by any stretch of the
> imagination, be considered to be "simultaneous call and connection
> establishment". How could it? If there is no call established, the
call
> cannot be established simultaneous to anything.

A call is defined as "an agreement between endpoints" and any connection
entails an agreement to be connected (as a connection request can be
rejected by the egress endpoint).  In the case of "connection setup
without a call" the terms of the agreement are implicit or commonly
understood.  For example, primary and secondary LSPs belong to the same
call, but do not require a separate call setup.  It is not such a
stretch to think that some common cases may benefit from carrying call
request information in the connection request rather than requiring an
additional protocol exchange to do this.  On the other hand, ...(see
below)

> 
> b. Simultaneous Call and Connection setup could have some uses on
single
> hop
> connections where (as you say) there is a single connection per call.
But
> this seemed to be a very limited subset of requirements.
> - What about supporting more than one conneciton per call? This must
> always
> be available within the solution.
> - What about connecitons that span more than one hope? This, too, must
> always be available within the solution.
> Following the oft-quoted (and reasonable) design premise that you do
not
> optimise for special cases, we have built a solution that can handle
all
> of
> the required network configurations yet fits within the defined
> requirements.
> RFC 4158 is pretty clear on the requirements that call and connection
> separation is required, while (if I recall the reference correctly)
G.7713
> says that solutions can choose to use simultaneous call and connection
> setup
> or not. We chose "not" because of the clear architectural benefits.

One could start with the general case, and only optimize later if clear
benefits can be realized.  So I understand your point here.

> 
> >5)       The call control mechanism defined appears to support
> > only IPv4 or IPv6 addressed endpoints from a single address
> > space.  Is this correct?
> 
>  I don't think so. Can you give an example of a network that is
worrying
> you?

Networks don't worry me, but it is useful to support address
independence in operator networks.  I'm not sure where my understanding
went wrong (separate address spaces and/or other than IP addressed
endpoints).  I suppose that's an exercise for the reader.

> 
> Thanks,
> Adrian
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 08:13:58 +0000
Date: Tue, 20 Jun 2006 16:07:23 +0800
From: Dan Li <[e-mail]>
Subject: Re: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository
To: Adrian Farrel <[e-mail]>, Diego Caviglia <[e-mail]>, [e-mail]
Cc: [e-mail], Dino Bramanti <[e-mail]>
Message-id: <007701c69440$8fcfb5d0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Dimitri,

I think Adrian's answer is correct, I agree with him.

Yes, when we talk about the LSP, it has different menas based on different circumstance such as data plane, control plane and management plane. The draft needs to be clear on this issue.

For the terms LSP in CP/MP, we mean the control state is migrated between CP and MP without any impact on its data plane state.

Regards,

Dan


----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "Dino Bramanti" <[e-mail]>
Sent: Tuesday, June 20, 2006 8:34 AM
Subject: Re: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository


> Hi Dimitri,
> 
> 
> > the doc enters in a discussion in section 1.1 which is the kernel of many
> > discussions we have had on this list
> >
> > from this perspective i'd like to know what you are referring to when
> > stating
> >
> > "A Label Switched Path (LSP) has different semantics depending on the
> > plane in which it the term is used"
> >                                           ^^^^^^^^^
> 
> A bit tricky to determine what is underlined here.
> 
> Anyway, you have highlighted and important issue.
> 
> Sometimes, when people say "LSP" they mean the data plane state. That is the 
> sequence of data plane resources (links, labels, cross-connects) that 
> achieve end-to-end data transport.
> 
> Sometimes people mean the control plane state created to manage the LSP in 
> the data plane.
> 
> Sometime people mean the management plane/configuration information for the 
> LSP in the data plane.
> 
> So the I-D needs to be clear what it is talking about.
> 
> > ps: looking at the terms used for LSP in the MP/CP, the corr. paragraphs
> > just speak about representation of the data path
> 
> Not sure. The authors will probably comment.
> 
> Seems to me that the I-D is talking about maintaining the data plane state 
> while exchanging the control state between the control and management 
> planes. This could probably be clearer in the draft.
> 
> Adrian
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jun 2006 00:39:10 +0000
Message-ID: <030501c69401$bed13e60$d7001fac@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository
Date: Tue, 20 Jun 2006 01:34:42 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Dimitri,


> the doc enters in a discussion in section 1.1 which is the kernel of many
> discussions we have had on this list
>
> from this perspective i'd like to know what you are referring to when
> stating
>
> "A Label Switched Path (LSP) has different semantics depending on the
> plane in which it the term is used"
>                                           ^^^^^^^^^

A bit tricky to determine what is underlined here.

Anyway, you have highlighted and important issue.

Sometimes, when people say "LSP" they mean the data plane state. That is the 
sequence of data plane resources (links, labels, cross-connects) that 
achieve end-to-end data transport.

Sometimes people mean the control plane state created to manage the LSP in 
the data plane.

Sometime people mean the management plane/configuration information for the 
LSP in the data plane.

So the I-D needs to be clear what it is talking about.

> ps: looking at the terms used for LSP in the MP/CP, the corr. paragraphs
> just speak about representation of the data path

Not sure. The authors will probably comment.

Seems to me that the I-D is talking about maintaining the data plane state 
while exchanging the control state between the control and management 
planes. This could probably be clearer in the draft.

Adrian






Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 23:22:23 +0000
To: "Diego Caviglia" <[e-mail]>
Cc: [e-mail], "Dino Bramanti" <[e-mail]>, [e-mail], "Adrian Farrel" <[e-mail]>
Subject: Re: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 20 Jun 2006 01:20:51 +0200
Content-Type: text/plain; charset="US-ASCII"

hi diego

the doc enters in a discussion in section 1.1 which is the kernel of many 
discussions we have had on this list

from this perspective i'd like to know what you are referring to when 
stating

"A Label Switched Path (LSP) has different semantics depending on the 
plane in which it the term is used"
                                           ^^^^^^^^^

ps: looking at the terms used for LSP in the MP/CP, the corr. paragraphs 
just speak about representation of the data path 

much thanks, 
- d.






"Diego Caviglia" <[e-mail]>
Sent by: [e-mail]
19/06/2006 09:01
 
        To:     [e-mail]
        cc:     ""Adrian Farrel" <adrian", "Dino Bramanti" 
<[e-mail]>, "Dan Li <danli"
        Subject:        New version of draft-caviglia-ccamp-pc-and-sc-reqs 
available on repository



Hi all, 
          a new version of the draft-caviglia-ccamp-pc-and-sc-reqs is 
available here: 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-01.txt
. 

In this version we tried to integrate the comments/suggestion received 
privately and on the list on the -00 version. 

Best Regards 

Diego




Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 13:19:56 +0000
Message-ID: <01d201c693a2$fab10cd0$d7001fac@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 19 Jun 2006 14:18:59 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Ben,

Welcome to the debate.

> I looked over this draft over the weekend and I have some
> comments and questions.

Many thanks.
Responses in line.

> 1)       It is hard to understand why a new feature (call control)
> is being designed as an extension to a notification message.
> The resulting protocol design obscures the function of the
> protocol and creates special case processing that may lead
> to problems.  Is there a reason that new message types were
> not specified for call request and response?

Strong words!
Actually we did discuss defining a new message following the model of 
G.7713.3, but we decided that the scope of the Notify message already 
includes end-to-end communication, negotiation and notification, and that 
this was consequently within scope of the Notify message.

Speaking as an author of this work, it is a little frustrating to have you 
wait until the last day of the working group last call to comment in this 
way on a protocol process that has been around the working group for a 
considerable time. In my view (speaking as an author) I don't think that WG 
last call should be used in this way.

> 2)       Given the stated intent of maintaining strict independence
> between call and connection control, were other (existing) call
> control protocols considered (rather than beginning a new call
> control protocol specification)?

Yes. Very much so.
But, the title of the I-D is "Generalized MPLS (GMPLS) RSVP-TE Signaling 
Extensions in support of Calls" so obviously this draft wouldn't discuss 
that sort of thing.
If you have other proposals for handling calls through other protocols, I'm 
sure that you could write an applicability I-D in CCAMP if no modifications 
to the protocol are required, or take your proposals for changes to the WG 
that owns the proposed protocol.

> 3)       The network models being used in section 4.3 and section 7 are
> not clear.  In particular the relationships between the call
> controllers, network boundaries, ingress/egress nodes, and
> ingress/egress links are not clear.  Figures would be very helpful here.

Figures are always helpful, and usually (but not always) better than words.

In order to be sure to clarify the network models that you are finding 
confusing, it would be helpful if you asked specific questions or proposed 
text.

> 4)       Simultaneous Call and connection establishment can
> be very handy in the common case of a call with a single
> connection.  This model should be supported (and in fact
>  it is in the case of so called "connection setup without a
> call").

Two points:

a. "Connection setup without a call" cannot, by any stretch of the 
imagination, be considered to be "simultaneous call and connection 
establishment". How could it? If there is no call established, the call 
cannot be established simultaneous to anything.

b. Simultaneous Call and Connection setup could have some uses on single hop 
connections where (as you say) there is a single connection per call. But 
this seemed to be a very limited subset of requirements.
- What about supporting more than one conneciton per call? This must always 
be available within the solution.
- What about connecitons that span more than one hope? This, too, must 
always be available within the solution.
Following the oft-quoted (and reasonable) design premise that you do not 
optimise for special cases, we have built a solution that can handle all of 
the required network configurations yet fits within the defined 
requirements.
RFC 4158 is pretty clear on the requirements that call and connection 
separation is required, while (if I recall the reference correctly) G.7713 
says that solutions can choose to use simultaneous call and connection setup 
or not. We chose "not" because of the clear architectural benefits.

>5)       The call control mechanism defined appears to support
> only IPv4 or IPv6 addressed endpoints from a single address
> space.  Is this correct?

 I don't think so. Can you give an example of a network that is worrying 
you?

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 12:59:19 +0000
Message-ID: <01c801c6939f$fb6e49b0$d7001fac@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 19 Jun 2006 13:55:59 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Lyndon,

> As far as the Association Object, I understand from the
> definition that this is serving a different purpose, however
> a separate object (different from the Association Object)
> could still have some advantage compared to using an
> existing field in the Session object.

You are right that using a separate object to carry the *short* call ID was 
a possibility. And we did consider it. However, the motivation for 
introducing a new object was not strong - it seems to be limited to handling 
broken implementations, and we shouldn't let that particular tail wag the 
dog.

In retrospect, perhaps we should not have included the description of how 
broken implementations might behave. After all, we clearly don't want to 
describe every possible broken implementation.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 07:02:24 +0000
MIME-Version: 1.0
Sensitivity: 
To: [e-mail]
Cc: ""Adrian Farrel" <adrian" <[e-mail]>, "Dino Bramanti" <[e-mail]>, "Dan Li <danli" <[e-mail]>
Subject: New version of draft-caviglia-ccamp-pc-and-sc-reqs available on repository
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 19 Jun 2006 09:01:39 +0200
Content-Type: multipart/alternative; boundary="=_alternative 00269AA7C1257192_="

This is a multipart message in MIME format.
--=_alternative 00269AA7C1257192_Content-Type: text/plain; charset="us-ascii"

Hi all,
          a new version of the draft-caviglia-ccamp-pc-and-sc-reqs is available here: http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-01.txt.

In this version we tried to integrate the comments/suggestion received 
privately and on the list on the -00 version.

Best Regards

Diego
--=_alternative 00269AA7C1257192_Content-Type: text/html; charset="us-ascii"


<br><font size=3 color=blue face="Times New Roman">Hi all,</font>
<br><font size=3 color=blue face="Times New Roman">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a new version of the </font><font size=2 face="sans-serif">draft-caviglia-ccamp-pc-and-sc-reqs</font><font size=3 color=blue face="Times New Roman"> is available here: </font><font size=2 face="sans-serif">http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-01.txt</font><font size=3 color=blue face="Times New Roman">.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">In this version we tried to integrate the comments/suggestion received privately and on the list on the -00 version.</font>
<br>
<br><font size=3 color=blue face="Times New Roman">Best Regards</font>
<br><font size=3 color=blue face="Times New Roman"><br>
Diego</font>
--=_alternative 00269AA7C1257192_=--



Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 06:49:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6936C.6CCAC535"
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 19 Jun 2006 01:49:10 -0500
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaI5F2W4YawH5vOSeW8BFFL//gd9wKgUFbA
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6936C.6CCAC535
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi,

 

I looked over this draft over the weekend and I have some comments and
questions.

 

1)       It is hard to understand why a new feature (call control) is
being designed as an extension to a notification message.  The resulting
protocol design obscures the function of the protocol and creates
special case processing that may lead to problems.  Is there a reason
that new message types were not specified for call request and response?

2)       Given the stated intent of maintaining strict independence
between call and connection control, were other (existing) call control
protocols considered (rather than beginning a new call control protocol
specification)?

3)       The network models being used in section 4.3 and section 7 are
not clear.  In particular the relationships between the call
controllers, network boundaries, ingress/egress nodes, and
ingress/egress links are not clear.  Figures would be very helpful here.

4)       Simultaneous Call and connection establishment can be very
handy in the common case of a call with a single connection.  This model
should be supported (and in fact it is in the case of so called
"connection setup without a call").

5)       The call control mechanism defined appears to support only IPv4
or IPv6 addressed endpoints from a single address space.  Is this
correct?

 

Regards,

Ben

 

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, June 05, 2006 5:10 PM
To: [e-mail]
Cc: Adrian Farrel; Brungard, Deborah A, ALABS
Subject: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

 

All,

 

As discussed at the last CCAMP meeting, the authors of this draft would
like the draft to be considered for WG Last Call. Although it appears to
be a 00 draft, the material was previously in
draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one implementation
exists.

 

This email begins a two week Working Group Last Call on the draft:

ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00
.txt

 

The last call will complete on June 19th at 9PM EST.

 

Comments should be addressed to the mailing list or, if anonymity is
preferred, to me. On a point of procedure, as both Adrian and myself are
co-authors, anyone who has an issue with this draft going to WG Last
Call should contact one of our ADs, Ross ([e-mail]) or Bill
([e-mail]).

 

Thanks,

Deborah

 t

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

------_=_NextPart_001_01C6936C.6CCAC535
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"
 downloadurl="http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:495845893;
	mso-list-type:hybrid;
	mso-list-template-ids:797197856 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I looked over this draft over the weekend
and I have some comments and questions.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>1)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>It is hard to understand why a new feature (call control) is being
designed as an extension to a notification message. &nbsp;The resulting
protocol design obscures the function of the protocol and creates special case
processing that may lead to problems.&nbsp; Is there a reason that new message types
were not specified for call request and response?<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>2)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Given the stated intent of maintaining strict independence between
call and connection control, were other (existing) call control protocols
considered (rather than beginning a new call control protocol specification)?<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>3)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>The network models being used in section 4.3 and section 7 are not
clear. &nbsp;In particular the relationships between the call controllers, network
boundaries, ingress/egress nodes, and ingress/egress links are not clear.&nbsp;
Figures would be very helpful here.<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>4)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Simultaneous Call and connection establishment can be very handy in
the common case of a call with a single connection.&nbsp; This model should be
supported (and in fact it is in the case of so called &#8220;connection setup
without a call&#8221;).<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>5)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>The call control mechanism defined appears to support only IPv4 or
IPv6 addressed endpoints from a single address space. &nbsp;Is this correct?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Ben<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> [e-mail]
[mailto:[e-mail]] <b><span style='font-weight:bold'>On Behalf
Of </span></b>Brungard, Deborah A, ALABS<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, June 05, 2006 5:10
PM<br>
<b><span style='font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Adrian
 Farrel</st1:PersonName>; Brungard, Deborah A, ALABS<br>
<b><span style='font-weight:bold'>Subject:</span></b> Working Group Last Call
on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>All,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>As discussed at the last CCAMP meeting, the authors of this
draft would like the draft to be considered for WG Last Call. Although&nbsp;it
appears to be a 00 draft, the material was previously in
draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one implementation exists.</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>This email begins a two week Working Group Last Call on the
draft:</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>The last call will complete on June 19th at 9PM EST.</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Comments should be addressed to the mailing list or, if
anonymity is preferred, to me. On a point of procedure, as both Adrian and
myself are co-authors, anyone who has an issue with this draft&nbsp;going to WG
Last Call should&nbsp;contact one of our ADs, Ross (<a
href="mailto:[e-mail]">[e-mail]</a>) or Bill (<a
href="mailto:[e-mail]">[e-mail]</a>).</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Deborah</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<font color=navy><span style='color:navy'>t</span></font><o:p></o:p></span></font></p>

</div>

</div>

</div>

<pre>============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
</pre></body>

</html>

------_=_NextPart_001_01C6936C.6CCAC535--



Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jun 2006 05:00:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 19 Jun 2006 00:58:29 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaR8OBAedlKDR3lSHmIqJoHmYZ0YgBAAVqw
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Dimitri,

Thanks for your responses.  I meant AS=Applicability Statement. 

As far as the Association Object, I understand from the definition
that this is serving a different purpose, however a separate object
(different from the Association Object) could still have some
advantage compared to using an existing field in the Session object.

Was not sure what you meant by call blocking based on informational
data - does this mean that you want to avoid the possibility that
a call will be rejected based on Link_Capability by making it
always flexible as to whether it is sent?

Thanks,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Saturday, June 17, 2006 2:32 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; [e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon - see in-inline

Again, thank you for your detailed response.  I had the following
thoughts:

-- regarding the format for Long Call ID, if there is to be an AS on the
use of the draft, a reference to G.7713.2 would be good.
A reference in the draft itself might be simpler, though.  References to
other Call ID formats could also be added, if desired.

[dp] - what do you mean by "is to be an AS on the use..."

-- on the issue of the Session Object processing, I see your thinking as
to why an implementation should not zero out the Short Call ID subfield,
but the draft itself notes that some implementations interpret RFC 3209
to mean the field is zeroed out due to the labeling of the field "MUST
be zero" in 3209.

Why not use a separate object for the Call ID, along the lines of the
Association object?  That would separate processing of the Call ID from
the Session object, and might fit the ASON model better by separating
Call information from LSP information.

[dp] already discussed see

<https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00209.html>

answer:

"association object associates by definition LSPs (using per-sender node
identifier and address) on the other side a call creates an association
between end-points by which subsequent LSPs may be made (call ids are
unique within the context of the pair of addresses that are the call
source and destination)"

-- on the LINK_CAPABILITY object, I may have missed it in the text, but
I did not see a way for a source node to request the destination node to
send its LINK_CAPABILITY back, that would be useful. 

[dp] it is a local policy decision, in both ways - leaves flexibility
and does not create additional call blocking on informational data from
the protocol perspective 

Also, shouldn't the object be forwarded if not recognized, and not
discarded?

[dp] you refer to the class-num, because when the notify message travels
end-to-end a non-supporting receiver just discard it; keep in mind that
the dest address of the notify message is a routable egress node address

-- One new question: "Simultaneous call and connection establishment
(sometimes called piggybacking) is not supported" in section 5.1 - does
this mean it may be supported in future, or is not considered possible
or desirable?

[dp] the latter v 

Cheers,

Lyndon 



Envelope-to: [e-mail]
Delivery-date: Sat, 17 Jun 2006 09:33:25 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 17 Jun 2006 11:31:51 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon - see in-inline

Again, thank you for your detailed response.  I had the following 
thoughts:

-- regarding the format for Long Call ID, if there is to be an AS
on the use of the draft, a reference to G.7713.2 would be good.
A reference in the draft itself might be simpler, though.  References
to other Call ID formats could also be added, if desired.

[dp] - what do you mean by "is to be an AS on the use..."

-- on the issue of the Session Object processing, I see your thinking
as to why an implementation should not zero out the Short Call ID 
subfield, but the draft itself notes that some implementations interpret
RFC 3209 to mean the field is zeroed out due to the labeling of the
field "MUST be zero" in 3209.

Why not use a separate object for the Call ID, along the lines of the
Association
object?  That would separate processing of the Call ID from the Session 
object, and might fit the ASON model better by separating Call
information from LSP information.

[dp] already discussed see

<https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00209.html>

answer:

"association object associates by definition LSPs (using per-sender node 
identifier and address) on the other side a call creates an association 
between end-points by which subsequent LSPs may be made (call ids are 
unique within the context of the pair of addresses that are the call 
source and destination)"

-- on the LINK_CAPABILITY object, I may have missed it in the text, but
I did not see a way for a source node to request the destination node to
send its LINK_CAPABILITY back, that would be useful. 

[dp] it is a local policy decision, in both ways - leaves flexibility
and does not create additional call blocking on informational data from 
the protocol perspective 

Also, shouldn't the object be forwarded if not recognized, and not 
discarded?

[dp] you refer to the class-num, because when the notify message 
travels end-to-end a non-supporting receiver just discard it; keep
in mind that the dest address of the notify message is a routable
egress node address

-- One new question: "Simultaneous call and connection establishment
(sometimes called piggybacking) is not supported" in section 5.1 - does
this mean it may be supported in future, or is not considered possible
or desirable?

[dp] the latter v 

Cheers,

Lyndon 




Envelope-to: [e-mail]
Delivery-date: Sat, 17 Jun 2006 00:45:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 16 Jun 2006 20:43:57 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaRT0wzSmAx8f53TGWJi8Pw7aGCTwAM97/A
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian,

Again, thank you for your detailed response.  I had the following 
thoughts:

-- regarding the format for Long Call ID, if there is to be an AS
on the use of the draft, a reference to G.7713.2 would be good.
A reference in the draft itself might be simpler, though.  References
to other Call ID formats could also be added, if desired.

-- on the issue of the Session Object processing, I see your thinking
as to why an implementation should not zero out the Short Call ID 
subfield, but the draft itself notes that some implementations interpret
RFC 3209 to mean the field is zeroed out due to the labeling of the
field
"MUST be zero" in 3209.

Why not use a separate object for the Call ID, along the lines of the
Association
object?  That would separate processing of the Call ID from the Session 
object, and might fit the ASON model better by separating Call
information
from LSP information.

-- on the LINK_CAPABILITY object, I may have missed it in the text, but
I
did not see a way for a source node to request the destination node to
send its LINK_CAPABILITY back, that would be useful.  Also, shouldn't
the object be forwarded if not recognized, and not discarded?

-- One new question: "Simultaneous call and connection establishment
(sometimes called piggybacking) is not supported" in section 5.1 - does
this mean it may be supported in future, or is not considered possible
or desirable?


Cheers,

Lyndon 




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 22:13:26 +0000
From: "Jim Jones" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Further communication received from the OIF
Date: Fri, 16 Jun 2006 17:12:31 -0500
Message-ID: <003501c69191$f63b6190$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AcaQiO/QQN2vnXrwRGy3KUPtHnMtwgBB7DXQ

Hi Adrian,

Thanks for making these documents available to the experts in the CCAMP
working group. In the March 2006 CCAMP meeting, Lyndon Ong presented an
overview of current events in OIF, which prompted discussion on both the
signaling interworking and routing projects. Our liaison is based on the
belief that more communication was needed in these areas. They were sent in
the spirit that you said it is not possible for us to overcommunicate
(though I apologize for the length of the response).

First, here is some background on the documents themselves:

The purpose of the current routing project is to capture experimental
codepoints and TLV formats that were used in multi-vendor interoperability
demonstration events in 2003, 2004 and 2005. These are documented in
Appendix 1 of oif2005.313. This document also contains placeholders
(sections 4.3, 5.3, 6.3, 7.2 and 8.2) where we hope to simply reference ASON
routing extensions defined by CCAMP in conjunction with ITU-T SG15. As
indicated in our liaison letter, it appears that the OIF routing document
and the current CCAMP WG document
draft-dimitri-ccamp-gmpls-ason-routing-sol-01 are similar and pointed out
differences that could be addressed to achieve alignment. 

The signaling interworking documents include (1) the project plan outlining
the objectives, scope and schedule of work (oif2004.442) and (2) the current
draft interworking document (oif2006.028). As the documents explain, the
purpose is to provide design guidelines allowing implementers to interwork
between IETF GMPLS [RFC3473, RFC 4208] and ITU-T/OIF ASON signaling
protocols [G.7713.2, OIF E-NNI1.0 Signaling, OIF UNI 1.0R2].

Second, please see my responses to your questions, indicated by <JDJ>.

"Please clarify the purpose of the communication with us and the status of
the two documents."

<JDJ>	These documents are sent to help CCAMP understand what work is in
progress in OIF and to solicit technical comments on the work.

"In particular, at what stage in the OIF process are these documents, and by
when are you hoping to receive comments from CCAMP?"

<JDJ>	The routing document (an updated oif2005.313) is planned to go to
straw ballot in the OIF within the next month, and principal ballot by 3Q06.
Please keep in mind the scope of the document is to formally capture
experimental codepoints and TLV formats that were tested in OIF interop
events. It is not to document ASON routing extensions, which we hope to
reference from future IETF CCAMP RFCs. Therefore, we are not asking CCAMP to
review the extensions to ensure they accurately document what was used in
OIF interop tests; we are seeking that input from over 20 member companies
who participated in the tests. We are recommending that CCAMP consider the
experimental codepoints and TLV formats as input toward defining ASON
routing extensions. Since OIF has tested and refined these codepoints over
the last 3 years, we feel that CCAMP could benefit from this experience.
Given the scope of the project, our only request is that the content of the
document be considered in the process of defining ASON routing extensions.

<JDJ> The signaling interworking document (an update to oif2006.028) is
planned to go to straw ballot in 3-4Q06 and principal ballot 4Q06 or 1Q07.
We hope to receive input from CCAMP on our interpretations of the GMPLS
signaling messages and objects and any further suggestions on interworking
techniques or limitations. As explained in section 5 of this document,
further details are yet to be defined on interworking procedures. Therefore
it is more realistic to look for detailed technical input from CCAMP in 3Q
or 4Q06.

"Also, how are you proposing that the OIF will handle any comments received
from CCAMP?"

<JDJ> Any liaison inputs received from CCAMP are uploaded as OIF
contributions and allocated agenda time during quarterly OIF Technical
Committee meetings. Depending on the topic, a subject matter expert from OIF
is asked to present the contribution in the meeting and initiate any
follow-up documentation. For the signaling interworking and routing
documents, this would fall to the editors and contributors, as well as our
CCAMP liaison, Lyndon Ong.

"Can you also confirm the stability of the documents that you have sent. If
you are asking for our review, will these documents remain stable during the
review period or are they being continually updated? If changes are being
made on a relatively frequent basis, from where can people download the most
up-to-date copies."

<JDJ>	As mentioned above, both documents are undergoing updates. I do not
expect the routing document to change significantly before going to straw
ballot, especially the extensions definition in Appendix 1. We can also
liaise any further updates to it resulting from our 3Q06 meeting in early
August, before it goes toward principal ballot. The signaling interworking
document will expand, with more detail being needed in the areas outlined in
section 5.

<JDJ> Normally, OIF does not publicly distribute work in progress, and only
sends liaisons to selected groups on specific topics. With our meetings
being held quarterly, the documents liaised are normally up to date. At our
August meeting, we can discuss possible methods to provide document updates
between meetings as needed. And as you have pointed out, the CCAMP mailing
list is an effective means for public communication for specific technical
points. 

Best Regards,
Jim Jones
OIF Technical Committee Chair



-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Thursday, June 15, 2006 9:34 AM
To: Jim Jones
Cc: [e-mail]
Subject: Re: Further communication received from the OIF

Hi Jim,

Further to my email of 12th June, can you also confirm the stability of the
documents that you have sent. If you are asking for our review, will these
documents remain stable during the review period or are they being
continually updated? If changes are being made on a relatively frequent
basis, from where can people download the most up-to-date copies to ensure
that they do not waste their time commenting on text that has changed.

Thanks,
Adrian
----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, June 12, 2006 2:30 PM
Subject: Re: Further communication received from the OIF


> Hi Jim,
>
> Thanks for your recent communication containing the current draft of the 
> OIF Interworking Guidelines and also of the OIF E-NNI Routing 
> Specification. I am sure that the CCAMP participants will read these with 
> interest.
>
> Can you please clarify the purpose of the communication with us, and the 
> status of the two documents. In particular, at what stage in the OIF 
> process are these documents, and by when are you hoping to receive 
> comments from CCAMP? Also, how are you proposing that the OIF will handle 
> any comments received from CCAMP.
>
> Many thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, June 10, 2006 6:55 PM
> Subject: Further communication received from the OIF
>
>
>> Hi,
>>
>> We have received a communication from the OIF.
>>
>> You can see the original files on http://www.olddog.co.uk/ccamp.htm
>>
>> The text of the communication is included below.
>>
>> Adrian
>>
>> =>>
>> To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
>> From: Jim Jones, OIF TC Chair
>> Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
>> Subject: OIF Draft Documents Provided for CCAMP Information and Comment
>>
>> Dear Adrian and Deborah,
>>
>> It was reported to us that members of the CCAMP WG expressed interest in 
>> reviewing and understanding some of the current activities in the OIF 
>> regarding interworking and optical routing protocols. Accordingly, we are

>> attaching current copies of draft documents in progress in these two 
>> areas, for your information and comment. Please note that the 
>> interworking guidelines draft is based on existing standards 
>> specifications from ITU-T and IETF, and the routing protocol draft 
>> specifies the requirements on and use of OSPF-TE at the E-NNI, using 
>> G.7715/7715.1 as a basis. It documents work that has been prototyped, 
>> tested and updated based on OIF demonstrations in 2003-5. It leaves room 
>> for protocol extensions to be added as corresponding work in IETF and 
>> ITU-T is completed.
>>
>> Some members have reported on 
>> draft-dimitri-ccamp-gmpls-ason-routing-sol-01.txt, which initiates work 
>> in CCAMP towards defining the protocol extensions needed to meet E-NNI 
>> requirements. It was observed that with minor changes some of the 
>> extensions defined in the draft could be aligned with those used in 
>> working implementations that have been tested in conjunction with OIF 
>> interoperability events. Related extensions include the Node IPv4 local 
>> prefix sub-TLV and the Local and Remote TE_Router_ID sub-TLV. We believe 
>> that a key area needing review is whether the proposed extensions meet 
>> the full independence of functional component to physical location 
>> provided in G.8080/G.7715/G.7715.1 .
>>
>> I'd also like to note that I have informed OIF members about the 
>> discussion of draft-ietf-ccamp-gmpls-addressing-03.txt and the survey of 
>> which ERO options are being supported, and asked that they provide any 
>> feedback directly to Adrian or the CCAMP list.
>>
>> The OIF continues to be interested in establishing a formal liaison 
>> relationship with CCAMP and other IETF WGs as the best way to keep both 
>> bodies informed of each others' progress and working in concert, and 
>> would like input from the IETF chairs on how to pursue this next step.
>>
>> Best regards,
>> Jim Jones
>> OIF Technical Committee Chair
>>
>> Attachments:
>> 1) Interworking Guidelines project plan (oif2004.442.03)
>> 2) Interworking Guidelines draft text (oif2006.028.03)
>> 3) E-NNI Routing 1.0 draft text (oif2005.313.05)
>>
>>
>>
>>
>>
>
>
>
>
>
> 






Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 19:27:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 16 Jun 2006 15:26:09 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaRb76cKq3/avxiRqWeActXExcKOwACstPg
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>

hi Dimitri,

Yes, I recall the plan that Adrian and you presented, of a two
draft approach to the signaling issues.  Is there a schedule
for the second (applicability) draft?

Thanks,

Lyndon 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, June 16, 2006 11:07 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; Brungard, Deborah A, ALABS;
[e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon -

- did you read them attentively ? -

if yes, you will see that the first question you asked on the list is
not to be addressed as part of this process but when the protocol
operations are going to be detailed as part of a document that will
describe ASON signaling using GMPLS RSVP-TE (as discussed during IETF 63
& 64)







"Ong, Lyndon" <[e-mail]>
16/06/2006 19:09
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[e-mail]>, 
<[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>,
<[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Dimitri,

I appreciate the hints as well, but Adrian has given a more detailed
email response before I had the chance to look up the cross-references
from your email :o)

Sorry about the "a)" and "b)" - forgot to label the dashed items in the
email with letters.

Cheers,

Lyndon 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Thursday, June 15, 2006 10:44 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; Brungard, Deborah A, ALABS;
[e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that
you're referring to - for the first sub-item see section 6.2.2 for the
second see section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can
arise

-d.





"Ong, Lyndon" <[e-mail]>
Sent by: [e-mail]
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <[e-mail]>, 
<[e-mail]>
        cc:     "Adrian Farrel" <[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed.

Some
of the questions I have are more on the thought behind the procedures
than the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly
think it would be good to pass this through ITU Q.12 and Q.14/15 before
it is submitted to the IESG, so that the definitions and procedures for
call can be reviewed for any inconsistencies.  Hopefully we will in that
way avoid having multiple definitions or defining procedures that do not
fit what is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a
format has been defined in ITU-T Recommendation G.7713.2, and it might
be worth pointing to this.
 
2. Want to be sure I understand the procedures for the Short Call ID. 
Since the field is labeled
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on
transmission)
-- a non-zero value will be treated as an error and generate an error
response
-- a non-zero value will be treated as an error and the message
discarded
 
It's noted in section 7 that the only way to successfully create an LSP
through a transit node following behavior's (a) or (b) above would be to
upgrade the LSP - does this mean you could potentially have successful
call setup but failure of the associated connection setup if the transit
LSP behavior is not correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It
seems to be totally optional at both ends.  Is this determined by
policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should
assume that the call is successful if it does not receive an ack to its
Notify message? 
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in
the call?  Possibly the LSP refresh could be sufficient, since this
carries the short Call ID.  Is it possible that the call would be
dropped while there are still active LSPs?
 
Cheers,
 
Lyndon
 
 
 




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 18:08:04 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 16 Jun 2006 20:07:19 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon -

- did you read them attentively ? -

if yes, you will see that the first question you asked on the list is not
to be addressed as part of this process but when the protocol operations 
are going to be detailed as part of a document that will describe ASON 
signaling using GMPLS RSVP-TE (as discussed during IETF 63 & 64)







"Ong, Lyndon" <[e-mail]>
16/06/2006 19:09
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[e-mail]>, 
<[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, 
<[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Dimitri,

I appreciate the hints as well, but Adrian has given a more detailed
email response before I had the chance to look up the cross-references
from your email :o)

Sorry about the "a)" and "b)" - forgot to label the dashed items in the
email with letters.

Cheers,

Lyndon 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Thursday, June 15, 2006 10:44 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; Brungard, Deborah A, ALABS;
[e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that
you're referring to - for the first sub-item see section 6.2.2 for the
second see section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can
arise

-d.





"Ong, Lyndon" <[e-mail]>
Sent by: [e-mail]
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <[e-mail]>, 
<[e-mail]>
        cc:     "Adrian Farrel" <[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed.

Some
of the questions I have are more on the thought behind the procedures
than the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly
think it would be good to pass this through ITU Q.12 and Q.14/15 before
it is submitted to the IESG, so that the definitions and procedures for
call can be reviewed for any inconsistencies.  Hopefully we will in that
way avoid having multiple definitions or defining procedures that do not
fit what is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a
format has been defined in ITU-T Recommendation G.7713.2, and it might
be worth pointing to this.
 
2. Want to be sure I understand the procedures for the Short Call ID. 
Since the field is labeled
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on
transmission)
-- a non-zero value will be treated as an error and generate an error
response
-- a non-zero value will be treated as an error and the message
discarded
 
It's noted in section 7 that the only way to successfully create an LSP
through a transit node following behavior's (a) or (b) above would be to
upgrade the LSP - does this mean you could potentially have successful
call setup but failure of the associated connection setup if the transit
LSP behavior is not correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It
seems to be totally optional at both ends.  Is this determined by
policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should
assume that the call is successful if it does not receive an ack to its
Notify message? 
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in
the call?  Possibly the LSP refresh could be sufficient, since this
carries the short Call ID.  Is it possible that the call would be
dropped while there are still active LSPs?
 
Cheers,
 
Lyndon
 
 
 





Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 17:09:45 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 16 Jun 2006 13:09:37 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaQo1TVJXCiyndkRjCw1ipXdFb+UAAxAEZg
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>

Hi Dimitri,

I appreciate the hints as well, but Adrian has given a more detailed
email response before I had the chance to look up the cross-references
from your email :o)

Sorry about the "a)" and "b)" - forgot to label the dashed items in the
email with letters.

Cheers,

Lyndon 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Thursday, June 15, 2006 10:44 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; Brungard, Deborah A, ALABS;
[e-mail]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that
you're referring to - for the first sub-item see section 6.2.2 for the
second see section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can
arise

-d.





"Ong, Lyndon" <[e-mail]>
Sent by: [e-mail]
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <[e-mail]>, 
<[e-mail]>
        cc:     "Adrian Farrel" <[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed.

Some
of the questions I have are more on the thought behind the procedures
than the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly
think it would be good to pass this through ITU Q.12 and Q.14/15 before
it is submitted to the IESG, so that the definitions and procedures for
call can be reviewed for any inconsistencies.  Hopefully we will in that
way avoid having multiple definitions or defining procedures that do not
fit what is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a
format has been defined in ITU-T Recommendation G.7713.2, and it might
be worth pointing to this.
 
2. Want to be sure I understand the procedures for the Short Call ID. 
Since the field is labeled
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on
transmission)
-- a non-zero value will be treated as an error and generate an error
response
-- a non-zero value will be treated as an error and the message
discarded
 
It's noted in section 7 that the only way to successfully create an LSP
through a transit node following behavior's (a) or (b) above would be to
upgrade the LSP - does this mean you could potentially have successful
call setup but failure of the associated connection setup if the transit
LSP behavior is not correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It
seems to be totally optional at both ends.  Is this determined by
policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should
assume that the call is successful if it does not receive an ack to its
Notify message? 
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in
the call?  Possibly the LSP refresh could be sufficient, since this
carries the short Call ID.  Is it possible that the call would be
dropped while there are still active LSPs?
 
Cheers,
 
Lyndon
 
 
 



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 17:04:30 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 16 Jun 2006 13:03:11 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaRT0wzSmAx8f53TGWJi8Pw7aGCTwABGphA
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian,

I appreciate the detailed response, and will look over the points
carefully.

Regarding the issue of ITU-T, however, it confuses me when you say this
draft is not
related to ASON: 
- if you are saying that this is IETF protocol work in support of
ASON-defined requirements then it seems to me that we should pass
this through ITU for their comments to ensure that it is in fact
meeting said requirements
- if you are saying that this is in support of IETF-defined requirements
then perhaps we should not be using the terms "call", "call and
connection
separation" and "ASON" in the draft and using other terms.

As far as community expertise, I can only speak for myself - I have been
attending 
CCAMP and ITU-T Q.14, however I do not typically attend Q.12, which
originally 
created G.8080.   

Cheers,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Friday, June 16, 2006 6:52 AM
To: Ong, Lyndon; [e-mail]
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Lyndon,

> General Comment:
>
> Not sure whether this is part of WG Last Call or not, but I certainly 
> think it would be good to pass this through ITU Q.12 and Q.14/15 
> before it is submitted to the IESG, so that the definitions and 
> procedures for call can be reviewed for any inconsistencies.
> Hopefully we will in that way avoid having multiple definitions or 
> defining procedures that do not fit what is desired for ASON.

How shall I put this, Lyndon?

CCAMP always welcomes input from members of the ITU-T community on the
content of our Internet-Drafts in any stage of the process up until the
end of working group last call. Since there are many members of that
community subscribed to the CCAMP list, and since (we assume) they are
all familiar with the ASON terminology and requirements, we can
reasonably assume that there are no outstanding issues that would
require us to consult more formally on this draft which is not related
to ASON.

> More Detailed Comments:
>
> 1. Although the draft does not define a format for the Long Call ID, a

> format has been defined in ITU-T Recommendation G.7713.2, and it might

> be worth pointing to this.

As I understand the scope of G.7713.2, it specifies protocol extensions,
procedures and applicability for the use of GMPLS extensions to RSVP-TE
at the ASON UNI and E-NNI if those reference points are exposed as
external protocol interfaces. It seems clear to me that this I-D should
not preclude the use of the definition of a long call ID in this
context, but I don't see that it is particularly the place of this I-D
to reference various different encodings for call IDs in different
contexts. This type of work is the job of applicability statements that
seek to apply particular protocols to particular applications.

> 2. Want to be sure I understand the procedures for the Short Call ID.
> Since the field is labeled
> "MUST be zero" in RFC 3209, there could be multiple interpretations:
> -- a non-zero value will be received and discarded (zero inserted on
> transmission)
> -- a non-zero value will be treated as an error and generate an error 
> response
> -- a non-zero value will be treated as an error and the message 
> discarded
>
> It's noted in section 7 that the only way to successfully create an 
> LSP through a transit node following behavior's (a) or (b) above would

> be to upgrade the LSP - does this mean you could potentially have 
> successful call setup but failure of the associated connection setup 
> if the transit LSP behavior is not correct?

Let me pick through your three examples:

> -- a non-zero value will be received and discarded (zero inserted on
> transmission)

In the opinions of the authors, such behavior would represent a
defective implementation since transit LSRs should not update fields of
received messages before transmitting them except where specifically
described by the procedures of the RFCs.

However, we recognise that defective implementations may exist, and need
to design the way that they are handled to be as graceful as possible.
This is covered in section 8.2.

> -- a non-zero value will be treated as an error and generate an error 
> response

This would represent a significant error in the implementation. There is
no text that describes this being correct behavior, and it would
demonstrate a lack of understanding of the principles of extensibility
in RSVP.

Again, the graceful handling of this process is covered in section 8.2.

> -- a non-zero value will be treated as an error and the message 
> discarded

This would represent a very poor implementation, indeed. Graceful
handling of such broken implementations is only possible with the
cooperation of other network nodes and the notes in section 8.2.

You ask whether, in the presence of defective implementations as
described above it might...
> mean you could potentially have successful call setup but failure of 
> the associated connection setup if the transit LSP behavior is not 
> correct?

The answer is yes, of course.

The same is true for any call and connection separation.

Let us consider G.7713.3 (note that I would explain this using G.7713.2,
but that specification does not support call and connection separation).
The call is set up using a dedicated message between call controllers.
Once this has been done, the connections are set up as required. But
suppose that there is a simple problem of lack of bandwidth or lack of
connectivity? The call has been set up, but the connection fails.

Now suppose that there is a transit node that is a little blue today. It
receives the connection request and decides to turn it into a paper
cut-out model of the Eiffel Tower. The connection fails to set up as a
result. Does that mean that G.7713.3 is broken, or does it mean that
there is bad, bad, bad, node in the network?

> 3. Are there procedures for when to send a LINK_CAPABILITY object?
> It seems to be totally optional at both ends.  Is this determined by 
> policy?

Either I don't understand your question or you haven't read sections
4.3,
6.2 and 6.7. Could you re-phrase and/or re-read?

> 4. Why is the procedure in section 6.2.1 that the responding side 
> should assume that the call is successful if it does not receive an 
> ack to its Notify message?

The intention is to cover all DCN failures in section 7. A very good
question to pose is whether a DCN failure between call end points should
cause the call (and associated connections) to be torn down. It is
generally accepted that, in a transport network, traffic should be king
(within policy control available to the operator).

So in this specific case there are two possible scenarios:
- The Ack did not reach the call responder, because the call response
   did not reach the call initiator.
  In this case, the call initiator will take actions commensurate with
  the call setup failing. It may tear the call, which would be helpful.
  If it doesn't tear the call, the call responder will observe that the
  call is not in use and that the communications with the call initiator
  have failed and will follow policy wrt the call.
- The Ack did not reach the call responder, because the Ack was
  lost.
  In this case, use of the call will be just fine.

Note that the delivery path for the call messages is very different from
that used for the connection messages.

> 5. Is refresh of the NOTIFY really necessary if there are active LSPs 
> in the call?  Possibly the LSP refresh could be sufficient, since this

> carries the short Call ID.  Is it possible that the call would be 
> dropped while there are still active LSPs?

The process is recommended not mandated. The reasons why the process is
a good idea are stated in section 6.7.

The fact that different timer values are appropriate when there are and
are not connections in use is described. But note that connection
refresh is hop-by-hop between connection controllers, while call refresh
is between call controllers.

Architecturally, it would be pretty odd to request the connection
controllers to provide information to the call controllers on the
survival of the call.

>From a protocol point of view, it would be unfortunate to determine the
state of a call because of the state of communications between the
connection egress and the connection control immediately upstream.

Recall, we are talking about establishing connections across arbitrary
networks, not just across links.


Hope this helps.

Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 14:16:32 +0000
Message-ID: <087d01c6914f$3b70f420$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 16 Jun 2006 14:51:33 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Lyndon,

> General Comment:
>
> Not sure whether this is part of WG Last Call or not, but I certainly
> think it would be good to pass this through ITU Q.12 and Q.14/15
> before it is submitted to the IESG, so that the definitions and
> procedures for call can be reviewed for any inconsistencies.
> Hopefully we will in that way avoid having multiple definitions
> or defining procedures that do not fit what is desired for ASON.

How shall I put this, Lyndon?

CCAMP always welcomes input from members of the ITU-T community on the
content of our Internet-Drafts in any stage of the process up until the end
of working group last call. Since there are many members of that community
subscribed to the CCAMP list, and since (we assume) they are all familiar
with the ASON terminology and requirements, we can reasonably assume that
there are no outstanding issues that would require us to consult more
formally on this draft which is not related to ASON.

> More Detailed Comments:
>
> 1. Although the draft does not define a format for the Long Call ID, a
> format has been defined in ITU-T Recommendation G.7713.2, and it
> might be worth pointing to this.

As I understand the scope of G.7713.2, it specifies protocol extensions,
procedures and applicability for the use of GMPLS extensions to RSVP-TE at
the ASON UNI and E-NNI if those reference points are exposed as external
protocol interfaces. It seems clear to me that this I-D should not preclude
the use of the definition of a long call ID in this context, but I don't see
that it is particularly the place of this I-D to reference various different
encodings for call IDs in different contexts. This type of work is the job
of applicability statements that seek to apply particular protocols to
particular applications.

> 2. Want to be sure I understand the procedures for the Short Call ID.
> Since the field is labeled
> "MUST be zero" in RFC 3209, there could be multiple interpretations:
> -- a non-zero value will be received and discarded (zero inserted on
> transmission)
> -- a non-zero value will be treated as an error and generate an error
> response
> -- a non-zero value will be treated as an error and the message
> discarded
>
> It's noted in section 7 that the only way to successfully create
> an LSP through a transit node following behavior's (a) or (b) above
> would be to upgrade the LSP - does this mean you could potentially
> have successful call setup but failure of the associated connection
> setup if the transit LSP behavior is not correct?

Let me pick through your three examples:

> -- a non-zero value will be received and discarded (zero inserted on
> transmission)

In the opinions of the authors, such behavior would represent a defective
implementation since transit LSRs should not update fields of received
messages before transmitting them except where specifically described by the
procedures of the RFCs.

However, we recognise that defective implementations may exist, and need to
design the way that they are handled to be as graceful as possible. This is
covered in section 8.2.

> -- a non-zero value will be treated as an error and generate an error
> response

This would represent a significant error in the implementation. There is no
text that describes this being correct behavior, and it would demonstrate a
lack of understanding of the principles of extensibility in RSVP.

Again, the graceful handling of this process is covered in section 8.2.

> -- a non-zero value will be treated as an error and the message
> discarded

This would represent a very poor implementation, indeed. Graceful handling
of such broken implementations is only possible with the cooperation of
other network nodes and the notes in section 8.2.

You ask whether, in the presence of defective implementations as described
above it might...
> mean you could potentially have successful call setup
> but failure of the associated connection
> setup if the transit LSP behavior is not correct?

The answer is yes, of course.

The same is true for any call and connection separation.

Let us consider G.7713.3 (note that I would explain this using G.7713.2, but
that specification does not support call and connection separation). The
call is set up using a dedicated message between call controllers. Once this
has been done, the connections are set up as required. But suppose that
there is a simple problem of lack of bandwidth or lack of connectivity? The
call has been set up, but the connection fails.

Now suppose that there is a transit node that is a little blue today. It
receives the connection request and decides to turn it into a paper cut-out
model of the Eiffel Tower. The connection fails to set up as a result. Does
that mean that G.7713.3 is broken, or does it mean that there is bad, bad,
bad, node in the network?

> 3. Are there procedures for when to send a LINK_CAPABILITY object?
> It seems to be totally optional at both ends.  Is this determined by
> policy?

Either I don't understand your question or you haven't read sections 4.3,
6.2 and 6.7. Could you re-phrase and/or re-read?

> 4. Why is the procedure in section 6.2.1 that the responding side
> should assume that the call is successful if it does not receive an
> ack to its Notify message?

The intention is to cover all DCN failures in section 7. A very good
question to pose is whether a DCN failure between call end points should
cause the call (and associated connections) to be torn down. It is generally
accepted that, in a transport network, traffic should be king (within policy
control available to the operator).

So in this specific case there are two possible scenarios:
- The Ack did not reach the call responder, because the call response
   did not reach the call initiator.
  In this case, the call initiator will take actions commensurate with
  the call setup failing. It may tear the call, which would be helpful.
  If it doesn't tear the call, the call responder will observe that the
  call is not in use and that the communications with the call initiator
  have failed and will follow policy wrt the call.
- The Ack did not reach the call responder, because the Ack was
  lost.
  In this case, use of the call will be just fine.

Note that the delivery path for the call messages is very different from
that used for the connection messages.

> 5. Is refresh of the NOTIFY really necessary if there are active
> LSPs in the call?  Possibly the LSP refresh could be sufficient,
> since this carries the short Call ID.  Is it possible that the call
> would be dropped while there are still active LSPs?

The process is recommended not mandated. The reasons why the process is a
good idea are stated in section 6.7.

The fact that different timer values are appropriate when there are and are
not connections in use is described. But note that connection refresh is
hop-by-hop between connection controllers, while call refresh is between
call controllers.

Architecturally, it would be pretty odd to request the connection
controllers to provide information to the call controllers on the survival
of the call.

>From a protocol point of view, it would be unfortunate to determine the
state of a call because of the state of communications between the 
connection
egress and the connection control immediately upstream.

Recall, we are talking about establishing connections across arbitrary
networks, not just across links.


Hope this helps.

Adrian





Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jun 2006 00:44:58 +0000
Date: Thu, 15 Jun 2006 17:43:24 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4558 on Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
From: [e-mail]
Cc: [e-mail], [e-mail]

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

        
        RFC 4558

        Title:      Node-ID Based Resource Reservation Protocol 
                    (RSVP) Hello: A Clarification Statement 
        Author:     Z. Ali, R. Rahman,
                    D. Prairie, D. Papadimitriou
        Status:     Standards Track
        Date:       June 2006
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail],  [e-mail]
        Pages:      7
        Characters: 14185
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt

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

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello
messages is implied in a number of cases, e.g., when data and control
planes are separated, when TE links are unnumbered.  Furthermore, when
link level failure detection is performed by some means other than
exchanging RSVP Hello messages, use of a Node-ID based Hello session is
optimal for detecting signaling adjacency failure for Resource
reSerVation Protocol-Traffic Engineering (RSVP-TE).  Nonetheless, this
implied behavior is unclear, and this document formalizes use of
the Node-ID based RSVP Hello session in some scenarios.  The procedure
described in this document applies to both Multi-Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.  [STANDARDS 
TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jun 2006 17:45:12 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 15 Jun 2006 19:44:04 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that you're 
referring to - for the first sub-item see section 6.2.2 for the second see 
section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist 
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can 
arise

-d.





"Ong, Lyndon" <[e-mail]>
Sent by: [e-mail]
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <[e-mail]>, 
<[e-mail]>
        cc:     "Adrian Farrel" <[e-mail]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed. 
Some
of the questions I have are more on the thought behind the procedures than
the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly 
think it would be good
to pass this through ITU Q.12 and Q.14/15 before it is submitted to the 
IESG, so that the
definitions and procedures for call can be reviewed for any 
inconsistencies.  Hopefully we
will in that way avoid having multiple definitions or defining procedures 
that do not fit what
is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a 
format has been
defined in ITU-T Recommendation G.7713.2, and it might be worth pointing 
to this.
 
2. Want to be sure I understand the procedures for the Short Call ID. 
Since the field is labeled 
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on 
transmission)
-- a non-zero value will be treated as an error and generate an error 
response
-- a non-zero value will be treated as an error and the message discarded
 
It's noted in section 7 that the only way to successfully create
an LSP through a transit node following behavior's (a) or (b) above would 
be to upgrade
the LSP - does this mean you could potentially have successful call setup 
but failure
of the associated connection setup if the transit LSP behavior is not 
correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It 
seems to
be totally optional at both ends.  Is this determined by policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should 
assume that the call is successful
if it does not receive an ack to its Notify message? 
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in 
the call?  Possibly the LSP refresh 
could be sufficient, since this carries the short Call ID.  Is it possible 
that the call would be dropped while
there are still active LSPs?
 
Cheers,
 
Lyndon
 
 
 




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jun 2006 15:53:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69093.AE083D1B"
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Thu, 15 Jun 2006 11:52:16 -0400
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaI5F2W4YawH5vOSeW8BFFL//gd9wGVg6gA
From: "Ong, Lyndon" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>

This is a multi-part message in MIME format.

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

Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed.
Some
of the questions I have are more on the thought behind the procedures
than
the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly
think it would be good
to pass this through ITU Q.12 and Q.14/15 before it is submitted to the
IESG, so that the
definitions and procedures for call can be reviewed for any
inconsistencies.  Hopefully we
will in that way avoid having multiple definitions or defining
procedures that do not fit what
is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a
format has been
defined in ITU-T Recommendation G.7713.2, and it might be worth pointing
to this.
 
2. Want to be sure I understand the procedures for the Short Call ID.
Since the field is labeled 
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on
transmission)
-- a non-zero value will be treated as an error and generate an error
response
-- a non-zero value will be treated as an error and the message
discarded
 
It's noted in section 7 that the only way to successfully create
an LSP through a transit node following behavior's (a) or (b) above
would be to upgrade
the LSP - does this mean you could potentially have successful call
setup but failure
of the associated connection setup if the transit LSP behavior is not
correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It
seems to
be totally optional at both ends.  Is this determined by policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should
assume that the call is successful
if it does not receive an ack to its Notify message?  
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in
the call?  Possibly the LSP refresh 
could be sufficient, since this carries the short Call ID.  Is it
possible that the call would be dropped while
there are still active LSPs?
 
Cheers,
 
Lyndon
 
 
 

------_=_NextPart_001_01C69093.AE083D1B
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=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>Hi Deborah,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>Sorry for the lateness of the comments, but the draft 
is quite detailed.&nbsp; Some</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>of the questions I have are&nbsp;more on the thought 
behind the procedures than</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>the correctness of the procedures.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>General Comment:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>Not sure whether this is part of WG Last Call or not, 
but I certainly think it would be good</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>to pass this through ITU Q.12 and Q.14/15 before it is 
submitted to the IESG, so that the</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>definitions and procedures for call can be reviewed for 
any inconsistencies.&nbsp; Hopefully we</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>will in that way avoid having multiple definitions or 
defining procedures that do not fit what</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>is desired for ASON.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN class=301514022-13062006>I 
leave it to you and Adrian as to the right way to go about doing 
this.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>More Detailed Comments:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>1. Although the draft does not define a format for the 
Long Call ID, a format has been</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>defined in ITU-T Recommendation G.7713.2, and it might 
be worth pointing to this.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>2. Want to be sure I understand the procedures for the 
Short Call ID. Since the field is labeled </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>"MUST be zero" in RFC 3209, there could be multiple 
interpretations:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>-- a non-zero value will be received and discarded 
(zero inserted on transmission)</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>-- a non-zero value will be treated as an error and 
generate an error response</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>-- a non-zero value will be treated as an error and the 
message discarded</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>It's </SPAN></FONT><FONT face=Arial size=2><SPAN 
class=301514022-13062006>noted in section 7 that&nbsp;the only way to 
successfully create</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>an LSP through a transit node following behavior's (a) 
or (b) above would be to upgrade</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>the LSP - does this mean you could potentially have 
successful call setup&nbsp;but failure</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>of the associated connection setup if the transit LSP 
behavior is not correct?</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>3. Are there procedures for when to send a 
LINK_CAPABILITY object?&nbsp; It seems to</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>be totally optional at both ends.&nbsp; Is this 
determined by policy?</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>4. Why is the procedure in section 6.2.1 
</SPAN></FONT><FONT face=Arial size=2><SPAN class=301514022-13062006>that the 
responding side should assume that the call is successful</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>if it does not receive an ack to its Notify 
message?&nbsp; </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>5. Is refresh of the NOTIFY really necessary if there 
are active LSPs in the call?&nbsp; Possibly</SPAN></FONT><FONT face=Arial 
size=2><SPAN class=301514022-13062006> the LSP refresh </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>could be sufficient, since this carries the 
</SPAN></FONT><FONT face=Arial size=2><SPAN class=301514022-13062006>short Call 
ID.&nbsp; Is it possible that the call would be dropped 
while</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>there are still active LSPs?</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>Cheers,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006>Lyndon</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
class=301514022-13062006></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C69093.AE083D1B--



Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jun 2006 14:36:52 +0000
Message-ID: <016a01c69088$df0a6430$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Further communication received from the OIF
Date: Thu, 15 Jun 2006 15:33:32 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi Jim,

Further to my email of 12th June, can you also confirm the stability of the 
documents that you have sent. If you are asking for our review, will these 
documents remain stable during the review period or are they being 
continually updated? If changes are being made on a relatively frequent 
basis, from where can people download the most up-to-date copies to ensure 
that they do not waste their time commenting on text that has changed.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, June 12, 2006 2:30 PM
Subject: Re: Further communication received from the OIF


> Hi Jim,
>
> Thanks for your recent communication containing the current draft of the 
> OIF Interworking Guidelines and also of the OIF E-NNI Routing 
> Specification. I am sure that the CCAMP participants will read these with 
> interest.
>
> Can you please clarify the purpose of the communication with us, and the 
> status of the two documents. In particular, at what stage in the OIF 
> process are these documents, and by when are you hoping to receive 
> comments from CCAMP? Also, how are you proposing that the OIF will handle 
> any comments received from CCAMP.
>
> Many thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Saturday, June 10, 2006 6:55 PM
> Subject: Further communication received from the OIF
>
>
>> Hi,
>>
>> We have received a communication from the OIF.
>>
>> You can see the original files on http://www.olddog.co.uk/ccamp.htm
>>
>> The text of the communication is included below.
>>
>> Adrian
>>
>> =>>
>> To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
>> From: Jim Jones, OIF TC Chair
>> Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
>> Subject: OIF Draft Documents Provided for CCAMP Information and Comment
>>
>> Dear Adrian and Deborah,
>>
>> It was reported to us that members of the CCAMP WG expressed interest in 
>> reviewing and understanding some of the current activities in the OIF 
>> regarding interworking and optical routing protocols. Accordingly, we are 
>> attaching current copies of draft documents in progress in these two 
>> areas, for your information and comment. Please note that the 
>> interworking guidelines draft is based on existing standards 
>> specifications from ITU-T and IETF, and the routing protocol draft 
>> specifies the requirements on and use of OSPF-TE at the E-NNI, using 
>> G.7715/7715.1 as a basis. It documents work that has been prototyped, 
>> tested and updated based on OIF demonstrations in 2003-5. It leaves room 
>> for protocol extensions to be added as corresponding work in IETF and 
>> ITU-T is completed.
>>
>> Some members have reported on 
>> draft-dimitri-ccamp-gmpls-ason-routing-sol-01.txt, which initiates work 
>> in CCAMP towards defining the protocol extensions needed to meet E-NNI 
>> requirements. It was observed that with minor changes some of the 
>> extensions defined in the draft could be aligned with those used in 
>> working implementations that have been tested in conjunction with OIF 
>> interoperability events. Related extensions include the Node IPv4 local 
>> prefix sub-TLV and the Local and Remote TE_Router_ID sub-TLV. We believe 
>> that a key area needing review is whether the proposed extensions meet 
>> the full independence of functional component to physical location 
>> provided in G.8080/G.7715/G.7715.1 .
>>
>> I'd also like to note that I have informed OIF members about the 
>> discussion of draft-ietf-ccamp-gmpls-addressing-03.txt and the survey of 
>> which ERO options are being supported, and asked that they provide any 
>> feedback directly to Adrian or the CCAMP list.
>>
>> The OIF continues to be interested in establishing a formal liaison 
>> relationship with CCAMP and other IETF WGs as the best way to keep both 
>> bodies informed of each others' progress and working in concert, and 
>> would like input from the IETF chairs on how to pursue this next step.
>>
>> Best regards,
>> Jim Jones
>> OIF Technical Committee Chair
>>
>> Attachments:
>> 1) Interworking Guidelines project plan (oif2004.442.03)
>> 2) Interworking Guidelines draft text (oif2006.028.03)
>> 3) E-NNI Routing 1.0 draft text (oif2005.313.05)
>>
>>
>>
>>
>>
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jun 2006 14:36:45 +0000
Message-ID: <016901c69088$de6d12c0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Response to your communication on GMPLS for Ethernet
Date: Thu, 15 Jun 2006 15:30:09 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Dear Jim,

 Thank you for bringing the concerns of your technical committee with 
respect to the use of GMPLS to support Ethernet access to the attention of 
the CCAMP working group.

 We are happy to be consulted on this type of issue although we would like 
to point out the inherent inefficiencies of communicating like this. We feel 
it would be far smoother, more rapid, and more conducive for constructive 
dialogue if your members raised these types of question direct to the CCAMP 
mailing list. The CCAMP mailing list is open to everyone at no cost. 
Subscription details can be found at the CCAMP charter page: 
http://www.ietf.org/html.charters/ccamp-charter.html

> During our discussion of protocol requirements to support Ethernet
> services over optical networks, we identified some issues where
> application of the GMPLS specifications were not clear to us. We request
> CCAMP's views on the following issues:
>
> 1. Use of parameters to distinguish port-based vs. VLAN-tag-based
> forwarding of Ethernet frames
>
> We have identified two variations on support of Ethernet services at the
> network access point:
>
> a) in the first variation, received frames are forwarded into a specific
> SONET/SDH path based on the incoming port, without processing the header
> information in the Ethernet frame; and
>
> b) in the second variation, received frames are forwarded into specific
> SONET/SDH paths based on header information, esp. the VLAN tag.

 When you say "forwarded into a specific SONET/SDH path" we presume that you 
mean "adapted into". In fact, at the Ethernet layer, the SONET/SDH path is 
simply providing a virtual Ethernet link, and it is at this layer that you 
wish to set up Ethernet switching. Your questions, we assume, apply to how 
to identify the switching quantity in an Ethernet switching network, and are 
not related to the adaptation mechanisms, although the adaptation function 
may also require to know how to identify the particular Ethernet flow within 
an Ethernet port.

> It is not fully clear to us how these are distinguished in GMPLS
> signaling, especially forwarding behavior (a) above.
>
> The closest match that was identified was to use the following approach:
> - use the Switching Type value of "FSC" to indicate forwarding based on
>   port; and
> - use the Switching Type value of "L2SC" to indicate forwarding based on
>   the L2 protocol header of received frames.
>
> However, we feel that neither FSC nor L2SC exactly expresses behavior (a)
> above. In particular, "FSC" can also be interpreted as meaning that the
> signal received on the fiber is forwarded exactly as received, in its
> entirety, independent of the signal type (SONET, Ethernet, or other).
>
> We request CCAMP comment on whether this approach is the correct
> interpretation of the specifications or if an alternative and/or
> supplemental mechanism should be considered.

 FSC would, indeed, be incorrect. It is used for spatial switching.

 You are switching layer 2 packets. That means that the switching type must 
be L2SC. The fact that all layer two packets received on a port are switched 
in the same way is not material.

 May we draw your attention to 
draft-ietf-ccamp-ethernet-traffic-parameters-00.txt. We believe that this 
draft was mentioned during your meeting in the report on IETF activity, and 
it is particularly relevant to this question. It can be downloaded free of 
charge from 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt

You will observe in section  that the Sender_TSpec object includes a 
Switching Granularity field defined as follows:

     Switching Granularity (SG): 16 bits

 This field indicates the type of link that comprises the requested Ethernet 
LSP.

      The permitted Ethernet Link Type values:
           Value   Switching Granularity
           -----   ---------------------
           1       Ethernet Port
           2       Ethernet Frame

      Value 0 is reserved. Values 1 through 127 are assigned by IANA via
      IETF Standards Track RFC action.

      Values 128 through 255 are reserved for vendor specific usage.

> 2. Use of Label for these cases
>
> In addition to the question on the use of Switching Capability, it was not
> clear what value should be used as the Generalized Label for these cases.

 You should note that labels are a local matter between neighbors. That is, 
and in particular, port identifiers may be local information shared between 
neighbors and does not need to have global scope.

> For case (a) above, our current assumption is that the Label reflects the
> affected port, however it was noted that this may duplicate information in
> the RSVP_HOP Interface Index sub-TLV.

 If the port is identified as an IP numbered or unnumbered interface, then 
you are correct that using the port identifier as the label will duplicate 
the information carried in the RSVP_HOP object. Can you clarify why this 
duplication is a concern to you?

On the other hand, if multiple ports are assembled as a single interface, or 
if the ports are given a local, non-IP identification, there is a clear 
separation between the quantities.

> For case (b) above it seems logical that the Label reflect the affected
> VLAN tags.

 Indeed. The label always represents the switching quantity.

> We are investigating label formats to represent a list or range of VLAN
> identifiers, as used in MEF.11 bundling. In the case where a large number
> of non-consecutive VLAN identifiers is used for the same connection, we
> would like to keep the label to a reasonable size.

 'Large number' and 'reasonable' are impossible for us to quantify without 
further discussion with you. It seems to us, however, that if the 
information needs to be known by both neighbors, there is little alternative 
to communicating the information between the neighbors. Whether this is done 
mainly through the management plane with a label identifying a preconfigured 
combination of VLAN identifiers (i.e. a MEF bundle), through the control 
plane using GMPLS link bundling, through the control plane using extended 
(concatenated) labels as in TDM virtual concatenation, or through dynamic 
control plan virtual concatenation techniques, is clearly an implementation 
choice and may be an appropriate work area for the OIF. We would certainly 
be interested to hear your conclusions.

> In the case of bi-directional connections, the UPSTREAM_LABEL is used
> to indicate the connection is bi-directional. The LABEL_SET is then used
> if there is a need for the labels to be identical in both directions. In
> that case, there is a redundancy of labels. That is problematic with large 
> label formats.

 Redundancy of information is not an issue, per se. In fact, since there is 
a possibility to require the use of different labels in each direction, the 
objects themselves are not redundant.

 The issue with the size of label is interesting. If there is a proposal to 
use labels so large than the inclusion of two of them in a signaling message 
is significant issue then we would strongly suggest that the label format is 
wrong. (Note that your requirement here is only to carry two labels, one in 
the Upstream Label object and one in the Label Set object.)

> We would appreciate your advice regarding the possibility to reduce the
> number of labels required in the case of bi-directional connections where
> the label is the same in both directions.

 Assuming that 'reduce the number of labels' means 'reduce from two to one' 
we appreciate that there is a minor optimisation possible in this specific 
case, but suggest that it would be better to examine the underlying problem 
of label size since there will be cases of asymmetrical bidirectional LSPs 
where it is necessary to carry both labels.

 Hoping that this answers your questions.

 Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs





Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jun 2006 16:42:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Tue, 13 Jun 2006 17:39:53 +0200
Message-ID: <[e-mail]>
Thread-Topic: A new ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Thread-Index: AcaIdauEgoY6+TQ/SBimgbrahB59NwGhndmQ
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: "\"ccamp\" <ccamp" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>, <[e-mail]>

Hi Diego, hi all.

I also think the PC<->SPC conversion is a useful function for transport
networks, especially for operators who were used to doing everything
from the MP.

About the 3-migration scenario, I do not see the need for having CP[b] =
CP[a]: internal CP information may be different between both states but,
provided the data plane remains the same, this is not an issue. Of
course, before committing any ownership transfer and removing
information, the new state must be ackowleged by each involved device.
This is true for a simple LSP but also for a group of LSPs, e.g. in case
of transfering a 1+1 protected connection.

Regards,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia

Hi Dimitri,

Quoted from your e-mail
"[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP"

Now I see your point, I think that we can add a req to cover your
concern.

Regards

Diego





[e-mail] on 03/06/2006 10.42.57

To:    "Diego Caviglia" <[e-mail]>
cc:    [e-mail], "ccamp" <[e-mail]>,
Dino
       Bramanti <[e-mail]>, "Adrian Farrel"
       <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

hi diego - see inline




"Diego Caviglia" <[e-mail]>
Sent by: [e-mail]
01/06/2006 09:20

        To:     [e-mail]
        cc:     "\"\"'Adrian Farrel'\" <adrian\"", Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" <[e-mail]>, "Dino
Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        RE: A new ID is available on the repository
draft-caviglia-ccamp-   pc-and-sc-reqs-00



Hi Vijay,
          some answers in line.

Regards

Diego



"Pandian, Vijay" <[e-mail]>@ops.ietf.org on
01/06/2006
04.34.12

Sent by:    [e-mail]


To:    "'Adrian Farrel'" <[e-mail]>,
       [e-mail]
cc:    [e-mail], Diego Caviglia <[e-mail]>,
       Dino Bramanti <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not
sure
why CP needs to guarantee identical states at [a] and [b]. May be I am
not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't
it?
[dc] That is the idea.

[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP

If this is true, then MP -> CP[b] should be treated as the ONLY general
case
of MP -> CP conversion, right?
[dc] Yes, unless Dimitri calirifies better what he intend with state[a]
and
state[b]

[dp] see my previous post - note the above has an impact on the present
point

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I
guess we would describe this in terms of SPCs. Is it necessary that
identical state is held at [a] and [b]. In particular, the question of
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to
suggest

some?

Adrian

----- Original Message -----
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state
[b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of
moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would
like
> to
> see some discussion from folk on whether they think this is valuable
work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-
00.t



xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions
are
>> proposed in the ID.
>>
>> Abstract
>>
>>   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.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>





















Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jun 2006 06:57:36 +0000
Message-ID: <[e-mail]>
Date: Tue, 13 Jun 2006 08:55:59 +0200
From: Piero Castoldi <[e-mail]>
Organization: Scuola Superiore Sant'Anna
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To:  [e-mail]
Subject: Re: A new ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I have gone through draft-caviglia-ccamp-pc-and-sc-reqs-00 and I believe
it faces an interesting and up-to-date problem.
Whatever will be the actual implementation, I think that PC<->SPC 
conversion is important from the perspective of resilience,
provisioning and service management.

Best regards,

Piero Castoldi

---------------------------------------------------------------------
Scuola Superiore Sant'Anna &
CNIT, Consorzio Nazionale Interuniversitario per le Telecomunicazioni
Italy



Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jun 2006 21:49:30 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Generalized Multi-Protocol Label Switching  (GMPLS) Extensions for Synchronous Optical Network (SONET) and  Synchronous Digital Hierarchy (SDH) Control' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 12 Jun 2006 17:48:03 -0400

The IESG has approved the following document:

- 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for 
   Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) 
   Control '
   <draft-ietf-ccamp-rfc3946bis-01.txt> as a Proposed Standard

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

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt

Technical Summary
 
  This is a relatively small update to RFC3946. RFC3946 specifies GMPLS
  extensions for supporting SONET and SDH, and as such is a companion to
  the GMPLS specification (RFC3945). 
 
Working Group Summary
 
  The WG chairs reported "Good consensus", with no controversy. 
 
Protocol Quality
 
  I (Ross Callon) reviewed the changes from 3946 in detail. This is a
  pretty small but worthwhile improvement to an existing RFC. 

Note to RFC Editor
 
  This of course will obsolete 3946. 

  There is a small change needed in the first sentence of the IANA
  Considerations:

OLD:
  Three values have been defined by IANA for this document. 

NEW: 
  Three values defined by IANA for RFC 3946 now apply to this document.

IANA Note

  This should not cause any IANA-specific change from the existing 3946.
  The three values that have been defined by IANA for RFC3946 now apply
  to this document.




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jun 2006 16:59:32 +0000
Message-ID: <00d601c68e41$80532970$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lou Berger" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Updated draft response to OIF on 1:n protection
Date: Mon, 12 Jun 2006 17:57:37 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Thanks Lou,

Yes, you are right.
I will fold that into the reply.

Adrian
----- Original Message ----- 
From: "Lou Berger" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, June 12, 2006 1:42 PM
Subject: Re: Updated draft response to OIF on 1:n protection


> Adrian,
>         I like what you have so far, but there is one additional item to 
> add:
>
> Bulk notifications *are* supported in the recovery drafts using the Notify 
> message.  Notify messages could be used to provide a "single signaling 
> interaction" and "a bulk notification ... procedure".  Protection/recovery 
> could then be provided on a per LSP basis (per segment protection) or use 
> the hierarchy approach you mentioned below.  (Bulk) reversion is also 
> supported via Notify messages, see section 12 of 
> draft-ietf-ccamp-gmpls-recovery-e2e-signaling.  Note that these procedures 
> also apply to segment recovery.
>
> Lou
>
> At 03:43 PM 6/8/2006, Adrian Farrel wrote:
>
>>Hi,
>>
>>Looking at the latest input from the OIF, I think we have to perform
>>some type of meld on the two incoming communications and respond
>>to them together.
>>
>>Here is my attempt building on what we had before. Please comment on or
>>off the list.
>>
>>Thanks,
>>
>>Adrian
>>
>>=
>>
>>Dear Jim,
>>
>>Thank you for your communication to CCAMP on the use of GMPLS to provide
>>1:n protection at the OIF UNI and the OIF E-NNI dated 20th May 2006 and
>>for your updates received on 2nd June 2006.
>>
>>We are grateful for this opportunity to comment, but we note that this
>>type of communication requesting clarifications is better suited to a 
>>mailing list discussion than to official communications that, by their
>>nature, have a slow turn-around. This opinion is considerably reinforced 
>>by the process we have gone through here with a revision to
>>the OIF communication being generated while CCAMP is trying to draft its 
>>response. It seems to us that if official lines of communication are to be 
>>followed then they have to be adhered to, but if iterative
>>discussions are needed (as has proved to be the case here) then it would
>>be possible to respond far more dynamically using mailing lists.
>>
>>The appropriate place for discussions of GMPLS protocols is the CCAMP
>>working group mailing list. Details of how to subscribe to the mailing
>>list can be found at
>>http://www.ietf.org/html.charters/ccamp-charter.html
>>
>>Anyway, the CCAMP chairs are keen to ensure smooth communications with
>>the OIF and have consulted as widely as they could in the short time in
>>order to update the response that we had already drafted to your original 
>>enquiries.
>>
>>We hope that our answers are satisfactory.
>>
>>In the remainder of our response we have quoted extracts from your two
>>communications as:
>>
>>>1> For a quote from the first communication dated 20th May 2006
>>
>>>2> For a quote from your second communication dated 2nd June 2006
>>
>>>1> Future updates to OIF UNI and E-NNI signaling may include a feature
>>>1> for 1:N connection protection. The attached document presents
>>>1> requirements for these features. Recently a review was completed
>>>1> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>>>1> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>>>1> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>>>1> It appears that the abstract messages from RFC 4426 provide much
>>>1> of this functionality, however several questions resulted from this
>>>1> review. OIF would appreciate review and comments from IETF
>>>1> CCAMP on the following items.
>>>1>
>>>1> 1.) OIF would appreciate knowing if there are protocol features in
>>>1> other IETF documents relevant to 1:N protection .
>>
>>We would like to suggest that, in order to utilize advanced features of
>>the GMPLS control plane protocol, engineers should be familiar with the
>>full set of GMPLS RFCs and Internet-Drafts. These are listed on the
>>CCAMP charter page and can be downloaded free of charge by clicking on
>>the links.
>>
>>Although not all of this work is directly related to protection and
>>restoration, it should be noted that any protocol aspect present for a
>>working path may also be required for a protection path. Protocol
>>engineers must, therefore, be familiar with the details of the protocol
>>before attempting to provide advanced functions like protection.
>>
>>>2> 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has
>>>2> defined standards for any similar form of restoration, i.e., one
>>>2> that protects a group of LSPs at once over a local span, by
>>>2> shifting these LSPs from their original link within the span over
>>>2> to a backup link.  It should be noted that
>>>2> - the backup link may be a different type than the original
>>>2> (e.g., OC192 rather than OC48), so that GMPLS signaling rather
>>>2> than underlying SONET/SDH link protection is used to perform
>>>2> the switchover; and
>>>2>
>>>2> - it is intended that the affected LSPs be shifted using a
>>>2> single signaling interaction rather than separate interactions
>>>2> per individual LSP in order to reduce the signaling overhead
>>>2> required.
>>>2>
>>>2> We believe that some of the existing work, especially for segment
>>>2> recovery, may be helpful, but may not meet the exact requirements
>>>2> of the service that has been proposed within OIF. Any pointers to
>>>2> existing drafts or RFCs, however, would be greatly appreciated.
>>
>>There are two principal ways in which the objectives you cite can be
>>met, and both of these techniques are, to our certain knowledge, 
>>implemented and successfully deployed.
>>
>>a) Link-level protection. This technique relies on the protection
>>   of the underlying link outside the scope of GMPLS. Thus, the
>>   TE link over which one or more LSPs are provisioned is actually
>>   supported by more than one underlying link. When one link fails,
>>   the traffic that it was carrying (the LSPs) is transferred to
>>   another link. This type of protection is transparent to GMPLS
>>   although it could leverage GMPLS fault notification procedures.
>>
>>   You can learn some more about link-level protection by reading
>>   RFC3945 and RFC4426 (where it is referred to as Span Protection).
>>
>>   Please note that the links used in this mode do not need to be
>>   of the same type. This is not link bundling.
>>
>>b) LSP Hierarchies. This technique relies on nesting multiple LSPs
>>   within another LSP. Most familiar in packet technologies, this
>>   process is also applicable to non-packet technologies where
>>   appropriate adaptation is available.
>>
>>   By nesting multiple LSPs within another LSP, it is possible to
>>   reroute them all simply by rerouting the nesting LSP. Thus any
>>   protection scheme that can be applied to the nesting LSP can be
>>   applied to the nested LSPs in a single stage. Such procedures
>>   are, therefore, fully available for GMPLS control.
>>
>>   You can read more about LSP hierarchies in RFC4206.
>>
>>Excellent though the procedures documented in
>>draft-ietf-ccamp-gmpls-segment-recovery are, we are unsure as to the 
>>"exact requirements of the service that has been proposed
>>within OIF" and so cannot be sure which procedures to advise for
>>the problem as you have described it.
>>
>>>2> 2) Reviewing some of the existing RFC text, we note that RFC 4426
>>>2> section 2.5.2 states "it MAY be possible for the LSPs on the working
>>>2> link to be mapped to the protection link without re-signaling each
>>>2> individual LSP" and "it MAY be possible to change the component
>>>2> links without needing to re-signal each individual LSP".
>>>2> This text appears to refer to the use of SONET/SDH link protection
>>>2> in such a way that the labels for each LSP remain the same. Does
>>>2> this imply, however, that an action that changes the local
>>>2> labels for the affected LSPs then requires re-signaling of each
>>>2> individual LSP, or is there a "bulk" mechanism to change labels
>>>2> for a group of LSPs simultaneously?
>>
>>Your question is confusing in the light of the referenced section. The
>>section describes the messages required to achieve span protection.
>>Clearly, if a span is protected, then all LSPs carried over that span
>>may be transparently protected. This is how normal link protection 
>>operates and there is nothing clever going on.
>>
>>Obviously (hopefully this is obvious) if you change the label in use on
>>a link for a particular LSP then the NEs at each end of the link need to 
>>know that information since both the sender and the receiver need to
>>use the correct label. This applies for each LSP whose label you change.
>>The accepted mechanism in the control plane for exchanging labels is the
>>signaling protocol, so it follows that, if you wish to change the label
>>in use for an LSP on a link, you must engage signaling.
>>
>>You should observe that an NE may change the label in use on a link at
>>any time using the RSVP-TE protocol. All that is required (assuming a
>>unidirectional LSP) is a trigger Resv message carrying a new label.
>>Considerations of the impact to user traffic are left as an exercise for
>>the reader.
>>
>>It is unclear how the "bulk" mechanism you propose could operate unless
>>it was well-known that all labels are going to change in the same way. So 
>>perhaps you are suggesting that a single signaling message might itemise 
>>all of the LSPs and show each new label. If this is really a significant 
>>issue (i.e., you feel it is absolutely imperative to reduce
>>the number of signaling messages) then you should consider RSVP message
>>bundling.
>>
>>>2> 3) RFC 4426 describes the sending of the Failure Indication
>>>2> Message upon detection of failure by a slave device.  It is
>>>2> our belief that the same mechanism could also be used when
>>>2> the slave device is triggered to send an indication due to
>>>2> management system intervention (cases are mentioned in RFC
>>>2> 4427 but not in 4426), and we would like to know if CCAMP
>>>2> concurs with this.
>>>2> An example of where this might occur is where the master
>>>2> and slave devices are in different management domains.
>>
>>As you correctly observe, RFC4427 section 4.13 describes exactly this
>>case where management plane intervention causes a Failure Indication,
>>and it is useful for forced or controlled switch-over.
>>
>>You should note that RFC4426 section 2.5.1 says of the Failure
>>Indication message...
>>   This message is sent from the slave to the master to indicate the
>>   identities of one or more failed working links.  This message MAY not
>>   be necessary when the transport plane technology itself provides for
>>   such a notification.
>>
>>It could also be the case that the message MAY not be necessary in the
>>case where the failure indication is conveyed to the master node by the
>>management plane. That is to say, there is no specific requirement (in
>>the case of management plane intervention) for the intervention to be to 
>>the slave and causing a Failure Indication message to be sent to the
>>master - the management plane intervention could consist of a notification 
>>sent to both the slave and the master from the management
>>plane.
>>
>>The absence of this discussion within the GMPLS RFCs owes much to the
>>fact that they are largely control plane specifications with some notes
>>about the management plane for additional helpfulness.
>>
>>Your final example about the use of this technique where the master and
>>slave are in different management domains is interesting, but the use of
>>a control plane means that you should consider the control plane domains, 
>>not just the management domains.
>>
>>>1> 4.) A goal of the 1:N protection is to use a bulk notification and
>>>1> recovery procedure, based on RFC 4427 section 4.15. However, that
>>>1> RFC states the corresponding recovery switching actions are
>>>1> performed at the LSP level. It would be useful to know if bulk
>>>1> processing could be applied to recovery of individual connection
>>>1> segments on the failed span, not entire LSPs.
>>
>>>2> 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span,
>>>2> and suggests that the recovery switching message to recovered LSP
>>>2> ratio may be 1 or greater.  OIF would like to know if it is possible
>>>2> to define procedures such that the ratio is much less than 1, 2> i.e., 
>>>a message that causes bulk recovery actions on a number of
>>>2> LSPs.
>>
>>We believe that you have missed the point of section 4.15 of RFC4427.
>>This section is describing the case where all or only some of the LSPs
>>carried on a span are protected by a single recovery message exchange 
>>(full or partial span protection). In the case of partial span
>>protection it is possible that not all LSPs on the span will be
>>protected. Thus, the discussion of message to LSP ratios refers to the
>>number of recovery messages needed to protect the LSPs on a span.
>>
>>The expression of the ratios is probably unclear, but the subsequent
>>text explains the situation.
>>
>>Let us assume that there are S LSPs on the span, and s LSPs protected by
>>a protection message. Consider the ratio S/s.
>>
>>If S/s = 1, one message has been used to protect all LSPs on the span.
>>(Full recovery)
>>
>>If S/s > 1, more than one message is used to protect all of the LSPs on
>>the span OR not all LSPs on the span are protected. (Partial recovery)
>>
>>Clearly a ratio of less than one would be particularly odd !
>>
>>It should be obvious from wider reading of the RFCs (4436, 4427, and
>>3473) that the whole point of the Failure Indication is to be able to
>>report on more than one LSP failure at a time.
>>
>>>2> 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1
>>>2> and 1:1 span protection and a "source" and "destination" role for
>>>2> control of end-to-end restoration and for reversion.  We believe
>>>2> that "source" and "destination" mean the initiator and receiver
>>>2> of the LSP (as opposed to the source and destination of data
>>>2> in-band).
>>
>>The terms "source" and "destination" are standard.
>>
>>For unidirectional LSPs, the "source" is the source of data on the LSP,
>>also known as he ingress. Where a control plane is used, signaling 
>>progresses from the source (also known as the head-end).
>>
>>Similarly, the "destination" is the destination of data on the LSP, also
>>known as the egress. Where a control plane is used, signaling progresses
>>from the source to the destination (also known as the tail-end).
>>
>>By common convention, for bidirectional LSPs set up by the control
>>plane, the "source" remains the signaling source (ingress) and the
>>"destination" is the signaling destination (egress). Traffic flowing
>>in the reverse direction is referred to as reverse direction traffic
>>and flows from destination to source.
>>
>>Very probably there is an ITU-T architectural term for these end points
>>of LSPs.
>>
>>Note that RFC 4426 is very careful to state:
>>   The end-to-end recovery models discussed in this
>>   document apply to segment protection where the source and destination
>>   refer to the protected segment rather than the entire LSP.
>>
>>Should this still be unclear to you, RFC4426 section 1 states
>>   Consider the control plane message flow during the establishment of
>>   an LSP.  This message flow proceeds from an initiating (or source)
>>   node to a terminating (or destination) node, via a sequence of
>>   intermediate nodes.  A node along the LSP is said to be "upstream"
>>   from another node if the former occurs first in the sequence.  The
>>   latter node is said to be "downstream" from the former node.  That
>>   is, an "upstream" node is closer to the initiating node than a node
>>   further "downstream".  Unless otherwise stated, all references to
>>   "upstream" and "downstream" are in terms of the control plane message
>>   flow.
>>
>>The terms "master" and "slave" are introduced to describe the trigger
>>points for protection activity and are defined clearly in section 2.3
>>of RFC4426.
>>   Consider two adjacent nodes, A and B.  Under 1:1 protection, a
>>   dedicated link j between A and B is pre-assigned to protect working
>>   link i.  Link j may be carrying (pre-emptable) Extra Traffic.  A
>>   failure affecting link i results in the corresponding LSP(s) being
>>   restored to link j.  Extra Traffic being routed over link j may need
>>   to be pre-empted to accommodate the LSPs that have to be restored.
>>
>>   Once a fault is isolated/localized, the affected LSP(s) must be moved
>>   to the protection link.  The process of moving an LSP from a failed
>>   (working) link to a protection link must be initiated by one of the
>>   nodes, A or B.  This node is referred to as the "master".  The other
>>   node is called the "slave".  The determination of the master and the
>>   slave may be based on configured information or protocol specific
>>   requirements.
>>
>>Thus, the "master" is responsible for initiating the switchover, and the
>>slave is responsible for keeping up with the state changes.
>>
>>>1> Further, it would be helpful to understand why the actions are
>>>1> performed by source and destination nodes rather than master and
>>>1> slave nodes. It may be appropriate to reuse the master/slave roles
>>>1> in the reversion process just as is done in the switchover process.
>>
>>>2> We are not clear on the rationale for when control
>>>2> plane roles are based on master/slave vs. source/destination:
>>>2> it appears that local span actions are controlled using
>>>2> master/slave while remote actions are controlled using
>>>2> source/destination, however the reasoning for control of
>>>2> reversion is less clear to us.  Any clarification of the
>>>2> rationale for using master/slave vs. source/destination
>>>2> control would be appreciated.
>>
>>As explained by the definitions of the terms, there is a distinction
>>between the node that invokes a switchover process (the master) and a
>>node that performs the process. For example, a Bridge and Switch Request
>>message is sent by the source node after it has bridged traffic back to 
>>both working and protection links simply because the source node has 
>>performed the bridging and is the only node that can know this fact.
>>
>>In other words, whether the source is master or slave depends on the
>>protection scheme in use and the nature of the operation. It should be
>>a simple matter when considering a protection scheme and the necessary
>>protocol exchanges and switchover actions to determine which of the
>>source and destination must play the master or slave role.
>>
>>>1> In addition, RFC 4426 does not include an abstract message similar
>>>1> to the Failure Indication Message to request the beginning of the
>>>1> reversion procedure. It may be beneficial to include a message from
>>>1> the slave device to initiate reversion, just as there is a Failure
>>>1> Indication Message to initiate switchover. (RFC 4426 states that the
>>>1> Failure Indication Message may not be needed when the transport 1> 
>>>plane technology itself provides such a notification. The same may
>>>1> apply when a failure is cleared; however, there should still be an
>>>1> optional message to trigger the reversion process.)
>>
>>>2> 6) We believe that it may be useful in some cases of reversion to
>>>2> allow a "slave" device to request reversion using an abstract 2> 
>>>message similar to the Failure Indication Message.  An example
>>>2> case is (again) when the "master" and "slave" devices are in
>>>2> different management domains, such that reversion is initiated from
>>>2> the management domain of the "slave" device.  We request CCAMP 2> 
>>>comment on this suggestion.
>>
>>Reversion is described as an administrative procedure in RFC4426 and
>>RFC4427 quite deliberately. In our view it should not be a rapid response 
>>to a specific situation triggered through the control plane
>>by the 'master', but should be a considered operation under the control
>>of administrative policy. The trigger is, therefore, outside the scope of 
>>the control plane. This discussion can be seen in section 4.13 of RFC4427.
>>
>>We believe that your suggestion does not change this view, but that you
>>are proposing that the control plane be used as a transport for a 
>>management plane request. You are suggesting that a management station
>>in the management domain that contains the slave sends the request to the 
>>slave, the slave would then deliver the request through the control
>>plane to the master. In the absence of any specific control plane
>>requirement for this message, we believe that the correct architectural
>>approach is for management plane messages to be delivered in the 
>>management plane. Thus, if there is a need for management plane 
>>coordination between separate management plane domains, this should be
>>arranged through an appropriate management plane peering point where the 
>>correct policies can be applied.
>>
>>
>>We hope this answers your questions, and we would be happy to enter into
>>further dialog on these topics.
>>
>>In conclusion, it may be helpful to the OIF to know the status of two
>>CCAMP drafts related to recovery.
>>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and
>>draft-ietf-ccamp-gmpls-segment-recovery-02 both completed CCAMP
>>working group last call in early 2005. Since then they have been
>>implemented and tested. The drafts are stable and complete, and are
>>queued in the IETF process waiting to become RFCs
>>
>>
>>
>>Best regards,
>>Adrian Farrel and Deborah Brungard
>>CCAMP co-chairs
>>
>>
>>
>>
>>
>>
>>
>>
>>--
>>Internal Virus Database is out-of-date.
>>Checked by AVG Anti-Virus.
>>Version: 7.1.394 / Virus Database: 268.7.0/345 - Release Date: 5/22/2006
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jun 2006 16:35:39 +0000
Message-ID: <008f01c68e3e$17d30620$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Further communication received from the OIF
Date: Mon, 12 Jun 2006 14:30:25 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi Jim,

Thanks for your recent communication containing the current draft of the OIF 
Interworking Guidelines and also of the OIF E-NNI Routing Specification. I 
am sure that the CCAMP participants will read these with interest.

Can you please clarify the purpose of the communication with us, and the 
status of the two documents. In particular, at what stage in the OIF process 
are these documents, and by when are you hoping to receive comments from 
CCAMP? Also, how are you proposing that the OIF will handle any comments 
received from CCAMP.

Many thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, June 10, 2006 6:55 PM
Subject: Further communication received from the OIF


> Hi,
>
> We have received a communication from the OIF.
>
> You can see the original files on http://www.olddog.co.uk/ccamp.htm
>
> The text of the communication is included below.
>
> Adrian
>
> =>
> To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
> From: Jim Jones, OIF TC Chair
> Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
> Subject: OIF Draft Documents Provided for CCAMP Information and Comment
>
> Dear Adrian and Deborah,
>
> It was reported to us that members of the CCAMP WG expressed interest in 
> reviewing and understanding some of the current activities in the OIF 
> regarding interworking and optical routing protocols. Accordingly, we are 
> attaching current copies of draft documents in progress in these two 
> areas, for your information and comment. Please note that the interworking 
> guidelines draft is based on existing standards specifications from ITU-T 
> and IETF, and the routing protocol draft specifies the requirements on and 
> use of OSPF-TE at the E-NNI, using G.7715/7715.1 as a basis. It documents 
> work that has been prototyped, tested and updated based on OIF 
> demonstrations in 2003-5. It leaves room for protocol extensions to be 
> added as corresponding work in IETF and ITU-T is completed.
>
> Some members have reported on 
> draft-dimitri-ccamp-gmpls-ason-routing-sol-01.txt, which initiates work in 
> CCAMP towards defining the protocol extensions needed to meet E-NNI 
> requirements. It was observed that with minor changes some of the 
> extensions defined in the draft could be aligned with those used in 
> working implementations that have been tested in conjunction with OIF 
> interoperability events. Related extensions include the Node IPv4 local 
> prefix sub-TLV and the Local and Remote TE_Router_ID sub-TLV. We believe 
> that a key area needing review is whether the proposed extensions meet the 
> full independence of functional component to physical location provided in 
> G.8080/G.7715/G.7715.1 .
>
> I'd also like to note that I have informed OIF members about the 
> discussion of draft-ietf-ccamp-gmpls-addressing-03.txt and the survey of 
> which ERO options are being supported, and asked that they provide any 
> feedback directly to Adrian or the CCAMP list.
>
> The OIF continues to be interested in establishing a formal liaison 
> relationship with CCAMP and other IETF WGs as the best way to keep both 
> bodies informed of each others' progress and working in concert, and would 
> like input from the IETF chairs on how to pursue this next step.
>
> Best regards,
> Jim Jones
> OIF Technical Committee Chair
>
> Attachments:
> 1) Interworking Guidelines project plan (oif2004.442.03)
> 2) Interworking Guidelines draft text (oif2006.028.03)
> 3) E-NNI Routing 1.0 draft text (oif2005.313.05)
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jun 2006 12:43:13 +0000
Message-Id: <[e-mail]>
Date: Mon, 12 Jun 2006 08:42:34 -0400
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Updated draft response to OIF on 1:n protection
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Adrian,
         I like what you have so far, but there is one additional item to add:

Bulk notifications *are* supported in the recovery drafts using the 
Notify message.  Notify messages could be used to provide a "single 
signaling interaction" and "a bulk notification ... 
procedure".  Protection/recovery could then be provided on a per LSP 
basis (per segment protection) or use the hierarchy approach you 
mentioned below.  (Bulk) reversion is also supported via Notify 
messages, see section 12 of 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling.  Note that these 
procedures also apply to segment recovery.

Lou

At 03:43 PM 6/8/2006, Adrian Farrel wrote:

>Hi,
>
>Looking at the latest input from the OIF, I think we have to perform
>some type of meld on the two incoming communications and respond
>to them together.
>
>Here is my attempt building on what we had before. Please comment on or
>off the list.
>
>Thanks,
>
>Adrian
>
>=
>
>Dear Jim,
>
>Thank you for your communication to CCAMP on the use of GMPLS to provide
>1:n protection at the OIF UNI and the OIF E-NNI dated 20th May 2006 and
>for your updates received on 2nd June 2006.
>
>We are grateful for this opportunity to comment, but we note that this
>type of communication requesting clarifications is better suited to 
>a mailing list discussion than to official communications that, by their
>nature, have a slow turn-around. This opinion is considerably 
>reinforced by the process we have gone through here with a revision to
>the OIF communication being generated while CCAMP is trying to draft 
>its response. It seems to us that if official lines of communication 
>are to be followed then they have to be adhered to, but if iterative
>discussions are needed (as has proved to be the case here) then it would
>be possible to respond far more dynamically using mailing lists.
>
>The appropriate place for discussions of GMPLS protocols is the CCAMP
>working group mailing list. Details of how to subscribe to the mailing
>list can be found at
>http://www.ietf.org/html.charters/ccamp-charter.html
>
>Anyway, the CCAMP chairs are keen to ensure smooth communications with
>the OIF and have consulted as widely as they could in the short time in
>order to update the response that we had already drafted to your 
>original enquiries.
>
>We hope that our answers are satisfactory.
>
>In the remainder of our response we have quoted extracts from your two
>communications as:
>
>>1> For a quote from the first communication dated 20th May 2006
>
>>2> For a quote from your second communication dated 2nd June 2006
>
>>1> Future updates to OIF UNI and E-NNI signaling may include a feature
>>1> for 1:N connection protection. The attached document presents
>>1> requirements for these features. Recently a review was completed
>>1> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>>1> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>>1> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>>1> It appears that the abstract messages from RFC 4426 provide much
>>1> of this functionality, however several questions resulted from this
>>1> review. OIF would appreciate review and comments from IETF
>>1> CCAMP on the following items.
>>1>
>>1> 1.) OIF would appreciate knowing if there are protocol features in
>>1> other IETF documents relevant to 1:N protection .
>
>We would like to suggest that, in order to utilize advanced features of
>the GMPLS control plane protocol, engineers should be familiar with the
>full set of GMPLS RFCs and Internet-Drafts. These are listed on the
>CCAMP charter page and can be downloaded free of charge by clicking on
>the links.
>
>Although not all of this work is directly related to protection and
>restoration, it should be noted that any protocol aspect present for a
>working path may also be required for a protection path. Protocol
>engineers must, therefore, be familiar with the details of the protocol
>before attempting to provide advanced functions like protection.
>
>>2> 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has
>>2> defined standards for any similar form of restoration, i.e., one
>>2> that protects a group of LSPs at once over a local span, by
>>2> shifting these LSPs from their original link within the span over
>>2> to a backup link.  It should be noted that
>>2> - the backup link may be a different type than the original
>>2> (e.g., OC192 rather than OC48), so that GMPLS signaling rather
>>2> than underlying SONET/SDH link protection is used to perform
>>2> the switchover; and
>>2>
>>2> - it is intended that the affected LSPs be shifted using a
>>2> single signaling interaction rather than separate interactions
>>2> per individual LSP in order to reduce the signaling overhead
>>2> required.
>>2>
>>2> We believe that some of the existing work, especially for segment
>>2> recovery, may be helpful, but may not meet the exact requirements
>>2> of the service that has been proposed within OIF. Any pointers to
>>2> existing drafts or RFCs, however, would be greatly appreciated.
>
>There are two principal ways in which the objectives you cite can be
>met, and both of these techniques are, to our certain knowledge, 
>implemented and successfully deployed.
>
>a) Link-level protection. This technique relies on the protection
>   of the underlying link outside the scope of GMPLS. Thus, the
>   TE link over which one or more LSPs are provisioned is actually
>   supported by more than one underlying link. When one link fails,
>   the traffic that it was carrying (the LSPs) is transferred to
>   another link. This type of protection is transparent to GMPLS
>   although it could leverage GMPLS fault notification procedures.
>
>   You can learn some more about link-level protection by reading
>   RFC3945 and RFC4426 (where it is referred to as Span Protection).
>
>   Please note that the links used in this mode do not need to be
>   of the same type. This is not link bundling.
>
>b) LSP Hierarchies. This technique relies on nesting multiple LSPs
>   within another LSP. Most familiar in packet technologies, this
>   process is also applicable to non-packet technologies where
>   appropriate adaptation is available.
>
>   By nesting multiple LSPs within another LSP, it is possible to
>   reroute them all simply by rerouting the nesting LSP. Thus any
>   protection scheme that can be applied to the nesting LSP can be
>   applied to the nested LSPs in a single stage. Such procedures
>   are, therefore, fully available for GMPLS control.
>
>   You can read more about LSP hierarchies in RFC4206.
>
>Excellent though the procedures documented in
>draft-ietf-ccamp-gmpls-segment-recovery are, we are unsure as to the 
>"exact requirements of the service that has been proposed
>within OIF" and so cannot be sure which procedures to advise for
>the problem as you have described it.
>
>>2> 2) Reviewing some of the existing RFC text, we note that RFC 4426
>>2> section 2.5.2 states "it MAY be possible for the LSPs on the working
>>2> link to be mapped to the protection link without re-signaling each
>>2> individual LSP" and "it MAY be possible to change the component
>>2> links without needing to re-signal each individual LSP".
>>2> This text appears to refer to the use of SONET/SDH link protection
>>2> in such a way that the labels for each LSP remain the same. Does
>>2> this imply, however, that an action that changes the local
>>2> labels for the affected LSPs then requires re-signaling of each
>>2> individual LSP, or is there a "bulk" mechanism to change labels
>>2> for a group of LSPs simultaneously?
>
>Your question is confusing in the light of the referenced section. The
>section describes the messages required to achieve span protection.
>Clearly, if a span is protected, then all LSPs carried over that span
>may be transparently protected. This is how normal link protection 
>operates and there is nothing clever going on.
>
>Obviously (hopefully this is obvious) if you change the label in use on
>a link for a particular LSP then the NEs at each end of the link 
>need to know that information since both the sender and the receiver need to
>use the correct label. This applies for each LSP whose label you change.
>The accepted mechanism in the control plane for exchanging labels is the
>signaling protocol, so it follows that, if you wish to change the label
>in use for an LSP on a link, you must engage signaling.
>
>You should observe that an NE may change the label in use on a link at
>any time using the RSVP-TE protocol. All that is required (assuming a
>unidirectional LSP) is a trigger Resv message carrying a new label.
>Considerations of the impact to user traffic are left as an exercise for
>the reader.
>
>It is unclear how the "bulk" mechanism you propose could operate unless
>it was well-known that all labels are going to change in the same 
>way. So perhaps you are suggesting that a single signaling message 
>might itemise all of the LSPs and show each new label. If this is 
>really a significant issue (i.e., you feel it is absolutely 
>imperative to reduce
>the number of signaling messages) then you should consider RSVP message
>bundling.
>
>>2> 3) RFC 4426 describes the sending of the Failure Indication
>>2> Message upon detection of failure by a slave device.  It is
>>2> our belief that the same mechanism could also be used when
>>2> the slave device is triggered to send an indication due to
>>2> management system intervention (cases are mentioned in RFC
>>2> 4427 but not in 4426), and we would like to know if CCAMP
>>2> concurs with this.
>>2> An example of where this might occur is where the master
>>2> and slave devices are in different management domains.
>
>As you correctly observe, RFC4427 section 4.13 describes exactly this
>case where management plane intervention causes a Failure Indication,
>and it is useful for forced or controlled switch-over.
>
>You should note that RFC4426 section 2.5.1 says of the Failure
>Indication message...
>   This message is sent from the slave to the master to indicate the
>   identities of one or more failed working links.  This message MAY not
>   be necessary when the transport plane technology itself provides for
>   such a notification.
>
>It could also be the case that the message MAY not be necessary in the
>case where the failure indication is conveyed to the master node by the
>management plane. That is to say, there is no specific requirement (in
>the case of management plane intervention) for the intervention to 
>be to the slave and causing a Failure Indication message to be sent to the
>master - the management plane intervention could consist of a 
>notification sent to both the slave and the master from the management
>plane.
>
>The absence of this discussion within the GMPLS RFCs owes much to the
>fact that they are largely control plane specifications with some notes
>about the management plane for additional helpfulness.
>
>Your final example about the use of this technique where the master and
>slave are in different management domains is interesting, but the use of
>a control plane means that you should consider the control plane 
>domains, not just the management domains.
>
>>1> 4.) A goal of the 1:N protection is to use a bulk notification and
>>1> recovery procedure, based on RFC 4427 section 4.15. However, that
>>1> RFC states the corresponding recovery switching actions are
>>1> performed at the LSP level. It would be useful to know if bulk
>>1> processing could be applied to recovery of individual connection
>>1> segments on the failed span, not entire LSPs.
>
>>2> 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span,
>>2> and suggests that the recovery switching message to recovered LSP
>>2> ratio may be 1 or greater.  OIF would like to know if it is possible
>>2> to define procedures such that the ratio is much less than 1, 2> 
>>i.e., a message that causes bulk recovery actions on a number of
>>2> LSPs.
>
>We believe that you have missed the point of section 4.15 of RFC4427.
>This section is describing the case where all or only some of the LSPs
>carried on a span are protected by a single recovery message 
>exchange (full or partial span protection). In the case of partial span
>protection it is possible that not all LSPs on the span will be
>protected. Thus, the discussion of message to LSP ratios refers to the
>number of recovery messages needed to protect the LSPs on a span.
>
>The expression of the ratios is probably unclear, but the subsequent
>text explains the situation.
>
>Let us assume that there are S LSPs on the span, and s LSPs protected by
>a protection message. Consider the ratio S/s.
>
>If S/s = 1, one message has been used to protect all LSPs on the span.
>(Full recovery)
>
>If S/s > 1, more than one message is used to protect all of the LSPs on
>the span OR not all LSPs on the span are protected. (Partial recovery)
>
>Clearly a ratio of less than one would be particularly odd !
>
>It should be obvious from wider reading of the RFCs (4436, 4427, and
>3473) that the whole point of the Failure Indication is to be able to
>report on more than one LSP failure at a time.
>
>>2> 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1
>>2> and 1:1 span protection and a "source" and "destination" role for
>>2> control of end-to-end restoration and for reversion.  We believe
>>2> that "source" and "destination" mean the initiator and receiver
>>2> of the LSP (as opposed to the source and destination of data
>>2> in-band).
>
>The terms "source" and "destination" are standard.
>
>For unidirectional LSPs, the "source" is the source of data on the LSP,
>also known as he ingress. Where a control plane is used, signaling 
>progresses from the source (also known as the head-end).
>
>Similarly, the "destination" is the destination of data on the LSP, also
>known as the egress. Where a control plane is used, signaling progresses
>from the source to the destination (also known as the tail-end).
>
>By common convention, for bidirectional LSPs set up by the control
>plane, the "source" remains the signaling source (ingress) and the
>"destination" is the signaling destination (egress). Traffic flowing
>in the reverse direction is referred to as reverse direction traffic
>and flows from destination to source.
>
>Very probably there is an ITU-T architectural term for these end points
>of LSPs.
>
>Note that RFC 4426 is very careful to state:
>   The end-to-end recovery models discussed in this
>   document apply to segment protection where the source and destination
>   refer to the protected segment rather than the entire LSP.
>
>Should this still be unclear to you, RFC4426 section 1 states
>   Consider the control plane message flow during the establishment of
>   an LSP.  This message flow proceeds from an initiating (or source)
>   node to a terminating (or destination) node, via a sequence of
>   intermediate nodes.  A node along the LSP is said to be "upstream"
>   from another node if the former occurs first in the sequence.  The
>   latter node is said to be "downstream" from the former node.  That
>   is, an "upstream" node is closer to the initiating node than a node
>   further "downstream".  Unless otherwise stated, all references to
>   "upstream" and "downstream" are in terms of the control plane message
>   flow.
>
>The terms "master" and "slave" are introduced to describe the trigger
>points for protection activity and are defined clearly in section 2.3
>of RFC4426.
>   Consider two adjacent nodes, A and B.  Under 1:1 protection, a
>   dedicated link j between A and B is pre-assigned to protect working
>   link i.  Link j may be carrying (pre-emptable) Extra Traffic.  A
>   failure affecting link i results in the corresponding LSP(s) being
>   restored to link j.  Extra Traffic being routed over link j may need
>   to be pre-empted to accommodate the LSPs that have to be restored.
>
>   Once a fault is isolated/localized, the affected LSP(s) must be moved
>   to the protection link.  The process of moving an LSP from a failed
>   (working) link to a protection link must be initiated by one of the
>   nodes, A or B.  This node is referred to as the "master".  The other
>   node is called the "slave".  The determination of the master and the
>   slave may be based on configured information or protocol specific
>   requirements.
>
>Thus, the "master" is responsible for initiating the switchover, and the
>slave is responsible for keeping up with the state changes.
>
>>1> Further, it would be helpful to understand why the actions are
>>1> performed by source and destination nodes rather than master and
>>1> slave nodes. It may be appropriate to reuse the master/slave roles
>>1> in the reversion process just as is done in the switchover process.
>
>>2> We are not clear on the rationale for when control
>>2> plane roles are based on master/slave vs. source/destination:
>>2> it appears that local span actions are controlled using
>>2> master/slave while remote actions are controlled using
>>2> source/destination, however the reasoning for control of
>>2> reversion is less clear to us.  Any clarification of the
>>2> rationale for using master/slave vs. source/destination
>>2> control would be appreciated.
>
>As explained by the definitions of the terms, there is a distinction
>between the node that invokes a switchover process (the master) and a
>node that performs the process. For example, a Bridge and Switch Request
>message is sent by the source node after it has bridged traffic back 
>to both working and protection links simply because the source node 
>has performed the bridging and is the only node that can know this fact.
>
>In other words, whether the source is master or slave depends on the
>protection scheme in use and the nature of the operation. It should be
>a simple matter when considering a protection scheme and the necessary
>protocol exchanges and switchover actions to determine which of the
>source and destination must play the master or slave role.
>
>>1> In addition, RFC 4426 does not include an abstract message similar
>>1> to the Failure Indication Message to request the beginning of the
>>1> reversion procedure. It may be beneficial to include a message from
>>1> the slave device to initiate reversion, just as there is a Failure
>>1> Indication Message to initiate switchover. (RFC 4426 states that the
>>1> Failure Indication Message may not be needed when the transport 
>>1> plane technology itself provides such a notification. The same may
>>1> apply when a failure is cleared; however, there should still be an
>>1> optional message to trigger the reversion process.)
>
>>2> 6) We believe that it may be useful in some cases of reversion to
>>2> allow a "slave" device to request reversion using an abstract 2> 
>>message similar to the Failure Indication Message.  An example
>>2> case is (again) when the "master" and "slave" devices are in
>>2> different management domains, such that reversion is initiated from
>>2> the management domain of the "slave" device.  We request CCAMP 
>>2> comment on this suggestion.
>
>Reversion is described as an administrative procedure in RFC4426 and
>RFC4427 quite deliberately. In our view it should not be a rapid 
>response to a specific situation triggered through the control plane
>by the 'master', but should be a considered operation under the control
>of administrative policy. The trigger is, therefore, outside the 
>scope of the control plane. This discussion can be seen in section 
>4.13 of RFC4427.
>
>We believe that your suggestion does not change this view, but that you
>are proposing that the control plane be used as a transport for a 
>management plane request. You are suggesting that a management station
>in the management domain that contains the slave sends the request 
>to the slave, the slave would then deliver the request through the control
>plane to the master. In the absence of any specific control plane
>requirement for this message, we believe that the correct architectural
>approach is for management plane messages to be delivered in the 
>management plane. Thus, if there is a need for management plane 
>coordination between separate management plane domains, this should be
>arranged through an appropriate management plane peering point where 
>the correct policies can be applied.
>
>
>We hope this answers your questions, and we would be happy to enter into
>further dialog on these topics.
>
>In conclusion, it may be helpful to the OIF to know the status of two
>CCAMP drafts related to recovery.
>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and
>draft-ietf-ccamp-gmpls-segment-recovery-02 both completed CCAMP
>working group last call in early 2005. Since then they have been
>implemented and tested. The drafts are stable and complete, and are
>queued in the IETF process waiting to become RFCs
>
>
>
>Best regards,
>Adrian Farrel and Deborah Brungard
>CCAMP co-chairs
>
>
>
>
>
>
>
>
>--
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.1.394 / Virus Database: 268.7.0/345 - Release Date: 5/22/2006




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jun 2006 11:13:36 +0000
Message-ID: <006001c68e10$fa9ad5b0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Provisional timing for Montreal
Date: Mon, 12 Jun 2006 12:09:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

There is a *PROVISIONAL* agenda at 
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_numf

It shows CCAMP at 9.00am on Monday.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jun 2006 18:26:29 +0000
Message-ID: <[e-mail]>
Date: Sat, 10 Jun 2006 20:25:46 +0200
From: Olivier Bonaventure <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501)
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
CC: Greg Bernstein <[e-mail]>, [e-mail], [e-mail], Pierre Francois <[e-mail]>
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer	routingloops
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Don,
>>-----Original Message-----
>>From: Greg Bernstein [mailto:[e-mail]] 
>>
>>Hi Don, I'm using the term "Virtual Network Topology" related 
>>to the data plane not the control plane.  For example, when I 
>>interconnect IP routers via a WDM or SDH switching layer the 
>>resulting IP layer topology is termed a "virtual network 
>>topology" since the connectivity amongst the IP routers is 
>>not necessarily the same as the fiber topology. It is these 
>>changes to the IP layer topology that can cause the traffic 
>>disrupting micro loops.  Note that other ways that micro loops occur
>>are: (1) during IGP link weight adjustments and (2) 
>>maintenance operations.
>>
>>The connection to GMPLS/PCE is we are trying to make setting 
>>up these virtual topologies quicker and potential for traffic 
>>engineering purposes. There have been some good papers in the 
>>literature on using GMPLS and advanced algorithms for the VNT 
>>design problem.
> 
> 
> OK In as much as these topologies represent nodes and links, some how
> distributed, I would agree that: 
> 
> 1) Proactive topology changes should be dealt with in a graceful manner.

I think that everyone agrees on this. Some operators have procedures to
deal with planned link shutdowns by first setting the OSPF/ISIS weight
of those links to the maximum metric value. This is a good way to move
traffic before shutting down the link, but this technique may lead to
transient loops during the OSPF/ISIS convergence.

> One way is to have loop free alternates activated then make the topology
> changes.  

Loop free alternates have one drawback. Only about 80% of the links in
common ISP topologies are protected by loop-free alternates. How should
the operator deal with links without LFA ?

I'm not convinced that operators would like solution like the following ;
- check whether the link is protected by LFA
- if the link is protected by LFA, do something
- otherwise do another check and do something else

I guess operators will prefer a solution where the router recognise
proactive changes and deal with them automatically.

> This may result in slowly stepwise shifting the topology when turning on/off resources. 
> More elaborate schemes can add coverage in this case. But you can just
> as well design mechanisms for this particular case that explicit versus
> algorithmic. 

There is one simple solution to deal with proactive topology changes :
order the FIB updates on the routers. This ordering guarantees that the
network will converge without any transient loop and thyus without
packet losses. This ordering can be easily added to link state protocols
as shown in the following drafts :

http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-01.txt
http://www.ietf.org/internet-drafts/draft-bonaventure-isis-ordered-00.txt

Furthermore, we recently did simulations to evaluate the convergence
time of IS-IS with the proposed extension. For these simulations, we
used as parameters the measured time to perform SPF, FIB updates, etc.
on Cisco 12k as discussed in
http://www.info.ucl.ac.be/people/OBO/papers/ccr403.pdf

The simulations were performed by considering a European network and a
Tier-1 ISP with presence in Europe, USA and Asia. In the Tier-1 ISP, the
paper mentionned above showed that sub-second convergence with regular
IS-IS can be achieved. Our recent simulations with the ordering of FIB
updates indicate that sub-second *ordered* convergence is also achieved
in this Tier-1 ISP.

Basically, in this Tier-1 ISP, our simulations indicate that for a
single link shutdown, regular IS-IS converges within 200- 300
milliseconds depending on the link being shutdown. During this regular
IS-IS convergence, there are transient loops that lead to packet losses.
With the ordered-ISIS, the convergence time is not larger than 750
milliseconds. During this convergence, there are *NO* packet losses in
contrast to regular IS-IS. Thus, in contrast to popular belief, ordered
FIB updates do not lead to slow network convergence...


Olivier








Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jun 2006 17:57:19 +0000
Message-ID: <032101c68cb7$209e31e0$c2849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Further communication received from the OIF
Date: Sat, 10 Jun 2006 18:55:50 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received a communication from the OIF.

You can see the original files on http://www.olddog.co.uk/ccamp.htm

The text of the communication is included below.

Adrian

=
To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
From: Jim Jones, OIF TC Chair
Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
Subject: OIF Draft Documents Provided for CCAMP Information and Comment

Dear Adrian and Deborah,

It was reported to us that members of the CCAMP WG expressed interest in 
reviewing and understanding some of the current activities in the OIF 
regarding interworking and optical routing protocols. Accordingly, we are 
attaching current copies of draft documents in progress in these two areas, 
for your information and comment. Please note that the interworking 
guidelines draft is based on existing standards specifications from ITU-T 
and IETF, and the routing protocol draft specifies the requirements on and 
use of OSPF-TE at the E-NNI, using G.7715/7715.1 as a basis. It documents 
work that has been prototyped, tested and updated based on OIF 
demonstrations in 2003-5. It leaves room for protocol extensions to be added 
as corresponding work in IETF and ITU-T is completed.

Some members have reported on 
draft-dimitri-ccamp-gmpls-ason-routing-sol-01.txt, which initiates work in 
CCAMP towards defining the protocol extensions needed to meet E-NNI 
requirements. It was observed that with minor changes some of the extensions 
defined in the draft could be aligned with those used in working 
implementations that have been tested in conjunction with OIF 
interoperability events. Related extensions include the Node IPv4 local 
prefix sub-TLV and the Local and Remote TE_Router_ID sub-TLV. We believe 
that a key area needing review is whether the proposed extensions meet the 
full independence of functional component to physical location provided in 
G.8080/G.7715/G.7715.1 .

I'd also like to note that I have informed OIF members about the discussion 
of draft-ietf-ccamp-gmpls-addressing-03.txt and the survey of which ERO 
options are being supported, and asked that they provide any feedback 
directly to Adrian or the CCAMP list.

The OIF continues to be interested in establishing a formal liaison 
relationship with CCAMP and other IETF WGs as the best way to keep both 
bodies informed of each others' progress and working in concert, and would 
like input from the IETF chairs on how to pursue this next step.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Interworking Guidelines project plan (oif2004.442.03)
2) Interworking Guidelines draft text (oif2006.028.03)
3) E-NNI Routing 1.0 draft text (oif2005.313.05) 





Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jun 2006 09:51:47 +0000
Date: Sat, 10 Jun 2006 17:49:37 +0800
From: Zheng Hewen <[e-mail]>
Subject: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-id: <000001c68c73$32b72970$[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT

Hi,

The signaling solution for the construction of P2MP MPLS-TE LSPs defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that 
the ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by 
which it can discover the identities of those receivers.

In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it is assumed that each receiver knows the identity of 
the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information.

In order to successfully operate P2MP MPLS, and to consider extending MPLS to support MP2MP it is necessary to examine
the requirements for exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover 
and distribute multicast membership information dynamically.

Currently some work is in progress. For L3VPN applications, it is one choice to carry and distribute multicast membership 
information through auto-discovery mechanism based on extended BGP defined in the 
draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE applications, one effort is to extend IGP-TE for such 
purpose using one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport 
network basing on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy 
those requirements directly if possible.

It is desired to clear the requirements for that mechanism. Is there any interest for this? I want to do something about it 
and hope to receive advices.


Best Regards,
Heaven






Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jun 2006 19:49:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Date: Fri, 9 Jun 2006 15:48:22 -0400
Message-ID: <[e-mail]>
Thread-Topic: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Thread-Index: AcaI3HZkq2MkWZY0Rdu+IWPkF1TLuAAAIdnA
From: "Don Fedyk" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi  Greg

Sorry for the delay on this. 
> -----Original Message-----
> From: Greg Bernstein [mailto:[e-mail]] 
> 
> Hi Don, I'm using the term "Virtual Network Topology" related 
> to the data plane not the control plane.  For example, when I 
> interconnect IP routers via a WDM or SDH switching layer the 
> resulting IP layer topology is termed a "virtual network 
> topology" since the connectivity amongst the IP routers is 
> not necessarily the same as the fiber topology. It is these 
> changes to the IP layer topology that can cause the traffic 
> disrupting micro loops.  Note that other ways that micro loops occur
> are: (1) during IGP link weight adjustments and (2) 
> maintenance operations.
> 
> The connection to GMPLS/PCE is we are trying to make setting 
> up these virtual topologies quicker and potential for traffic 
> engineering purposes. There have been some good papers in the 
> literature on using GMPLS and advanced algorithms for the VNT 
> design problem.

OK In as much as these topologies represent nodes and links, some how
distributed, I would agree that: 

1) Proactive topology changes should be dealt with in a graceful manner.
One way is to have loop free alternates activated then make the topology
changes.  This may result in slowly stepwise shifting the topology when
turning on/off resources. 
More elaborate schemes can add coverage in this case. But you can just
as well design mechanisms for this particular case that explicit versus
algorithmic. 

2) When it comes to reactive topology changes that is where it gets a
bit trickier. You should have have loop free and perhaps a few more
advanced IPFRR techniques. But most of IPFRR can only protect single
failure protection, node or links. There are provisions for shared
resource correlation to maximize picking independent alternates still
biased by a single failure. 

While the simple IPFRR techniques are a no brainer I'm not convinced
that Virutal network topology is an agrument for more complex IPFRR. 

Regards,
Don 
<snip>




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jun 2006 20:37:29 +0000
Message-ID: <005b01c68b3b$191d9be0$c2849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated draft response to OIF on 1:n protection
Date: Thu, 8 Jun 2006 20:43:50 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Looking at the latest input from the OIF, I think we have to perform
some type of meld on the two incoming communications and respond
to them together.

Here is my attempt building on what we had before. Please comment on or
off the list.

Thanks,

Adrian

=

Dear Jim,

Thank you for your communication to CCAMP on the use of GMPLS to provide
1:n protection at the OIF UNI and the OIF E-NNI dated 20th May 2006 and
for your updates received on 2nd June 2006.

We are grateful for this opportunity to comment, but we note that this
type of communication requesting clarifications is better suited to a 
mailing list discussion than to official communications that, by their
nature, have a slow turn-around. This opinion is considerably 
reinforced by the process we have gone through here with a revision to
the OIF communication being generated while CCAMP is trying to draft 
its response. It seems to us that if official lines of communication 
are to be followed then they have to be adhered to, but if iterative
discussions are needed (as has proved to be the case here) then it would
be possible to respond far more dynamically using mailing lists.

The appropriate place for discussions of GMPLS protocols is the CCAMP
working group mailing list. Details of how to subscribe to the mailing
list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Anyway, the CCAMP chairs are keen to ensure smooth communications with
the OIF and have consulted as widely as they could in the short time in
order to update the response that we had already drafted to your 
original enquiries.

We hope that our answers are satisfactory.

In the remainder of our response we have quoted extracts from your two
communications as:

>1> For a quote from the first communication dated 20th May 2006

>2> For a quote from your second communication dated 2nd June 2006

>1> Future updates to OIF UNI and E-NNI signaling may include a feature
>1> for 1:N connection protection. The attached document presents
>1> requirements for these features. Recently a review was completed
>1> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>1> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>1> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>1> It appears that the abstract messages from RFC 4426 provide much
>1> of this functionality, however several questions resulted from this
>1> review. OIF would appreciate review and comments from IETF
>1> CCAMP on the following items.
>1>
>1> 1.) OIF would appreciate knowing if there are protocol features in
>1> other IETF documents relevant to 1:N protection .

We would like to suggest that, in order to utilize advanced features of
the GMPLS control plane protocol, engineers should be familiar with the
full set of GMPLS RFCs and Internet-Drafts. These are listed on the
CCAMP charter page and can be downloaded free of charge by clicking on
the links.

Although not all of this work is directly related to protection and
restoration, it should be noted that any protocol aspect present for a
working path may also be required for a protection path. Protocol
engineers must, therefore, be familiar with the details of the protocol
before attempting to provide advanced functions like protection.

>2> 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has
>2> defined standards for any similar form of restoration, i.e., one
>2> that protects a group of LSPs at once over a local span, by
>2> shifting these LSPs from their original link within the span over
>2> to a backup link.  It should be noted that
>2> - the backup link may be a different type than the original
>2> (e.g., OC192 rather than OC48), so that GMPLS signaling rather
>2> than underlying SONET/SDH link protection is used to perform
>2> the switchover; and
>2>
>2> - it is intended that the affected LSPs be shifted using a
>2> single signaling interaction rather than separate interactions
>2> per individual LSP in order to reduce the signaling overhead
>2> required.
>2>
>2> We believe that some of the existing work, especially for segment
>2> recovery, may be helpful, but may not meet the exact requirements
>2> of the service that has been proposed within OIF. Any pointers to
>2> existing drafts or RFCs, however, would be greatly appreciated.

There are two principal ways in which the objectives you cite can be
met, and both of these techniques are, to our certain knowledge, 
implemented and successfully deployed.

a) Link-level protection. This technique relies on the protection
   of the underlying link outside the scope of GMPLS. Thus, the
   TE link over which one or more LSPs are provisioned is actually
   supported by more than one underlying link. When one link fails,
   the traffic that it was carrying (the LSPs) is transferred to
   another link. This type of protection is transparent to GMPLS
   although it could leverage GMPLS fault notification procedures.

   You can learn some more about link-level protection by reading
   RFC3945 and RFC4426 (where it is referred to as Span Protection).

   Please note that the links used in this mode do not need to be
   of the same type. This is not link bundling.

b) LSP Hierarchies. This technique relies on nesting multiple LSPs
   within another LSP. Most familiar in packet technologies, this
   process is also applicable to non-packet technologies where
   appropriate adaptation is available.

   By nesting multiple LSPs within another LSP, it is possible to
   reroute them all simply by rerouting the nesting LSP. Thus any
   protection scheme that can be applied to the nesting LSP can be
   applied to the nested LSPs in a single stage. Such procedures
   are, therefore, fully available for GMPLS control.

   You can read more about LSP hierarchies in RFC4206.

Excellent though the procedures documented in
draft-ietf-ccamp-gmpls-segment-recovery are, we are unsure as to 
the "exact requirements of the service that has been proposed
within OIF" and so cannot be sure which procedures to advise for
the problem as you have described it.

>2> 2) Reviewing some of the existing RFC text, we note that RFC 4426
>2> section 2.5.2 states "it MAY be possible for the LSPs on the working
>2> link to be mapped to the protection link without re-signaling each
>2> individual LSP" and "it MAY be possible to change the component
>2> links without needing to re-signal each individual LSP".
>2> This text appears to refer to the use of SONET/SDH link protection
>2> in such a way that the labels for each LSP remain the same. Does
>2> this imply, however, that an action that changes the local
>2> labels for the affected LSPs then requires re-signaling of each
>2> individual LSP, or is there a "bulk" mechanism to change labels
>2> for a group of LSPs simultaneously?

Your question is confusing in the light of the referenced section. The
section describes the messages required to achieve span protection.
Clearly, if a span is protected, then all LSPs carried over that span
may be transparently protected. This is how normal link protection 
operates and there is nothing clever going on.

Obviously (hopefully this is obvious) if you change the label in use on
a link for a particular LSP then the NEs at each end of the link need 
to know that information since both the sender and the receiver need to
use the correct label. This applies for each LSP whose label you change.
The accepted mechanism in the control plane for exchanging labels is the
signaling protocol, so it follows that, if you wish to change the label
in use for an LSP on a link, you must engage signaling.

You should observe that an NE may change the label in use on a link at
any time using the RSVP-TE protocol. All that is required (assuming a
unidirectional LSP) is a trigger Resv message carrying a new label.
Considerations of the impact to user traffic are left as an exercise for
the reader.

It is unclear how the "bulk" mechanism you propose could operate unless
it was well-known that all labels are going to change in the same way. 
So perhaps you are suggesting that a single signaling message might 
itemise all of the LSPs and show each new label. If this is really a 
significant issue (i.e., you feel it is absolutely imperative to reduce
the number of signaling messages) then you should consider RSVP message
bundling.

>2> 3) RFC 4426 describes the sending of the Failure Indication
>2> Message upon detection of failure by a slave device.  It is
>2> our belief that the same mechanism could also be used when
>2> the slave device is triggered to send an indication due to
>2> management system intervention (cases are mentioned in RFC
>2> 4427 but not in 4426), and we would like to know if CCAMP
>2> concurs with this.
>2> An example of where this might occur is where the master
>2> and slave devices are in different management domains.

As you correctly observe, RFC4427 section 4.13 describes exactly this
case where management plane intervention causes a Failure Indication,
and it is useful for forced or controlled switch-over.

You should note that RFC4426 section 2.5.1 says of the Failure
Indication message...
   This message is sent from the slave to the master to indicate the
   identities of one or more failed working links.  This message MAY not
   be necessary when the transport plane technology itself provides for
   such a notification.

It could also be the case that the message MAY not be necessary in the
case where the failure indication is conveyed to the master node by the
management plane. That is to say, there is no specific requirement (in
the case of management plane intervention) for the intervention to be 
to the slave and causing a Failure Indication message to be sent to the
master - the management plane intervention could consist of a 
notification sent to both the slave and the master from the management
plane.

The absence of this discussion within the GMPLS RFCs owes much to the
fact that they are largely control plane specifications with some notes
about the management plane for additional helpfulness.

Your final example about the use of this technique where the master and
slave are in different management domains is interesting, but the use of
a control plane means that you should consider the control plane 
domains, not just the management domains.

>1> 4.) A goal of the 1:N protection is to use a bulk notification and
>1> recovery procedure, based on RFC 4427 section 4.15. However, that
>1> RFC states the corresponding recovery switching actions are
>1> performed at the LSP level. It would be useful to know if bulk
>1> processing could be applied to recovery of individual connection
>1> segments on the failed span, not entire LSPs.

>2> 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span,
>2> and suggests that the recovery switching message to recovered LSP
>2> ratio may be 1 or greater.  OIF would like to know if it is possible
>2> to define procedures such that the ratio is much less than 1, 
>2> i.e., a message that causes bulk recovery actions on a number of
>2> LSPs.

We believe that you have missed the point of section 4.15 of RFC4427.
This section is describing the case where all or only some of the LSPs
carried on a span are protected by a single recovery message exchange 
(full or partial span protection). In the case of partial span
protection it is possible that not all LSPs on the span will be
protected. Thus, the discussion of message to LSP ratios refers to the
number of recovery messages needed to protect the LSPs on a span.

The expression of the ratios is probably unclear, but the subsequent
text explains the situation.

Let us assume that there are S LSPs on the span, and s LSPs protected by
a protection message. Consider the ratio S/s.

If S/s = 1, one message has been used to protect all LSPs on the span.
(Full recovery)

If S/s > 1, more than one message is used to protect all of the LSPs on
the span OR not all LSPs on the span are protected. (Partial recovery)

Clearly a ratio of less than one would be particularly odd !

It should be obvious from wider reading of the RFCs (4436, 4427, and
3473) that the whole point of the Failure Indication is to be able to
report on more than one LSP failure at a time.

>2> 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1
>2> and 1:1 span protection and a "source" and "destination" role for
>2> control of end-to-end restoration and for reversion.  We believe
>2> that "source" and "destination" mean the initiator and receiver
>2> of the LSP (as opposed to the source and destination of data
>2> in-band).

The terms "source" and "destination" are standard.

For unidirectional LSPs, the "source" is the source of data on the LSP,
also known as he ingress. Where a control plane is used, signaling 
progresses from the source (also known as the head-end).

Similarly, the "destination" is the destination of data on the LSP, also
known as the egress. Where a control plane is used, signaling progresses
from the source to the destination (also known as the tail-end).

By common convention, for bidirectional LSPs set up by the control
plane, the "source" remains the signaling source (ingress) and the
"destination" is the signaling destination (egress). Traffic flowing
in the reverse direction is referred to as reverse direction traffic
and flows from destination to source.

Very probably there is an ITU-T architectural term for these end points
of LSPs.

Note that RFC 4426 is very careful to state:
   The end-to-end recovery models discussed in this
   document apply to segment protection where the source and destination
   refer to the protected segment rather than the entire LSP.

Should this still be unclear to you, RFC4426 section 1 states
   Consider the control plane message flow during the establishment of
   an LSP.  This message flow proceeds from an initiating (or source)
   node to a terminating (or destination) node, via a sequence of
   intermediate nodes.  A node along the LSP is said to be "upstream"
   from another node if the former occurs first in the sequence.  The
   latter node is said to be "downstream" from the former node.  That
   is, an "upstream" node is closer to the initiating node than a node
   further "downstream".  Unless otherwise stated, all references to
   "upstream" and "downstream" are in terms of the control plane message
   flow.

The terms "master" and "slave" are introduced to describe the trigger
points for protection activity and are defined clearly in section 2.3
of RFC4426.
   Consider two adjacent nodes, A and B.  Under 1:1 protection, a
   dedicated link j between A and B is pre-assigned to protect working
   link i.  Link j may be carrying (pre-emptable) Extra Traffic.  A
   failure affecting link i results in the corresponding LSP(s) being
   restored to link j.  Extra Traffic being routed over link j may need
   to be pre-empted to accommodate the LSPs that have to be restored.

   Once a fault is isolated/localized, the affected LSP(s) must be moved
   to the protection link.  The process of moving an LSP from a failed
   (working) link to a protection link must be initiated by one of the
   nodes, A or B.  This node is referred to as the "master".  The other
   node is called the "slave".  The determination of the master and the
   slave may be based on configured information or protocol specific
   requirements.

Thus, the "master" is responsible for initiating the switchover, and the
slave is responsible for keeping up with the state changes.

>1> Further, it would be helpful to understand why the actions are
>1> performed by source and destination nodes rather than master and
>1> slave nodes. It may be appropriate to reuse the master/slave roles
>1> in the reversion process just as is done in the switchover process.

>2> We are not clear on the rationale for when control
>2> plane roles are based on master/slave vs. source/destination:
>2> it appears that local span actions are controlled using
>2> master/slave while remote actions are controlled using
>2> source/destination, however the reasoning for control of
>2> reversion is less clear to us.  Any clarification of the
>2> rationale for using master/slave vs. source/destination
>2> control would be appreciated.

As explained by the definitions of the terms, there is a distinction
between the node that invokes a switchover process (the master) and a
node that performs the process. For example, a Bridge and Switch Request
message is sent by the source node after it has bridged traffic back to 
both working and protection links simply because the source node has 
performed the bridging and is the only node that can know this fact.

In other words, whether the source is master or slave depends on the
protection scheme in use and the nature of the operation. It should be
a simple matter when considering a protection scheme and the necessary
protocol exchanges and switchover actions to determine which of the
source and destination must play the master or slave role.

>1> In addition, RFC 4426 does not include an abstract message similar
>1> to the Failure Indication Message to request the beginning of the
>1> reversion procedure. It may be beneficial to include a message from
>1> the slave device to initiate reversion, just as there is a Failure
>1> Indication Message to initiate switchover. (RFC 4426 states that the
>1> Failure Indication Message may not be needed when the transport 
>1> plane technology itself provides such a notification. The same may
>1> apply when a failure is cleared; however, there should still be an
>1> optional message to trigger the reversion process.)

>2> 6) We believe that it may be useful in some cases of reversion to
>2> allow a "slave" device to request reversion using an abstract 
>2> message similar to the Failure Indication Message.  An example
>2> case is (again) when the "master" and "slave" devices are in
>2> different management domains, such that reversion is initiated from
>2> the management domain of the "slave" device.  We request CCAMP 
>2> comment on this suggestion.

Reversion is described as an administrative procedure in RFC4426 and
RFC4427 quite deliberately. In our view it should not be a rapid 
response to a specific situation triggered through the control plane
by the 'master', but should be a considered operation under the control
of administrative policy. The trigger is, therefore, outside the scope 
of the control plane. This discussion can be seen in section 4.13 of 
RFC4427.

We believe that your suggestion does not change this view, but that you
are proposing that the control plane be used as a transport for a 
management plane request. You are suggesting that a management station
in the management domain that contains the slave sends the request to 
the slave, the slave would then deliver the request through the control
plane to the master. In the absence of any specific control plane
requirement for this message, we believe that the correct architectural
approach is for management plane messages to be delivered in the 
management plane. Thus, if there is a need for management plane 
coordination between separate management plane domains, this should be
arranged through an appropriate management plane peering point where 
the correct policies can be applied.


We hope this answers your questions, and we would be happy to enter into
further dialog on these topics.

In conclusion, it may be helpful to the OIF to know the status of two
CCAMP drafts related to recovery.
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and
draft-ietf-ccamp-gmpls-segment-recovery-02 both completed CCAMP
working group last call in early 2005. Since then they have been
implemented and tested. The drafts are stable and complete, and are
queued in the IETF process waiting to become RFCs



Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs




Envelope-to: [e-mail]
Delivery-date: Wed, 07 Jun 2006 14:22:25 +0000
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail], [e-mail]
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routing loops
Date: Wed, 7 Jun 2006 10:20:22 -0400
To: Greg Bernstein <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l$13; t49690028; x50554028; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:JP Vasseur <[e-mail]> |Subject:Re: [Pce] Virtual Network Topology (VNT) changes and I P layer routing loops; X=v=cisco.com; h=4WLiFWjDUNLvTOSsgm7b6ade6MA=; b=Pf843R8r0aQsi9LZR4oqi8AhT+1SmubLcC1hLrc5B9WXNUe6kFtAiuWy/nwzKWnjArB33m2L bLO7CQIXX5dCGuuUrUDZdEAHlbEuWnDFTrhoGiCDQRsyRaSpDx89MePZ;
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

Hi Greg,

Thanks for your note. I just wanted to add that this is no different  
from IGP Link weight tuning and off-line algorithms/heuristics  
computing link costs already take such constraint into account. One  
can expect an PCE implementation for VNT computation to also take  
such constraint into account.

Cheers,

JP.

On Jun 5, 2006, at 12:17 PM, Greg Bernstein wrote:

> Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt and  
> draft-ietf-pce-inter-layer-frwk-00.txt the concepts of multi-layer  
> and multi-region networking are defined and discussed.
> An important case is when the IP layer rests directly upon a  
> "virtual network topology" layer that we will desire to change via  
> GMPLS signaling. Changes to the IP layer VNT can produce "transient  
> IP layer routing loops" also known as "micro loops" which can last  
> 100's of mili seconds or more.  Hence any time we change a  
> connection between IP layer routers via GMPLS we can cause  
> significant outages compared to the recovery times that we set out  
> to achieve with GMPLS fast reroute and other mechanisms such as SDH  
> APS (rings and linear).
>
> At the Routing working group, Alex's draft draft-ietf-rtgwg- 
> microloop-analysis-01.txt provides some analysis and a method to  
> reduce the impact (duration too) of the transient loops.  More  
> recently the drafts:
> (1) draft-bryant-shand-lf-applicability-01.txt
> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
> (3) draft-francois-ordered-fib-01.txt
> Address this problem more generally including in (3) a method that  
> guarantee loop free convergence.
>
> The problem is that these have generated very little interest at  
> the RTG WG and may not move forward.  This area is not within PCE  
> or CCAMPs charter but can have an impact on the adoption of GMPLS  
> in multi-layer/region networking. If you're interested please take  
> a look and comment to the RTG WG.  Note I wasn't involved with  
> writing these, but came across them when considering the effects of  
> GMPLS changes on the IP layer VNT.
>
> Thanks
>
> Greg B.
>
> -- 
> =========================> Dr Greg Bernstein, Grotto Networking [phone]
>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pce



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Jun 2006 02:34:27 +0000
Message-ID: <[e-mail]>
Date: Wed, 07 Jun 2006 11:31:20 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: Greg Bernstein <[e-mail]>
CC: Don Fedyk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Greg

Thank you for your reply.

> Hi Kohei,  For the folks who haven't read the "micro-loop" drafts. These 
> describe transient loops that can occur at the IP layer or in MPLS with 
> LDP. In the GMPLS world we may also use the term LSP somewhat loosely to 
> apply to SDH, WDM, G.709 connections. Since these are all explicitly 
> routed (and due to their circuit switched nature too) we won't get loops 
> at these layers.

I just meant to explicit-routed LSP in MPLS domain over VNT in the
previous email.

> 
> However, when we use GMPLS to set up a new SDH, WDM, G.709, etc... 
> connection (or tear down a connection) between IP routers (modifying the 
> IP layer VNT) this looks like a link up or down "maintenance" action to 
> the IP layer and hence the issue with micro-loops so well described in 
> the drafts.

Yes. I called it VNT reconfiguration in the previous email. Either IP
datagram or MPLS labeled packet can be forwarded over the VNT. If we use
the explicit routed LSP to forward the MPLS labeled packet, we can
control the route to avoid micro-loop before the VNT changes.

Of course we need a micro-loop avoidance mechanism when we carry IP
datagram packet directly over the VNT. Such issue need to be addressed
in the future revision in the MLN docs and the Inter-layer PCE/VNT
manager docs.

Thanks,
--
Kohei

> 
> Regards
> 
> Greg B.
> 
> Kohei Shiomoto wrote:
> 
>> Hi Greg
>>
>> Thank you for your kind notice.
>>
>> I think that the avoiding micro-loop is an important work. Micro-loop
>> could unnecessarily amplify traffic load as much as 128 times, which
>> should be a serious problem for today's wire-speed packet forwarding at
>> high-speed link.
>>
>> So far micro-loop avoidance has been discussed in the context of
>> maintenance operations including link install/removal, IGP link cost
>> change, etc. As you pointed out, micro-loop may form in the process of
>> VNT reconfiguration if IP datagram is forwarded directly on top of VNT
>> (if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop
>> avoidance should also be considered in the context of VNT 
>> reconfiguration.
>>
>> Thank you again for your pointer.
>> -- 
>> Kohei
>>
>>
>> Greg Bernstein wrote:
>>
>>  
>>
>>> Hi Don, I'm using the term "Virtual Network Topology" related to the 
>>> data plane not the control plane.  For example, when I interconnect 
>>> IP routers via a WDM or SDH switching layer the resulting IP layer 
>>> topology is termed a "virtual network topology" since the 
>>> connectivity amongst the IP routers is not necessarily the same as 
>>> the fiber topology. It is these changes to the IP layer topology that 
>>> can cause the traffic disrupting micro loops.  Note that other ways 
>>> that micro loops occur are: (1) during IGP link weight adjustments 
>>> and (2) maintenance operations.
>>>
>>> The connection to GMPLS/PCE is we are trying to make setting up these 
>>> virtual topologies quicker and potential for traffic engineering 
>>> purposes. There have been some good papers in the literature on using 
>>> GMPLS and advanced algorithms for the VNT design problem.
>>>
>>> Greg B.
>>>
>>> Don Fedyk wrote:
>>>
>>>    
>>>
>>>> Hi Greg
>>>>
>>>> Whoa....
>>>>   [Snip]
>>>> 1) These virtual topologies are for control traffic and they are solid
>>>> most of the time.
>>>> 2) The existing data traffic is not disrupted when the control traffic
>>>> has microloops. 3) There may be a delay in signaling of new or 
>>>> rerouted connections when
>>>> the control traffic has microloops. This is analogous to Graceful
>>>> recovery of the control plane where the data plane is momentarily 
>>>> unable
>>>> to adapt to new changes.
>>>> 4) Many of the optical technologies we have do not need response to
>>>> signaling in less than 100s of milliseconds so the delay is not
>>>> critical.
>>>> 5) We need a clear separation of protection which can be locally driven
>>>> and fast (50 msec) and routing and rerouting which are slower
>>>> restoration mechanisms. As long as protection mechanisms are 
>>>> independent
>>>> of the control plane primary protection is safe IMHO.
>>>>
>>>>
>>>>  
>>>>
>>>>      
>>>>
>>>>> At the Routing working group, Alex's draft 
>>>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis 
>>>>> and a method to reduce the impact (duration too) of the transient 
>>>>> loops.  More recently the drafts:
>>>>> (1) draft-bryant-shand-lf-applicability-01.txt
>>>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
>>>>> (3) draft-francois-ordered-fib-01.txt
>>>>> Address this problem more generally including in (3) a method that 
>>>>> guarantee loop free convergence.
>>>>>
>>>>>             
>>>>
>>>> Loop Free Alternates are a good thing.  But with more advanced
>>>> mechanisms it is very hard to determine if the cure is worse than the
>>>> symptoms.
>>>>
>>>>
>>>>  
>>>>
>>>>      
>>>>
>>>>> The problem is that these have generated very little interest at 
>>>>> the RTG WG and may not move forward.  This area is not within PCE 
>>>>> or CCAMPs charter but can have an impact on the adoption of GMPLS 
>>>>> in multi-layer/region networking. If you're interested please take 
>>>>> a look and comment to the RTG WG.  Note I wasn't involved with 
>>>>> writing these, but came across them when considering the effects of 
>>>>> GMPLS changes on the IP layer VNT.
>>>>>             
>>>>
>>>> There was a lot of interest and a genuine amount of push back.
>>>> Personally I would be very concerned about tight coupling of a control
>>>> plane convergence to impacts on a GMPLS control data plane.
>>>> Regards,
>>>> Don
>>>>
>>>>  
>>>>
>>>>      
>>>>
>>>>> Thanks
>>>>>
>>>>> Greg B.
>>>>>
>>>>> -- 
>>>>> =========================>>>>> Dr Greg Bernstein, Grotto Networking [phone]
>>>>>             
>>>>
>>>>
>>>>         
>>>
>>>     
>>
>>
>>
>>   
> 
> 


-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan




Envelope-to: [e-mail]
Delivery-date: Wed, 07 Jun 2006 01:05:29 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Jun 2006 17:54:58 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Kohei Shiomoto <[e-mail]>
CC: Don Fedyk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Kohei,  For the folks who haven't read the "micro-loop" drafts. These 
describe transient loops that can occur at the IP layer or in MPLS with 
LDP. In the GMPLS world we may also use the term LSP somewhat loosely to 
apply to SDH, WDM, G.709 connections. Since these are all explicitly 
routed (and due to their circuit switched nature too) we won't get loops 
at these layers.

However, when we use GMPLS to set up a new SDH, WDM, G.709, etc... 
connection (or tear down a connection) between IP routers (modifying the 
IP layer VNT) this looks like a link up or down "maintenance" action to 
the IP layer and hence the issue with micro-loops so well described in 
the drafts.

Regards

Greg B.

Kohei Shiomoto wrote:
> Hi Greg
>
> Thank you for your kind notice.
>
> I think that the avoiding micro-loop is an important work. Micro-loop
> could unnecessarily amplify traffic load as much as 128 times, which
> should be a serious problem for today's wire-speed packet forwarding at
> high-speed link.
>
> So far micro-loop avoidance has been discussed in the context of
> maintenance operations including link install/removal, IGP link cost
> change, etc. As you pointed out, micro-loop may form in the process of
> VNT reconfiguration if IP datagram is forwarded directly on top of VNT
> (if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop
> avoidance should also be considered in the context of VNT reconfiguration.
>
> Thank you again for your pointer.
> --
> Kohei
>
>
> Greg Bernstein wrote:
>
>   
>> Hi Don, I'm using the term "Virtual Network Topology" related to the 
>> data plane not the control plane.  For example, when I interconnect IP 
>> routers via a WDM or SDH switching layer the resulting IP layer topology 
>> is termed a "virtual network topology" since the connectivity amongst 
>> the IP routers is not necessarily the same as the fiber topology. It is 
>> these changes to the IP layer topology that can cause the traffic 
>> disrupting micro loops.  Note that other ways that micro loops occur 
>> are: (1) during IGP link weight adjustments and (2) maintenance operations.
>>
>> The connection to GMPLS/PCE is we are trying to make setting up these 
>> virtual topologies quicker and potential for traffic engineering 
>> purposes. There have been some good papers in the literature on using 
>> GMPLS and advanced algorithms for the VNT design problem.
>>
>> Greg B.
>>
>> Don Fedyk wrote:
>>
>>     
>>> Hi Greg
>>>
>>> Whoa....
>>>   [Snip]
>>> 1) These virtual topologies are for control traffic and they are solid
>>> most of the time.
>>> 2) The existing data traffic is not disrupted when the control traffic
>>> has microloops. 3) There may be a delay in signaling of new or 
>>> rerouted connections when
>>> the control traffic has microloops. This is analogous to Graceful
>>> recovery of the control plane where the data plane is momentarily unable
>>> to adapt to new changes.
>>> 4) Many of the optical technologies we have do not need response to
>>> signaling in less than 100s of milliseconds so the delay is not
>>> critical.
>>> 5) We need a clear separation of protection which can be locally driven
>>> and fast (50 msec) and routing and rerouting which are slower
>>> restoration mechanisms. As long as protection mechanisms are independent
>>> of the control plane primary protection is safe IMHO.
>>>
>>>
>>>  
>>>
>>>       
>>>> At the Routing working group, Alex's draft 
>>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and 
>>>> a method to reduce the impact (duration too) of the transient loops.  
>>>> More recently the drafts:
>>>> (1) draft-bryant-shand-lf-applicability-01.txt
>>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
>>>> (3) draft-francois-ordered-fib-01.txt
>>>> Address this problem more generally including in (3) a method that 
>>>> guarantee loop free convergence.
>>>>
>>>>     
>>>>         
>>> Loop Free Alternates are a good thing.  But with more advanced
>>> mechanisms it is very hard to determine if the cure is worse than the
>>> symptoms.
>>>
>>>
>>>  
>>>
>>>       
>>>> The problem is that these have generated very little interest at the 
>>>> RTG WG and may not move forward.  This area is not within PCE or 
>>>> CCAMPs charter but can have an impact on the adoption of GMPLS in 
>>>> multi-layer/region networking. If you're interested please take a 
>>>> look and comment to the RTG WG.  Note I wasn't involved with writing 
>>>> these, but came across them when considering the effects of GMPLS 
>>>> changes on the IP layer VNT.
>>>>     
>>>>         
>>> There was a lot of interest and a genuine amount of push back.
>>> Personally I would be very concerned about tight coupling of a control
>>> plane convergence to impacts on a GMPLS control data plane.
>>> Regards,
>>> Don
>>>
>>>  
>>>
>>>       
>>>> Thanks
>>>>
>>>> Greg B.
>>>>
>>>> -- 
>>>> =========================>>>> Dr Greg Bernstein, Grotto Networking [phone]
>>>>     
>>>>         
>>>
>>>   
>>>       
>>     
>
>
>   

-- 
=========================Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jun 2006 23:13:46 +0000
Message-ID: <[e-mail]>
Date: Wed, 07 Jun 2006 08:11:35 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: Greg Bernstein <[e-mail]>
CC: Don Fedyk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Greg

Thank you for your kind notice.

I think that the avoiding micro-loop is an important work. Micro-loop
could unnecessarily amplify traffic load as much as 128 times, which
should be a serious problem for today's wire-speed packet forwarding at
high-speed link.

So far micro-loop avoidance has been discussed in the context of
maintenance operations including link install/removal, IGP link cost
change, etc. As you pointed out, micro-loop may form in the process of
VNT reconfiguration if IP datagram is forwarded directly on top of VNT
(if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop
avoidance should also be considered in the context of VNT reconfiguration.

Thank you again for your pointer.
--
Kohei


Greg Bernstein wrote:

> Hi Don, I'm using the term "Virtual Network Topology" related to the 
> data plane not the control plane.  For example, when I interconnect IP 
> routers via a WDM or SDH switching layer the resulting IP layer topology 
> is termed a "virtual network topology" since the connectivity amongst 
> the IP routers is not necessarily the same as the fiber topology. It is 
> these changes to the IP layer topology that can cause the traffic 
> disrupting micro loops.  Note that other ways that micro loops occur 
> are: (1) during IGP link weight adjustments and (2) maintenance operations.
> 
> The connection to GMPLS/PCE is we are trying to make setting up these 
> virtual topologies quicker and potential for traffic engineering 
> purposes. There have been some good papers in the literature on using 
> GMPLS and advanced algorithms for the VNT design problem.
> 
> Greg B.
> 
> Don Fedyk wrote:
> 
>> Hi Greg
>>
>> Whoa....
>>   [Snip]
>> 1) These virtual topologies are for control traffic and they are solid
>> most of the time.
>> 2) The existing data traffic is not disrupted when the control traffic
>> has microloops. 3) There may be a delay in signaling of new or 
>> rerouted connections when
>> the control traffic has microloops. This is analogous to Graceful
>> recovery of the control plane where the data plane is momentarily unable
>> to adapt to new changes.
>> 4) Many of the optical technologies we have do not need response to
>> signaling in less than 100s of milliseconds so the delay is not
>> critical.
>> 5) We need a clear separation of protection which can be locally driven
>> and fast (50 msec) and routing and rerouting which are slower
>> restoration mechanisms. As long as protection mechanisms are independent
>> of the control plane primary protection is safe IMHO.
>>
>>
>>  
>>
>>> At the Routing working group, Alex's draft 
>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and 
>>> a method to reduce the impact (duration too) of the transient loops.  
>>> More recently the drafts:
>>> (1) draft-bryant-shand-lf-applicability-01.txt
>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
>>> (3) draft-francois-ordered-fib-01.txt
>>> Address this problem more generally including in (3) a method that 
>>> guarantee loop free convergence.
>>>
>>>     
>>
>>
>> Loop Free Alternates are a good thing.  But with more advanced
>> mechanisms it is very hard to determine if the cure is worse than the
>> symptoms.
>>
>>
>>  
>>
>>> The problem is that these have generated very little interest at the 
>>> RTG WG and may not move forward.  This area is not within PCE or 
>>> CCAMPs charter but can have an impact on the adoption of GMPLS in 
>>> multi-layer/region networking. If you're interested please take a 
>>> look and comment to the RTG WG.  Note I wasn't involved with writing 
>>> these, but came across them when considering the effects of GMPLS 
>>> changes on the IP layer VNT.
>>>     
>>
>>
>> There was a lot of interest and a genuine amount of push back.
>> Personally I would be very concerned about tight coupling of a control
>> plane convergence to impacts on a GMPLS control data plane.
>> Regards,
>> Don
>>
>>  
>>
>>> Thanks
>>>
>>> Greg B.
>>>
>>> -- 
>>> =========================>>> Dr Greg Bernstein, Grotto Networking [phone]
>>>     
>>
>>
>>
>>   
> 
> 


-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories




Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 21:10:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688E4.5DFF6140"
Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 5 Jun 2006 16:09:43 -0500
Message-ID: <[e-mail]>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaI5F2W4YawH5vOSeW8BFFL//gd9w=
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C688E4.5DFF6140
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
 
As discussed at the last CCAMP meeting, the authors of this draft would
like the draft to be considered for WG Last Call. Although it appears to
be a 00 draft, the material was previously in
draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one implementation
exists.
 
This email begins a two week Working Group Last Call on the draft:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00
.txt
 
The last call will complete on June 19th at 9PM EST.
 
Comments should be addressed to the mailing list or, if anonymity is
preferred, to me. On a point of procedure, as both Adrian and myself are
co-authors, anyone who has an issue with this draft going to WG Last
Call should contact one of our ADs, Ross ([e-mail]) or Bill
([e-mail]).
 
Thanks,
Deborah
 

------_=_NextPart_001_01C688E4.5DFF6140
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=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>As discussed at the 
last CCAMP meeting, the authors of this draft would like the draft to be 
considered for WG Last Call. Although&nbsp;it appears to be a 00 draft, the 
material was previously in draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one 
implementation exists.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>This email begins a 
two week Working Group Last Call on the draft:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006><A 
href="ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>The last call will 
complete on June 19th at 9PM EST.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=906582120-05062006>Comments should be 
addressed to the mailing list or, if anonymity is preferred, to me. On a point 
of procedure, as both Adrian and myself are co-authors, anyone who has an issue 
with this draft&nbsp;going to WG Last Call should&nbsp;contact one of our ADs, 
Ross (<A href="mailto:[e-mail]">[e-mail]</A>) or Bill (<A 
href="mailto:[e-mail]">[e-mail]</A>).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006>Deborah</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=906582120-05062006></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C688E4.5DFF6140--



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 20:13:25 +0000
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 13:10:45 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Don, I'm using the term "Virtual Network Topology" related to the 
data plane not the control plane.  For example, when I interconnect IP 
routers via a WDM or SDH switching layer the resulting IP layer topology 
is termed a "virtual network topology" since the connectivity amongst 
the IP routers is not necessarily the same as the fiber topology. It is 
these changes to the IP layer topology that can cause the traffic 
disrupting micro loops.  Note that other ways that micro loops occur 
are: (1) during IGP link weight adjustments and (2) maintenance operations.

The connection to GMPLS/PCE is we are trying to make setting up these 
virtual topologies quicker and potential for traffic engineering 
purposes. There have been some good papers in the literature on using 
GMPLS and advanced algorithms for the VNT design problem.

Greg B.

Don Fedyk wrote:
> Hi Greg
>
> Whoa.... 
>
>   
> [Snip]
> 1) These virtual topologies are for control traffic and they are solid
> most of the time.
> 2) The existing data traffic is not disrupted when the control traffic
> has microloops. 
> 3) There may be a delay in signaling of new or rerouted connections when
> the control traffic has microloops. This is analogous to Graceful
> recovery of the control plane where the data plane is momentarily unable
> to adapt to new changes.
> 4) Many of the optical technologies we have do not need response to
> signaling in less than 100s of milliseconds so the delay is not
> critical.
> 5) We need a clear separation of protection which can be locally driven
> and fast (50 msec) and routing and rerouting which are slower
> restoration mechanisms. As long as protection mechanisms are independent
> of the control plane primary protection is safe IMHO.
>
>
>   
>> At the Routing working group, Alex's draft 
>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some 
>> analysis and a method to reduce the impact (duration too) of 
>> the transient loops.  More recently the drafts:
>> (1) draft-bryant-shand-lf-applicability-01.txt
>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
>> (3) draft-francois-ordered-fib-01.txt
>> Address this problem more generally including in (3) a method 
>> that guarantee loop free convergence.
>>
>>     
>
> Loop Free Alternates are a good thing.  But with more advanced
> mechanisms it is very hard to determine if the cure is worse than the
> symptoms.
>
>
>   
>> The problem is that these have generated very little interest 
>> at the RTG WG and may not move forward.  This area is not 
>> within PCE or CCAMPs charter but can have an impact on the 
>> adoption of GMPLS in multi-layer/region networking. If you're 
>> interested please take a look and comment to the RTG WG.  
>> Note I wasn't involved with writing these, but came across 
>> them when considering the effects of GMPLS changes on the IP 
>> layer VNT.
>>     
>
> There was a lot of interest and a genuine amount of push back.
> Personally I would be very concerned about tight coupling of a control
> plane convergence to impacts on a GMPLS control data plane. 
>
> Regards,
> Don 
>
>
>   
>> Thanks
>>
>> Greg B.
>>
>> --
>> =========================>> Dr Greg Bernstein, Grotto Networking [phone]
>>     
>
>
>   

-- 
=========================Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 19:58:29 +0000
Message-ID: <14af01c6888a$d21195b0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Proposed response to OIF on GMPLS for Ethernet
Date: Mon, 5 Jun 2006 11:27:59 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Having assembled comments from several people, and having trawled the CCAMP
archive for discussions on these very points, we have put together the
following response to the OIF.

Please comment on the list in the next week or so.

Thanks,
Adrian and Deborah

=
 Dear Jim,

Thank you for bringing the concerns of your technical committee with
respect to the use of GMPLS to support Ethernet access to our attention.

We are happy to be consulted on this type of issue although we would like to
point out the inherent inefficiencies of communicating like this. We feel it
would be far smoother, more rapid, and more conducive for constructive
dialogue if your members raised these types of question direct to the CCAMP
mailing list. The CCAMP mailing list is open to everyone at no cost.
Subscription details can be found at the CCAMP charter page:
http://www.ietf.org/html.charters/ccamp-charter.html

> During our discussion of protocol requirements to support Ethernet
> services over optical networks, we identified some issues where
> application of the GMPLS specifications were not clear to us. We request
> CCAMP's views on the following issues:
>
> 1. Use of parameters to distinguish port-based vs. VLAN-tag-based
> forwarding of Ethernet frames
>
> We have identified two variations on support of Ethernet services at the
> network access point:
>
> a) in the first variation, received frames are forwarded into a specific
> SONET/SDH path based on the incoming port, without processing the header
> information in the Ethernet frame; and
>
> b) in the second variation, received frames are forwarded into specific
> SONET/SDH paths based on header information, esp. the VLAN tag.

When you say "forwarded into a specific SONET/SDH path" we presume that you
mean "adapted into". In fact, at the Ethernet layer, the SONET/SDH path is
simply providing a virtual Ethernet link, and it is at this layer that you
wish to set up Ethernet switching. Your questions, we assume, apply to how
to identify the switching quantity in an Ethernet switching network, and are
not related to the adaptation mechanisms, although the adaptation function
may also require to know how to identify the particular Ethernet flow within
an Ethernet port.

> It is not fully clear to us how these are distinguished in GMPLS
> signaling, especially forwarding behavior (a) above.
>
> The closest match that was identified was to use the following approach:
> - use the Switching Type value of "FSC" to indicate forwarding based on
>   port; and
> - use the Switching Type value of "L2SC" to indicate forwarding based on
>   the L2 protocol header of received frames.
>
> However, we feel that neither FSC nor L2SC exactly expresses behavior (a)
> above. In particular, "FSC" can also be interpreted as meaning that the
> signal received on the fiber is forwarded exactly as received, in its
> entirety, independent of the signal type (SONET, Ethernet, or other).
>
> We request CCAMP comment on whether this approach is the correct
> interpretation of the specifications or if an alternative and/or
> supplemental mechanism should be considered.

FSC would, indeed, be incorrect. It is used for spatial switching.

You are switching layer 2 packets. That means that the switching type must
be L2SC. The fact that all layer two packets received on a port are switched
in the same way is not material.

May we draw your attention to
draft-ietf-ccamp-ethernet-traffic-parameters-00.txt. We believe that this
draft was mentioned during your meeting in the report on IETF activity, and
it is particularly relevant to this question. It can be downloaded free of
charge from
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt

You will observe in section  that the Sender_TSpec object includes a
Switching Granularity field defined as follows:

     Switching Granularity (SG): 16 bits

This field indicates the type of link that comprises the requested Ethernet
LSP.

      The permitted Ethernet Link Type values:
           Value   Switching Granularity
           -----   ---------------------
           1       Ethernet Port
           2       Ethernet Frame

      Value 0 is reserved. Values 1 through 127 are assigned by IANA via
      IETF Standards Track RFC action.

      Values 128 through 255 are reserved for vendor specific usage.

> 2. Use of Label for these cases
>
> In addition to the question on the use of Switching Capability, it was not
> clear what value should be used as the Generalized Label for these cases.

You should note that labels are a local matter between neighbors. That is,
and in particular, port identifiers may be local information shared between
neighbors and does not need to have global scope.

> For case (a) above, our current assumption is that the Label reflects the
> affected port, however it was noted that this may duplicate information in
> the RSVP_HOP Interface Index sub-TLV.

If the port is identified as an IP numbered or unnumbered interface, then
you are correct that using the port identifier as the label will duplicate
the information carried in the RSVP_HOP object. Can you clarify why this
duplication is a concern to you?

On the other hand, if multiple ports are assembled as a single interface,
or if the ports are given a local, non-IP identification, there is a clear
separation between the quantities.

> For case (b) above it seems logical that the Label reflect the affected
> VLAN tags.

Indeed. The label always represents the switching quantity.

> We are investigating label formats to represent a list or range of VLAN
> identifiers, as used in MEF.11 bundling. In the case where a large number
> of non-consecutive VLAN identifiers is used for the same connection, we
> would like to keep the label to a reasonable size.

'Large number' and 'reasonable' are impossible for us to quantify without
further discussion with you. It seems to us, however, that if the
information needs to be known by both neighbors, there is little alternative
to communicating the information between the neighbors. Whether this is done
mainly through the management plane with a label identifying a preconfigured
combination of VLAN identifiers (i.e. a MEF bundle), through the control
plane using GMPLS link bundling, through the control plane using extended
(concatenated) labels as in TDM virtual concatenation, or through dynamic
control plan virtual concatenation techniques, is clearly an implementation
choice and may be an appropriate work area for the OIF. We would certainly
be interested to hear your conclusions.

> In the case of bi-directional connections, the UPSTREAM_LABEL is used
> to indicate the connection is bi-directional. The LABEL_SET is then used
> if there is a need for the labels to be identical in both directions. In
> that
> case, there is a redundancy of labels. That is problematic with large
> label
> formats.

Redundancy of information is not an issue, per se. In fact, since there is
a possibility to require the use of different labels in each direction, the
objects themselves are not redundant.

The issue with the size of label is interesting. If there is a proposal to
use labels so large than the inclusion of two of them in a signaling message
is significant issue then we would strongly suggest that the label format is
wrong. (Note that your requirement here is only to carry two labels, one in
the Upstream Label object and one in the Label Set object.)

> We would appreciate your advice regarding the possibility to reduce the
> number of labels required in the case of bi-directional connections where
> the label is the same in both directions.

Assuming that 'reduce the number of labels' means 'reduce from two to one'
we appreciate that there is a minor optimisation possible in this specific
case, but suggest that it would be better to examine the underlying problem
of label size since there will be cases of asymmetrical bidirectional LSPs
where it is necessary to carry both labels.

Hoping that this answers your questions.

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs 





Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 18:39:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Date: Mon, 5 Jun 2006 14:38:34 -0400
Message-ID: <[e-mail]>
Thread-Topic: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Thread-Index: AcaIu5iEb+JIM5PjSJeSLES9IYXNVwAERA9w
From: "Don Fedyk" <[e-mail]>
To: "Greg Bernstein" <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Greg

Whoa.... 

> -----Original Message-----
> From: Greg Bernstein [mailto:[e-mail]] 
> Sent: Monday, June 05, 2006 12:17 PM
> To: [e-mail]; [e-mail]
> Subject: [Pce] Virtual Network Topology (VNT) changes and IP 
> layer routingloops
> 
> Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt 
> and draft-ietf-pce-inter-layer-frwk-00.txt the concepts of 
> multi-layer and multi-region networking are defined and discussed. 
> 
> An important case is when the IP layer rests directly upon a 
> "virtual network topology" layer that we will desire to 
> change via GMPLS signaling. Changes to the IP layer VNT can 
> produce "transient IP layer routing loops" also known as 
> "micro loops" which can last 100's of mili seconds or more.  
> Hence any time we change a connection between IP layer 
> routers via GMPLS we can cause significant outages compared 
> to the recovery times that we set out to achieve with GMPLS 
> fast reroute and other mechanisms such as SDH APS (rings and linear).

1) These virtual topologies are for control traffic and they are solid
most of the time.
2) The existing data traffic is not disrupted when the control traffic
has microloops. 
3) There may be a delay in signaling of new or rerouted connections when
the control traffic has microloops. This is analogous to Graceful
recovery of the control plane where the data plane is momentarily unable
to adapt to new changes.
4) Many of the optical technologies we have do not need response to
signaling in less than 100s of milliseconds so the delay is not
critical.
5) We need a clear separation of protection which can be locally driven
and fast (50 msec) and routing and rerouting which are slower
restoration mechanisms. As long as protection mechanisms are independent
of the control plane primary protection is safe IMHO.


> 
> At the Routing working group, Alex's draft 
> draft-ietf-rtgwg-microloop-analysis-01.txt provides some 
> analysis and a method to reduce the impact (duration too) of 
> the transient loops.  More recently the drafts:
> (1) draft-bryant-shand-lf-applicability-01.txt
> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
> (3) draft-francois-ordered-fib-01.txt
> Address this problem more generally including in (3) a method 
> that guarantee loop free convergence.
> 

Loop Free Alternates are a good thing.  But with more advanced
mechanisms it is very hard to determine if the cure is worse than the
symptoms.


> The problem is that these have generated very little interest 
> at the RTG WG and may not move forward.  This area is not 
> within PCE or CCAMPs charter but can have an impact on the 
> adoption of GMPLS in multi-layer/region networking. If you're 
> interested please take a look and comment to the RTG WG.  
> Note I wasn't involved with writing these, but came across 
> them when considering the effects of GMPLS changes on the IP 
> layer VNT.

There was a lot of interest and a genuine amount of push back.
Personally I would be very concerned about tight coupling of a control
plane convergence to impacts on a GMPLS control data plane. 

Regards,
Don 


> 
> Thanks
> 
> Greg B.
> 
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 16:18:07 +0000
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 09:17:24 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Virtual Network Topology (VNT) changes and IP layer routing loops
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt and 
draft-ietf-pce-inter-layer-frwk-00.txt the concepts of multi-layer and 
multi-region networking are defined and discussed. 

An important case is when the IP layer rests directly upon a "virtual 
network topology" layer that we will desire to change via GMPLS 
signaling. Changes to the IP layer VNT can produce "transient IP layer 
routing loops" also known as "micro loops" which can last 100's of mili 
seconds or more.  Hence any time we change a connection between IP layer 
routers via GMPLS we can cause significant outages compared to the 
recovery times that we set out to achieve with GMPLS fast reroute and 
other mechanisms such as SDH APS (rings and linear).

At the Routing working group, Alex's draft 
draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and a 
method to reduce the impact (duration too) of the transient loops.  More 
recently the drafts:
(1) draft-bryant-shand-lf-applicability-01.txt
(2) draft-bryant-shand-lf-conv-frmwk-02.txt
(3) draft-francois-ordered-fib-01.txt
Address this problem more generally including in (3) a method that 
guarantee loop free convergence.

The problem is that these have generated very little interest at the RTG 
WG and may not move forward.  This area is not within PCE or CCAMPs 
charter but can have an impact on the adoption of GMPLS in 
multi-layer/region networking. If you're interested please take a look 
and comment to the RTG WG.  Note I wasn't involved with writing these, 
but came across them when considering the effects of GMPLS changes on 
the IP layer VNT.

Thanks

Greg B.

-- 
=========================Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 15:34:11 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:X-RocketDSI:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sse+W8bw4KL98gQpwaq6cca6q24uauBO86/+ze7krLmqp0ERV7cfAXmyD0AbH7qXMXfgqzRKo7bhcGcexRbXvpMH5NrjETUfnkMupQmbZH2Vrk5PQfLJodf8OwyummHyoY79BxRrURmAanzojwowMgmVXe16KAAKoE3voY14GSk=  ;
Message-ID: <[e-mail]>
Date: Mon, 5 Jun 2006 08:28:27 -0700 (PDT)
From: =?iso-8859-1?q?jerald lawal?= <[e-mail]>
Reply-To: [e-mail]
Subject: CONFIDENTIAL TRANSFER !!
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1216701838-1149521307=:97780"
Content-Transfer-Encoding: 8bit

--0-1216701838-1149521307=:97780
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I have a new email address!You can now email me at: [e-mail]

ATTN:SIR/MADAM,


I WISH TO SOLICITE YOUR ASSISTANCE TO PROVIDE MEWITH A SOLUTION TO A MONEY TRANSFER OF FIFTEEEN MILLION FOUR HUNDRED  THOUSAND (US$15,400,000.00).


MY NAME IS JERALD LAWAL, AN ACCOUNT OFFICER WITH HORSE BANK PLC.I GOT YOUR CONTACT ADDRESS VIA THE INTERNATIONAL INFORMATION EXCHANGE BUREAU OF MY COUNTRY,IN MY SEARCH FOR A RELIABLE AND TRUSTED FOREIGN PARTNER FOR THIS BENEFICIAL BUSSINESS .


A TURKISH BUSSINESSMAN BY NAME (LATE DONALD ARIJ),LEFT A CLOSING BALANCE OF(US$15,400,000.00),WITH MY BANK BEFORE HIS DEATH IN THE BOMB EXPLOSION IN LAGOS, NIGERIA.WHICH SAD EVENT TOOK PLACE ON THE

27TH OF JANUARY 2002.


AFTER THE DEATH OF MR. DONALD ARIJ,I DISCOVERED  HE PRESENTED HIS ONLY SON AS THE NEXT OF KIN TO HIS FUND, BUT IT WAS QUITE UNFORTUNATE THAT THE EXPLOSION CLAIMED THE LIVES OF THE ENTIRE FAMILIES, AS THEIR WAS KNOW SURVIVOR.


AFTER SERIOUS INVESTIGATIONS,I FOUND OUT THAT THERE WAS NOBODY LEFT TO CLAIM THIS MONEY,AND IF THE MONEY IS KEPT IN THE BANK FOR A LONG TIME,THE BOARD OF DIRECTORS MAY TURN IT INTO A DIFFERENT ACCOUNT,IT WAS IN THE COURSE OF THESE THAT I DECIDED TO CONTACT YOU TO FRONT YOU AS THE BENEFICIARY OF THE MONEY,FOR THE IMMEDIATE TRANSFER OF THE FUND INTO YOUR ACCOUNT.


ARRANGEMENT HAS BEEN PUT IN PLACE FOR THE SUCCESS OF THIS TRANSACTION,I WILL USE MY POSITION IN THE BANK TO EFFECT THE TRANSFER.THE NECCESSARY BACK UP DOCUMENT THAT YOU WILL NEED FOR THE CLAIM WILL BE PUT IN PLACE AND FORWARDED TO THE APPROPRATE QUARTERS AS SOON AS WE BEGIN THE TRANSACTION PROCESSES.


I WANT TO LET YOU KNOW THAT THIS IS A LIFE TIME TRANSACTION THAT WILL BE BENEFICIAL TO BOTH OF US,AS WE WILL LIVE TO BE HAPPY AFTER THE CONCLUSION OF THIS TRANSACTION, ALL I NEED IS YOUR MUTUAL SUPPORT,COMMITEMENT,CONFIDENTIALITY AND TRUST. I HAVE RESOLVED TO COMPENSATE YOUR INVOLVEMENT WITH 30% OF THE TOTAL AMOUNT REMMITED,I SHALL KEEP 60% AND 10% FOR TAXES AND OTHER MISCELLANEOUS EXPENSES.


YOU ARE TO PROVIDE ME WITH A SAFE ACCOUNT WHERE THE FUNDS WILL BE TRANSFERED,SECONDLY I WILL NEED YOUR PRIVATE TELEPHONE/FAX NUMBER.


I INTEND TO CONSUMATE THESE TRANSACTION WITHIN THE SHORTEST POSSIBLE TIME BASED ON YOUR CO-OPERATION AND SUPPORT.


I AWAIT YOUR IMMEDIATE RESPONSE.


REGARDS.


JERALD LAWAL




- jerald lawal


--0-1216701838-1149521307=:97780
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div style="border: solid 1px #cccccc; width:448px; background-color:white; margin:10px 0px;";><table border=0 cellspacing=0 cellpadding=0 width="448"><tr><td class=tablot background="http://us.i1.yimg.com/us.yimg.com/i/us/pim/gr/gr_announce_1.gif" valignÎnter heightW><big style="padding:10px;">I have a new email address!</big></td></tr></table><div style="padding:10px;">You can now email me at: <b>[e-mail]</b><br><br><span style="color:green;">ATTN:SIR/MADAM,<br><br><br>I WISH TO SOLICITE YOUR ASSISTANCE TO PROVIDE MEWITH A SOLUTION TO A MONEY TRANSFER OF FIFTEEEN MILLION FOUR HUNDRED  THOUSAND (US$15,400,000.00).<br><br><br>MY NAME IS JERALD LAWAL, AN ACCOUNT OFFICER WITH HORSE BANK PLC.I GOT YOUR CONTACT ADDRESS VIA THE INTERNATIONAL INFORMATION EXCHANGE BUREAU OF MY COUNTRY,IN MY SEARCH FOR A RELIABLE AND TRUSTED FOREIGN PARTNER FOR THIS BENEFICIAL BUSSINESS .<br><br><br>A TURKISH BUSSINESSMAN BY NAME (LATE DONALD ARIJ),LEFT A CLOSING BALANCE OF(US$15,400,000.00),WITH MY BANK BEFORE HIS DEATH IN THE BOMB EXPLOSION IN LAGOS, NIGERIA.WHICH SAD EVENT TOOK PLACE ON THE<br><br>27TH OF JANUARY 2002.<br><br><br>AFTER THE DEATH OF MR. DONALD ARIJ,I DISCOVERED  HE PRESENTED HIS ONLY SON AS THE NEXT OF KIN TO HIS FUND, BUT IT WAS QUITE UNFORTUNATE THAT THE EXPLOSION CLAIMED THE LIVES OF THE ENTIRE FAMILIES, AS THEIR WAS KNOW SURVIVOR.<br><br><br>AFTER SERIOUS INVESTIGATIONS,I FOUND OUT THAT THERE WAS NOBODY LEFT TO CLAIM THIS MONEY,AND IF THE MONEY IS KEPT IN THE BANK FOR A LONG TIME,THE BOARD OF DIRECTORS MAY TURN IT INTO A DIFFERENT ACCOUNT,IT WAS IN THE COURSE OF THESE THAT I DECIDED TO CONTACT YOU TO FRONT YOU AS THE BENEFICIARY OF THE MONEY,FOR THE IMMEDIATE TRANSFER OF THE FUND INTO YOUR ACCOUNT.<br><br><br>ARRANGEMENT HAS BEEN PUT IN PLACE FOR THE SUCCESS OF THIS TRANSACTION,I WILL USE MY POSITION IN THE BANK TO EFFECT THE TRANSFER.THE NECCESSARY BACK UP DOCUMENT THAT YOU WILL NEED FOR THE CLAIM WILL BE PUT IN PLACE AND FORWARDED TO THE APPROPRATE QUARTERS AS SOON AS WE BEGIN THE TRANSACTION PROCESSES.<br><br><br>I WANT TO LET YOU KNOW THAT THIS IS A LIFE TIME TRANSACTION THAT WILL BE BENEFICIAL TO BOTH OF US,AS WE WILL LIVE TO BE HAPPY AFTER THE CONCLUSION OF THIS TRANSACTION, ALL I NEED IS YOUR MUTUAL SUPPORT,COMMITEMENT,CONFIDENTIALITY AND TRUST. I HAVE RESOLVED TO COMPENSATE YOUR INVOLVEMENT WITH 30% OF THE TOTAL AMOUNT REMMITED,I SHALL KEEP 60% AND 10% FOR TAXES AND OTHER MISCELLANEOUS EXPENSES.<br><br><br>YOU ARE TO PROVIDE ME WITH A SAFE ACCOUNT WHERE THE FUNDS WILL BE TRANSFERED,SECONDLY I WILL NEED YOUR PRIVATE TELEPHONE/FAX NUMBER.<br><br><br>I INTEND TO CONSUMATE THESE TRANSACTION WITHIN THE SHORTEST POSSIBLE TIME BASED ON YOUR CO-OPERATION AND SUPPORT.<br><br><br>I AWAIT YOUR IMMEDIATE RESPONSE.<br><br><br>REGARDS.<br><br><br>JERALD LAWAL<br><br><br></span><br><br>- <span style="color:green;">jerald lawal</span></div></div>
--0-1216701838-1149521307=:97780--


Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 07:48:54 +0000
Sensitivity: 
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp-	pc-and-sc-reqs-00
To: "Dimitri.Papadimitriou" <[e-mail]>
Cc: ""Diego Caviglia" <Diego.Caviglia" <[e-mail]>, "Dimitri.Papadimitriou" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>, ""Adrian Farrel" <adrian" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 5 Jun 2006 09:47:46 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Dimitri,

Quoted from your e-mail
"[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP"

Now I see your point, I think that we can add a req to cover your concern.

Regards

Diego





[e-mail] on 03/06/2006 10.42.57

To:    "Diego Caviglia" <[e-mail]>
cc:    [e-mail], "ccamp" <[e-mail]>, Dino
       Bramanti <[e-mail]>, "Adrian Farrel"
       <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

hi diego - see inline




"Diego Caviglia" <[e-mail]>
Sent by: [e-mail]
01/06/2006 09:20

        To:     [e-mail]
        cc:     "\"\"'Adrian Farrel'\" <adrian\"", Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" <[e-mail]>, "Dino
Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        RE: A new ID is available on the repository
draft-caviglia-ccamp-   pc-and-sc-reqs-00



Hi Vijay,
          some answers in line.

Regards

Diego



"Pandian, Vijay" <[e-mail]>@ops.ietf.org on
01/06/2006
04.34.12

Sent by:    [e-mail]


To:    "'Adrian Farrel'" <[e-mail]>,
       [e-mail]
cc:    [e-mail], Diego Caviglia <[e-mail]>,
       Dino Bramanti <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not sure
why CP needs to guarantee identical states at [a] and [b]. May be I am not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it?
[dc] That is the idea.

[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP

If this is true, then MP -> CP[b] should be treated as the ONLY general
case
of MP -> CP conversion, right?
[dc] Yes, unless Dimitri calirifies better what he intend with state[a]
and
state[b]

[dp] see my previous post - note the above has an impact on the present
point

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I
guess we would describe this in terms of SPCs. Is it necessary that
identical state is held at [a] and [b]. In particular, the question of
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to
suggest

some?

Adrian

----- Original Message -----
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable
work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t



xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   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.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>




















Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jun 2006 06:41:55 +0000
Sensitivity: 
Subject: Re:  =?gb2312?B?u9i4tDpSZTogQSBuZXJ3IElEIGlzIGF2YWlsYWJsZSBvbiB0aGU=?= =?gb2312?B?IHJlcG9zaXRvcnkgZHJhZnQtY2F2aWdsaWEtY2NhbXAtcGMtYW5kLXNj?= =?gb2312?B?LXJlcXMtMDA=?To: "Dimitri.Papadimitriou" <[e-mail]>
Cc: "lidan 37133 <danli" <[e-mail]>, "Adrian Farrel <adrian" <[e-mail]>, "ccamp" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 5 Jun 2006 08:38:37 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

DQpIaSBndXlzLA0KICAgICAgICAgSSBhZ3JlZSB3aXRoIERhbiwgSU1ITyB0ZWhyZSBpcyBubyBu
ZWVkIHRvIGFzc3VyZSB0aGF0IHRoZSBzdGF0ZQ0KYXQgc3RlcCAxIGFuZCAzIGFyZSB0aGUgc2Ft
ZS4NCg0KSSB0aGluayB3ZSBjYW4gc2F5IHRoYXQgdGhpcyBraW5kIG9mIHRyYW5zb3JtYXRpb24g
YXJlIHN0YXRlbGVzcyBpbiB0aGUNCnNlbnNlIHRoYXQgYW55IG1lbW9yeSBvZiB0aGUgQ1Agc3Rh
dGUgaXMgbG9zdCB3aGVuIGEgbWlncmF0aW9uIHRvIE1QIGlzDQpkb25lLg0KDQpSZWdhcmRzDQoN
CkRpZWdvDQoNCg0KDQpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSBvbiAwMi8wNi8y
MDA2IDE1LjU5LjQyDQoNClRvOiAgICBsaWRhbiAzNzEzMyA8ZGFubGlAaHVhd2VpLmNvbT4NCmNj
OiAgICBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiwgY2NhbXBAb3BzLmlldGYu
b3JnLCBEaWVnbw0KICAgICAgIENhdmlnbGlhIDxEaWVnby5DYXZpZ2xpYUBtYXJjb25pLmNvbT4s
IERpbm8gQnJhbWFudGkNCiAgICAgICA8RGluby5CcmFtYW50aUBtYXJjb25pLmNvbT4NCg0KU3Vi
amVjdDogICAgUmU6ICC72Li0OlJlOiBBIG5lcncgSUQgaXMgYXZhaWxhYmxlIG9uIHRoZSByZXBv
c2l0b3J5DQogICAgICAgZHJhZnQtY2F2aWdsaWEtY2NhbXAtcGMtYW5kLXNjLXJlcXMtMDANCg0K
aGkgLSB0aGlzIG9uZSBvZiB0aGUgY2FzZSB0byBiZSBjb3ZlcmVkIC0gbm93IGkgZGlkbid0IHll
dCBwcm9wb3NlIGFueQ0Kc3BlY2lmaWMgYmVoYXZpb3VyIC0NCmkgZGlkIGp1c3QgbWVudGlvbiB0
aGF0IHRoZSBwcm9ibGVtIGV4aXN0IGFuZCBzaG91bGQgYmUgY29uc2lkZXJlZA0KDQoNCg0KDQoN
CmxpZGFuIDM3MTMzIDxkYW5saUBodWF3ZWkuY29tPg0KMDEvMDYvMjAwNiAxNjo0OQ0KDQogICAg
ICAgIFRvOiAgICAgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KICAg
ICAgICBjYzogICAgIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+LCBjY2FtcEBv
cHMuaWV0Zi5vcmcsDQpEaWVnbyBDYXZpZ2xpYSA8RGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20+
LCBEaW5vIEJyYW1hbnRpDQo8RGluby5CcmFtYW50aUBtYXJjb25pLmNvbT4NCiAgICAgICAgU3Vi
amVjdDogICAgICAgILvYuLQ6UmU6IEEgbmVydyBJRCBpcyBhdmFpbGFibGUgb24gdGhlIHJlcG9z
aXRvcnkNCmRyYWZ0LWNhdmlnbGlhLWNjYW1wLXBjLWFuZC1zYy1yZXFzLTAwDQoNCg0KSGkgRGlt
aXRyaSwNCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhdmUgZHJhd24gYSBzY2Vu
YXJpbyBsaWtlIHRoaXM6DQpTdGVwIDE6IEEgUEMgaXMgbWlncmF0ZWQgdG8gYSBTQzsNClN0ZXAg
MjogVGhlbiB0aGUgU0MgaXMgbWlncmF0ZWQgdG8gYSBQQzsNClN0ZXAgMzogVGhlbiB0aGUgUEMg
aXMgbWlncmF0ZWQgdG8gYSBTQyBhZ2FpbjsNCg0KU28gaG93IHRvIGd1YXJhbnRlZSB0aGUgc3Rh
dGUgb2YgYSBTQyBhdCB0aGUgc3RlcCAzIGlzIHNhbWUgYXMgdGhlIHN0YXRlDQpvZiBhIFNDIGF0
IHRoZSBzdGVwIDEsIGFtIEkgcmlnaHQ/DQoNCkkgdGhpbmsgd2UgZG9uJ3QgbmVlZCB0byBrZWVw
IHRoZSBzYW1lIHN0YXRlIG9mIHRoZSBTQyBhdCBkaWZmZXJlbnQgc3RlcHMsDQpmb3IgZXhhbXBs
ZSwgdGhlIHNlc3Npb24gSUQgb2YgYSBTQyBhdCBzdGVwIDEgTUFZIGJlIGRpZmZlcmVudCB3aXRo
IHRoZQ0Kc2Vzc2lvbiBJRCBvZiBhIFNDIGF0IHN0ZXAgMy4NCg0KSSBncmVhdGx5IGFwcHJlY2lh
dGUgeW91ciBjb21tZW50cywgaG9wZSB5b3UgY2FuIGhlbHAgd2l0aCB0aGlzIHdvcmsuDQoNCkJl
c3QgcmVnYXJkcywNCg0KRGFuDQoNCi0tLS0tINSt08q8/iAtLS0tLQ0Kt6K8/sjLOiBEaW1pdHJp
LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0KyNXG2jog0MfG2svELCDB+dTCIDHI1SwgMjAwNiDJ
z87nMjo0NA0K1vfM4jogUmU6IEEgbmVydyBJRCBpcyBhdmFpbGFibGUgb24gdGhlIHJlcG9zaXRv
cnkNCmRyYWZ0LWNhdmlnbGlhLWNjYW1wLXBjLWFuZC1zYy1yZXFzLTAwDQoNCj4gYWdyZWVkIC0N
Cj4NCj4gcXVlc3Rpb246IGluIGNhc2Ugb2YgbW92ZSBDUC0+TVAgd2hvIGd1YXJhbnRlZXMgdGhh
dCB0aGUgQ1AgYXQNCj4gc3RhdGUgW2JdDQo+IHJldHJpZXZlcyBpdHMgc3RhdGVzIGl0IGhhZCBh
dCBbYV0gZS5nLg0KPg0KPiBNUC0+Q1BbYV0tPk1QLT5DUFtiXT8NCj4NCj4gZG8gd2UgbmVlZCBh
IHNwZWNpZmljIHJlcXVpcmVtZW50IGZvciB0aGlzIGNhc2UgPw0KPg0KPg0KPg0KPg0KPg0KPg0K
PiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQo+IFNlbnQgYnk6IG93bmVy
LWNjYW1wQG9wcy5pZXRmLm9yZw0KPiAyNS8wNS8yMDA2IDE5OjUzDQo+IFBsZWFzZSByZXNwb25k
IHRvICJBZHJpYW4gRmFycmVsIg0KPg0KPiAgICAgICAgVG86ICAgICA8Y2NhbXBAb3BzLmlldGYu
b3JnPiwgIkRpZWdvIENhdmlnbGlhIg0KPiA8RGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20+DQo+
ICAgICAgICBjYzogICAgICJEYW4gTGkgPGRhbmxpIiwgIkRpbm8gQnJhbWFudGkiDQo+IDxEaW5v
LkJyYW1hbnRpQG1hcmNvbmkuY29tPg0KPiAgICAgICAgU3ViamVjdDogICAgICAgIFJlOiBBIG5l
cncgSUQgaXMgYXZhaWxhYmxlIG9uIHRoZQ0KPiByZXBvc2l0b3J5DQo+IGRyYWZ0LWNhdmlnbGlh
LWNjYW1wLXBjLWFuZC1zYy1yZXFzLTAwDQo+DQo+DQo+IEhpIERpZWdvLA0KPg0KPiBUaGFua3Mg
Zm9yIHB1dHRpbmcgdGhpcyBJLUQgdG9nZXRoZXIuIEkgdGhpbmsgaXQgZ2l2ZXMgYSBtdWNoDQo+
IGNsZWFyZXINCj4gcGljdHVyZSBvZiB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGFjaGlldmUgd2l0
aCB5b3VyIGRpc2N1c3Npb24gb2YNCj4gbW92aW5nDQo+IGNvbnRyb2wgb2YgYW4gTFNQIGJldHdl
ZW4gdGhlIG1hbmFnZW1lbnQgcGxhbmUgYW5kIHRoZSBjb250cm9sIHBsYW5lLg0KPg0KPiBUaGlz
IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHNldCBvZiByZXF1aXJlbWVudHMgdG8gbWUsIGFuZCBJ
DQo+IHdvdWxkIGxpa2UNCj4gdG8NCj4gc2VlIHNvbWUgZGlzY3Vzc2lvbiBmcm9tIGZvbGsgb24g
d2hldGhlciB0aGV5IHRoaW5rIHRoaXMgaXMNCj4gdmFsdWFibGUgd29yaywNCj4NCj4gYW5kIHdo
ZXRoZXIgd2Ugc2hvdWxkIHN0YXJ0IHRvIGxvb2sgZm9yIHByb3RvY29sIHNvbHV0aW9ucy4NCj4N
Cj4gVGhhbmtzLA0KPiBBZHJpYW4NCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K
PiBGcm9tOiAiRGllZ28gQ2F2aWdsaWEiIDxEaWVnby5DYXZpZ2xpYUBtYXJjb25pLmNvbT4NCj4g
VG86IDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+IENjOiAiRGFuIExpIDxkYW5saSIgPGRhbmxpQGh1
YXdlaS5jb20+OyAiRGlubyBCcmFtYW50aSINCj4gPERpbm8uQnJhbWFudGlAbWFyY29uaS5jb20+
DQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI0LCAyMDA2IDg6NDggQU0NCj4gU3ViamVjdDogQSBu
ZXJ3IElEIGlzIGF2YWlsYWJsZSBvbiB0aGUgcmVwb3NpdG9yeQ0KPiBkcmFmdC1jYXZpZ2xpYS1j
Y2FtcC1wYy1hbmQtc2MtcmVxcy0wMA0KPg0KPg0KPiA+QSBuZXcgSUQgaXMgYXZhaWxhYmxlIG9u
IHRoZSBJRCByZXBvc2l0b3J5DQo+ID4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k
cmFmdHMvZHJhZnQtY2F2aWdsaWEtY2NhbXAtcGMtYW5kLXNjLQ0KPiByZXFzLTAwLnR4dA0KPiAu
DQo+ID4NCj4gPiBUaGUgSUQgc3RhdGVzIHNvbWUgYmFzaWMgcmVxdXJlbWVudHMgZm9yIHRoZSBw
b3NzaWJpbGl0eSBvZg0KPiB0dXJuaW5nIGENCj4gPiBQZXJtYW5lbnQgQ29ubmVjdGlvbiAoUEMp
IGludG8gYSBTb2Z0IFBlcm1hbmVudCBDb25uZWN0aW9uIChTUEMpDQo+IGFuZA0KPiB2aWNlDQo+
ID4gdmVyc2EsIHdpdGhvdXQgYWN0dWFsbHkgYWZmZWN0aW5nIERhdGEgUGxhbmUgdHJhZmZpYywg
bm8NCj4gc29sdXRpb25zIGFyZQ0KPiA+IHByb3Bvc2VkIGluIHRoZSBJRC4NCj4gPg0KPiA+IEFi
c3RyYWN0DQo+ID4NCj4gPiAgIEZyb20gYSBDYXJyaWVyIHBlcnNwZWN0aXZlLCB0aGUgcG9zc2li
aWxpdHkgb2YgdHVybmluZyBhIFBlcm1hbmVudA0KPiA+ICAgQ29ubmVjdGlvbiAoUEMpIGludG8g
YSBTb2Z0IFBlcm1hbmVudCBDb25uZWN0aW9uIChTUEMpIGFuZCB2aWNlDQo+ID4gICB2ZXJzYSwg
d2l0aG91dCBhY3R1YWxseSBhZmZlY3RpbmcgRGF0YSBQbGFuZSB0cmFmZmljIGJlaW5nIGNhcnJp
ZWQNCj4gPiAgIG92ZXIgaXQsIGlzIGEgdmFsdWFibGUgb3B0aW9uLiBJbiBvdGhlciB0ZXJtcywg
c3VjaCBvcGVyYXRpb24NCj4gY2FuIGJlDQo+ID4gICBzZWVuIGFzIGEgd2F5IG9mIHRyYW5zZmVy
cmluZyB0aGUgb3duZXJzaGlwIGFuZCBjb250cm9sIG9mIGFuDQo+ID4gICBleGlzdGluZyBhbmQg
aW4tdXNlIERhdGEgUGxhbmUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBNYW5hZ2VtZW50DQo+ID4g
ICBQbGFuZSBhbmQgdGhlIENvbnRyb2wgUGxhbmUsIGxlYXZpbmcgaXRzIERhdGEgUGxhbmUgc3Rh
dGUNCj4gdW50b3VjaGVkLj4gICBUaGlzIG1lbW8gc2V0cyBvdXQgdGhlIHJlcXVpcmVtZW50cyBm
b3Igc3VjaA0KPiBwcm9jZWR1cmVzIHdpdGhpbiBhDQo+ID4gICBHZW5lcmFsaXplZCBNdWx0aXBy
b3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIG5ldHdvcmsuDQo+ID4NCj4gPg0KPiA+IENv
bW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSB3ZWxjb21lIHN4cGVjaWFsbHkgZnJvbSB0
aGUNCj4gY2Fycmllcj4gY29tbXVuaXR5Lg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+DQo+ID4gRGll
Z28NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCg0K
DQoNCg0KDQoNCg0K





Envelope-to: [e-mail]
Delivery-date: Sat, 03 Jun 2006 15:57:54 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:X-RocketDSI:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; bÚh6UKYFTw8UTUSS4EzPV08IMaILvnqNj/qgCxZioCRhMc/snR+JOYnTo9LtW+HO5dCYeZ4RO+OzwV7oYM08c61/PDIAm35iS4L8deb/twt6+heIRJdzhdIyv5j11RskV/rv7XLKNBJ5KYhyyEH+6jqehbLPqkE6R3+JSg83Pas=  ;
Message-ID: <[e-mail]>
Date: Sat, 3 Jun 2006 03:27:24 -0700 (PDT)
From: =?big5?q?Hon Olu Adeniji?= <[e-mail]>
Reply-To: [e-mail]
Subject: Very Urgent.
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-544080164-1149330444=:89022"
Content-Transfer-Encoding: 8bit

--0-544080164-1149330444=:89022
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit

§Ú¦³·sªº¹q¶l¦a§}¡I§A²{¥i¹q¶lµ¹§Ú¡[e-mail]

Minister of Foreign Affairs

Federal Ministry of foreign Affairs

Maputo Street

Wuse Zone 3 PMB 130

Garki Abuja Nigeria.


Attention: Sir/Madam, 


I am Hon. Dr. Adeniji Olu, Minister Foreign Affairs Ministry, my office monitors and controls the affairs of all banks and financial institutions in Nigeria concerned with foreign contract payments,I am the final signatory to any transfer or remittance of huge funds moving within banks both on the local and international levels in line to foreign contracts/payment settlement.


I have before me list of funds, which could not be transferred to some nominated accounts as these accounts have been identified either as ghost accounts, unclaimed deposits and over-invoiced sum etc. I write to present you to the federal government that you are among the people expecting funds to be transfered into their account, on this note,I wish to have a deal with you as regards to the unpaid certified contract funds,all files are before me and the data's will be changed to your name to enable you receive the fund into your nominated bank account as the beneficiary of the fund amount of US$17.4Million.


As it is my duty to recommend the transfer of these surplus funds to the Federal Government Treasury and Reserve Accounts as unclaimed deposits,I have the opportunity to write you based on the instructions i received 2 days ago from the Senate Committee on Contract Payments /Foreign Debts to submit the List of payment reports / expenditures and audited reports of revenues. Among several others, I have decided to remit this sum following my idea that we have a deal /agreement and I am going to do this legally.


MY CONDITIONS.

1. You will give me 40% of your contract funds as soon as you confirm 

it in your designated bank account.

2. This deal must be kept secret,and all correspondence will be 

strictly by email / telephone for security purposes.

3. There should be no third parties as most problem associated with 

your fund release are caused by your agents or representative.


If you AGREE with my conditions, l will advise you on what to do immediately so that the transfer will commence without delay as I will proceed to fix your name on the Payment schedule instantly to meet the three days mandate.


I hope you don't reject this offer and have the funds transferred. 


Waiting for your reply soon.


HON. Dr. Adeniji Olu.

FOREIGN AFFAIRS MINISTER

DIRECT LINE: 234-1-72223351

Very Urgent.

- Hon Adeniji Olu 


--0-544080164-1149330444=:89022
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit

<div style="border: solid 1px #cccccc; width:448px; background-color:white; margin:10px 0px;";><table border=0 cellspacing=0 cellpadding=0 width="448"><tr><td class=tablot background="http://us.i1.yimg.com/us.yimg.com/i/us/pim/gr/gr_announce_1.gif" valignÎnter heightW><big style="padding:10px;">§Ú¦³·sªº¹q¶l¦a§}¡I</big></td></tr></table><div style="padding:10px;">§A²{¥i¹q¶lµ¹§Ú¡G<b>[e-mail]</b><br><br><span style="color:green;">Minister of Foreign Affairs<br><br>Federal Ministry of foreign Affairs<br><br>Maputo Street<br><br>Wuse Zone 3 PMB 130<br><br>Garki Abuja Nigeria.<br><br><br>Attention: Sir/Madam, <br><br><br>I am Hon. Dr. Adeniji Olu, Minister Foreign Affairs Ministry, my office monitors and controls the affairs of all banks and financial institutions in Nigeria concerned with foreign contract payments,I am the final signatory to any transfer or remittance of huge funds moving within banks both on the local and international levels in line to foreign contracts/payment settlement.<br><br><br>I have before me list of funds, which could not be transferred to some nominated accounts as these accounts have been identified either as ghost accounts, unclaimed deposits and over-invoiced sum etc. I write to present you to the federal government that you are among the people expecting funds to be transfered into their account, on this note,I wish to have a deal with you as regards to the unpaid certified contract funds,all files are before me and the data's will be changed to your name to enable you receive the fund into your nominated bank account as the beneficiary of the fund amount of US$17.4Million.<br><br><br>As it is my duty to recommend the transfer of these surplus funds to the Federal Government Treasury and Reserve Accounts as unclaimed deposits,I have the opportunity to write you based on the instructions i received 2 days ago from the Senate Committee on Contract Payments /Foreign Debts to submit the List of payment reports / expenditures and audited reports of revenues. Among several others, I have decided to remit this sum following my idea that we have a deal /agreement and I am going to do this legally.<br><br><br>MY CONDITIONS.<br><br>1. You will give me 40% of your contract funds as soon as you confirm <br><br>it in your designated bank account.<br><br>2. This deal must be kept secret,and all correspondence will be <br><br>strictly by email / telephone for security purposes.<br><br>3. There should be no third parties as most problem associated with <br><br>your fund release are caused by your agents or representative.<br><br><br>If you AGREE with my conditions, l will advise you on what to do immediately so that the transfer will commence without delay as I will proceed to fix your name on the Payment schedule instantly to meet the three days mandate.<br><br><br>I hope you don't reject this offer and have the funds transferred. <br><br><br>Waiting for your reply soon.<br><br><br>HON. Dr. Adeniji Olu.<br><br>FOREIGN AFFAIRS MINISTER<br><br>DIRECT LINE: 234-1-72223351<br><br>Very Urgent.</span><br><br>- <span style="color:green;">Hon Adeniji Olu </span></div></div>
--0-544080164-1149330444=:89022--


Envelope-to: [e-mail]
Delivery-date: Sat, 03 Jun 2006 08:44:41 +0000
To: "Diego Caviglia" <[e-mail]>
Cc: [e-mail], "ccamp" <[e-mail]>, Dino Bramanti <[e-mail]>, "Adrian Farrel" <[e-mail]>
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp-	pc-and-sc-reqs-00
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 3 Jun 2006 10:42:57 +0200
Content-Type: text/plain; charset="US-ASCII"

hi diego - see inline




"Diego Caviglia" <[e-mail]>
Sent by: [e-mail]
01/06/2006 09:20
 
        To:     [e-mail]
        cc:     "\"\"'Adrian Farrel'\" <adrian\"", Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" <[e-mail]>, "Dino 
Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        RE: A new ID is available on the repository 
draft-caviglia-ccamp-   pc-and-sc-reqs-00



Hi Vijay,
          some answers in line.

Regards

Diego



"Pandian, Vijay" <[e-mail]>@ops.ietf.org on 
01/06/2006
04.34.12

Sent by:    [e-mail]


To:    "'Adrian Farrel'" <[e-mail]>,
       [e-mail]
cc:    [e-mail], Diego Caviglia <[e-mail]>,
       Dino Bramanti <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not sure
why CP needs to guarantee identical states at [a] and [b]. May be I am not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it?
[dc] That is the idea.

[dp] meaning that you must be ensure that b/f transfer the state is 
completely in-sync among all nodes used to be traversed by the LSP

If this is true, then MP -> CP[b] should be treated as the ONLY general
case
of MP -> CP conversion, right?
[dc] Yes, unless Dimitri calirifies better what he intend with state[a] 
and
state[b]

[dp] see my previous post - note the above has an impact on the present
point

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I
guess we would describe this in terms of SPCs. Is it necessary that
identical state is held at [a] and [b]. In particular, the question of
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to
suggest

some?

Adrian

----- Original Message -----
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable
work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t


xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   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.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>














Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 20:01:45 +0000
Message-ID: <126001c6867f$42dc4be0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated communication from the OIF on 1: protection
Date: Fri, 2 Jun 2006 20:57:04 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

As promissed, we have received an update to the 20th May communication from 
the OIF on 1:n protection. Hopefully this clarifies the questions so that we 
can provide suitable answers. As usual, all incoming communications can be 
found at http://www.olddog.co.uk/ccamp.htm

We will see how we can adapt our draft response to respond ASAP. All input 
is welcome.

Cheers,
Adrian
=
From: "Jim Jones" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>;
    "'Brungard, Deborah A, ALABS'" <[e-mail]>
Cc: "'Ong, Lyndon'" <[e-mail]>
Sent: Friday, June 02, 2006 7:47 PM
Subject: Draft response to OIF on 1:n protection

Dear Adrian and Deborah,


In observing some of the e-mails on the CCAMP list and the draft response to
the OIF Liaison to IETF CCAMP WG on 1:N Protection, it was apparent that
some clarification of our questions was in order. This revised input was
drafted by OIF members that composed the outgoing liaison and contributions
on the topic. The OIF is still interested in a response from the experts
participating in CCAMP.

1) OIF would appreciate CCAMP's guidance as to whether CCAMP has defined
standards for any similar form of restoration, i.e., one that protects a
group of LSPs at once over a local span, by shifting these LSPs from their
original link within the span over to a backup link.  It should be noted
that

- the backup link may be a different type than the original (e.g., OC192
rather than OC48), so that GMPLS signaling rather than underlying SONET/SDH
link protection is used to perform the switchover; and

- it is intended that the affected LSPs be shifted using a single signaling
interaction rather than separate interactions per individual LSP in order to
reduce the signaling overhead required.


We believe that some of the existing work, especially for segment recovery,
may be helpful, but may not meet the exact requirements of the service that
has been proposed within OIF. Any pointers to existing drafts or RFCs,
however, would be greatly appreciated.


2) Reviewing some of the existing RFC text, we note that RFC 4426 section
2.5.2 states "it MAY be possible for the LSPs on the working link to be
mapped to the protection link without re-signaling each individual LSP" and
"it MAY be possible to change the component links without needing to
re-signal each individual LSP".  This text appears to refer to the use of
SONET/SDH link protection in such a way that the labels for each LSP remain
the same.  Does this imply, however, that an action that changes the local
labels for the affected LSPs then requires re-signaling of each individual
LSP, or is there a "bulk" mechanism to change labels for a group of LSPs
simultaneously?


3) RFC 4426 describes the sending of the Failure Indication Message upon
detection of failure by a slave device.  It is our belief that the same
mechanism could also be used when the slave device is triggered to send an
indication due to management system intervention (cases are mentioned in RFC
4427 but not in 4426), and we would like to know if CCAMP concurs with this.
An example of where this might occur is where the master and slave devices
are in different management domains.


4) RFC 4427, section 4.15 discusses bulk recovery for a failed span, and
suggests that the recovery switching message to recovered LSP ratio may be 1
or greater.  OIF would like to know if it is possible to define procedures
such that the ratio is much less than 1, i.e., a message that causes bulk
recovery actions on a number of LSPs.


5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1 and 1:1
span protection and a "source" and "destination" role for control of
end-to-end restoration and for reversion.  We believe that "source" and
"destination" mean the initiator and receiver of the LSP (as opposed to the
source and destination of data in-band).  We are not clear on the rationale
for when control plane roles are based on master/slave vs.
source/destination: it appears that local span actions are controlled using
master/slave while remote actions are controlled using source/destination,
however the reasoning for control of reversion is less clear to us.  Any
clarification of the rationale for using master/slave vs. source/destination
control would be appreciated.


6) We believe that it may be useful in some cases of reversion to allow a
"slave" device to request reversion using an abstract message similar to the
Failure Indication Message.  An example case is (again) when the "master"
and "slave" devices are in different management domains, such that reversion
is initiated from the management domain of the "slave" device.  We request
CCAMP comment on this suggestion.


The OIF would appreciate the review and feedback of the experts in the CCAMP
working group on these items.


Best regards,


Jim Jones
OIF Technical Committee Chair





Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 19:51:48 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-te-node-cap-01.txt 
Message-Id: <[e-mail]>
Date: Fri, 02 Jun 2006 15:50:01 -0400

--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		: Routing extensions for discovery of Traffic Engineering Node Capabilities
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-te-node-cap-01.txt
	Pages		: 15
	Date		: 2006-6-2
	
It is highly desired in several cases, to take into account Traffic 
Engineering (TE) node capabilities during TE LSP path selection, such 
as for instance the capability to act as a branch LSR of a P2MP LSP. 
This requires advertising these capabilities within the IGP. 
For that purpose, this document specifies OSPF and IS-IS traffic 
engineering extensions for the advertisement of control plane and 
data plane traffic engineering node capabilities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-te-node-cap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-te-node-cap-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 18:25:52 +0000
To: "Pandian, Vijay" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, ccamp <[e-mail]>, Diego Caviglia <[e-mail]>
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp-		pc-and-sc-reqs-00
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 2 Jun 2006 20:24:49 +0200
Content-Type: text/plain; charset="US-ASCII"

pandian

i simply referred to the case where 

MP -> CP[t(i),s[i],LSP[i]] -> MP -> CP[t(j),s[j],LSP[j]]

that t(j) > t(i) represents a temporal move

that s(i) =/= s(j) represents a spatial move

LSP[i] =/= LSP[j] represents a state modification

it seems to me that (with time unit being refresh time) we've four cases, 
with each time a subcase depending on either a) LSP[i] = LSP[j] for all s. 
or b) LSP[i] =/= LSP[j] but when a change is performed for a given 
parameter describing the PSB/RSB it must be performed at each hop i.e. for 
all s.:

1. t(i) = t(j), in case s(i) = s(j) nothing changes

2. t(i) = t(j), in case s(i) =/= s(j) - spatial move - 

3. t(i) > t(j), in case s(i) = s(j) *** this is for me the only case 
covered with the subcase a) ***

4. t(i) > t(j), in case s(i) =/= s(j) - spatial move -

=> do we want sub-case 3.b ?

how to cover case 2. and 4 ?

the point is that i still have to check how this would work during the 
transit period b/w successive intervals ](n-1) R, n R], R = Refresh int. L 
= cleanup, with L >= N x R) because you must ensure that the states that 
are taken over by the MP are consistent (during the move CP->MP) before 
being capable to be released to the control plane (during the move MP -> 
CP)






"Pandian, Vijay" <[e-mail]>
02/06/2006 19:42
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[e-mail]>
        cc:     ccamp <[e-mail]>, Diego Caviglia 
<[e-mail]>
        Subject:        RE: A new ID is available on the repository 
draft-caviglia-ccamp-           pc-and-sc-reqs-00


Dimitri,

Could you please give some additional detail on the issue. 

The original scenario is as follows:

  MP -> CP[a] -> MP -> CP[b]

What exactly is this scenario illustrating:

a) Is it illustrating a scenario where an LSP was transferred to the CP in
three steps: first from MP to CP (i.e.., MP -> CP[a] part), secondly, at
some later point in time, the same LSP is transferred back to MP for what
ever reason (i.e., the CP[a] -> MP part) and finally at some later point 
in
time the same LSP is transferred back from MP to CP (MP -> CP[b] part).

b) or is it like what Adrian has interpreted: i.e., there are 4 LSR's
involved in this scenario. But then what exactly is the problem? Is it the
case that the LSP is partially converted to CP at two of the LSR's and MP
still owns the LSP at the other two LSRs?

c) or is it some thing else.

My interpretation of your issue was scenario (a). If that is the case, I
don't see need for extra requirements. 

On the other hand, if it is (b), I am not sure how would this be possible 
if
we do the protocol right.

If (c), please provide some additional detail on the scenario.

Thanks and best regards,

Vijay


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Friday, June 02, 2006 9:57 AM
To: Adrian Farrel
Cc: ccamp; Diego Caviglia; Pandian, Vijay
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00


hi adrian

CP[I] is to be complemented with I including values from the set 
{t,s[i],lsp[i]}

t      = time
s[i]   = rsvp_instance
lsp[i] = values associated to the P/RSB indexed by 5_tuple[i]

thanks,
- dimitri.







"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
01/06/2006 13:25
Please respond to "Adrian Farrel"
 
        To:     <[e-mail]>, "Diego Caviglia" 
<[e-mail]>
        cc:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" 
<[e-mail]>, "Dino Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        Re: A new ID is available on the repository 
draft-caviglia-ccamp-   pc-and-sc-reqs-00


Hi,

I read Dimitri's comments as being spatial not temporal.
I.e. he drew a figure showing four LSRs.

Dimitri?

Cheers,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: """'Adrian Farrel'" <adrian"" <[e-mail]>; 
"Dimitri.Papadimitriou" <[e-mail]>; "ccamp" 
<[e-mail]>; "Dino Bramanti <Dino.Bramanti" 
<[e-mail]>; "Dan Li <danli" <[e-mail]>
Sent: Thursday, June 01, 2006 8:20 AM
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- 


pc-and-sc-reqs-00


>
> Hi Vijay,
>          some answers in line.
>
> Regards
>
> Diego
>
>
>
> "Pandian, Vijay" <[e-mail]>@ops.ietf.org on 
> 01/06/2006
> 04.34.12
>
> Sent by:    [e-mail]
>
>
> To:    "'Adrian Farrel'" <[e-mail]>,
>       [e-mail]
> cc:    [e-mail], Diego Caviglia <[e-mail]>,
>       Dino Bramanti <[e-mail]>
>
> Subject:    RE: A new ID is available on the repository
>       draft-caviglia-ccamp-  pc-and-sc-reqs-00
>
> Adrian and Dimitri,
>
> Not sure why we need extra requirements to handle this case. Also not 
sure
> why CP needs to guarantee identical states at [a] and [b]. May be I am 
not
> understanding the case that is being pictured here.
>
> The way I read the requirements, once the control is transferred to MP
> (i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't 
it?
> [dc] That is the idea.
>
> If this is true, then MP -> CP[b] should be treated as the ONLY general
> case
> of MP -> CP conversion, right?
> [dc] Yes, unless Dimitri calirifies better what he intend with state[a] 
> and
> state[b]
>
> Regards,
> Vijay
>
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2006 7:18 PM
> To: [e-mail]
> Cc: [e-mail]; Diego Caviglia; Dino Bramanti
> Subject: Re: A new ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Interesting question.
>
> It would certainly be the case that the picture you draw could arise. I
> guess we would describe this in terms of SPCs. Is it necessary that
> identical state is held at [a] and [b]. In particular, the question of
> Session ID and LSP ID spring to mind.
>
> Yes, we need clear requirements for this type of situation.  Want to
> suggest
>
> some?
>
> Adrian
>
> ----- Original Message -----
> From: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
> "Dino Bramanti" <[e-mail]>
> Sent: Wednesday, May 31, 2006 7:44 PM
> Subject: Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>> agreed -
>>
>> question: in case of move CP->MP who guarantees that the CP at state 
[b]
>> retrieves its states it had at [a] e.g.
>>
>> MP->CP[a]->MP->CP[b]?
>>
>> do we need a specific requirement for this case ?
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <[e-mail]>
>> Sent by: [e-mail]
>> 25/05/2006 19:53
>> Please respond to "Adrian Farrel"
>>
>>        To:     <[e-mail]>, "Diego Caviglia"
>> <[e-mail]>
>>        cc:     "Dan Li <danli", "Dino Bramanti"
>> <[e-mail]>
>>        Subject:        Re: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>> Hi Diego,
>>
>> Thanks for putting this I-D together. I think it gives a much clearer
>> picture of what you are trying to achieve with your discussion of 
moving
>> control of an LSP between the management plane and the control plane.
>>
>> This seems like a reasonable set of requirements to me, and I would 
like
>> to
>> see some discussion from folk on whether they think this is valuable
> work,
>>
>> and whether we should start to look for protocol solutions.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Diego Caviglia" <[e-mail]>
>> To: <[e-mail]>
>> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
>> <[e-mail]>
>> Sent: Wednesday, May 24, 2006 8:48 AM
>> Subject: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>>>A new ID is available on the ID repository
>>>
>>
> 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t


>
> xt
>> .
>>>
>>> The ID states some basic requrements for the possibility of turning a
>>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
>> vice
>>> versa, without actually affecting Data Plane traffic, no solutions are
>>> proposed in the ID.
>>>
>>> Abstract
>>>
>>>   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.
>>>
>>>
>>> Comments and suggestions are very welcome sxpecially from the carrier
>>> community.
>>>
>>> Regards
>>>
>>> Diego
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
> 









Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 17:43:59 +0000
Message-ID: <[e-mail]>
From: "Pandian, Vijay" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: ccamp <[e-mail]>, Diego Caviglia <[e-mail]>
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- pc-and-sc-reqs-00
Date: Fri, 2 Jun 2006 13:42:39 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Dimitri,

Could you please give some additional detail on the issue. 

The original scenario is as follows:

  MP -> CP[a] -> MP -> CP[b]

What exactly is this scenario illustrating:

a) Is it illustrating a scenario where an LSP was transferred to the CP in
three steps: first from MP to CP (i.e.., MP -> CP[a] part), secondly, at
some later point in time, the same LSP is transferred back to MP for what
ever reason (i.e., the CP[a] -> MP part) and finally at some later point in
time the same LSP is transferred back from MP to CP (MP -> CP[b] part).

b) or is it like what Adrian has interpreted: i.e., there are 4 LSR's
involved in this scenario. But then what exactly is the problem? Is it the
case that the LSP is partially converted to CP at two of the LSR's and MP
still owns the LSP at the other two LSRs?

c) or is it some thing else.

My interpretation of your issue was scenario (a). If that is the case, I
don't see need for extra requirements. 

On the other hand, if it is (b), I am not sure how would this be possible if
we do the protocol right.

If (c), please provide some additional detail on the scenario.

Thanks and best regards,

Vijay


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Friday, June 02, 2006 9:57 AM
To: Adrian Farrel
Cc: ccamp; Diego Caviglia; Pandian, Vijay
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00


hi adrian

CP[I] is to be complemented with I including values from the set 
{t,s[i],lsp[i]}

t      = time
s[i]   = rsvp_instance
lsp[i] = values associated to the P/RSB indexed by 5_tuple[i]

thanks,
- dimitri.







"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
01/06/2006 13:25
Please respond to "Adrian Farrel"
 
        To:     <[e-mail]>, "Diego Caviglia" 
<[e-mail]>
        cc:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" 
<[e-mail]>, "Dino Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        Re: A new ID is available on the repository 
draft-caviglia-ccamp-   pc-and-sc-reqs-00


Hi,

I read Dimitri's comments as being spatial not temporal.
I.e. he drew a figure showing four LSRs.

Dimitri?

Cheers,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: """'Adrian Farrel'" <adrian"" <[e-mail]>; 
"Dimitri.Papadimitriou" <[e-mail]>; "ccamp" 
<[e-mail]>; "Dino Bramanti <Dino.Bramanti" 
<[e-mail]>; "Dan Li <danli" <[e-mail]>
Sent: Thursday, June 01, 2006 8:20 AM
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- 

pc-and-sc-reqs-00


>
> Hi Vijay,
>          some answers in line.
>
> Regards
>
> Diego
>
>
>
> "Pandian, Vijay" <[e-mail]>@ops.ietf.org on 
> 01/06/2006
> 04.34.12
>
> Sent by:    [e-mail]
>
>
> To:    "'Adrian Farrel'" <[e-mail]>,
>       [e-mail]
> cc:    [e-mail], Diego Caviglia <[e-mail]>,
>       Dino Bramanti <[e-mail]>
>
> Subject:    RE: A new ID is available on the repository
>       draft-caviglia-ccamp-  pc-and-sc-reqs-00
>
> Adrian and Dimitri,
>
> Not sure why we need extra requirements to handle this case. Also not 
sure
> why CP needs to guarantee identical states at [a] and [b]. May be I am 
not
> understanding the case that is being pictured here.
>
> The way I read the requirements, once the control is transferred to MP
> (i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't 
it?
> [dc] That is the idea.
>
> If this is true, then MP -> CP[b] should be treated as the ONLY general
> case
> of MP -> CP conversion, right?
> [dc] Yes, unless Dimitri calirifies better what he intend with state[a] 
> and
> state[b]
>
> Regards,
> Vijay
>
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2006 7:18 PM
> To: [e-mail]
> Cc: [e-mail]; Diego Caviglia; Dino Bramanti
> Subject: Re: A new ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Interesting question.
>
> It would certainly be the case that the picture you draw could arise. I
> guess we would describe this in terms of SPCs. Is it necessary that
> identical state is held at [a] and [b]. In particular, the question of
> Session ID and LSP ID spring to mind.
>
> Yes, we need clear requirements for this type of situation.  Want to
> suggest
>
> some?
>
> Adrian
>
> ----- Original Message -----
> From: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
> "Dino Bramanti" <[e-mail]>
> Sent: Wednesday, May 31, 2006 7:44 PM
> Subject: Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>> agreed -
>>
>> question: in case of move CP->MP who guarantees that the CP at state 
[b]
>> retrieves its states it had at [a] e.g.
>>
>> MP->CP[a]->MP->CP[b]?
>>
>> do we need a specific requirement for this case ?
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <[e-mail]>
>> Sent by: [e-mail]
>> 25/05/2006 19:53
>> Please respond to "Adrian Farrel"
>>
>>        To:     <[e-mail]>, "Diego Caviglia"
>> <[e-mail]>
>>        cc:     "Dan Li <danli", "Dino Bramanti"
>> <[e-mail]>
>>        Subject:        Re: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>> Hi Diego,
>>
>> Thanks for putting this I-D together. I think it gives a much clearer
>> picture of what you are trying to achieve with your discussion of 
moving
>> control of an LSP between the management plane and the control plane.
>>
>> This seems like a reasonable set of requirements to me, and I would 
like
>> to
>> see some discussion from folk on whether they think this is valuable
> work,
>>
>> and whether we should start to look for protocol solutions.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Diego Caviglia" <[e-mail]>
>> To: <[e-mail]>
>> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
>> <[e-mail]>
>> Sent: Wednesday, May 24, 2006 8:48 AM
>> Subject: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>>>A new ID is available on the ID repository
>>>
>>
> 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t

>
> xt
>> .
>>>
>>> The ID states some basic requrements for the possibility of turning a
>>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
>> vice
>>> versa, without actually affecting Data Plane traffic, no solutions are
>>> proposed in the ID.
>>>
>>> Abstract
>>>
>>>   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.
>>>
>>>
>>> Comments and suggestions are very welcome sxpecially from the carrier
>>> community.
>>>
>>> Regards
>>>
>>> Diego
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
> 







Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 14:00:23 +0000
To: lidan 37133 <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Diego Caviglia <[e-mail]>, Dino Bramanti <[e-mail]>
Subject: Re:  =?gb2312?B?u9i4tDpSZTogQSBuZXJ3IElEIGlzIGF2YWlsYWJsZSBvbiB0aGU=?= =?gb2312?B?IHJlcG9zaXRvcnkgZHJhZnQtY2F2aWdsaWEtY2NhbXAtcGMtYW5kLXNj?= =?gb2312?B?LXJlcXMtMDA=?MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 2 Jun 2006 15:59:42 +0200
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

aGkgLSB0aGlzIG9uZSBvZiB0aGUgY2FzZSB0byBiZSBjb3ZlcmVkIC0gbm93IGkgZGlkbid0IHll
dCBwcm9wb3NlIGFueSANCnNwZWNpZmljIGJlaGF2aW91ciAtIA0KaSBkaWQganVzdCBtZW50aW9u
IHRoYXQgdGhlIHByb2JsZW0gZXhpc3QgYW5kIHNob3VsZCBiZSBjb25zaWRlcmVkDQoNCg0KDQoN
Cg0KbGlkYW4gMzcxMzMgPGRhbmxpQGh1YXdlaS5jb20+DQowMS8wNi8yMDA2IDE2OjQ5DQogDQog
ICAgICAgIFRvOiAgICAgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0K
ICAgICAgICBjYzogICAgIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+LCBjY2Ft
cEBvcHMuaWV0Zi5vcmcsIA0KRGllZ28gQ2F2aWdsaWEgPERpZWdvLkNhdmlnbGlhQG1hcmNvbmku
Y29tPiwgRGlubyBCcmFtYW50aSANCjxEaW5vLkJyYW1hbnRpQG1hcmNvbmkuY29tPg0KICAgICAg
ICBTdWJqZWN0OiAgICAgICAgu9i4tDpSZTogQSBuZXJ3IElEIGlzIGF2YWlsYWJsZSBvbiB0aGUg
cmVwb3NpdG9yeSANCmRyYWZ0LWNhdmlnbGlhLWNjYW1wLXBjLWFuZC1zYy1yZXFzLTAwDQoNCg0K
SGkgRGltaXRyaSwNCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhdmUgZHJhd24g
YSBzY2VuYXJpbyBsaWtlIHRoaXM6DQpTdGVwIDE6IEEgUEMgaXMgbWlncmF0ZWQgdG8gYSBTQzsN
ClN0ZXAgMjogVGhlbiB0aGUgU0MgaXMgbWlncmF0ZWQgdG8gYSBQQzsNClN0ZXAgMzogVGhlbiB0
aGUgUEMgaXMgbWlncmF0ZWQgdG8gYSBTQyBhZ2FpbjsNCg0KU28gaG93IHRvIGd1YXJhbnRlZSB0
aGUgc3RhdGUgb2YgYSBTQyBhdCB0aGUgc3RlcCAzIGlzIHNhbWUgYXMgdGhlIHN0YXRlIA0Kb2Yg
YSBTQyBhdCB0aGUgc3RlcCAxLCBhbSBJIHJpZ2h0Pw0KIA0KSSB0aGluayB3ZSBkb24ndCBuZWVk
IHRvIGtlZXAgdGhlIHNhbWUgc3RhdGUgb2YgdGhlIFNDIGF0IGRpZmZlcmVudCBzdGVwcywgDQpm
b3IgZXhhbXBsZSwgdGhlIHNlc3Npb24gSUQgb2YgYSBTQyBhdCBzdGVwIDEgTUFZIGJlIGRpZmZl
cmVudCB3aXRoIHRoZSANCnNlc3Npb24gSUQgb2YgYSBTQyBhdCBzdGVwIDMuDQoNCkkgZ3JlYXRs
eSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMsIGhvcGUgeW91IGNhbiBoZWxwIHdpdGggdGhpcyB3
b3JrLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRhbg0KDQotLS0tLSDUrdPKvP4gLS0tLS0NCreivP7I
yzogRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCsjVxto6INDHxtrLxCwgwfnUwiAx
yNUsIDIwMDYgyc/O5zI6NDQNCtb3zOI6IFJlOiBBIG5lcncgSUQgaXMgYXZhaWxhYmxlIG9uIHRo
ZSByZXBvc2l0b3J5IA0KZHJhZnQtY2F2aWdsaWEtY2NhbXAtcGMtYW5kLXNjLXJlcXMtMDANCg0K
PiBhZ3JlZWQgLQ0KPiANCj4gcXVlc3Rpb246IGluIGNhc2Ugb2YgbW92ZSBDUC0+TVAgd2hvIGd1
YXJhbnRlZXMgdGhhdCB0aGUgQ1AgYXQgDQo+IHN0YXRlIFtiXSANCj4gcmV0cmlldmVzIGl0cyBz
dGF0ZXMgaXQgaGFkIGF0IFthXSBlLmcuDQo+IA0KPiBNUC0+Q1BbYV0tPk1QLT5DUFtiXT8gDQo+
IA0KPiBkbyB3ZSBuZWVkIGEgc3BlY2lmaWMgcmVxdWlyZW1lbnQgZm9yIHRoaXMgY2FzZSA/DQo+
IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5j
by51az4NCj4gU2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQo+IDI1LzA1LzIwMDYg
MTk6NTMNCj4gUGxlYXNlIHJlc3BvbmQgdG8gIkFkcmlhbiBGYXJyZWwiDQo+IA0KPiAgICAgICAg
VG86ICAgICA8Y2NhbXBAb3BzLmlldGYub3JnPiwgIkRpZWdvIENhdmlnbGlhIiANCj4gPERpZWdv
LkNhdmlnbGlhQG1hcmNvbmkuY29tPg0KPiAgICAgICAgY2M6ICAgICAiRGFuIExpIDxkYW5saSIs
ICJEaW5vIEJyYW1hbnRpIiANCj4gPERpbm8uQnJhbWFudGlAbWFyY29uaS5jb20+DQo+ICAgICAg
ICBTdWJqZWN0OiAgICAgICAgUmU6IEEgbmVydyBJRCBpcyBhdmFpbGFibGUgb24gdGhlIA0KPiBy
ZXBvc2l0b3J5IA0KPiBkcmFmdC1jYXZpZ2xpYS1jY2FtcC1wYy1hbmQtc2MtcmVxcy0wMA0KPiAN
Cj4gDQo+IEhpIERpZWdvLA0KPiANCj4gVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgSS1EIHRvZ2V0
aGVyLiBJIHRoaW5rIGl0IGdpdmVzIGEgbXVjaCANCj4gY2xlYXJlciANCj4gcGljdHVyZSBvZiB3
aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGFjaGlldmUgd2l0aCB5b3VyIGRpc2N1c3Npb24gb2YgDQo+
IG1vdmluZyANCj4gY29udHJvbCBvZiBhbiBMU1AgYmV0d2VlbiB0aGUgbWFuYWdlbWVudCBwbGFu
ZSBhbmQgdGhlIGNvbnRyb2wgcGxhbmUuDQo+IA0KPiBUaGlzIHNlZW1zIGxpa2UgYSByZWFzb25h
YmxlIHNldCBvZiByZXF1aXJlbWVudHMgdG8gbWUsIGFuZCBJIA0KPiB3b3VsZCBsaWtlIA0KPiB0
byANCj4gc2VlIHNvbWUgZGlzY3Vzc2lvbiBmcm9tIGZvbGsgb24gd2hldGhlciB0aGV5IHRoaW5r
IHRoaXMgaXMgDQo+IHZhbHVhYmxlIHdvcmssIA0KPiANCj4gYW5kIHdoZXRoZXIgd2Ugc2hvdWxk
IHN0YXJ0IHRvIGxvb2sgZm9yIHByb3RvY29sIHNvbHV0aW9ucy4NCj4gDQo+IFRoYW5rcywNCj4g
QWRyaWFuDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiRGll
Z28gQ2F2aWdsaWEiIDxEaWVnby5DYXZpZ2xpYUBtYXJjb25pLmNvbT4NCj4gVG86IDxjY2FtcEBv
cHMuaWV0Zi5vcmc+DQo+IENjOiAiRGFuIExpIDxkYW5saSIgPGRhbmxpQGh1YXdlaS5jb20+OyAi
RGlubyBCcmFtYW50aSIgDQo+IDxEaW5vLkJyYW1hbnRpQG1hcmNvbmkuY29tPg0KPiBTZW50OiBX
ZWRuZXNkYXksIE1heSAyNCwgMjAwNiA4OjQ4IEFNDQo+IFN1YmplY3Q6IEEgbmVydyBJRCBpcyBh
dmFpbGFibGUgb24gdGhlIHJlcG9zaXRvcnkgDQo+IGRyYWZ0LWNhdmlnbGlhLWNjYW1wLXBjLWFu
ZC1zYy1yZXFzLTAwDQo+IA0KPiANCj4gPkEgbmV3IElEIGlzIGF2YWlsYWJsZSBvbiB0aGUgSUQg
cmVwb3NpdG9yeQ0KPiA+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k
cmFmdC1jYXZpZ2xpYS1jY2FtcC1wYy1hbmQtc2MtDQo+IHJlcXMtMDAudHh0DQo+IC4NCj4gPg0K
PiA+IFRoZSBJRCBzdGF0ZXMgc29tZSBiYXNpYyByZXF1cmVtZW50cyBmb3IgdGhlIHBvc3NpYmls
aXR5IG9mIA0KPiB0dXJuaW5nIGENCj4gPiBQZXJtYW5lbnQgQ29ubmVjdGlvbiAoUEMpIGludG8g
YSBTb2Z0IFBlcm1hbmVudCBDb25uZWN0aW9uIChTUEMpIA0KPiBhbmQgDQo+IHZpY2UNCj4gPiB2
ZXJzYSwgd2l0aG91dCBhY3R1YWxseSBhZmZlY3RpbmcgRGF0YSBQbGFuZSB0cmFmZmljLCBubyAN
Cj4gc29sdXRpb25zIGFyZQ0KPiA+IHByb3Bvc2VkIGluIHRoZSBJRC4NCj4gPg0KPiA+IEFic3Ry
YWN0DQo+ID4NCj4gPiAgIEZyb20gYSBDYXJyaWVyIHBlcnNwZWN0aXZlLCB0aGUgcG9zc2liaWxp
dHkgb2YgdHVybmluZyBhIFBlcm1hbmVudA0KPiA+ICAgQ29ubmVjdGlvbiAoUEMpIGludG8gYSBT
b2Z0IFBlcm1hbmVudCBDb25uZWN0aW9uIChTUEMpIGFuZCB2aWNlDQo+ID4gICB2ZXJzYSwgd2l0
aG91dCBhY3R1YWxseSBhZmZlY3RpbmcgRGF0YSBQbGFuZSB0cmFmZmljIGJlaW5nIGNhcnJpZWQN
Cj4gPiAgIG92ZXIgaXQsIGlzIGEgdmFsdWFibGUgb3B0aW9uLiBJbiBvdGhlciB0ZXJtcywgc3Vj
aCBvcGVyYXRpb24gDQo+IGNhbiBiZQ0KPiA+ICAgc2VlbiBhcyBhIHdheSBvZiB0cmFuc2ZlcnJp
bmcgdGhlIG93bmVyc2hpcCBhbmQgY29udHJvbCBvZiBhbg0KPiA+ICAgZXhpc3RpbmcgYW5kIGlu
LXVzZSBEYXRhIFBsYW5lIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgTWFuYWdlbWVudA0KPiA+ICAg
UGxhbmUgYW5kIHRoZSBDb250cm9sIFBsYW5lLCBsZWF2aW5nIGl0cyBEYXRhIFBsYW5lIHN0YXRl
IA0KPiB1bnRvdWNoZWQuPiAgIFRoaXMgbWVtbyBzZXRzIG91dCB0aGUgcmVxdWlyZW1lbnRzIGZv
ciBzdWNoIA0KPiBwcm9jZWR1cmVzIHdpdGhpbiBhDQo+ID4gICBHZW5lcmFsaXplZCBNdWx0aXBy
b3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIG5ldHdvcmsuDQo+ID4NCj4gPg0KPiA+IENv
bW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSB3ZWxjb21lIHN4cGVjaWFsbHkgZnJvbSB0
aGUgDQo+IGNhcnJpZXI+IGNvbW11bml0eS4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPg0KPiA+IERp
ZWdvDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+
IA0KPiANCg0KDQoNCg=



Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 13:58:38 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: "ccamp" <[e-mail]>, "Diego Caviglia" <[e-mail]>, [e-mail]
Subject: Re: A new ID is available on the repository draft-caviglia-ccamp-	pc-and-sc-reqs-00
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 2 Jun 2006 15:56:35 +0200
Content-Type: text/plain; charset="US-ASCII"

hi adrian

CP[I] is to be complemented with I including values from the set 
{t,s[i],lsp[i]}

t      = time
s[i]   = rsvp_instance
lsp[i] = values associated to the P/RSB indexed by 5_tuple[i]

thanks,
- dimitri.







"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
01/06/2006 13:25
Please respond to "Adrian Farrel"
 
        To:     <[e-mail]>, "Diego Caviglia" 
<[e-mail]>
        cc:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" 
<[e-mail]>, "Dino Bramanti <Dino.Bramanti", "Dan Li <danli"
        Subject:        Re: A new ID is available on the repository 
draft-caviglia-ccamp-   pc-and-sc-reqs-00


Hi,

I read Dimitri's comments as being spatial not temporal.
I.e. he drew a figure showing four LSRs.

Dimitri?

Cheers,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: """'Adrian Farrel'" <adrian"" <[e-mail]>; 
"Dimitri.Papadimitriou" <[e-mail]>; "ccamp" 
<[e-mail]>; "Dino Bramanti <Dino.Bramanti" 
<[e-mail]>; "Dan Li <danli" <[e-mail]>
Sent: Thursday, June 01, 2006 8:20 AM
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- 

pc-and-sc-reqs-00


>
> Hi Vijay,
>          some answers in line.
>
> Regards
>
> Diego
>
>
>
> "Pandian, Vijay" <[e-mail]>@ops.ietf.org on 
> 01/06/2006
> 04.34.12
>
> Sent by:    [e-mail]
>
>
> To:    "'Adrian Farrel'" <[e-mail]>,
>       [e-mail]
> cc:    [e-mail], Diego Caviglia <[e-mail]>,
>       Dino Bramanti <[e-mail]>
>
> Subject:    RE: A new ID is available on the repository
>       draft-caviglia-ccamp-  pc-and-sc-reqs-00
>
> Adrian and Dimitri,
>
> Not sure why we need extra requirements to handle this case. Also not 
sure
> why CP needs to guarantee identical states at [a] and [b]. May be I am 
not
> understanding the case that is being pictured here.
>
> The way I read the requirements, once the control is transferred to MP
> (i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't 
it?
> [dc] That is the idea.
>
> If this is true, then MP -> CP[b] should be treated as the ONLY general
> case
> of MP -> CP conversion, right?
> [dc] Yes, unless Dimitri calirifies better what he intend with state[a] 
> and
> state[b]
>
> Regards,
> Vijay
>
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2006 7:18 PM
> To: [e-mail]
> Cc: [e-mail]; Diego Caviglia; Dino Bramanti
> Subject: Re: A new ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Interesting question.
>
> It would certainly be the case that the picture you draw could arise. I
> guess we would describe this in terms of SPCs. Is it necessary that
> identical state is held at [a] and [b]. In particular, the question of
> Session ID and LSP ID spring to mind.
>
> Yes, we need clear requirements for this type of situation.  Want to
> suggest
>
> some?
>
> Adrian
>
> ----- Original Message -----
> From: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
> "Dino Bramanti" <[e-mail]>
> Sent: Wednesday, May 31, 2006 7:44 PM
> Subject: Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>> agreed -
>>
>> question: in case of move CP->MP who guarantees that the CP at state 
[b]
>> retrieves its states it had at [a] e.g.
>>
>> MP->CP[a]->MP->CP[b]?
>>
>> do we need a specific requirement for this case ?
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <[e-mail]>
>> Sent by: [e-mail]
>> 25/05/2006 19:53
>> Please respond to "Adrian Farrel"
>>
>>        To:     <[e-mail]>, "Diego Caviglia"
>> <[e-mail]>
>>        cc:     "Dan Li <danli", "Dino Bramanti"
>> <[e-mail]>
>>        Subject:        Re: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>> Hi Diego,
>>
>> Thanks for putting this I-D together. I think it gives a much clearer
>> picture of what you are trying to achieve with your discussion of 
moving
>> control of an LSP between the management plane and the control plane.
>>
>> This seems like a reasonable set of requirements to me, and I would 
like
>> to
>> see some discussion from folk on whether they think this is valuable
> work,
>>
>> and whether we should start to look for protocol solutions.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Diego Caviglia" <[e-mail]>
>> To: <[e-mail]>
>> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
>> <[e-mail]>
>> Sent: Wednesday, May 24, 2006 8:48 AM
>> Subject: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>>>A new ID is available on the ID repository
>>>
>>
> 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t

>
> xt
>> .
>>>
>>> The ID states some basic requrements for the possibility of turning a
>>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
>> vice
>>> versa, without actually affecting Data Plane traffic, no solutions are
>>> proposed in the ID.
>>>
>>> Abstract
>>>
>>>   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.
>>>
>>>
>>> Comments and suggestions are very welcome sxpecially from the carrier
>>> community.
>>>
>>> Regards
>>>
>>> Diego
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
> 








Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 02:48:26 +0000
Date: Fri, 02 Jun 2006 10:44:03 +0800
From: Dan Li <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
To: "Dean Cheng (dcheng)" <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail], Diego Caviglia <[e-mail]>
Cc: Dino Bramanti <[e-mail]>
Message-id: <006001c685ee$68da3780$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Dean,

Many thanks for your support.

Please see my answer below.

Dan

----- Original Message ----- 
From: "Dean Cheng (dcheng)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>; "Diego Caviglia" <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" <[e-mail]>
Sent: Friday, June 02, 2006 8:17 AM
Subject: RE: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00


Dear Author,

The conversion between PC and SPC as documented is useful
sometimes, and there was example in carriers networks
in the past as such from PC to SPC although with other
data plane technologies. And so I support this I-D.

Some suggestions:

1) Regarding the division of resources (Section 1.2 etc.).

   This is not only an "implementation" issue. If we allow
   the conversion, it should be defined clearly architecturally.

[DL] Ok.

2) In addition to the "ownership" and "resource division",
   it might also be useful to mention interaction and
   resource transition between CP and MP during the conversion
   as required.

[DL] Yes, for PC and SC, there is no interaction between CP and MP, but for SPC, there are some interactions between CP and MP. Could you give us a suggestion requirement on this issue?

3) In Section 4.1, it may be clearer to say normal make-before-break
   is not an option for the requirement here (data plane consistency).

[DL] Ok.

Thanks
Dean 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, May 25, 2006 10:53 AM
> To: [e-mail]; Diego Caviglia
> Cc: Dan Li <danli; Dino Bramanti
> Subject: Re: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> Hi Diego,
> 
> Thanks for putting this I-D together. I think it gives a much 
> clearer picture of what you are trying to achieve with your 
> discussion of moving control of an LSP between the management 
> plane and the control plane.
> 
> This seems like a reasonable set of requirements to me, and I 
> would like to see some discussion from folk on whether they 
> think this is valuable work, and whether we should start to 
> look for protocol solutions.
> 
> Thanks,
> Adrian
> 
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> >A new ID is available on the ID repository  
> >http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-a
> nd-sc-reqs-00.txt.
> >
> > The ID states some basic requrements for the possibility of 
> turning a 
> > Permanent Connection (PC) into a Soft Permanent Connection 
> (SPC) and 
> > vice versa, without actually affecting Data Plane traffic, no 
> > solutions are proposed in the ID.
> >
> > Abstract
> >
> >   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.
> >
> >
> > Comments and suggestions are very welcome sxpecially from 
> the carrier 
> > community.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jun 2006 00:20:12 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Thu, 1 Jun 2006 17:17:55 -0700
Message-ID: <[e-mail]>
Thread-Topic: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Thread-Index: AcaAJQKaYOSLwUFQQpuw6BoUIArs8AFenxow
From: "Dean Cheng \(dcheng\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>, "Dino Bramanti" <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l349; t49207478; x50071478; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; iÜ[e-mail]; z=From:"Dean Cheng \(dcheng\)" <[e-mail]> |Subject:RE: A nerw ID is available on the repository draft-c aviglia-ccamp-pc-and-sc-reqs-00; X=v=cisco.com; h=Fk/zbQ1KlODnZYy5bpBC0GK9hiY=; b=uhOCGBNM/EW8ioRmiTnX2aCa7J+/5ZtrilFh6glX8dSijFI0eaEHR+F52X9FCeHnBPLtp2BM qXOJBcn8S7xpJmgUV7QNlVAAI+kNPicGYtlWgQg2NpSWCgRuSobccxi2;
Authentication-Results: sj-dkim-1.cisco.com; header.FromÜ[e-mail]; dkim=pass ( sig from cisco.com verified; );

Dear Author,

The conversion between PC and SPC as documented is useful
sometimes, and there was example in carriers networks
in the past as such from PC to SPC although with other
data plane technologies. And so I support this I-D.

Some suggestions:

1) Regarding the division of resources (Section 1.2 etc.).

   This is not only an "implementation" issue. If we allow
   the conversion, it should be defined clearly architecturally.

2) In addition to the "ownership" and "resource division",
   it might also be useful to mention interaction and
   resource transition between CP and MP during the conversion
   as required.

3) In Section 4.1, it may be clearer to say normal make-before-break
   is not an option for the requirement here (data plane consistency).

Thanks
Dean 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, May 25, 2006 10:53 AM
> To: [e-mail]; Diego Caviglia
> Cc: Dan Li <danli; Dino Bramanti
> Subject: Re: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> Hi Diego,
> 
> Thanks for putting this I-D together. I think it gives a much 
> clearer picture of what you are trying to achieve with your 
> discussion of moving control of an LSP between the management 
> plane and the control plane.
> 
> This seems like a reasonable set of requirements to me, and I 
> would like to see some discussion from folk on whether they 
> think this is valuable work, and whether we should start to 
> look for protocol solutions.
> 
> Thanks,
> Adrian
> 
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> >A new ID is available on the ID repository  
> >http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-a
> nd-sc-reqs-00.txt.
> >
> > The ID states some basic requrements for the possibility of 
> turning a 
> > Permanent Connection (PC) into a Soft Permanent Connection 
> (SPC) and 
> > vice versa, without actually affecting Data Plane traffic, no 
> > solutions are proposed in the ID.
> >
> > Abstract
> >
> >   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.
> >
> >
> > Comments and suggestions are very welcome sxpecially from 
> the carrier 
> > community.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 01 Jun 2006 15:00:05 +0000
Date: Thu, 01 Jun 2006 22:54:26 +0800
From: lidan 37133 <[e-mail]>
Subject: =?gb2312?B?u9i4tA=?=:RE: A new ID is available on the repository draft-caviglia-ccamp- pc-and-sc-reqs-00
To: "Pandian, Vijay" <[e-mail]>
Cc: 'Adrian Farrel' <[e-mail]>, [e-mail], [e-mail], Diego Caviglia <[e-mail]>, Dino Bramanti <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline

Hi Vijay,

Please see my comments below.

Regards,

Dan


----- Ô­Óʼþ -----
·¢¼þÈË: "Pandian, Vijay" <[e-mail]>
ÈÕÆÚ: ÐÇÆÚËÄ, ÁùÔÂ 1ÈÕ, 2006 ÉÏÎç10:34
Ö÷Ìâ: RE: A new ID is available on the repository draft-caviglia-ccamp- pc-and-sc-reqs-00

> Adrian and Dimitri,
> 
> Not sure why we need extra requirements to handle this case. Also 
> not sure
> why CP needs to guarantee identical states at [a] and [b]. May be 
> I am not
> understanding the case that is being pictured here.

[DL] Agree with you.

> 
> The way I read the requirements, once the control is transferred 
> to MP
> (i.e., CP[a] -> MP), CP should forget everything about this LSP, 
> Isn't it? 

[DL] Yes, CP SHOULD NOT keep any state of this LSP.

> 
> If this is true, then MP -> CP[b] should be treated as the ONLY 
> general case
> of MP -> CP conversion, right?

[DL] Agree with you.

> 
> Regards,
> Vijay
> 
> 
> -----Original Message-----
> From: Adrian Farrel [[e-mail]]
> Sent: Wednesday, May 31, 2006 7:18 PM
> To: [e-mail]
> Cc: [e-mail]; Diego Caviglia; Dino Bramanti
> Subject: Re: A new ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> Interesting question.
> 
> It would certainly be the case that the picture you draw could 
> arise. I 
> guess we would describe this in terms of SPCs. Is it necessary 
> that 
> identical state is held at [a] and [b]. In particular, the 
> question of 
> Session ID and LSP ID spring to mind.
> 
> Yes, we need clear requirements for this type of situation.  Want 
> to suggest
> 
> some?
> 
> Adrian
> 
> ----- Original Message ----- 
> From: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Diego Caviglia" 
> <[e-mail]>; 
> "Dino Bramanti" <[e-mail]>
> Sent: Wednesday, May 31, 2006 7:44 PM
> Subject: Re: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> > agreed -
> >
> > question: in case of move CP->MP who guarantees that the CP at 
> state [b]
> > retrieves its states it had at [a] e.g.
> >
> > MP->CP[a]->MP->CP[b]?
> >
> > do we need a specific requirement for this case ?
> >
> >
> >
> >
> >
> >
> > "Adrian Farrel" <[e-mail]>
> > Sent by: [e-mail]
> > 25/05/2006 19:53
> > Please respond to "Adrian Farrel"
> >
> >        To:     <[e-mail]>, "Diego Caviglia"
> > <[e-mail]>
> >        cc:     "Dan Li <danli", "Dino Bramanti"
> > <[e-mail]>
> >        Subject:        Re: A nerw ID is available on the repository
> > draft-caviglia-ccamp-pc-and-sc-reqs-00
> >
> >
> > Hi Diego,
> >
> > Thanks for putting this I-D together. I think it gives a much 
> clearer> picture of what you are trying to achieve with your 
> discussion of moving
> > control of an LSP between the management plane and the control 
> plane.>
> > This seems like a reasonable set of requirements to me, and I 
> would like
> > to
> > see some discussion from folk on whether they think this is 
> valuable work,
> >
> > and whether we should start to look for protocol solutions.
> >
> > Thanks,
> > Adrian
> >
> > ----- Original Message ----- 
> > From: "Diego Caviglia" <[e-mail]>
> > To: <[e-mail]>
> > Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> > <[e-mail]>
> > Sent: Wednesday, May 24, 2006 8:48 AM
> > Subject: A nerw ID is available on the repository
> > draft-caviglia-ccamp-pc-and-sc-reqs-00
> >
> >
> >>A new ID is available on the ID repository
> >>
> >
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-
> reqs-00.t
> xt
> > .
> >>
> >> The ID states some basic requrements for the possibility of 
> turning a
> >> Permanent Connection (PC) into a Soft Permanent Connection 
> (SPC) and
> > vice
> >> versa, without actually affecting Data Plane traffic, no 
> solutions are
> >> proposed in the ID.
> >>
> >> Abstract
> >>
> >>   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.
> >>
> >>
> >> Comments and suggestions are very welcome sxpecially from the 
> carrier>> community.
> >>
> >> Regards
> >>
> >> Diego
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> > 
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 01 Jun 2006 14:59:57 +0000
Date: Thu, 01 Jun 2006 22:49:49 +0800
From: lidan 37133 <[e-mail]>
Subject: =?gb2312?B?u9i4tA=?=:Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
To: [e-mail]
Cc: Adrian Farrel <[e-mail]>, [e-mail], Diego Caviglia <[e-mail]>, Dino Bramanti <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline

Hi Dimitri,

If I understand correctly, you have drawn a scenario like this:
Step 1: A PC is migrated to a SC;
Step 2: Then the SC is migrated to a PC;
Step 3: Then the PC is migrated to a SC again;

So how to guarantee the state of a SC at the step 3 is same as the state of a SC at the step 1, am I right?
 
I think we don't need to keep the same state of the SC at different steps, for example, the session ID of a SC at step 1 MAY be different with the session ID of a SC at step 3.

I greatly appreciate your comments, hope you can help with this work.

Best regards,

Dan

----- Ô­Óʼþ -----
·¢¼þÈË: [e-mail]
ÈÕÆÚ: ÐÇÆÚËÄ, ÁùÔÂ 1ÈÕ, 2006 ÉÏÎç2:44
Ö÷Ìâ: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00

> agreed -
> 
> question: in case of move CP->MP who guarantees that the CP at 
> state [b] 
> retrieves its states it had at [a] e.g.
> 
> MP->CP[a]->MP->CP[b]? 
> 
> do we need a specific requirement for this case ?
> 
> 
> 
> 
> 
> 
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
> 
>        To:     <[e-mail]>, "Diego Caviglia" 
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti" 
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the 
> repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> Hi Diego,
> 
> Thanks for putting this I-D together. I think it gives a much 
> clearer 
> picture of what you are trying to achieve with your discussion of 
> moving 
> control of an LSP between the management plane and the control plane.
> 
> This seems like a reasonable set of requirements to me, and I 
> would like 
> to 
> see some discussion from folk on whether they think this is 
> valuable work, 
> 
> and whether we should start to look for protocol solutions.
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> >A new ID is available on the ID repository
> > 
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-
> reqs-00.txt
> .
> >
> > The ID states some basic requrements for the possibility of 
> turning a
> > Permanent Connection (PC) into a Soft Permanent Connection (SPC) 
> and 
> vice
> > versa, without actually affecting Data Plane traffic, no 
> solutions are
> > proposed in the ID.
> >
> > Abstract
> >
> >   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.
> >
> >
> > Comments and suggestions are very welcome sxpecially from the 
> carrier> community.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > 
> 
> 
> 
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 01 Jun 2006 11:27:08 +0000
Message-ID: <0ff501c6856e$1b82c6d0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "Dimitri.Papadimitriou" <[e-mail]>, "ccamp" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>, "Dan Li <danli" <[e-mail]>
Subject: Re: A new ID is available on the repository draft-caviglia-ccamp-	pc-and-sc-reqs-00
Date: Thu, 1 Jun 2006 12:25:26 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I read Dimitri's comments as being spatial not temporal.
I.e. he drew a figure showing four LSRs.

Dimitri?

Cheers,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: """'Adrian Farrel'" <adrian"" <[e-mail]>; 
"Dimitri.Papadimitriou" <[e-mail]>; "ccamp" 
<[e-mail]>; "Dino Bramanti <Dino.Bramanti" 
<[e-mail]>; "Dan Li <danli" <[e-mail]>
Sent: Thursday, June 01, 2006 8:20 AM
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- 
pc-and-sc-reqs-00


>
> Hi Vijay,
>          some answers in line.
>
> Regards
>
> Diego
>
>
>
> "Pandian, Vijay" <[e-mail]>@ops.ietf.org on 
> 01/06/2006
> 04.34.12
>
> Sent by:    [e-mail]
>
>
> To:    "'Adrian Farrel'" <[e-mail]>,
>       [e-mail]
> cc:    [e-mail], Diego Caviglia <[e-mail]>,
>       Dino Bramanti <[e-mail]>
>
> Subject:    RE: A new ID is available on the repository
>       draft-caviglia-ccamp-  pc-and-sc-reqs-00
>
> Adrian and Dimitri,
>
> Not sure why we need extra requirements to handle this case. Also not sure
> why CP needs to guarantee identical states at [a] and [b]. May be I am not
> understanding the case that is being pictured here.
>
> The way I read the requirements, once the control is transferred to MP
> (i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it?
> [dc] That is the idea.
>
> If this is true, then MP -> CP[b] should be treated as the ONLY general
> case
> of MP -> CP conversion, right?
> [dc] Yes, unless Dimitri calirifies better what he intend with state[a] 
> and
> state[b]
>
> Regards,
> Vijay
>
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2006 7:18 PM
> To: [e-mail]
> Cc: [e-mail]; Diego Caviglia; Dino Bramanti
> Subject: Re: A new ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Interesting question.
>
> It would certainly be the case that the picture you draw could arise. I
> guess we would describe this in terms of SPCs. Is it necessary that
> identical state is held at [a] and [b]. In particular, the question of
> Session ID and LSP ID spring to mind.
>
> Yes, we need clear requirements for this type of situation.  Want to
> suggest
>
> some?
>
> Adrian
>
> ----- Original Message -----
> From: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
> "Dino Bramanti" <[e-mail]>
> Sent: Wednesday, May 31, 2006 7:44 PM
> Subject: Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>> agreed -
>>
>> question: in case of move CP->MP who guarantees that the CP at state [b]
>> retrieves its states it had at [a] e.g.
>>
>> MP->CP[a]->MP->CP[b]?
>>
>> do we need a specific requirement for this case ?
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <[e-mail]>
>> Sent by: [e-mail]
>> 25/05/2006 19:53
>> Please respond to "Adrian Farrel"
>>
>>        To:     <[e-mail]>, "Diego Caviglia"
>> <[e-mail]>
>>        cc:     "Dan Li <danli", "Dino Bramanti"
>> <[e-mail]>
>>        Subject:        Re: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>> Hi Diego,
>>
>> Thanks for putting this I-D together. I think it gives a much clearer
>> picture of what you are trying to achieve with your discussion of moving
>> control of an LSP between the management plane and the control plane.
>>
>> This seems like a reasonable set of requirements to me, and I would like
>> to
>> see some discussion from folk on whether they think this is valuable
> work,
>>
>> and whether we should start to look for protocol solutions.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Diego Caviglia" <[e-mail]>
>> To: <[e-mail]>
>> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
>> <[e-mail]>
>> Sent: Wednesday, May 24, 2006 8:48 AM
>> Subject: A nerw ID is available on the repository
>> draft-caviglia-ccamp-pc-and-sc-reqs-00
>>
>>
>>>A new ID is available on the ID repository
>>>
>>
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t
>
> xt
>> .
>>>
>>> The ID states some basic requrements for the possibility of turning a
>>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
>> vice
>>> versa, without actually affecting Data Plane traffic, no solutions are
>>> proposed in the ID.
>>>
>>> Abstract
>>>
>>>   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.
>>>
>>>
>>> Comments and suggestions are very welcome sxpecially from the carrier
>>> community.
>>>
>>> Regards
>>>
>>> Diego
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Jun 2006 07:22:07 +0000
Sensitivity: 
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp-	pc-and-sc-reqs-00
To: [e-mail]
Cc: "\"\"'Adrian Farrel'\" <adrian\"" <[e-mail]>, "Dimitri.Papadimitriou" <[e-mail]>, "ccamp" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>, "Dan Li <danli" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Thu, 1 Jun 2006 09:20:00 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Vijay,
          some answers in line.

Regards

Diego



"Pandian, Vijay" <[e-mail]>@ops.ietf.org on 01/06/2006
04.34.12

Sent by:    [e-mail]


To:    "'Adrian Farrel'" <[e-mail]>,
       [e-mail]
cc:    [e-mail], Diego Caviglia <[e-mail]>,
       Dino Bramanti <[e-mail]>

Subject:    RE: A new ID is available on the repository
       draft-caviglia-ccamp-  pc-and-sc-reqs-00

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not sure
why CP needs to guarantee identical states at [a] and [b]. May be I am not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it?
[dc] That is the idea.

If this is true, then MP -> CP[b] should be treated as the ONLY general
case
of MP -> CP conversion, right?
[dc] Yes, unless Dimitri calirifies better what he intend with state[a] and
state[b]

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I
guess we would describe this in terms of SPCs. Is it necessary that
identical state is held at [a] and [b]. In particular, the question of
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to
suggest

some?

Adrian

----- Original Message -----
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>;
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable
work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t

xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   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.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>











Envelope-to: [e-mail]
Delivery-date: Thu, 01 Jun 2006 02:35:37 +0000
Message-ID: <[e-mail]>
From: "Pandian, Vijay" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>,  [e-mail]
Cc: [e-mail], Diego Caviglia <[e-mail]>,  Dino Bramanti <[e-mail]>
Subject: RE: A new ID is available on the repository draft-caviglia-ccamp- pc-and-sc-reqs-00
Date: Wed, 31 May 2006 22:34:12 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not sure
why CP needs to guarantee identical states at [a] and [b]. May be I am not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it? 

If this is true, then MP -> CP[b] should be treated as the ONLY general case
of MP -> CP conversion, right?

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I 
guess we would describe this in terms of SPCs. Is it necessary that 
identical state is held at [a] and [b]. In particular, the question of 
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to suggest

some?

Adrian

----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>; 
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t
xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   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.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>