Subject: routing area design team on dataplane encapsulation considerations

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Dec 2014 17:46:30 -0500

I have chartered a Routing Area Design Team to work on data-plane
encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.
Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of
the design
team are:

  Albert Tian <[email-masked]>
  Erik Nordmark <[email-masked]>
  Jesse Gross <[email-masked]>
  Jon Hudson <[email-masked]>
  Larry Kreeger (kreeger) <[email-masked]>
  Pankaj Garg <[email-masked]>
  Pat Thaler <[email-masked]>
  Tom Herbert <[email-masked]>

The mailing list, [email-masked], is closed but the
archives are
publicly available at:

http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/current/maillist.html

The Design Team is chartered as follows:

There have been multiple efforts over the years that have resulted in new
or modified data plane behaviors involving encapsulations. That includes
IETF efforts like MPLS, LISP, and TRILL but also industry efforts like
Vxlan and NVGRE.  These collectively can be seen as a source of insight
into the properties that data planes need to meet.  The IETF is currently
working on potentially new encapsulations in NVO3 and SFC and considering
working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful
advice to parties working on new or modified data plane behaviors that
include additional encapsulations.  The goal is for the group to document
useful advice gathered from interacting with ongoing efforts.  An Internet
Draft will be produced for IETF92 to capture that advice, which will be
discussed in RTGWG.

Data plane encapsulations face a set of common issues such as:

  * How to provide entropy for ECMP
  * Issues around packet size and fragmentation/reassembly
  * OAM - what support is needed in an encapsulation format?
  * Security and privacy.
  * QoS
  * Congestion Considerations
  * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
  * Extensibility - e.g., for evolving OAM, security, and/or congestion
control
  * Layering of multiple encapsulations e.g., SFC over NVO3 over BIER

The design team will provide advice on those issues. The intention is that
even where we have different encapsulations for different purposes carrying
different data, each such encapsulation doesn’t have to reinvent the wheel
for the above common issues.

The design team will look across the routing area in particular at SFC,
NVO3 and BIER. It will not be involved in comparing or analyzing any
particular encapsulation formats proposed in those WGs and BoFs but instead
focus on common advice.

Regards,
Alia

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 09 Dec 2014 22:53:12 +0000

Alia

> * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
I am not sure if it is the non-zero UDP checksum over IPv6 issue, or
the zeroUDP checksum over IPv6 issue.

Most people doing tunneling seem quite happy with zero but get pushback
from the transport area.

Perhaps the topic is really

* IPv6 header protection (UDP checksum issue)

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Dec 2014 17:57:33 -0500

Stewart,

> * IPv6 header protection (UDP checksum issue)

These are examples of considerations for the design team and aren't intended
to be exhaustive.

Alia

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 09 Dec 2014 23:13:08 -0800

Stewart,

That would probably be a better way to name the issue.

Thanks,
    Erik

>
> - Stewart
>
>
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 10:01:32 +0000

Of course the tunnellers are happy with a zero checksum. The pollution caused by missent corrupted ipv6 packets evading checks elsewhere does not affect them.

Congestion is not a problem for tunnellers either. Like zero checksums, any congestion problem caused by a tunnel is just not the tunnel's problem. Why should the tunneller have to consider congestion? Or zero checksums? Or anything that impedes tunnel performance?

The tragedy of the commons, in action.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: routing-discussion <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Sent: Wednesday, 10 December 2014 9:53:12 AM
To: Alia Atlas; [email-masked]
Subject: Re: routing area design team on dataplane encapsulation considerations

Alia

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Dec 2014 10:23:01 +0000

Lloyd

You run a network these days, what error rates are you actually measuring?

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 10:30:59 +0000

well, it's an IPv4 network.

because customers don't require or demand IPv6.

(see Jonathan Stone's papers for some large-scale IPv4 measurements. yes, you can quibble about whether software and hardware has improved in reliability thanks to all of the ongoing engineering and lessons learned - and who is maintaining cef these days? - but the papers are a handy existence proof of the problem.)
________________________________________
From: Stewart Bryant <[email-masked]>
Sent: Wednesday, 10 December 2014 9:23:01 PM
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Subject: Re: routing area design team on dataplane encapsulation considerations

Lloyd

Stewart

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 11:37:12 +0000

It's an issue with zero checksums, ie not hsving a functional working checksum. Non-zero checksums are not an issue.

It's a bit like 60s car manufacturers saying 'do we really need to add seatbelts? They're expensive.' Seatbelts are clearly an issue! Like creationism and evolution, it's not clearcut. We should teach the controversy!

Lloyd Wood

Alia

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Dec 2014 12:07:54 +0000

Lloyd as a first approximation what do your IP header checksum error 
rates look like.

The old paper that you point to is not representative of modern routing 
technology
and I would like to see some new modern numbers relevant to router to 
router traffic
which is what we are talking about.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Dec 2014 12:15:03 +0000

Lloyd

Let's have a current data driven approach to this. You are in a position to
look inside an NMS and tell us what modern data error rates are.

A counter existence proof is MPLS networking which acts at the same
layer that we are discussing and does not seem to have a misdelivery
or "not in table drop rate" that is getting on anyone's radar. Certainly
no one is asking us to upgrade MPLS to add this protection.

- Stewart

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 13:24:52 +0000

Stewart,

Who needs an NMS? Let's go old school.
TCP and UDP have equivalent pseudo-header+payload ones complement checksums. So data from TCP can be considered as somewhat equivalent as the technology is the same, and TCP is somewhat better instrumented and monitored than UDP is.

Below sample from two core switches, on tcp connections to them  (not, alas, through them) shows e.g. 10287 TCP checksum errors for 4.3 million TCP/IP packets received. That would be an error rate of 0.24% - the other switch is 0.45% . Note the figure of e.g. 19458 no port - entirely possible something inside the core network is trying a port that isn't there, but also possible corruption of port nos. These are firewalled core devices with limited traffic to them, so I would consider this a best case, without throwing edge device data into the mix.

Extrapolating from TCP checksum rates to UDP checksum rates, from traffic to to traffic through, and from v4 to v6 is left as an exercise for the reader. 

Incidentally, these rates pretty much match the 1 in 400 observation made early in Stone's SIGCOMM 2000 paper. 1:400 is 10,000:4,000,000
http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf
Zut alors, quelle surprise, physics is still physics, this particular SIGCOMM paper is still valid.
Checksums fail because of corruption. But at least there's a checksum to catch the corruption. Sans checksums, the corruption is unnoticed. 

The main reason noone has seen misbehaviour with MPLS is because no-one is looking for or instrumenting for it. (Just like MPLS doesn't need TTL, because no-one ever sees MPLS routing loops, right?) Please go measure MPLS and report back.

Traversing over UDP, as suggested in draft-ietf-mpls-in-udp and draft-ietf-tsvwg-gre-in-udp-encap, increases the scope for corruption across a longer path, rather than individual links - and the UDP checksum is an important last check.

SWT1#sh tcp stat
Rcvd: 4332545 Total, 19458 no port
      10287 checksum error, 4959 bad offset, 0 too short
      62946 packets (2289083 bytes) in sequence
      93 dup packets (19167 bytes)
      34 partially dup packets (1878 bytes)
      107 out-of-order packets (17980 bytes)
      8 packets (8 bytes) with data after window
      0 packets after close
      0 window probe packets, 614 window update packets
      682 dup ack packets, 0 ack packets with unsend data
      179823 ack packets (37459618 bytes)
Sent: 2049509 Total, 0 urgent packets
      1774234 control packets (including 345 retransmitted)
      249103 data packets (37439059 bytes)
      308 data packets (41767 bytes) retransmitted
      46 data packets (4876 bytes) fastretransmitted
      25718 ack only packets (3764 delayed)
      0 window probe packets, 104 window update packets
9649 Connections initiated, 1230 connections accepted, 10857 connections established
1760675 Connections closed (including 30 dropped, 1749812 embryonic dropped)
653 Total rxmt timeout, 9 connections dropped in rxmt timeout
0 Keepalive timeout, 6 keepalive probe, 0 Connections dropped in keepalive

SWT2#sh tcp stat
Rcvd: 6370948 Total, 37608 no port
      28419 checksum error, 1749 bad offset, 0 too short
      181714 packets (3507560 bytes) in sequence
      130 dup packets (4925 bytes)
      164 partially dup packets (302 bytes)
      35 out-of-order packets (278 bytes)
      64 packets (4549 bytes) with data after window
      0 packets after close
      0 window probe packets, 2006 window update packets
      3865 dup ack packets, 0 ack packets with unsend data
      857922 ack packets (92503306 bytes)
Sent: 3793587 Total, 0 urgent packets
      2667720 control packets (including 215 retransmitted)
      1042867 data packets (92804839 bytes)
      1772 data packets (74842 bytes) retransmitted
      192 data packets (7176 bytes) fastretransmitted
      81025 ack only packets (15840 delayed)
      0 window probe packets, 19 window update packets
28735 Connections initiated, 5928 connections accepted, 34638 connections established
2626485 Connections closed (including 1349 dropped, 2591827 embryonic dropped)
1987 Total rxmt timeout, 4 connections dropped in rxmt timeout
0 Keepalive timeout, 0 keepalive probe, 0 Connections dropped in keepalive

Lloyd Wood

error-free modern networking technology? ha.
________________________________________
From: Stewart Bryant <[email-masked]>
Sent: Wednesday, 10 December 2014 11:15 PM
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Subject: Re: routing area design team on dataplane encapsulation considerations

Lloyd

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 10 Dec 2014 09:26:55 -0500

Alia,

To hijack this discussion back to your original post, I'm very surprised to
see no mention of PALS anywhere. We in PALS (and PWE3 before that) have
plenty of experience with data plane encapsulations, and we already have
solutions for a number of the issues in your list, including ECMP (RFC
6391), packet size and fragmentation (4623), OAM (5085 and others), and a
draft on congestion considerations just in the process of finishing up. PWs
have been extremely successful in the marketplace. So I hope the design
team keeps us in mind as well.

Cheers,
Andy

---

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Dec 2014 09:38:37 -0500

Hi Andy,

Absolutely true.   I apologize for the oversight.   Psuedo-wires are
another encapsulation that we can learn from.

I expect the design team to be reaching out to get more insight on these
different issues.

Regards
Alia
On Dec 10, 2014 9:27 AM, "Andrew G. Malis" <[email-masked]> wrote:

> Alia,
>
> To hijack this discussion back to your original post, I'm very surprised
> to see no mention of PALS anywhere. We in PALS (and PWE3 before that) have
>> The mailing list, [email-masked], is closed but
>> the archives are
>> publicly available at:
>>
>> This is a short term design team chartered to collect and construct
>> useful advice to parties working on new or modified data plane behaviors
>> that include additional encapsulations.  The goal is for the group to
>> document useful advice gathered from interacting with ongoing efforts.  An
>> Internet Draft will be produced for IETF92 to capture that advice, which
>> will be discussed in RTGWG.
>>
>> The design team will provide advice on those issues. The intention is
>> that even where we have different encapsulations for different purposes
>> carrying different data, each such encapsulation doesn’t have to reinvent
>> the wheel for the above common issues.
>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Dec 2014 16:19:27 +0000

Changing the thread title to match the subject

Lloyd

Those numbers are orders of magnitude larger than anything I have
seen elsewhere.

If we look at them in detail they are interesting because if the no ports
are c/s errors as you hypothesis, then only 1/3 of the errors are seemingly
caught by the c/s. I would thus expect  you to be arguing strongly
that we need to deprecate the existing c/s in favour of something
much stronger such as fletcher, or ideally a crypto checksum.
In the case of the link state IGPs we have operators that turn on
link state security not for security but for the enhanced checksum
and that seems to be what you need here in the host stacks.

However we have another study that is worth looking at:

https://www.verisigninc.com/assets/VRSN_Bitsquatting_TR_20120320.pdf

This looks at the UDP c/s errors received by DNS servers, and they
saw an error rate of 1 in 10^5. However if you read the detail there are 
some
systematic effects going on, with a significant fraction seemingly due
to transmit host stack problems which may be what you are seeing.

Now I think all this points to two things, firstly from a perspective
of a host the c/s looks inadequate and there may need to be a
revision of the host stack.

On the other hand the reported error rate for UDP that the paper
reports is an over estimate of the error rate in the tunnel case since
only an error in the IP and UDP header can cause misdelivery
with all other errors reflecting themselves as payload errors which
the payload error protection. Although I do note that they report
some systematic effect in terms of bit position which may point either
way.

One other aspect of this, which is important in Routing, if we are seeing
the error rates you imply are getting past the TCP c/s, surely the routing
protocols will be importing long term errors into the routing subsystems
(specifically BGP and LDP). Are people observing that and if so don't we
need to fix it?

- Stewart

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 10 Dec 2014 18:16:30 +0000

Throwing in my two cents worth of data.

I looked at two routers - one in the US, one in South America.  The TCP numbers (largely BGP and SSH) are:

Router #1:  
Rcvd: 3990580271 Total, 125489 no port
      60097 checksum error, 43239 bad offset, 0 too short

60097/3990580271 = 0.0015%

Router #2:
         1291670737 packets received
                 20332 discarded for bad checksums

(20332/1291670737) = 0.0015% again

A little worse than Stewarts 1/10^5, but not much.  Certainly not high on my list of Things That Give Me Ulcers.

eric

> -----Original Message-----
> From: routing-discussion [mailto:[email-masked]] On
> Behalf Of Stewart Bryant
> Sent: Wednesday, December 10, 2014 11:19 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: dataplane encapsulation considerations - checksums
> 
> > TCP and UDP have equivalent pseudo-header+payload ones complement
> checksums. So data from TCP can be considered as somewhat equivalent as the
> technology is the same, and TCP is somewhat better instrumented and
> monitored than UDP is.
> >
> > Below sample from two core switches, on tcp connections to them  (not, alas,
> through them) shows e.g. 10287 TCP checksum errors for 4.3 million TCP/IP
> packets received. That would be an error rate of 0.24% - the other switch is
> 0.45% . Note the figure of e.g. 19458 no port - entirely possible something
> inside the core network is trying a port that isn't there, but also possible
> corruption of port nos. These are firewalled core devices with limited traffic to
> them, so I would consider this a best case, without throwing edge device data
> into the mix.
> >
> > Extrapolating from TCP checksum rates to UDP checksum rates, from traffic
> to to traffic through, and from v4 to v6 is left as an exercise for the reader.
> >
> > Incidentally, these rates pretty much match the 1 in 400 observation made
> early in Stone's SIGCOMM 2000 paper. 1:400 is 10,000:4,000,000
> > Checksums fail because of corruption. But at least there's a checksum to
> catch the corruption. Sans checksums, the corruption is unnoticed.
> >
> > The main reason noone has seen misbehaviour with MPLS is because no-one
> is looking for or instrumenting for it. (Just like MPLS doesn't need TTL, because
> no-one ever sees MPLS routing loops, right?) Please go measure MPLS and
> report back.
> >
> > Traversing over UDP, as suggested in draft-ietf-mpls-in-udp and draft-ietf-
> tsvwg-gre-in-udp-encap, increases the scope for corruption across a longer
> path, rather than individual links - and the UDP checksum is an important last
> check.
> >
> > SWT1#sh tcp stat

---

From: Pat Thaler <[email-masked]>
Date: Wed, 10 Dec 2014 19:42:25 +0000

"If we look at them in detail they are interesting because if the no ports
are c/s errors as you hypothesis, then only 1/3 of the errors are seemingly
caught by the c/s. I would thus expect  you to be arguing strongly
that we need to deprecate the existing c/s in favour of something
much stronger such as fletcher, or ideally a crypto checksum."

The no port errors could be happening on a much larger base of traffic than the checksum errors. 
Check sum is only being checked on traffic destined for the router. 
Arrival of a packet with no corresponding port could be due to an error in the IP address of any packet on the network - presumably a much larger amount of traffic. 
Checksum might be catching most of the errors but a very small portion of the network traffic has the router as a destination so the router is more likely to see a corrupted packet arrive (something where the destination IP changed but with good checksum and bad port number) than a checksum error.

However, the reason that checksum is being urged is to prevent delivering packets to the wrong tenants because of an undetected error causing misdirection.  If the no port traffic is from corrupted packets that the checksum didn't catch, checksum isn't doing a thorough job of doing that. We don't know what % is getting misdirected because we don't have a number for the total traffic.  Of course, that "if" is a big assumption - the no port traffic may be from some other cause.

One can't evaluate the comparative strength of error detection methods without knowing something about the kind of errors expected, the rate they occur at and the acceptable rate of undetected error.

If the error mechanism is an alpha particle corrupting a bit in un-parity checked memory with a very low BER so that the likelihood of two bits in a packet having 2 errors is below the goal for undetected errors, any of the checksum algorithms or any CRC will catch a single bit error.  
On the other hand, if the memory is parity protected, it will catch the single bit error itself

If the goal is catching burst errors of less than 32 bits or multiple single bit errors, Fletcher will catch more of the errors than the plain checksum but not an order of magnitude better so if the plain checksum isn't good enough for the goal, one probably needs to go to a CRC (which gets a few orders of magnitude improvement) or a cryptographic integrity check.

See RFC 3385.

Pat

-----Original Message-----
From: routing-discussion [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, December 10, 2014 8:19 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: dataplane encapsulation considerations - checksums

Lloyd

- Stewart

---

From: "Fedyk, Don" <[email-masked]>
Date: Wed, 10 Dec 2014 20:10:35 +0000

Hi Alia

I think it would be good for the design team to  also include for reference comparisons of the L2 encapsulations from IEEE 802.1 such as Provider backbone Bridging(PBB) aka Mac-in-MAC and IEEE 802.1Qbp – Equal Cost Multipath (ECMP)  (also a Mac-in-MAC encaps) which have some common properties with data plane encapsulations in general.  As with PWE the designers of these encapsulations have grappled with a lot of the same issues.

One  addition to your list these L2 encapsulations  have specific support for multicast that can be utilized in the in the underlay data plane.

Cheers,
Don

From: routing-discussion [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, December 10, 2014 9:39 AM
To: Andrew G. Malis
Cc: [email-masked]
Subject: Re: routing area design team on dataplane encapsulation considerations

Hi Andy,

Absolutely true.   I apologize for the oversight.   Psuedo-wires are another encapsulation that we can learn from.

I expect the design team to be reaching out to get more insight on these different issues.

Regards
Alia
On Dec 10, 2014 9:27 AM, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

To hijack this discussion back to your original post, I'm very surprised to see no mention of PALS anywhere. We in PALS (and PWE3 before that) have plenty of experience with data plane encapsulations, and we already have solutions for a number of the issues in your list, including ECMP (RFC 6391), packet size and fragmentation (4623), OAM (5085 and others), and a draft on congestion considerations just in the process of finishing up. PWs have been extremely successful in the marketplace. So I hope the design team keeps us in mind as well.

Cheers,
Andy

On Tue, Dec 9, 2014 at 5:46 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I have chartered a Routing Area Design Team to work on data-plane encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.  Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of the design
team are:

  Albert Tian <[email-masked]<mailto:[email-masked]>>
  Erik Nordmark <[email-masked]<mailto:[email-masked]>>
  Jesse Gross <[email-masked]<mailto:[email-masked]>>
  Jon Hudson <[email-masked]<mailto:[email-masked]>>
  Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]>>
  Pankaj Garg <[email-masked]<mailto:[email-masked]>>
  Pat Thaler <[email-masked]<mailto:[email-masked]>>
  Tom Herbert <[email-masked]<mailto:[email-masked]>>

The mailing list, [email-masked]<mailto:[email-masked]>, is closed but the archives are
publicly available at:
   http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/current/maillist.html

There have been multiple efforts over the years that have resulted in new or modified data plane behaviors involving encapsulations. That includes IETF efforts like MPLS, LISP, and TRILL but also industry efforts like Vxlan and NVGRE.  These collectively can be seen as a source of insight into the properties that data planes need to meet.  The IETF is currently working on potentially new encapsulations in NVO3 and SFC and considering working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful advice to parties working on new or modified data plane behaviors that include additional encapsulations.  The goal is for the group to document useful advice gathered from interacting with ongoing efforts.  An Internet Draft will be produced for IETF92 to capture that advice, which will be discussed in RTGWG.

  * Extensibility - e.g., for evolving OAM, security, and/or congestion control

The design team will provide advice on those issues. The intention is that even where we have different encapsulations for different purposes carrying different data, each such encapsulation doesn’t have to reinvent the wheel for the above common issues.
The design team will look across the routing area in particular at SFC, NVO3 and BIER. It will not be involved in comparing or analyzing any particular encapsulation formats proposed in those WGs and BoFs but instead focus on common advice.

Regards,
Alia

_______________________________________________
routing-discussion mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 10 Dec 2014 12:24:49 -0800

> The no port errors could be happening on a much larger base of traffic than the checksum errors. 

Would a (UDP a.k.a. "Unix-style") traceroute increment the 'no port' error?

-d

---

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Dec 2014 16:15:43 -0500

Hi Don,

Thanks for the suggestion.  I expect that Pat Thaler will be able to help
out with pulling
in experts on these technologies if the design team decides that
comparisons are useful.
In general, I'm expecting a draft that discusses options and the different
considerations
(of which a list was included).

I don't intend to revisit or revise the charter now - particularly for
other examples of technology
to consider.  However, I'm certain that the design team is following the
thread and taking in
the good advice.

An initial draft from the design team is expected before Dallas.

Regards,
Alia

On Wed, Dec 10, 2014 at 3:10 PM, Fedyk, Don <[email-masked]> wrote:

>  Hi Alia
>
>
>
> I think it would be good for the design team to  also include for
> reference comparisons of the L2 encapsulations from IEEE 802.1 such as
> Provider backbone Bridging(PBB) aka Mac-in-MAC and IEEE 802.1Qbp – Equal
> Cost Multipath (ECMP)  (also a Mac-in-MAC encaps) which have some common
> properties with data plane encapsulations in general.  As with PWE the
> designers of these encapsulations have grappled with a lot of the same
> issues.
>
>
>
> One  addition to your list these L2 encapsulations  have specific support
> for multicast that can be utilized in the in the underlay data plane.
>
>
>
> Cheers,
> Don
>
>
>
> *From:* routing-discussion [mailto:[email-masked]] *On
> Behalf Of *Alia Atlas
> *Sent:* Wednesday, December 10, 2014 9:39 AM
> *To:* Andrew G. Malis
> *Cc:* [email-masked]
> *Subject:* Re: routing area design team on dataplane encapsulation
> considerations
>
>
>
> Hi Andy,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Dec 2014 20:19:42 +0000

Hi Andy,

You mentioned packet size and fragmentation wrt RFC4623, and I just wanted
to note that the idea of tunnel fragmentation goes back even earlier than that
to Section 3.1.7 of RFC2764 which I see that you are also co-author on. I have
cited this in some of my earlier works.

AERO is also using tunnel fragmentation in pretty much the same way, except
that AERO has a comprehensive specification for when to fragment, when not
to fragment, how to test if fragmentation is necessary, and what packet size
ranges are candidates for fragmentation. So, in addition to your earlier works
I hope the design team will have a look at the packet size and fragmentation
aspects of AERO.

Thanks – Fred
[email-masked]

From: routing-discussion [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Wednesday, December 10, 2014 6:27 AM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: routing area design team on dataplane encapsulation considerations

Alia,

Cheers,
Andy

Regards,
Alia