Re: [Idr] 6PE-Alt draft

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 31 January 2008 15:00 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKauO-0002ez-9U; Thu, 31 Jan 2008 10:00:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKauN-0002et-80 for idr@ietf.org; Thu, 31 Jan 2008 10:00:55 -0500
Received: from rn-out-0910.google.com ([64.233.170.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKauL-0007XT-03 for idr@ietf.org; Thu, 31 Jan 2008 10:00:55 -0500
Received: by rn-out-0910.google.com with SMTP id a46so208209rne.10 for <idr@ietf.org>; Thu, 31 Jan 2008 07:00:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Xlwrs7Nb30N0PONg78RkwWosNCpKOK/7akkaKVLi8kI=; b=XgGjdNV4vOrz0LHCDWYtUI5JY4jw63OeXoDqUR5WhwXsYMH10QFF81HeTKjEIRBcK+Y/32wHCeM6dCjv+N6xXeWY1xIVtvJ0z/yH6kAfLb7OZw0zEA9GVbPrN1U91L2Pyqz5kLBzEfstXwSExmMLZqqbpBqtcYfEE+m5wuAeZKo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nX3P3TWiElkHmgakGHyxZWaKpBn9Bm7MROPlJ+Xf9ryOTgUocS+/zRCHqp3wFRwFeh5ineMsvEfKHvtPX+yKiNZ5K8Ho7M2G9DGA3YfLNkn1eyor2zYgSWJT6tBnjiF1vE5VwxsjQWMAAPvVl5nZ5DNAgBA3p7MMTKn8Ntf1Bm8=
Received: by 10.143.36.15 with SMTP id o15mr1186909wfj.182.1201791651357; Thu, 31 Jan 2008 07:00:51 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Thu, 31 Jan 2008 07:00:51 -0800 (PST)
Message-ID: <77ead0ec0801310700j55f10bcah2aae27dd0fea3927@mail.gmail.com>
Date: Thu, 31 Jan 2008 07:00:51 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Jan Novak <jjjnovak@hotmail.com>
Subject: Re: [Idr] 6PE-Alt draft
In-Reply-To: <77ead0ec0801310631r29449dafq961d8a9aecfea098@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <BAY120-W259B9D353746E33D0864CED8370@phx.gbl> <77ead0ec0801310631r29449dafq961d8a9aecfea098@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: idr@ietf.org, Francois Le Faucheur IMAP <flefauch@cisco.com>, Ooms Dirk <dirk@onesparrow.com>
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

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