Re: [Idr] 6PE-Alt draft

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 31 January 2008 19:31 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 1JKf86-00073K-SC; Thu, 31 Jan 2008 14:31:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKf84-000735-J6 for idr@ietf.org; Thu, 31 Jan 2008 14:31:20 -0500
Received: from rn-out-0910.google.com ([64.233.170.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKf82-0005pA-Pe for idr@ietf.org; Thu, 31 Jan 2008 14:31:20 -0500
Received: by rn-out-0910.google.com with SMTP id a46so358771rne.10 for <idr@ietf.org>; Thu, 31 Jan 2008 11:31:16 -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=KzCtmj/LRBTtElNUBet1ZySCz8H4XAZByBYfwWj9YCc=; b=B6uFvr/1GcGxYxNnZBqTg/Y9qtJf7cU8C7tYrUCs4wF4nlwiDA559k8z2/pp4Dk5QBIZvF9d6vKjTcrVVu4mByMKrESOkMpiVv0u+HUsXAxiTjrgk2fspaNeMeqUbVVckAzmAkH3K+Rnr+DqJaSEukM54aKSimxFfmIT8N1uo6s=
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=mEIg8sI/BpLmUfiZ6Hks9Eb5YCry46q9x9jC7iBCDTnWTNQcy9Vc1O3DbB5LUA+fQmlf2xMnDvvMtocVIyL/LWd1QBYvTnLwgn/COqVKWCedZu4U8vTIwfZg9xzePvDMGfI0FfW0nZNnLBTDQG0MDtQXAE8Sep1gB05aNkm2ylw=
Received: by 10.142.246.8 with SMTP id t8mr1515429wfh.8.1201807874636; Thu, 31 Jan 2008 11:31:14 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Thu, 31 Jan 2008 11:31:14 -0800 (PST)
Message-ID: <77ead0ec0801311131r372138fbh389becdd9e101402@mail.gmail.com>
Date: Thu, 31 Jan 2008 11:31:14 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Francois Le Faucheur IMAP <flefauch@cisco.com>
Subject: Re: [Idr] 6PE-Alt draft
In-Reply-To: <77ead0ec0801310923q44251999i8af1b386c8c5bbc2@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> <77ead0ec0801310700j55f10bcah2aae27dd0fea3927@mail.gmail.com> <C6F4F2F4-7113-4611-9723-425A49817D5B@cisco.com> <77ead0ec0801310923q44251999i8af1b386c8c5bbc2@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
Cc: idr@ietf.org, Jan Novak <jjjnovak@hotmail.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

Forwarding Francois reply and my subsequent reply on the v6ops list,
to this list.

Thanks,
Vishwas
====================================================================
Hi Francois,

Thanks a lot for the reply.

It seems the only thing the 6PE RFC does is that it allows different
label allocation policies (for different routes), when no label
allocation is required at all.

If you think people will still use the 6PE approach even when they can
achieve the same without any new signaling extensions (a new AFI/SAFI
pair) then I am fine to position the draft as an option to your draft.
Do let me know if you feel that way?

Thanks,
Vishwas
- Hide quoted text -

On Jan 31, 2008 11:00 AM, Francois Le Faucheur IMAP <flefauch@cisco.com> wrote:
> Hi Vishwas,
>
> I think I've brought up my main points in the previous message so
> will leave it at that for now.
>
> On 31 Jan 2008, at 18:29, Vishwas Manral wrote:
>
> > Hi Francois,
> >
> > As the 6PE-Alt does not require any additional functionality from
> > BGP-IPv6 (yes that is the signaling required - but that is the same
> > required for normal BGP IPv6. For 6PE we use a new AFI/ SAFI and send
> > labels uselessly. So please do not say that the claim no signaling
> > changes are required for 6PE-Alt  is a stretch), and that is why we
> > have inter-operable implementations of 6PE-Alt too. It is not about
> > interoperable implementations alone though. I however am surprised how
> > this simple mechanism was not captured earlier in the review or coding
> > process.
> >
> > We do not need to transport labels at all which are now being
> > transported. Also as the peer decides the label I use, we may have to
> > configure different labels from different peers (thus using bigger
> > keys/ more memory in the tables and a lot of other overload). There is
> > a lot of overhead of signaling and dataplane without any necessity.
> >
> > I also have issues with the 6VPE RFC too but let us tackle issues one
> > at a time. Also please note 6VPE has the concept of VRF's and is used
> > to give VPN services, while VPE is used for basic IPv6 connectivity
> > over MPLS IPv4 coulds. So please do not confuse the 2.
>
> I didn't really feel confused about the 2, but thanks for the advise ^)
>
> Cheers
>
> Francois
>
>
> >
> > Thanks,
> > Vishwas
> >
> > On Jan 31, 2008 8:53 AM, Francois Le Faucheur IMAP
> > <flefauch@cisco.com> wrote:
> >>
> >> On 31 Jan 2008, at 15:25, Vishwas Manral wrote:
> >>
> >>> Hi Francois,
> >>>
> >>> The document I have written does not use signaling
> >>
> >> It is a bit of a stretch to claim that 6PE-Alt does not use
> >> signaling.
> >> 6PE-Alt and 6PE both use MP-BGP to signal IPv6 reachability.  6PE-Alt
> >> would simply save you one field (the label value) inside the same
> >> advertisement.
> >>
> >> On the other hand, 6PE-Alt would restrict operations to only one of
> >> the options allowed in 6PE. The reasons 6PE allowed multiple label
> >> allocation is precisely because different PEs may want to use
> >> different label allocation policies.  For example, one 6PE router may
> >> prefer to allocate per-prefix label in order to be able to forward
> >> packets via label switching as opposed to performing IPv6 lookup. 6PE
> >> allows each PR router to use whatever label allocation scheme it sees
> >> best.
> >>
> >>
> >>> and does not define
> >>> a new AFI/SAFI functionality to achieve the 6PE.
> >>
> >> It is a bit of a stretch to imply that 6PE defines a new AFI/SAFI.
> >> 6PE uses the IPv6 AFI and the SAFI defined in RFC3107 (which for
> >> memory dates back from 2001) precisely for the purpose of binding an
> >> MPLS label when advertising IPv6 reachability.
> >>
> >>>
> >>> The difference is obvious, we get the same functionality
> >>
> >> my impression is that you get a restricted subset of the
> >> functionality (ie forcing every router to use that single label
> >> allocation scheme). This had been discussed before and decided that
> >> such a restriction was undesirable and unnecessary.
> >>
> >>> without
> >>> adding any new signaling mechanism.
> >>
> >> my impression is that both use the same MP-BGP signaling mechanism
> >> except one would save a few bytes in the same MP-BGP advertisements.
> >>
> >> There are multiple interoperable implementations of 6PE today and am
> >> not aware of significant issues with the current 6PE control plane.
> >>
> >> Cheers
> >>
> >> Francois
> >>
>
>

On Jan 31, 2008 9:23 AM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
> Hi Francois,
>
> As the 6PE-Alt does not require any additional functionality from
> BGP-IPv6 (yes that is the signaling required - but that is the same
> required for normal BGP IPv6. For 6PE we use a new AFI/ SAFI and send
> labels uselessly. So please do not say that the claim no signaling
> changes are required for 6PE-Alt  is a stretch), and that is why we
> have inter-operable implementations of 6PE-Alt too. It is not about
> interoperable implmentations alone though. I however am surprised how
> this simple mechanism was not captured earlier in the review or coding
> process.
>
> We do not need to transport labels at all which are now being
> transported. Also as the peer decides the label I use, we may have to
> configure different labels from different peers (thus using bigger
> keys/ more memory in the tables and a lot of other overload). There is
> a lot of overhead of signaling and dataplane without any necessity.
>
> I also have issues with the 6VPE RFC too but let us tackle issues one at a time.
>
> Thanks,
> Vishwas
>
>
> On Jan 31, 2008 8:56 AM, Francois Le Faucheur IMAP <flefauch@cisco.com> wrote:
> >
> > Hi,
> >
> > FYI, here is a note posted on the v6ops list where that topic was brought up
> > first by Vishwas.
> >
> >
> >
> > Begin forwarded message:
> > From: Francois Le Faucheur IMAP <flefauch@cisco.com>
> > Date: 31 January 2008 17:53:54 GMT+01:00
> > To: Vishwas Manral <vishwas.ietf@gmail.com>
> > Cc: Francois Le Faucheur IMAP <flefauch@cisco.com>, v6ops@ops.ietf.org,
> > "Jeremy De Clercq" <jeremy.de_clercq@alcatel-lucent.be>, "Ooms Dirk"
> > <dirk@onesparrow.com>, stuart.prevost@bt.com
> > Subject: Re: 6PE-Alt
> >
> >
> > On 31 Jan 2008, at 15:25, Vishwas Manral wrote:
> >
> >
> > Hi Francois,
> >
> > The document I have written does not use signaling
> >
> > It is a bit of a stretch to claim that 6PE-Alt does not use signaling.
> > 6PE-Alt and 6PE both use MP-BGP to signal IPv6 reachability.  6PE-Alt would
> > simply save you one field (the label value) inside the same advertisement.
> >
> > On the other hand, 6PE-Alt would restrict operations to only one of the
> > options allowed in 6PE. The reasons 6PE allowed multiple label allocation is
> > precisely because different PEs may want to use different label allocation
> > policies.  For example, one 6PE router may prefer to allocate per-prefix
> > label in order to be able to forward packets via label switching as opposed
> > to performing IPv6 lookup. 6PE allows each PR router to use whatever label
> > allocation scheme it sees best.
> >
> >
> >
> > and does not define
> > a new AFI/SAFI functionality to achieve the 6PE.
> >
> > It is a bit of a stretch to imply that 6PE defines a new AFI/SAFI.
> > 6PE uses the IPv6 AFI and the SAFI defined in RFC3107 (which for memory
> > dates back from 2001) precisely for the purpose of binding an MPLS label
> > when advertising IPv6 reachability.
> >
> >
> >
> > The difference is obvious, we get the same functionality
> >
> > my impression is that you get a restricted subset of the functionality (ie
> > forcing every router to use that single label allocation scheme). This had
> > been discussed before and decided that such a restriction was undesirable
> > and unnecessary.
> >
> >
> > without
> > adding any new signaling mechanism.
> >
> > my impression is that both use the same MP-BGP signaling mechanism except
> > one would save a few bytes in the same MP-BGP advertisements.
> >
> > There are multiple interoperable implementations of 6PE today and am not
> > aware of significant issues with the current 6PE control plane.
> >
> > Cheers
> >
> > Francois
> >
> >
> >
> >
> >
> >
> > On 31 Jan 2008, at 16:00, Vishwas Manral wrote:
> >
> > 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