Subject: [Idr] interoperability of 6PE and native-IPv6 within same network

From: "Ilya Varlashkin" <[email-masked]>
Date: Fri, 9 Jul 2010 13:48:04 +0200

Hi,

while migrating from native IPv6 core to 6PE I've encountered situation
which is not covered by RFC4798 and can potentially cause problems.

Consider a network with native IPv6 where routers speak BGP with
route-reflector(s). Old sessions are between IPv6 addresses. Now I add
new session between IPv4 addresses of the route-reflector and an edge
router to exchange IPv6+label. 

Imagine the route reflectors going through the route selection process
for IPv6 prefix NetA. For whatever reason native IPv6 route happens to
be the best route for NetA. Is it valid for the route reflector to
propagate this route over the session that carries IPv6+label? Route
reflector is not allowed to change the next-hop, and the edge router
expects next-hop to be IPv4 address over IPv6+label session. Is update
containing IPv6 address considered malformed in this situation and
warrants session reset? If so, then session will flap permanently. A
better solution would be to require route-reflector to drop such updates
towards IPv6+label peers. RFC4798 does not address this situation.
Shouldn't 6PE specification consider this scenario and not leave it up
to implementations to define the behaviour?

Cheers,
iLya

---

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 12 Jul 2010 03:15:03 +0000

> router to exchange IPv6+label.

I suspect the best current practise should be not to mix native and 6PE 
routes on the same reflector. I.e. as part of the migration you describe 
one should create a new reflector for 6PE and after the migration is 
complete one can scrap the old reflector for native IPv6.

I suppose this should be written down somewhere?

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology

---

From: Renwei Li <[email-masked]>
Date: Mon, 12 Jul 2010 09:20:10 -0700

As a matter of fact, they can be mixed on the same reflector. If the
implementation is correct, they should use different SAFI to differentiate
them.

/RL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aleksi
Suhonen
Sent: Sunday, July 11, 2010 8:15 PM
To: [email-masked]
Subject: Re: [Idr] interoperability of 6PE and native-IPv6 within same
network

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 12 Jul 2010 18:41:03 +0200

> As a matter of fact, they can be mixed on the same reflector. 
> If the implementation is correct, they should use different 
> SAFI to differentiate them.
> 
How do you tell native-v6 next-hop from 6pe next-hop within AFI=2 SAFI=4
update?

/iLya

---

From: Renwei Li <[email-masked]>
Date: Mon, 12 Jul 2010 09:57:59 -0700

As their SAFIs are different, the received RIB-INs should not be leaked into
each other, nor should they be combined into a single one. And therefore
they will be undergoing different Best Path Selection Processes. As a
result, you will see that for the same route, there will be two paths: one
is a native IPv6 routed path with a V6 next hop, and the other is
BGP-labeled path with a V4 next hop which is expected to be transported over
a v4-signalled MPLS LSP. 

/RL

-----Original Message-----
From: Ilya Varlashkin [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 9:41 AM
To: [email-masked]; [email-masked]
Subject: RE: [Idr] interoperability of 6PE and native-IPv6 withinsame
network

/iLya

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 Jul 2010 15:18:22 -0400

I think the question was:

+-----+              +------+             +------+
|     |   Native     |      |    6PE      |      |
|  R1 |--------------|  RR  |-------------|  PE  |
|     |    IPv6      |      |             |      |
+-----+              +------+             +------+

No tunnel exists between R1 and PE.
Should the RR form a tunnel to PE and pass the traffic
between the native IPv6 and the tunnel?

I don't think it should that, because then the traffic
will go through the RR. A better way is

+-----+              +------+             +------+
|     |     6PE      |      |    6PE      |      |
|  R1 |--------------|  RR  |-------------|  PE  |
|     |              |      |             |      |
|     |  Native Ipv6 |      |             |      |
|     |--------------|      |             |      |
|     |              |      |             |      |
+-----+              +------+             +------+
   |       Tunnel                             |
   +------------------------------------------+

Then the RR does not forward traffic. The RR just
passes on the tunnel endpoint IPv4 nexthop of R1 to PE.
Or as Aleksi suggested, split the RR in two, one for
Native IPv6 and the other for 6PE.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ilya Varlashkin
Sent: Monday, July 12, 2010 9:41 AM
To: [email-masked]; [email-masked]
Subject: Re: [Idr] interoperability of 6PE and native-IPv6 withinsame network

/iLya

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Jul 2010 15:46:09 -0500

Hi Ilya,

Good scenario. Pls see inline,

> propagate this route over the session that carries IPv6+label? Route

No, ideally speaking, since IPv6 and 6PE are different SAFI. 

> warrants session reset? If so, then session will flap permanently. A

Yes, Yes, IMO, if the route did get advertised to the client (despite
SAFI not being negoitated).

> better solution would be to require route-reflector to drop such
> updates towards IPv6+label peers. 

Fully agreed.

> RFC4798 does not address this situation.

Agreed. It is reasonable to produce a 4798bis for this.

Cheers,
Rajiv

> Sent: Friday, July 09, 2010 7:48 AM
> To: [email-masked]
> Subject: [Idr] interoperability of 6PE and native-IPv6 within same
> network
> 
> Hi,
>

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 Jul 2010 17:23:22 -0400

To send the IPv6 address in the nexthop field of a 6PE message
is simply a bug. RFC 4798 has adequate words to that effect:

      The IPv4 address of the egress 6PE
      router MUST be encoded as an IPv4-mapped IPv6 address in the BGP
      Next Hop field.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Monday, July 12, 2010 1:46 PM
To: Ilya Varlashkin; [email-masked]
Subject: Re: [Idr] interoperability of 6PE and native-IPv6 within same network

Hi Ilya,

Fully agreed.

Cheers,
Rajiv

> updates

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Jul 2010 16:52:53 -0500

Jakob,

> is simply a bug. 

That's not quite accurate, since labeled IPv6 advertisement can very
well have IPv6 address in the next-hop field, per RFC3107. There is NO
way for the receiving router to differentiate 6PE update message from a
native IPv6 labeled advertisement, since both use the same AFI/SAFI
(2/4).

The only way to differentiate is to look at the Next-hop field itself,
since it would be an IPv4-mapped IPv6 address (6PE case) or regular IPv6
address.

Having said all that, Ilya's observation is different and is about
route-reflector incorrectly advertising a native IPv6 update to a 6PE
peer, just because the native path became the bestpath. You are right
about it being a bug per your quote, however, that doesn't address
Ilya's point, which is about what should the BGP speaker do when it
receives a native IPv6 update over a 6PE iBGP session --
	- ignore it, tear down the session
	- ignore it, don't tear down the session
Or should the BGP speaker be blocked to even advertised such a route? Of
course, yes.

But this is not explicit in the 6PE draft, and that's what Ilya is
pointing out. This deserves clarity.

Now that I think about it, we could make a case that RFC3107 (instead of
RFC4798) is the right place for such clarification, since it is about
labeled SAFI (1/4 or 2/4) vs. unlabeled SAFI (1/1 or 2/1) having the
same route. Needs to double-check the wording there.

Cheers,
Rajiv

> From: Jakob Heitz [mailto:[email-masked]]
> Sent: Monday, July 12, 2010 5:23 PM
> To: Rajiv Asati (rajiva); Ilya Varlashkin; [email-masked]
> Subject: RE: [Idr] interoperability of 6PE and native-IPv6 within
> samenetwork
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> > Ilya Varlashkin

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 Jul 2010 18:08:06 -0400

There is also the question of the label.
Where does the RR get a label?
The old peer did not advertise one, so the RR will have to allocate one.
That means that the RR will have to send it's own address as nexthop,
else the label makes no sense.
It also means the RR will terminate the tunnel and forward the traffic.
Not scalable. 

--
Jakob Heitz.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 2:53 PM
To: Jakob Heitz; Ilya Varlashkin; [email-masked]
Subject: RE: [Idr] interoperability of 6PE and native-IPv6 within samenetwork

Jakob,

Cheers,
Rajiv

Of

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Jul 2010 17:14:32 -0500

Hi Jakob,

Good points. It is downhill from there.:)

Suffice to say that this deserves a bit of text to clarify the expected
behavior. 

Cheers,
Rajiv

> Sent: Monday, July 12, 2010 6:08 PM
Of
> > Rajiv Asati (rajiva)
> > > for IPv6 prefix NetA. For whatever reason native IPv6 route
happens
> > to
> > > Shouldn't 6PE specification consider this scenario and not leave
it
> > up
> > > for IPv6 prefix NetA. For whatever reason native IPv6 route
happens
> > to
> > > Shouldn't 6PE specification consider this scenario and not leave
it
> > up

---

From: Renwei Li <[email-masked]>
Date: Mon, 12 Jul 2010 15:53:12 -0700

I don't see any issue with the original spec. The standard is just fine (but
it is OK to clarify its use in such a scenario in some more words).

This problem comes out as an incorrect mixed-up of RIB-INs with different
AFI/SAFI.
 
The RR will select the best path for each AFI/SAFI, and thus it will
generate the same route with two different paths: one is a native IPv6
routed path with a V6 next hop, and the other is BGP-labeled path with a V4
next hop which is expected to be transported over a v4-signalled MPLS LSP.

The same route will be announced to the RR's clients in two different
updates for each AFI/SAFI, respectively. And therefore the RR's clients will
get the two correct BGP routes, assuming the RR's clients have supported the
both capabilities. Which path will be used for forwarding is then a local
issue of the implementation, and most of the implementations prefer label
switched path to the routed path.

/RL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv
Asati (rajiva)
Sent: Monday, July 12, 2010 1:46 PM
To: Ilya Varlashkin; [email-masked]
Subject: Re: [Idr] interoperability of 6PE and native-IPv6 within same
network

Hi Ilya,

Fully agreed.

Cheers,
Rajiv

---

From: Renwei Li <[email-masked]>
Date: Mon, 12 Jul 2010 15:57:14 -0700

NO way. RR should not allocate any label. The sole purpose of RR is just
"reflecting" what it receives to its clients. In the case of iBGP, RR is not
even allowed to change the BGP next hop otherwise you will suffer from some
unexpected behaviour. The RR's own address should not be used as the next
hop.

/RL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob
Heitz
Sent: Monday, July 12, 2010 3:08 PM
To: Rajiv Asati (rajiva); Ilya Varlashkin; [email-masked]
Subject: Re: [Idr] interoperability of 6PE and native-IPv6 within
samenetwork

--
Jakob Heitz.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 2:53 PM
To: Jakob Heitz; Ilya Varlashkin; [email-masked]
Subject: RE: [Idr] interoperability of 6PE and native-IPv6 within
samenetwork

Jakob,

Cheers,
Rajiv

Of

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 Jul 2010 19:23:58 -0400

I absolutely agree.

The ultimate conclusion is that the RR can not reflect routes
from the IPv6 peer to the 6PE peer, because the IPv6 peer
advertised no labels for those routes. 

You can not advertise routes between labeled and non-labeled
spaces, unless you are willing to terminate the tunnels.
Not technically impossible, just not scalable if you do it
on an RR.

--
Jakob Heitz.

-----Original Message-----
From: Renwei Li [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 3:57 PM
To: Jakob Heitz; 'Rajiv Asati (rajiva)'; 'Ilya Varlashkin'; [email-masked]
Subject: RE: [Idr] interoperability of 6PE and native-IPv6 within samenetwork

/RL

-----Original Message-----

--
Jakob Heitz.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 2:53 PM
To: Jakob Heitz; Ilya Varlashkin; [email-masked]
Subject: RE: [Idr] interoperability of 6PE and native-IPv6 within
samenetwork

Jakob,

Cheers,
Rajiv

Of

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 13 Jul 2010 12:57:10 +0200

> Not technically impossible, just not scalable if you do it on an RR.
> 

The peering topology for this discussion is essentially what Jakob has
said: [r1]---[rr]---[6pe1], some other 6pe routers may send IPv6+labels
to the RR, but for the purpose of this issue those updates should be
considered as less preferred than those coming from r1.

I share the PoV that RR should not allocate a label for any update. I
could rephrase my question as: which part of what RFC does specify: a)
whether RR is allowed to send an update that contains native IPv6 next
hop on 6PE session; and b) how should receiver react on seeing native v6
next-hop in an incoming update - tear session or try to use next-hop or
completely ignore the update. My experience is that receiver tends to
reset session, while my opinion is that it should silently ignore the
update.

/iLya