Don, Please, see in line.
----- Original Message ----- From: "Don Fedyk" <[EMAIL PROTECTED]> To: "Igor Bryskin" <[EMAIL PROTECTED]>; "Drake, John E" <[EMAIL PROTECTED]>; "Acee Lindem" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, May 12, 2006 12:08 PM 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. 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. Auto Discovery IMO has the requirement to learn and distribute VPN members. IB>> Agree, and the point of this discussion is whether the BGP is the only solution or OSPF is a legitimate solution as well. 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. 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 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. 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. 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. 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 > -----Original Message----- > From: Igor Bryskin [mailto:[EMAIL PROTECTED] > Sent: Friday, May 12, 2006 10:59 AM > To: Drake, John E; Acee Lindem > Cc: [EMAIL PROTECTED] > Subject: Re: [L1vpn] Issues and concerns about Basic Mode > OSPF Discovery > > > -----Original Message----- > > From: Igor Bryskin [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 12, 2006 7:20 AM > > To: Drake, John E; Acee Lindem > > Cc: [EMAIL PROTECTED] > > 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 > L1vpn@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/l1vpn > > _______________________________________________ L1vpn mailing list L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn
