Subject: RE: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery

From: "Don Fedyk" <[email-masked]>
Date: Fri, 12 May 2006 12:08:14 -0400

Hi Igor

Please note I think that we have to step back and look a requirements.
I see a mixture of auto discovery and path computation requirements all
being mixed together. 

Auto Discovery IMO has the requirement to learn and distribute VPN
members.  

There is also an optional requirement of targeting VPN information where
PE switches are the only nodes that learn VPN membership and that they
do so only when they participate in the VPN. 

There is another optional requirement that the distribution of VPN
information can be controlled by policy -- and I think this is where we
start to get confused. The BGP mechanisms that I understand do this
abstract from the physical topology but they are capable producing
certain connectivity.

However as you point out there are additional requirements due to the
physical nature of L1 when setting up an L1VPN which also affects the
topology. At this point I would say these are for future (perhaps near
future) study.  But these functions are common regardless of how VPN
membership is obtained.  

So I think we should cap VPN discovery at learning and distributing
Membership and then we should look at when we set up L1VPN how we deal
with additional constraints.  Some of these are topological, some are
resource based and some are VPN specific IMHO, but I think we can still
use general mechanisms to address these.  

Regards,
Don 

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]] 
> Sent: Friday, May 12, 2006 10:59 AM
> To: Drake, John E; Acee Lindem
> Cc: [email-masked]
> Subject: Re: [L1vpn] Issues and concerns about Basic Mode 
> OSPF Discovery
> 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[email-masked]]
> > Sent: Friday, May 12, 2006 7:20 AM
> > To: Drake, John E; Acee Lindem
> > Cc: [email-masked]
> > Subject: Re: [L1vpn] Issues and concerns about Basic Mode OSPF
> Discovery
> >
> > >
> > > IB>> I have already answered to this. In the context of the L1VPNs
> > only
> > > PEs
> > > are the users of the TE info, because only them who perform path 
> > > computation, and the only purpose of TE info distribution is to
> enable
> > the
> > > path computation. Likewise PEs are the only users of the L1VPN 
> > > information.
> > > So I don't see any conceptual difference between L1VPN and TE
> > applications
> > > in this respect.
> > >
> >
> > In the TE case, the PEs require the information about the 
> Ps' links in 
> > order to perform CSPF, so the PEs and the Ps are working
> cooperatively.
> > This is not the same as the L1VPN case.
> >
> > IB>> But Ps do not use the TE information. So, from the scalability
> point
> > of
> > view how is different from L1VPN application?
> > Furthermore, in the Routing per-VPN model Ps will have to advertise
> which
> > L1VPNs P links belong to to enable PEs publishing per-VPN resource
> layout
> > to
> > CEs.
> 
> It sounds as though you are proposing that a P link is 
> configured with a list of the VPNs which can use it, and that 
> this information is advertised in the IGP.  If this is what 
> you are proposing, I think it is a truly terrible idea.
> 
> IB>> And why is it so?  Routing per-VPN model requires that 
> PEs provide 
> IB>> the
> attached CEs with info about resource availability of 
> Provider network on per-VPN basis, so that CEs could control 
> the path selection over the Provider network. You have to 
> configure P links (and their attributes) anyway, so you might 
> as well configure the VPN constraints - a simple and light 
> overhead that will make PEs dynamically discover which P 
> links belong to which VPNs.
> 
> I have asked already: how would you accomplish this with BGP?
> 
> Igor
> 
> 
> _______________________________________________
> L1vpn mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l1vpn
> 
> 

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 12 May 2006 14:08:03 -0400

Don,

Please, see in line.

----- Original Message ----- 
From: "Don Fedyk" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; "Drake, John E"
<[email-masked]>; "Acee Lindem" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 12, 2006 12:08 PM
Subject: RE: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery

Hi Igor

IB>> Not at all. Auto Discovery is a part of L1VPN application, computing TE
paths for L1VPN services is another part. Both parts are equally important
and must be supported.

IB>> Agree, and the point of this discussion is whether the BGP is the only
solution or OSPF is a legitimate solution as well.

IB>> And we agree that BGP satisfies this requirement. while OSPF is not,
however, this is, as you pointed out, an optional requirement and only as
important as potential scalability hazard. To summarize our (my at least)
position:
a) OSPF (and requirements to OSPF) in IP networks and L1 networks is/are
fundamentally different, and what is a problem in IP network is not
necessarily a problem in L1 network;
b) From OSPF (support) point of view TE application and L1VPN applications
are very similar, and it is unclear why an OSPF based solution is legitimate
(if not the only one) for TE , while evil for L1VPN

IB>> And here is one of the major disagreements. I believe that it is
important to control the connectivity on per VPN basis, and in the context
of L1 netwroks, the OSPF solution can accomplish this probably better that
the BGP solution.

IB>> Again, one of the near future problems to solve is to publish by PEs
Provider network resource layout to VPNs on per-VPN basis, so that CEs could
control L1VPN service paths accross the Provider network. I have explained
how it could be achieved using OSPF. I have asked several times how it could
be achieved by BGP, and yet to see a single response. We can not just
concentrate on the initial (Auto Discovery) phase without looking ahead at
least on a high level. This would be unwise to say the least.

So I think we should cap VPN discovery at learning and distributing
Membership and then we should look at when we set up L1VPN how we deal
with additional constraints.

IB>> If we make a mistake now, it could be too late.

  Some of these are topological, some are
resource based and some are VPN specific IMHO, but I think we can still
use general mechanisms to address these.

IB>> or maybe not. It could just be that whatever works for layer2 and
layer3 simply does not work for layer 1.

Igor

Regards,
Don

---

From: [email-masked]
Date: Sat, 13 May 2006 10:50:14 +0200

hi don

in general i see where you are landing at but there is also an issue
that for me - but probably for others - is not clear

by definition there are requirements that any solution should cover 
since at the root of what a VPN discovery mechanism implies - these
are part of the base mode (PE-to-PE VPN membership info. exchange)
*** even if the requirement doc does not say a word about this ***

i am looking at the requirement document the group has produced - see
section 7 and 8 & i see four models, each with different implications
on the PE-to-PE information exchange (these models are referred to as
enhanced mode(s): 

a) Overlay extension service model
b) Virtual node service model
c) Virtual link service model
d) Per-VPN peer service model

a) is the natural extension of membership information exchange b/w
CEs ... but what about b), c) and d) ... so in terms of solution we
are confronted to the following issue OSPF vs BGP solving the same 
or non-necessarily identical problems ?

i am quite surprised this discussion happens now because the document
<http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-01.txt>
was initially intended to answer to these questions, in part. when 
it comes the identification on the impact in selecting a specific 
protocol sol. vs proposed service models; however, this doc. mentions 
at several places "Detailed analysis is for further study." including
the base "VPN membership information exchange within the provider network"
see Section 6.1.3

so, the discussion we're having simply shows that we're not mature 
enough to cover more than the base discovery mode and before stepping
toward enhanced modes we certainly need to complete these FFS - the
important point is that before completing this work it is certainly
more than premature to state than one size fits all

thanks,
- dimitri.

"Don Fedyk" <[email-masked]>
12/05/2006 18:08
 
        To:     "Igor Bryskin" <[email-masked]>, "Drake, John E" 
<[email-masked]>, "Acee Lindem" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [L1vpn] Issues and concerns about Basic Mode 
OSPF Discovery

Hi Igor

Regards,
Don