Re: [Idr] 6PE-Alt draft

"Vishwas Manral" <vishwas.ietf@gmail.com> Fri, 01 February 2008 21:28 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: ietfarch-idr-archive@core3.amsl.com
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0480E28C1D1; Fri, 1 Feb 2008 13:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.06
X-Spam-Level:
X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, URIBL_RHS_DOB=1.083]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2jXf3iMGO5I; Fri, 1 Feb 2008 13:28:15 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08393A6915; Fri, 1 Feb 2008 13:28:15 -0800 (PST)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADD33A6915 for <idr@core3.amsl.com>; Fri, 1 Feb 2008 13:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V+rXk1rDzCm for <idr@core3.amsl.com>; Fri, 1 Feb 2008 13:28:14 -0800 (PST)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by core3.amsl.com (Postfix) with ESMTP id D07443A68A6 for <idr@ietf.org>; Fri, 1 Feb 2008 13:28:13 -0800 (PST)
Received: by wr-out-0506.google.com with SMTP id 50so1623981wri.25 for <idr@ietf.org>; Fri, 01 Feb 2008 13:29:48 -0800 (PST)
Received: by 10.142.212.19 with SMTP id k19mr2548222wfg.224.1201901387226; Fri, 01 Feb 2008 13:29:47 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 13:29:47 -0800 (PST)
Message-ID: <77ead0ec0802011329x705024e3ubb514e9556238eb6@mail.gmail.com>
Date: Fri, 01 Feb 2008 13:29:47 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
In-Reply-To: <15B86BC7352F864BB53A47B540C089B604DAB2EE@xmb-rtp-20b.amer.cisco.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <77ead0ec0801310700j55f10bcah2aae27dd0fea3927@mail.gmail.com> <15B86BC7352F864BB53A47B540C089B604DAB2EE@xmb-rtp-20b.amer.cisco.com>
Cc: idr@ietf.org, Jan Novak <jjjnovak@hotmail.com>, Ooms Dirk <dirk@onesparrow.com>, "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
Subject: Re: [Idr] 6PE-Alt draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

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) <rajiva@cisco.com> 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: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