Subject: Re: [Idr] 6PE-Alt draft

From: Martin Horneffer <[email-masked]>
Date: Fri, 1 Feb 2008 10:07:33 +0100

Hi Vishwas,

just a quick question from an operator's point of view: what is your
consideration of how a P device (IPv4/MPLS only) should do the
load-sharing for 6PE traffic in case of ECMP?

If I got it correctly 6PE allows the egress PE to use different labels
which would make it easy for a P device to load-share. It does not
have to, though...

Best regards, Martin

On Thu, Jan 31, 2008 at 09:32:01AM -0800, Vishwas Manral wrote:
> Hi Jan,
> 
> Unlike in BGP MPLS IP VPN, the label does not tell any interface as we
> finally look up the only routing table the IPv6 routing table. We do
> not have the VRF concept here. That is the reason we do not need any
> presignaled label. The 6PE draft mentions why we need the top label
> very clearly.
> 
> However they have wrongly decided to signal a label with each route
> instead of just using the IPv6 Explicit NULL label.
> 
> Thanks,
> Vishwas
> 
> On Jan 31, 2008 9:00 AM, Jan Novak <[email-masked]> wrote:
> >
> >
> >
> > Hi Vishwas,
> >
> > I believe you refer to this part of 6PE spec:
> >
> >    The label bound by MP-BGP to the IPv6 prefix indicates to the egress
> >    6PE Router that the packet is an IPv6 packet.  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.  An
> >    ingress 6PE Router MUST be able to accept any such advertised label.
> >
> > I don't know what is the envisaged use of Explicit Null here - but I would think
> > it is for some other purposes since to deliver the packet to the VPN this is
> > still needed "identifies an IPv6 routing context or outgoing interface to".
> >
> > Jan
> >
> >
> >
> >
> > _________________________________________________________________
> > Share what Santa brought you
> > https://www.mycooluncool.com
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

-- 
Dr. Martin Horneffer
T-Com Center Technology Engineering
Internet Backbone Architecture

Deutsche Telekom AG
Supervisory Board: Dr. Klaus Zumwinkel (Chairman)
Board of Management: René Obermann (Chairman),
Dr. Karl-Gerhard Eick (Deputy Chairman),
Hamid Akhavan, Timotheus Höttges, Thomas Sattelberger
Commercial register: Amtsgericht Bonn HRB 6794,
corporate seat: Bonn
WEEEreg.no: DE50478376
_______________________________________________
Idr mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/idr

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 1 Feb 2008 09:26:38 -0800

Hi Martin,

The load sharing and everything else on the of P devices will still
work the same way. So we would have for example LDP running on the P
routers giving out labels for FEC's just the same way. The P device
works on the outer Tunnel label and its functionality will not change
in my view.

There is a case of having different labels for preventing one IPv6
lookup in some cases but in case we had the ECMP case we would have to
use the IPv6 header lookup and use the inner label as an IPv6 Explicit
NULL label.

Do let me know if I missed the point?

Thanks,
Vishwas

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 1 Feb 2008 15:23:01 -0500

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:[email-masked]] 
> Sent: Thursday, January 31, 2008 10:01 AM
> To: Jan Novak
> Cc: [email-masked]; 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 
> <[email-masked]> 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 <[email-masked]> 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
> >
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 1 Feb 2008 13:29:47 -0800

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 3 Feb 2008 11:03:56 -0500

Hi Vishwas,

> the use of route distinguisher (RD) when the routes themselves are

RD is certainly quite useful even if the VPN routes are unique.

Please consider the multi-homed VPN site in a BGP/VPN network having
route reflector(s). Even if the VPN routes (advertised by the
multi-homed VPN site) are unique, without RD, each remote PE routers in
the BGP/VPN network would get only one path to the VPN route (because
the Route Reflector would select and advertise only the bestpath). This
means no traffic loadsharing to the route(s) in multi-homed VPN site.

With RD, the loadsharing can be easily provided, assuming unique RD per
VRF per PE is put in place. This is already a common practice in
deployments out there.

Anyway, we digress from the main point in which your draft is proposing
an alternative to the 6PE, not to the 6VPE. 

Cheers,
Rajiv

PS: This could have also been solved if the BGP route reflector
advertised multiple paths besides the bestpath.

> Sent: Friday, February 01, 2008 4:30 PM
> To: Rajiv Asati (rajiva)
> Cc: Jan Novak; [email-masked]; Francois Le Faucheur (flefauch); 
> Ooms Dirk

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 03 Feb 2008 13:28:12 -0800

Hi Vishwas,

 > The P device works on the outer Tunnel label and its functionality
 > will not change in my view.

I must say that your view here is incorrect.

There are hardware implementations just like Martin pointed out which 
take not the only top most but _entire_label_stack_ in the mpls packets 
into considerations when hashing in P routers for load sharing purposes.

As far as I can see your proposal breaks this as the second label will 
be always the same thus all packets going to single PE will always take 
the same path.

To address this you would need to change implementations of those P 
routers mpls switching vectors to also consider IPv6 header which is a 
non starter operationally.

Cheers,
R.

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Feb 2008 14:55:05 -0800

Hi Robert/ Martin,

That is an interesting point you bring out.  What you say does make sense.

I agree if load balancing is based on the labels it will not help load
share in case of 6PE-Alt - if we use a constant label. Anyway I would
assume the load sharing mechanism is configurable (what fields to use
to hash) and works within the scope of the router.

Thanks,
Vishwas

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 03 Feb 2008 15:02:18 -0800

Hi Vishwas,

Unfortunately it is not configurable ... as it is done at the forwarding 
layer in hardware ASICs in some implementations I am familiar with.

In fact some just hash on first and last label in stack some indeed 
could hash only on first two or three and some could go up to the IP 
header (if this is IP which is a big question at the P router).

Cheers,
R.

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Feb 2008 15:45:14 -0800

Hi Robert,

I am unaware of the ASIC's you work on, but I guess the entire idea is
that micro-flows do not get reordered and yet use load balancing.

I will update the 6PE-Alt draft with the information you have given.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 3 Feb 2008 20:00:10 -0800

Hi  Robert/ Martin,

One more question.

So are you saying the implementations you know provides a separate
label for each route, or is it per peer?  I guess it is the later, but
just want to reconfirm the same.

Thanks,
Vishwas

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 03 Feb 2008 23:49:46 -0800

Hi Vishwas,

What VPN label allocation scheme to use is often left to the operator by 
the CLI. From P router load balancing point of view the worst is per vrf 
granularity ... your draft proposes per PE.

Cheers,
R.

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 13 Feb 2008 15:29:00 -0800

Hi Robert/ Martin,

I thought over the load balancing case, which seems to be the only
advantage(it is anyway not guaranteed - but best effort) of the 6PE.

Another way to just get the behavior with 6PE of getting different
hashes for a label stack for same tunnel label is to use the label
stack more affectively.

So we can have a label stack which could have either Explicit NULL
IPv6 label, or a combination of Explicit NULL IPv6 label and Explicit
NULL IPv4 label, with the bottom of stack being the Explicit NULL IPv6
label.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 13 Feb 2008 15:30:23 -0800

Hi Robert,

Of course we could use another set of reserved labels (after taking it
from IANA) for Explicit NULL IPv6 label and Explicit NULL IPv4 label.

Thanks,
Vishwas