The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS/BGP routing question
Hi Jim You are right, I forgot to mention that the MP-BGP next hop can change due to the fact that the CPE is multihomed. That change must be transparent for the customer traffic. Transparency of the provider network like opaque packet transport should be a requirements for designing IP VPN. Regards herve **************************************************************** Hervé Guesdon DAC/CPN/RRI Research and Development Engineer IP Routing and VPN lab France Télécom - R&D 38-40 rue du Général-Leclerc 92794 Issy Moulineaux Cedex 9 France phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 **************************************************************** "L'avenir c'est du passé en préparation." >-----Message d'origine----- >De : Jim Guichard [mailto:jguichar@cisco.com] >Envoyé : lundi 2 octobre 2000 16:43 >À : GUESDON Herve FTRD/DAC/ISS; 'S.Matsushima'; erosen@cisco.com >Cc : mpls@UU.NET; 'nbvpn@bbo.com' >Objet : RE: MPLS/BGP routing question > > >it seems reasonable to suppose that if the BGP next-hop >changes then the >MP-BGP update has been originated by a different PE router. >This being the >case, then one can assume that the attached VPN site will have >advertised >the route across two separate paths so that two separate PE routers can >originate the route. In this scenario, we should pick the best >path based >on BGP decision process and if this best path goes away, we >would revert to >the other path, hence tranparency to the VPN traffic. Not sure >how else the >BGP next-hop would change .. regards, Jim > >At 08:04 02/10/2000 +0200, GUESDON Herve FTRD/DAC/ISS wrote: >>Hi >> >>If a network event breaks the MPLS LSP between two PE in a >BGP/MPLS VPN >>design, then I agree that the rerouting is an IGP issue. But >there is also a >>MP-BGP-MPLS synchronisation issue if this rerouting leads to >a change in the >>MP-BGP next hop. The switch to the LSP corresponding to the >new MP-BGP net >>hop has to be transparent to the customer VPN traffic. >> >>Regards >> >>hervé >> >>**************************************************************** >>Hervé Guesdon DAC/CPN/RRI >>Research and Development Engineer >>IP Routing and VPN lab >>France Télécom - R&D >>38-40 rue du Général-Leclerc >>92794 Issy Moulineaux Cedex 9 France >>phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 >>**************************************************************** >> >>"L'avenir c'est du passé en préparation." >> >> >>>-----Message d'origine----- >>>De : S.Matsushima [mailto:satoru@japan-telecom.co.jp] >>>Envoyé : samedi 30 septembre 2000 03:24 >>>À : erosen@cisco.com; Satoru Matsushima >>>Cc : mpls@UU.NET >>>Objet : Re: MPLS/BGP routing question >>> >>> >>>on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: >>> >>>> >>>> Matsushima> When a LSP of PE to PE broken, BGP has no way >>>of LSP broken. >>>> Matsushima> Then, BGP keep up of VPN routes and VPN >>>traffic going to black >>>> Matsushima> hole, until LSP available. >>>> >>>> Matsushima> As a result, VPN customer can not back up >>>their traffic to any >>>> Matsushima> link. >>>> >>>> Matsushima> I think this is one of most seriously problem of >>>BGP/MPLS VPN. >>>> >>>> The situation you are worried about is where there is >>>IGP connectivity >>>> between the edges, but for some reason labeled packets >>>cannot make it from >>>> one edge to another. >>> >>>Yes, exactly. >>> >>>> I guess we don't really see this as a realistic failure >>>> scenario. Sure, buggy software could cause this, but >>>there's a million ways >>>> in which buggy software could cause undetected packet loss. >>>> >>> >>>I think that LSP failure was caused by not only buggy >software but also >>>oparation failure. >>>For example, i) erase a interface as LDP ID ;-< , ii) routes >>>summarization >>>failure on ospf area,... >>> >>>IMO, BGP which on PE should has some way to know of LSP failure. >>>This is for customer. >>> >>>-- >>>Satoru Matsushima >>> >> > > >Jim Guichard CCIE #2069 >Network Design Consultant EMEA >Global Solutions Engineering > >+44 (0)181 756 8806 >Mobile: +44 802 809763 > |
|