Dimitri, The CE-PE link characteristics could be easily placed in a BGP based auto-discovery design. (I think they were in the antecedent I-Ds.)
Further, due to scalability (#s of links) and frequency of updates, it is not clear that the CE-PE links should be placed in the provider's IGP. There is also the issue that you would need to modify the IGP flooding procedures to advertise the CE->PE link characteristics, and the issue that if you do all this, it still only works intra-AS. Btw, the call procedures that we jointly worked on provide yet another mechanism for obtaining CE-PE link characteristics, a pull rather than a push, and they work inter-AS. Thanks, John > -----Original Message----- > From: dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Sent: Monday, March 27, 2006 12:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [L1vpn] Autodiscovery Protocol > > > > [EMAIL PROTECTED] wrote: > > > > > > > > >>o) time - depending on need's importance vs urgency, if dynamic PTI > >>tables population is to be there in a couple of month, or in > >>a couple of > >>years (would like to point out that understimating the time > >>it may take > >>to convince l1/trans networks to make use of BGP may be impacting) > > > > I think I understand the timing issue, but what is the specific > > 'problem' with BGP in relation to L1 transport network? (with BGP being > > used for the purpose of discovery) > > afaik, there is no large "install base" as for IP/MPLS (L3VPN) > > >>o) cost - can be seen both ways is there a need to have a single > >>protocol for LxVPN (x = 1, 2, 3) or is there a need to have a single > >>protocol for L1/TE operations ? so it depends whether operators are > >>looking for integrating their TE operations (including VPN or not) or > >>VPN operations (including TE or not); > > > > Possibly both .. the same/similar protocols for VPN (L1,2,3..) and for > > TE (L1,2,3..). I'm not the same protocols for VPN and TE is that > > obvious, the applications are very different. > > because there is a need to have some characterization of the CE-PE links > (in part. if dual homing like discussed during last L1VPN is going to be > part of the ref.architecture) > > >>o) perf - concerning the protocol perf. we're discussing path vector vs > >>link-state protocol so impact/properties are different by nature but TE > >>processing overhead/impact would be worth investigated (note that this > >>depends on the problem statement e.g. what would be the impact of > >>progressively incorporating TE specific mechanisms for > >>L1(VPN) into BGP if such need is identifed ?) > > > > How is L1VPN discovery related to TE (path computation?) these seem not > > related to me. > > this has been discussed during ietf63 also, having CPI-PPI information > delivers a set of reachable end-points only but the CE-PE links have TE > attributes like any other links that are to be taken into account by the > ingress PE for correctly route the request and reach (one out of the > possible) egress PE > > > If multiple solutions for L1VPN discovery are to be described within the > > IETF, I agree with Julien that not all of them necessarily need to be > > made standard. > > possible but this was not the purpose of my message (as one solution is > more than certainly better than multiple) the real issue is that none of > the proposed approaches is going to be applicable without appropriate > extensions; so it is certainly of interest to have better understanding > of the real motivations behind > > > cheers, > > Eduard > > > > > >>MEURIC Julien RD-CORE-LAN wrote: > >> > >> > >>>Hi all. > >>> > >>>Allow me to get back to the issue raised during the L1VPN meeting: > >>>the autodiscovery protocol. > >>> > >>>I think it is clear for everyone that BGP really fits the > >> > >>job. Thus I > >> > >>>do not see why we would need to add an IGP to do less > >> > >>things. Lots of > >> > >>>drawbacks were even pinpointed during the meeting: more flooding, > >>>less scalability, no AS crossing, less flexibility (full > >> > >>mesh)... but > >> > >>>no real advantage. > >>> > >>>What is more, as Kireeti said, starting with 2 different > >> > >>solutions is > >> > >>>likely to bring more problems than solve any. Since something needs > >>>to be added, I am not sure that extending an IGP (or both if we do > >>>not want to preclude any option...) will be easier/quicker > >> > >>than using > >> > >>>BGP. And if, despite this, some consider it as a 1st step, then I > >>>think we do not need to make it a standard. > >>> > >>>So I am in favour of BGP autodiscovery, but BGP only. > >>> > >>>Best regards, > >>> > >>>Julien > >>> > >>>_______________________________________________ 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 > >> > > > > > > . > > > > _______________________________________________ > 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
