Subject: Re: Draft L1VPN Charter

From: Alex Zinin <[email-masked]>
Date: Wed, 4 May 2005 18:07:30 -0700

Hmmm... endorsement? I thought it was about cooperation, whatever that
means, no?

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

Wednesday, May 4, 2005, 4:35:09 PM, [email-masked] wrote:
> alex, i understand ... the reason is to be clear in terms of protocol
> work endorsement (also CCAMP WG was triggered by SG13 during Seoul
> meeting) ... but indeed worth re-explaining the rules of the game

> Alex Zinin <[email-masked]>
> 05/04/2005 15:48 MST
> Please respond to Alex Zinin

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

> Makes my skin crawl after the ITU NGN workshop earlier this week, but I can
> add that. Will have to talk to the future WG chairs to clearly explain that
> this shouldn't become a DoS...

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

> Wednesday, May 4, 2005, 10:23:32 AM, Igor Bryskin wrote:
>> Good idea.
>> Igor

>> [email-masked] wrote:

>> igor, all - now that i am thinking of it there is probably a need to
>> add a sentence like "The WG will also liaise with related ITU-T SGs"
>> after "... and other WGs where necessary."

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

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

>> Alex, All

>> 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

>> Igor

>> Alex Zinin <[email-masked]> wrote:

>> Folks-

>> Before we bring it to the l1vpn mailing list, I'd like to run this draft
>> by you guys for comments.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 5 May 2005 08:18:34 -0700 (PDT)

Alex,

See in-line.

Igor

Igor,

> I#9619;d like to replace this with:

> 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: Igor Bryskin <[email-masked]>
Date: Thu, 5 May 2005 13:47:16 -0700 (PDT)

Dimitri,

> - 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

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

[dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are perfectly capable to support such functionality - did you have any other equipment in mind ? (same applies for ETH o SDH equipment supporting IP based control plane)

IB>> What if CEs are TDM LSRs and the CE-CE connection is a lambda LSP?

Igor

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

Igor,

> Iùþd like to replace this with:

> consistent with the requirements stated in ITU-T SG13 L1VPN do! cuments 

Alex

¡@

Let¡¦s consider a very simple VPN view:

¡@

¡@

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 necessa! rily 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 ¡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 

---------------------------------
Do you Yahoo!?
 Yahoo! Mail - You care about security. So do we.

---

From: [email-masked]
Date: Thu, 5 May 2005 22:53:54 +0200

igor,

> - 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

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

[dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are
perfectly capable to support such functionality - did you have any other
equipment in mind ? (same applies for ETH o SDH equipment supporting IP
based control plane)

[dp] simply by using the RS-DCC or MS-DCC which is then transparent and
over
which IP control packets can be exchanged using RFC 1662

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 5 May 2005 14:17:37 -0700 (PDT)

Dimitri,
 
Are saying that in general if you have a pair of nodes interconnected by a link in any network layer it is always possible to have the nodes exchange control plane (IP) messages over this link by, say,  using overhead bits of a server layer? Do you also believe that the bandwidth that could be used by control plane in this way is always adecuade for all its needs? Why do we need the out-of-band signaling then?
 
Igor

igor,

control

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