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

[[e-mail]]

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" <[e-mail]>
12/05/2006 18:08
 
        To:     "Igor Bryskin" <[e-mail]>, "Drake, John E" 
<[e-mail]>, "Acee Lindem" <[e-mail]>
        cc:     [e-mail]
        Subject:        RE: [L1vpn] Issues and concerns about Basic Mode 
OSPF Discovery


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:[e-mail]] 
> Sent: Friday, May 12, 2006 10:59 AM
> To: Drake, John E; Acee Lindem
> Cc: [e-mail]
> Subject: Re: [L1vpn] Issues and concerns about Basic Mode 
> OSPF Discovery
> 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[e-mail]]
> > Sent: Friday, May 12, 2006 7:20 AM
> > To: Drake, John E; Acee Lindem
> > Cc: [e-mail]
> > 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l1vpn
> 
> 

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



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