Subject: Multiprotocol tunneling over UDP using AERO

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Dec 2014 17:28:55 +0000

Hello,

I am working on a spec for generic tunneling of any protocol over UDP, including
MPLS, GRE, IPsec, etc. The spec is called "AERO", and it includes:

  - an encapsulation format
  - a fragmentation and reassembly capability for MTU mitigation
  - a virtual link model
  - a control messaging mechanism
  - a routing and addressing system based on BGP

https://datatracker.ietf.org/doc/draft-templin-aerolink/

I understand that there have been discussions regarding protocol-specific
GRE and MPLS encapsulations within UDP, but I would like to offer up AERO
as a protocol-independent way of accommodating UDP encapsulations. I
also believe the routing system and other aspects of AERO should be of
interest to the routing area.

This work is derived from an earlier experimental RFC (RFC6706) which was
originally briefed to the routing area several years ago and published as an
AD-sponsored Individual Submission RFC. The current document can be
considered as a second edition of AERO, and the goal is to advance it to
standards track. Please send any comments or questions to the list.

Thanks - Fred
[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Dec 2014 19:49:22 -0000

Hi Fred,

Thanks for the heads-up.

You're right that there has been some work going on in the Routing Area chiefly
around MPLS-in-UDP in the MPLS working group.
There has also been a lot of overlap with the TSV area. Specifically the TSVWG
has had a lot to say about MPLS-in-UDP and also has a document on its books for
GRE-in-UDP (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/)

These try to be conformant to
https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ and there has
been a lot of debate about getting the congestion control and checksum parts of
the work correct.

Now, it should be said that both pieces of this work are handling the
encapsulation only.

They are not looking at forming a "new network layer" in the way that AERO is.

Regards,
Adrian

> -----Original Message-----
> From: routing-discussion [mailto:[email-masked]] On
Behalf
> Of Templin, Fred L
> Sent: 01 December 2014 17:29
> To: [email-masked]
> Subject: Multiprotocol tunneling over UDP using AERO
> 
> Hello,
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Dec 2014 22:46:31 +0000

Hi Adrian,

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, December 01, 2014 11:49 AM
> To: Templin, Fred L; [email-masked]
> Subject: RE: Multiprotocol tunneling over UDP using AERO
> 
> Hi Fred,
> 
> Thanks for the heads-up.
> 

Thanks for the pointer. It appears that this proposal is punting on tunnel fragmentation,
meaning that the tunnel would either have to use IP fragmentation or perform MTU
clamping. We would like for tunnels to be able to support a minimum 1500 MTU and
also allow larger packets when the path MTU is sufficient. Tunnels that clamp the MTU
to something smaller than 1500 can't do that. AERO fixes this by including tunnel
fragmentation to avoid the need for MTU clamping.

> been a lot of debate about getting the congestion control and checksum parts of

That looks like  a good reference, and I will read up on it further. I am pretty sure
we will find that AERO is also compliant.

> Now, it should be said that both pieces of this work are handling the

OK.

> They are not looking at forming a "new network layer" in the way that AERO is.

Right, AERO is looking at a complete tunneling solution, including routing, addressing,
mobility, security, etc. However, the AERO encapsulation format can be used w/o
having to adopt the proposal in its entirety. But, I'm not sure why you wouldn't.

Thanks - Fred