Subject: Re: Draft L1VPN Charter

From: [email-masked]
Date: Thu, 5 May 2005 17:56:55 +0200

igor,

you mention that the provider's control plane needs to participate in CE-CE control message exchanges, actually this is not the case, RFC 3946 supports the possiblity to request for DCC channel transparency (if supported by the network data plane), and nothing prevents from running the LMP session over the VC-4-Xc connection itself - in case

- concerning the exchange of other control plane information the L1VPN models described since so far does not assume something different from what has been developed in the GMPLS overlay context i.e. the connection at the SDH/circuit level is used by the client control plane to exchange its own control plane information, in case dedicated channel are required - for instance when the client network wants to maintain an out of band control channel - that is to be established over a dedicated VC-4-Xc

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
05/05/2005 08:18 MST

To: Alex Zinin <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked], Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
bcc:
Subject: Re: Draft L1VPN Charter

Alex,

See in-line.

Igor

Alex Zinin <[email-masked]> wrote:

Igor,

> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities
> as in the Basic mode, plus permits utilization of the provider's control
> plane for distribution of user's routing information (e.g. similar to the
> MPLS/BGP model).

> I￭d like to replace this with:

> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities
> as in the Basic mode, plus permits utilization of the provider's control
> plane for distribution of user's arbitrary control plane information
> between the VPN sites including but not limited to routing information.

> Provider network IHMO should make no assumptions on what protocols are
> running within VPNs. Generally speaking, a L1VPN user is not necessarily
> GMPLS controlled network. Furthermore, even in case it does use GMPLS it
> needs L1VPN CE-CE connections to provide (TE) links within VPNs.
> Specifically, the User should be capable to run LMP for such links, it
> also should be possible to establish signaling (RSVP) adjacencies between
> their ends, etc. The bottom line is that distribution of routing
> information between CEs IHMO is not sufficient. I believe this is
> consistent with the requirements stated in ITU-T SG13 L1VPN documents

Distributing "arbitrary" control plane information is a scary idea. In
fact, I should really change that to "reachability" to be even more
specific.

Igor, could you explain how representing CE-CE connections as TE links and
running LMP over them requires additional info to be distributed by the
cloud's control plane?

Alex

Let’s consider a very simple VPN view:

C1-----CE1========CE2-----C2

In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP which requires exchange of IP packets between CE1 and CE2, The fact that there is a data plane connectivity between CE1 and CE2 (realized via L1VPN connection) does not necessarily mean that CE1 and CE2 can use this connection for the purpose of exchanging IP packets. Consider, for instance, the situation when CE1 and CE2 are SDH cross-connects and the CE1-CE2 connection is a VC4-4c LSP. Hence, the Provider network needs to participate in the out-of-band IP packet delivery to make CE1-CE2 LMP session work.

Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP messages will need to be propagated between CE1 and CE2. Prior to that C1 needs to compute a TE path for the LSP, hence it needs to know the attributes of, say, TE link CE2-C2, which could be achieved if routing and TE information is flooded over an IGP adjacency between CE1 and CE2. Mind that just the knowledge of the fact that C2 could be reachable via CE2 is not sufficient – there could be no TE path of the required parameters and quality available between CE2 and C2.

The bottom line is that the Provider network needs to participate in pretty much every aspect of the VPN control plane, and as scary as it sounds, the simplest way to accomplish this is to allow arbitrary control plane connectivity between CEs. If one assumes that VPN control plane is always IP based, the phrase “arbitrary control plane connectivity” could be transformed into “IP connectivity”. However, generally speaking, the VPN control plane may not necessarily be IP based.

Igor

Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 09:26:37 -0700

Igor, Dimitri-

 I just realized that we've again fallen in to the same trap--we're having
 a discussion on technical details here :)

 I'll change the text to say "distribution of some information from user's
 control plane", and we'll leave the rest to you guys and the WG process.

-- 
Alex
http://www.psg.com/~zinin

> you mention that the provider's control plane needs to participate in
> CE-CE control message exchanges, actually this is not the case, RFC 3946
> supports the possiblity to request for DCC channel transparency (if
> supported by the network data plane), and nothing prevents from running
> the LMP session over the VC-4-Xc connection itself - in case 

> - concerning the exchange of other control plane information the L1VPN
> models described since so far does not assume something different from
> what has been developed in the GMPLS overlay context i.e. the connection
> at the SDH/circuit level is used by the client control plane to exchange
> its own control plane information, in case dedicated channel are required
> - for instance when the client network wants to maintain an out of band
> control channel - that is to be established over a dedicated VC-4-Xc

> To:Alex Zinin <[email-masked]>
> cc:Kireeti Kompella <[email-masked]>, Adrian Farrel
> <[email-masked]>, [email-masked], [email-masked],
> Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> bcc:
> Subject:Re: Draft L1VPN Charter

> In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use
> LMP which requires exchange of IP packets between CE1 and CE2, The fact
> that there is a data plane connectivity between CE1 and CE2 (realized via
> L1VPN connection) does not necessarily mean that CE1 and CE2 can use this
> connection for the purpose of exchanging IP packets. Consider, for
> instance, the situation when CE1 and CE2 are SDH cross-connects and the
> CE1-CE2 connection is a VC4-4c LSP. Hence, the Provider network needs to
> participate in the out-of-band IP packet delivery to make CE1-CE2 LMP
> session work.

> Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP
> messages will need to be propagated between CE1 and CE2. Prior to that C1
> needs to compute a TE path for the LSP, hence it needs to know the
> attributes of, say, TE link CE2-C2, which could be achieved if routing
> and TE information is flooded over an IGP adjacency between CE1 and CE2.
> Mind that just the knowledge of the fact that C2 could be reachable via
> CE2 is not sufficient – there could be no TE path of the required
> parameters and quality available between CE2 and C2.

> The bottom line is that the Provider network needs to participate in
> pretty much every aspect of the VPN control plane, and as scary as it
> sounds, the simplest way to accomplish this is to allow arbitrary control
> plane connectivity between CEs. If one assumes that VPN control plane is
> always IP based, the phrase “arbitrary control plane connectivity”
> could be transformed into “IP connectivity”. However, generally
> speaking, the VPN control plane may not necessarily be IP based.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 5 May 2005 09:50:02 -0700 (PDT)

Great idea. That is, actually, more or less what I was asking for.
 
Igor

> Igor Bryskin 

> To:Alex Zinin 
> cc:Kireeti Kompella , Adrian Farrel
> , [email-masked], [email-masked],

> ¡@

> ¡@

> Alex Zinin wrote: 

>> Iùþd like to replace this with:

> ¡@

> Let¡¦s consider a very simple VPN view:

> ¡@

> ¡@

> ¡@

> CE2 is not sufficient ¡V there could be no TE path of the required

> ¡@

> always IP based, the phrase ¡§arbitrary control plane connectivity¡¨
> could be transformed into ¡§IP connectivity¡¨. However, generally

> ¡@

> ¡@

> ¡@

> Take Yahoo! Mail with you! Check email on your mobile phone.

---------------------------------
Discover Yahoo!
 Get on-the-go sports scores, stock quotes, news & more. Check it out!

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 10:00:05 -0700

OK, I'm sending the updated charter to the L1VPN mailing + rtg-dir.
If any of you are not on one of the lists--please subscribe to l1vpn.
Thanks.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 5 May 2005 11:57:21 -0700 (PDT)

Dimitri,

[email-masked] wrote:
igor,

you mention that the provider's control plane needs to participate in CE-CE control message exchanges, actually this is not the case, RFC 3946 supports the possiblity to request for DCC channel transparency (if supported by the network data plane)

IB>> What if not? Also what if CEs need to exchange control plane information before actual L1VPN connection is established?

, and nothing prevents from running the LMP session over the VC-4-Xc connection itself - in case 

IB>> True, but only if controllers can insert/extract control plane packets to/from the SDH payload.

Igor

Alex,

¡@

See in-line.

¡@

Igor

Igor,

Alex

¡@

¡@

¡@

¡@

Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP messages will need to be propagated between CE1 and CE2. Prior to that C1 needs to compute a TE path for the LSP, hence it needs to know the attributes of, say, TE link CE2-C2, which could be achieved if routing and TE information is flooded over an IGP adjacency between CE1 and CE2. Mind that just the knowledge of the fact that C2 could be reachable via CE2 is not sufficient ¡V there could be no TE path of the required parameters and quality available between CE2 and C2.

¡@

The bottom line is that the Provider network needs to participate in pretty much every aspect of the VPN control plane, and as scary as it sounds, the simplest way to accomplish this is to allow arbitrary control plane connectivity between CEs. If one assumes that VPN control plane is always IP based, the phrase ¡§arbitrary control plane connectivity¡¨ could be transformed into ¡§IP connectivity¡¨. However, generally speaking, the VPN control plane may not necessarily be IP based.

¡@

Igor

¡@

¡@

Yahoo! Mail Mobile

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com