Re: [Idr] 6PE-Alt draft

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:vishwas.ietf@gmail.com] 
> Sent: Thursday, January 31, 2008 10:01 AM
> To: Jan Novak
> Cc: idr@ietf.org; 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 
> <vishwas.ietf@gmail.com> 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 <jjjnovak@hotmail.com> 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
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
> 
_______________________________________________
Idr mailing list
Idr@ietf.org
http://www.ietf.org/mailman/listinfo/idr