Subject: 6PE-Alt

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 30 Jan 2008 21:08:26 -0800

Hi folks,

We have written a draft which will possibly replace the 6PE RFC. The
6PE RFC uses a label to be sent along with the prefix for each route.
This label is then used as the "VPN label" (keeping with the
terminology of BGP MPLS IP VPN RFC). However the only use the label
serves is to tell the encapsulated packet is an IPv6 packet, as well
as some additional uses as defined in the RFC.

Because a VPN label is required and its only use is to signal that the
inside packet is IPv6, we instead elegantly use the "IPv6 Explicit
NULL label". This label signals the same information. The advantage is
that labels need not be added with the routes and no such extension is
required. It also considerably simplifies the Multi AS scenarios.

The draft will soon be visible in the IETF site and is attached here.

Thanks,
Vishwas and Manoj

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 31 Jan 2008 11:34:13 +0100

Hello Vishwas,

There are two documents that relate to transport of IPv6 over an IPv4  
MPLS core:
	* RFC4659 (6VPE): IPv6 VPNS over (say) IPv4 MPLS
	* RFC4798 (6PE): IPv6 over IPv4 MPLS

RFC4798 (6PE) already explicitly discusses the option of using the  
IPv6 Explicit Null Label:
"This label advertised by the egress 6PE Router with MP-BGP MAY be an  
arbitrary label value,
    which identifies an IPv6 routing context or outgoing interface to
    send the packet to, or MAY be the IPv6 Explicit Null Label.
"

 From your description below, it sounds like your document  
effectively (re)discusses one particular option of the 6PE approach.  
Is this the case or is there really some new approach that is not  
already covered in 6PE?

Cheers

Francois

Begin forwarded message:

> From: "Vishwas Manral" <[email-masked]>
> Date: 31 January 2008 06:08:26 GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked],  
> [email-masked], [email-masked]
> Subject: 6PE-Alt
>
> Hi folks,
>

￼

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 Jan 2008 06:25:46 -0800

Hi Francois,

The document I have written does not use signaling and does not define
a new AFI/SAFI functionality to achieve the 6PE. The document you have
defined allows the use of signaling the IPv6 Explicit NULL label,
which is different.There is no need to signal an IPv6 Explicit NULL
label, the meaning is already implied in the label.

The difference is obvious, we get the same functionality without
adding any new signaling mechanism. I am well aware of both the RFC's
and if you read the draft carefully, I have mentioned both the RFC's
in the draft.

Thanks,
Vishwas

On Jan 31, 2008 2:34 AM, Francois Le Faucheur IMAP <[email-masked]> wrote:
>  Hello Vishwas,
>
> There are two documents that relate to transport of IPv6 over an IPv4 MPLS
> core:
> RFC4798 (6PE) already explicitly discusses the option of using the IPv6
> Explicit Null Label:
> From your description below, it sounds like your document effectively
> (re)discusses one particular option of the 6PE approach. Is this the case or
> is there really some new approach that is not already covered in 6PE?
>
> Cheers
>
> Francois
>
>
> Begin forwarded message:
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 Jan 2008 06:33:21 -0800

Hi Francois,

To add to what you said. Yes with explicit NULL label use the
dataplane will be just the same, as when in the 6PE draft the Explicit
NULL label is signalled. So the new draft gives the exact same
functionality as 6PE with no extra signaling overhead.

Thanks,
Vishwas

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 31 Jan 2008 17:53:54 +0100

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 Jan 2008 09:29:39 -0800

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.

Thanks,
Vishwas

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 31 Jan 2008 20:00:05 +0100

Hi Vishwas,

I think I've brought up my main points in the previous message so  
will leave it at that for now.

> 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

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 Jan 2008 11:06:48 -0800

Hi Francois,

Thanks a lot for the reply.

It seems the only thing the 6PE draft 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