Re: [Idr] 6PE-Alt draft

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Vishwas,

> I agree the security part of VRF is incomparable. However what about
> the use of route distinguisher (RD) when the routes themselves are
> unique.

RD is certainly quite useful even if the VPN routes are unique.

Please consider the multi-homed VPN site in a BGP/VPN network having
route reflector(s). Even if the VPN routes (advertised by the
multi-homed VPN site) are unique, without RD, each remote PE routers in
the BGP/VPN network would get only one path to the VPN route (because
the Route Reflector would select and advertise only the bestpath). This
means no traffic loadsharing to the route(s) in multi-homed VPN site.

With RD, the loadsharing can be easily provided, assuming unique RD per
VRF per PE is put in place. This is already a common practice in
deployments out there.

Anyway, we digress from the main point in which your draft is proposing
an alternative to the 6PE, not to the 6VPE. 

Cheers,
Rajiv

PS: This could have also been solved if the BGP route reflector
advertised multiple paths besides the bestpath.


> -----Original Message-----
> From: Vishwas Manral [mailto:[e-mail]] 
> Sent: Friday, February 01, 2008 4:30 PM
> To: Rajiv Asati (rajiva)
> Cc: Jan Novak; [e-mail]; Francois Le Faucheur (flefauch); 
> Ooms Dirk
> Subject: Re: [Idr] 6PE-Alt draft
> 
> Hi Rajeev,
> 
> I agree the security part of VRF is incomparable. However what about
> the use of route distinguisher (RD) when the routes themselves are
> unique.
> 
> That is the reason the draft does not say it is replacing
> BGP-MPLS-IPv6 VPN, it says it could be used as an alternative to
> getting the same functionality, without having to actually implement
> the entire big peace of code required for the same, with added
> policies.
> 
> Thanks,
> Vishwas
> 
> On Feb 1, 2008 12:23 PM, Rajiv Asati (rajiva) 
> <[e-mail]> wrote:
> > Hi Vishwas,
> >
> > Good discussion.
> > It was interesting to see the following excerpt wrt 6VPE -
> >
> > > become IPv6 and the network may still have IPv4. If the assumption
> > > that each device in the IPv6 networks has a Global IPv6 
> address (not
> > > that IPv6 site local has been deprecated), we can do without the
> > > entire BGP MPLS IPv6 VPN functionality.
> >
> > Assuming PE-to-PE tunneling is still in place, yah, you are 
> right from
> > the routing perspective in 6VPE. But how would we prohibit 
> one IPv6 site
> > communicating with another IPv6 site belonging to different 
> enterprises.
> >
> > AFAIK, the benefit of having VRF is beyond just the 
> routing. And that's
> > one of the key components of BGP IP VPN functionality. 6VPE 
> indeed has
> > merits.
> >
> > Perhaps, you intended to point to something else in BGP IPv6 VPN
> > functionality.
> >
> > Cheers,
> > Rajiv
> >
> >
> > > -----Original Message-----
> > > From: Vishwas Manral [mailto:[e-mail]]
> > > Sent: Thursday, January 31, 2008 10:01 AM
> > > To: Jan Novak
> > > Cc: [e-mail]; Francois Le Faucheur (flefauch); Ooms Dirk
> > > Subject: Re: [Idr] 6PE-Alt draft
> > >
> > > Hi Jan,
> > >
> > > I am CC'ing the authors of the 6PE draft to get their 
> views. Let me
> > > explain the draft in greater detail however.
> > >
> > > In 6PE, MP-BGP SAFI family label is used to exchange 
> routes between 2
> > > 6PE routers (a new AFI/ SAFI combination is defined). 
> Each route is
> > > attached with a label (which may be the IPv6 Explicit 
> NULL label). In
> > > the data-plane this label is used as the inner label and the other
> > > label is the tunnel label, which gets the packet from source PE to
> > > destination PE. Once the packet gets to the destination 
> PE, the inner
> > > label is looked up and a POP operation is done on it and the IPv6
> > > header is looked up in the routing table.
> > >
> > > With 6PE-Alt, no additional signaling mechanism is 
> required. All we
> > > need to do is instead of using the signaled label as the 
> inner label,
> > > we use the IPv6 Explicit NULL label. The same operations 
> happen as 6PE
> > > without any explicit signaling of the labels with each 
> route. It helps
> > > prevent all the excess signaling and still providing the 
> exact same
> > > functionality. We are using the meaning implied in the 
> "Explicit NULL
> > > Label". We do not need to signal anything here.
> > >
> > > As an alternate, if you notice in IPv6, the end sites/ 
> devices will
> > > become IPv6 and the network may still have IPv4. If the assumption
> > > that each device in the IPv6 networks has a Global IPv6 
> address (not
> > > that IPv6 site local has been deprecated), we can do without the
> > > entire BGP MPLS IPv6 VPN functionality.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > On Jan 31, 2008 6:31 AM, Vishwas Manral
> > > <[e-mail]> wrote:
> > > > Hi Jan,
> > > >
> > > > You may be missing the scope of the document. There is a
> > > discussion in
> > > > the v6ops group too which .
> > > >
> > > > The idea is simple. We do not need to define a new AFI/ SAFI
> > > > combination to achieve the 6PE functionality. We can 
> just use the
> > > > meaning implied in the IPv6 Explicit NULL label. The 6PE
> > > RFC does talk
> > > > about allowing signaling for the Explicit NULL label in
> > > which case the
> > > > dataplane functionality becomes just the same, but in 6PE
> > > even that is
> > > > signaled using BGP extensions defined in RFC3107.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > >
> > > > On Jan 31, 2008 2:14 AM, Jan Novak <[e-mail]> wrote:
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Just out of curiosity - lets say you have two IPv4 VPNs with
> > > > > overlapping set of Pes and both of them want to provide 6PE
> > > > > service.
> > > > > When the explicit-null encapsulated packets from two different
> > > > > VPNs (but same PE) arrive to the other side PE - how do you
> > > > > decide which is which - e.g. which packet should be shipped to
> > > > > which VPN ??
> > > > >
> > > > > Jan
> > > > >
> > > > >
> > > > > 
> _________________________________________________________________
> > > > > Telly addicts unite!
> > > > > http://www.searchgamesbox.com/tvtown.shtml
> > > >
> > >
> >
> > > _______________________________________________
> > > Idr mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/idr
> > >
> >
> 
_______________________________________________
Idr mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/idr