Subject: [Isis-wg] Tsinghua work on source/destination routing

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:45:06 +0000

I'd like to draw your attention to a talk that will be given this morning in homenet. The context is:

http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
  "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
  2013-08-13

http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class
http://tools.ietf.org/html/draft-xu-homenet-traffic-class
  "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang,
  Jianping Wu, Fred Baker, 2013-10-21

http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing
http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 2013-08-22

http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing
http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28

http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend
http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend
  "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
  Baker, 2013-10-15

I had breakfast this morning with Shu Yang, who has been writing Quagga code for several years in the course of his PHd. He first implemented a source/destination model, reported on in draft-xu-homenet-twod-ip-routing, which was an MTR scheme. He tells me he found that very complex. He also listened to my talk in homenet around draft-baker-fun-routing-class, and has now implemented (if I understand him correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-dst-src-routing. The FIB implementation has a limitation: the source prefixes must be disjoint. However, given that, he has two FIB implementations, one of which has separate FIBs for each source prefix in play including ::/0 (so if there are M prefixes in the network, M+1 FIBs), and one of which is a single hierarchical M-Trie that looks up the destination and then the source. He has tested the code in simulation; the next step is testing in live networks.

Examples of use cases are generally around multi-prefix campus networks. There is a security use case that could be of value; at IETF 87, George Michaelson of APNIC reported on ULAs seen in his darknet. The short report is that he sees a fair bit of traffic with a ULA source address on the backbone. An interesting potential use of source/destination routing would counter that, and perhaps mitigate the need for ISP BCP 38 if generally deployed; in a case where a network is using a ULA and a global prefix (e.g., is not multihomed but has two prefixes, one of which is intended to only be used within its network), the default route to the network egress would use the global prefix as a source, and as a result traffic sent outside the network with a ULA source prefix would in effect have no route. The network could literally only emit traffic from its correct prefix.

I think this is relevant to the discussion of 
	draft-baker-rtgwg-src-dst-routing-use-cases
	draft-ietf-ospf-ospfv3-lsa-extend
	draft-baker-ipv6-ospf-dst-src-routing
	draft-baker-ipv6-isis-dst-src-routing

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Nov 2013 17:07:34 +0000

Hi Fred,

It is good to see this discussion, but an alternative approach that should
also be considered is tunneling. In the IRON approach at least, the end
user network gets a stable IPv6 prefix that is independent of the access
network IP addresses it gets from its ISPs. So, there is no need for source
address-based forwarding to ensure that packets sent via ISP A will not
have a source address from ISP B.

The use cases for tunneling are very broad, and probably overlap with the
ones you are considering in this approach. The relevant documents are here:

http://tools.ietf.org/html/draft-templin-ironbis
http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-intarea-seal
  
Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Thursday, November 07, 2013 8:45 AM
> To: Routing WG; [email-masked]; [email-masked]
> Cc: [email-masked] Group; [email-masked] WG
> Subject: [v6ops] Tsinghua work on source/destination routing
> 
> I had breakfast this morning with Shu Yang, who has been writing Quagga code for several years in the
> course of his PHd. He first implemented a source/destination model, reported on in draft-xu-homenet-
> twod-ip-routing, which was an MTR scheme. He tells me he found that very complex. He also listened to
> my talk in homenet around draft-baker-fun-routing-class, and has now implemented (if I understand him
> correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-dst-src-routing. The FIB
> implementation has a limitation: the source prefixes must be disjoint. However, given that, he has two
> FIB implementations, one of which has separate FIBs for each source prefix in play including ::/0 (so
> if there are M prefixes in the network, M+1 FIBs), and one of which is a single hierarchical M-Trie
> that looks up the destination and then the source. He has tested the code in simulation; the next step
> is testing in live networks.
> 
> Examples of use cases are generally around multi-prefix campus networks. There is a security use case
> that could be of value; at IETF 87, George Michaelson of APNIC reported on ULAs seen in his darknet.
> The short report is that he sees a fair bit of traffic with a ULA source address on the backbone. An
> interesting potential use of source/destination routing would counter that, and perhaps mitigate the
> need for ISP BCP 38 if generally deployed; in a case where a network is using a ULA and a global
> prefix (e.g., is not multihomed but has two prefixes, one of which is intended to only be used within
> its network), the default route to the network egress would use the global prefix as a source, and as
> a result traffic sent outside the network with a ULA source prefix would in effect have no route. The
> network could literally only emit traffic from its correct prefix.
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 08 Nov 2013 13:23:54 +0100

> The context is:

A pity you didn't cite any of the previous work on the subject:

  http://tools.ietf.org/html/draft-troan-homenet-sadr-01  

  https://github.com/fingon/hnet-core

  http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing
  http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git  
  
> I had breakfast this morning with Shu Yang, who has been writing
> Quagga code for several years in the course of his PHd.  [...]  and
> has now implemented (if I understand him correctly)
> draft-ietf-ospf-ospfv3-lsa-extend and
> draft-baker-ipv6-ospf-dst-src-routing.

Excellent.  Could we please have a look at the source code ?  (It was
already promised in Berlin, if memory serves.)

Regards,

-- Juliusz

---

From: Shu Yang <[email-masked]>
Date: Fri, 8 Nov 2013 20:51:44 +0800

> already promised in Berlin, if memory serves.)
We will make it public after testing it in live networks (we are still
implementing the Click code, and combining quagga and click
together).

If you want, I can send you the current version privately at this moment.

Shu Yang
Tsinghua University

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Nov 2013 14:37:02 +0100

> We will make it public after testing it in live networks

Ah, I see.

> If you want, I can send you the current version privately at this moment.

I'd much prefer a public repository, something I can discuss freely
with people (and eventually cite) without worrying whether I'm disclosing
anything confidential.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Sun, 10 Nov 2013 15:24:15 +0100

> with people (and eventually cite) without worrying whether I'm disclosing

I agree with Juliusz, a public repository would be much better, even
if it only contains "in development" code.

If the code will be open sourced in the end anyways I don't see any drawbacks.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Shu Yang <[email-masked]>
Date: Mon, 11 Nov 2013 15:06:05 +0800

> If the code will be open sourced in the end anyways I don't see any drawbacks.

Ok, we will make it public in this week.

Shu Yang

---

From: Shu Yang <[email-masked]>
Date: Tue, 19 Nov 2013 16:10:18 +0800

> Ok, we will make it public in this week.
The page for the project is here:
https://github.com/t-routing/traffic-class-routing-system-based-on-OSPFv3
It's still in development status, and we will keep improving it.

Shu Yang

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 19 Nov 2013 11:22:34 +0100

> The page for the project is here: https://github.com/t-routing/
> traffic-class-routing-system-based-on-OSPFv3

Thanks, but could you please point us at your code?  That's a full
Quagga tree merged with a full Click tree, with no development history.

(I've quickly checked the Quagga-FIB interface, and haven't found
anything new in there, but then perhaps I haven't looked hard enough.)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 19 Nov 2013 12:30:59 +0200

On 19.11.2013, at 12.22, Juliusz Chroboczek <[email-masked]> wrote:

> anything new in there, but then perhaps I haven’t looked hard enough.)

Looks like the integration with click is done right from ospf6d and it never even goes to zebra. 

Two tips for next github export:

- save history so it’s more convenient to compare with baseline (now I needed to do fairly arcane diff due to non-clean tree + no history)

- put cleaned tree (no *~, no binaries such as *.o)

Kind of sad, I was hoping for general src+dst aware Quagga code :)

Cheers,

-Markus

---

From: Shu Yang <[email-masked]>
Date: Wed, 20 Nov 2013 16:20:23 +0800

Hi, Markus,

Sorry for uploading a version without any baseline, we have changed it.

We are using Click router, which can also be integrated with Quagga easily,
i.e., Quagga generates the src+dst routing entries and updates Click
through pre-defined interfaces (we will write a detailed Readme file). We
use it because 1) Click is quite modularized (we only need to modify the
two related modules); 2) we have such experiences before.

Shu Yang
Tsinghua University

On Tue, Nov 19, 2013 at 6:30 PM, Markus Stenberg <[email-masked]>wrote:

> - save history so it’s more convenient to compare with baseline (now I
> needed to do fairly arcane diff due to non-clean tree + no history)
>