draft-ietf-rtgwg-dt-encap-00.txt   draft-ietf-rtgwg-dt-encap-01.txt 
RTGWG E. Nordmark (ed) RTGWG E. Nordmark (ed)
Internet-Draft Arista Networks Internet-Draft Arista Networks
Intended status: Informational A. Tian Intended status: Informational A. Tian
Expires: December 3, 2015 Ericsson Inc. Expires: September 22, 2016 Ericsson Inc.
J. Gross J. Gross
VMware VMware
J. Hudson J. Hudson
Brocade Communications Systems, Brocade Communications Systems, Inc.
Inc.
L. Kreeger L. Kreeger
Cisco Systems, Inc. Cisco Systems, Inc.
P. Garg P. Garg
Microsoft Microsoft
P. Thaler P. Thaler
Broadcom Corporation Broadcom Corporation
T. Herbert T. Herbert
Facebook Facebook
June 2015 March 21, 2016
Encapsulation Considerations Encapsulation Considerations
draft-ietf-rtgwg-dt-encap-00 draft-ietf-rtgwg-dt-encap-01
Abstract Abstract
The IETF Routing Area director has chartered a design team to look at The IETF Routing Area director has chartered a design team to look at
common issues for the different data plane encapsulations being common issues for the different data plane encapsulations being
discussed in the NVO3 and SFC working groups and also in the BIER discussed in the NVO3 and SFC working groups and also in the BIER
BoF, and also to look at the relationship between such encapsulations BoF, and also to look at the relationship between such encapsulations
in the case that they might be used at the same time. The purpose of in the case that they might be used at the same time. The purpose of
this design team is to discover, discuss and document considerations this design team is to discover, discuss and document considerations
across the different encapsulations in the different WGs/BoFs so that across the different encapsulations in the different WGs/BoFs so that
we can reduce the number of wheels that need to be reinvented in the we can reduce the number of wheels that need to be reinvented in the
future. future.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
This Internet-Draft will expire on December 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Design Team Charter . . . . . . . . . . . . . . . . . . . . . 4 1. Design Team Charter . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Common Issues . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Next-protocol indication . . . . . . . . . . . . . . . . . . . 9 8. Next-protocol indication . . . . . . . . . . . . . . . . . . 9
9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . . . 11 9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . . . 10
10. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11.1. Encapsulation-specific considerations . . . . . . . . . . 14 11.1. Encapsulation-specific considerations . . . . . . . . . 14
11.2. Virtual network isolation . . . . . . . . . . . . . . . . 16 11.2. Virtual network isolation . . . . . . . . . . . . . . . 15
11.3. Packet level security . . . . . . . . . . . . . . . . . . 17 11.3. Packet level security . . . . . . . . . . . . . . . . . 16
11.4. In summary: . . . . . . . . . . . . . . . . . . . . . . . 17 11.4. In summary: . . . . . . . . . . . . . . . . . . . . . . 17
12. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Congestion Considerations . . . . . . . . . . . . . . . . . . 19 13. Congestion Considerations . . . . . . . . . . . . . . . . . . 18
14. Header Protection . . . . . . . . . . . . . . . . . . . . . . 20 14. Header Protection . . . . . . . . . . . . . . . . . . . . . . 20
15. Extensibility Considerations . . . . . . . . . . . . . . . . . 22 15. Extensibility Considerations . . . . . . . . . . . . . . . . 22
16. Layering Considerations . . . . . . . . . . . . . . . . . . . 25 16. Layering Considerations . . . . . . . . . . . . . . . . . . . 25
17. Service model . . . . . . . . . . . . . . . . . . . . . . . . 26 17. Service model . . . . . . . . . . . . . . . . . . . . . . . . 26
18. Hardware Friendly . . . . . . . . . . . . . . . . . . . . . . 27 18. Hardware Friendly . . . . . . . . . . . . . . . . . . . . . . 27
18.1. Considerations for NIC offload . . . . . . . . . . . . . 28 18.1. Considerations for NIC offload . . . . . . . . . . . . . 28
19. Middlebox Considerations . . . . . . . . . . . . . . . . . . . 32 19. Middlebox Considerations . . . . . . . . . . . . . . . . . . 32
20. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 33 20. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 32
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
22. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34 22. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34
23. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 35 23. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
24.1. Normative References . . . . . . . . . . . . . . . . . . 36 24.1. Normative References . . . . . . . . . . . . . . . . . . 35
24.2. Informative References . . . . . . . . . . . . . . . . . 37 24.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Design Team Charter 1. Design Team Charter
There have been multiple efforts over the years that have resulted in There have been multiple efforts over the years that have resulted in
new or modified data plane behaviors involving encapsulations. That new or modified data plane behaviors involving encapsulations. That
includes IETF efforts like MPLS, LISP, and TRILL but also industry includes IETF efforts like MPLS, LISP, and TRILL but also industry
efforts like VXLAN and NVGRE. These collectively can be seen as a efforts like VXLAN and NVGRE. These collectively can be seen as a
source of insight into the properties that data planes need to meet. source of insight into the properties that data planes need to meet.
The IETF is currently working on potentially new encapsulations in The IETF is currently working on potentially new encapsulations in
NVO3 and SFC and considering working on BIER. In addition there is NVO3 and SFC and considering working on BIER. In addition there is
skipping to change at page 17, line 30 skipping to change at page 17, line 7
happen today in security gateways. In this case, there is no special happen today in security gateways. In this case, there is no special
consideration for the fact that packet is encapsulated, however since consideration for the fact that packet is encapsulated, however since
the encapsulation layer headers are included (part of encrypted data the encapsulation layer headers are included (part of encrypted data
for instance) we lose visibility in the network of the encapsulation. for instance) we lose visibility in the network of the encapsulation.
The more interesting case is when security is applied to the The more interesting case is when security is applied to the
encapsulation payload. This will keep the encapsulation headers in encapsulation payload. This will keep the encapsulation headers in
the outer header visible to the network (for instance in nvo3 we may the outer header visible to the network (for instance in nvo3 we may
way to firewall based on VNI ID even if the payload is encrypted). way to firewall based on VNI ID even if the payload is encrypted).
One possibility is to apply DTLS to the encapsulation payload. In One possibility is to apply DTLS to the encapsulation payload. In
this model the protocol stack may be something like IP|UDP|Encap| this model the protocol stack may be something like
DTLS|encrypted_payload. The encapsulation and security should be IP|UDP|Encap|DTLS|encrypted_payload. The encapsulation and security
done together at an encapsulator and resolved at the decapsulator. should be done together at an encapsulator and resolved at the
Since the encapsulation header is outside of the security coverage, decapsulator. Since the encapsulation header is outside of the
this may itself require security (like described above). security coverage, this may itself require security (like described
above).
In both of the above the security associations (SAs) may be between In both of the above the security associations (SAs) may be between
physical hosts, so for instance in nvo3 we can have packets of physical hosts, so for instance in nvo3 we can have packets of
different virtual networks using the same SA-- this should not be an different virtual networks using the same SA-- this should not be an
issue since it is the VNI ID that ensures isolation (which needs to issue since it is the VNI ID that ensures isolation (which needs to
be secured also). be secured also).
11.4. In summary: 11.4. In summary:
o Encapsulations need extensibility mechanisms to be able to add o Encapsulations need extensibility mechanisms to be able to add
skipping to change at page 20, line 8 skipping to change at page 19, line 32
If the underlay is provisioned in such a way that it can guarantee If the underlay is provisioned in such a way that it can guarantee
sufficient capacity for non-congestion controlled Layer 2 traffic, sufficient capacity for non-congestion controlled Layer 2 traffic,
then such circuit breakers might not be needed. then such circuit breakers might not be needed.
Two other considerations appear in the context of these Two other considerations appear in the context of these
encapsulations as applied to overlay networks: encapsulations as applied to overlay networks:
o Protect against malicious end stations o Protect against malicious end stations
o Ensure fairness and/or measure resource usage across multiple o Ensure fairness and/or measure resource usage across multiple
tenants tenants
Those issues are really orthogonal to the encapsulation, in that they Those issues are really orthogonal to the encapsulation, in that they
are present even when no new encapsulation header is in use. are present even when no new encapsulation header is in use.
However, the application of the new encapsulations are likely to be However, the application of the new encapsulations are likely to be
in environments where those issues are becoming more important. in environments where those issues are becoming more important.
Hence it makes sense to consider them. Hence it makes sense to consider them.
One could make the encapsulation header be extensible to that it can One could make the encapsulation header be extensible to that it can
carry sufficient information to be able to measure resource usage, carry sufficient information to be able to measure resource usage,
delays, and congestion. The suggestions in the OAM section about a delays, and congestion. The suggestions in the OAM section about a
single bit for counter synchronization, and optional timestamps single bit for counter synchronization, and optional timestamps and/
and/or sequence numbers, could be part of such an approach. There or sequence numbers, could be part of such an approach. There might
might also be additional congestion-control extensions to be carried also be additional congestion-control extensions to be carried in the
in the encapsulation. Overall this results in a consideration to encapsulation. Overall this results in a consideration to support
support sufficient extensibility in the encapsulation to handle sufficient extensibility in the encapsulation to handle potential
potential future developments in this space. future developments in this space.
Coarse measurements are likely to suffice, at least for circuit- Coarse measurements are likely to suffice, at least for circuit-
breaker-like purposes, see [I-D.wei-tsvwg-tunnel-congestion-feedback] breaker-like purposes, see [I-D.wei-tsvwg-tunnel-congestion-feedback]
and [I-D.briscoe-conex-data-centre] for examples on active work in and [I-D.briscoe-conex-data-centre] for examples on active work in
this area via use of ECN. [RFC6040] Appendix C is also relevant. this area via use of ECN. [RFC6040] Appendix C is also relevant.
The outer ECN bits seem sufficient (at least when everything uses The outer ECN bits seem sufficient (at least when everything uses
ECN) to do this course measurements. Needs some more study for the ECN) to do this course measurements. Needs some more study for the
case when there are also drops; might need to exchange counters case when there are also drops; might need to exchange counters
between ingress and egress to handle drops. between ingress and egress to handle drops.
skipping to change at page 32, line 40 skipping to change at page 32, line 30
encapsulation protocol just as middleboxes have been made aware of encapsulation protocol just as middleboxes have been made aware of
other protocols where there are business and deployment other protocols where there are business and deployment
opportunities. Such middleboxes are likely to do more than just drop opportunities. Such middleboxes are likely to do more than just drop
packets based on the UDP port number used by an encapsulation packets based on the UDP port number used by an encapsulation
protocol. protocol.
We note that various forms of encapsulation gateways that stitch one We note that various forms of encapsulation gateways that stitch one
encapsulation protocol together with another form of protocol could encapsulation protocol together with another form of protocol could
have similar effects. have similar effects.
An example of a middlebox that could see some use would be an NVO3- An example of a middlebox that could see some use would be an
aware firewall that would filter on the VNI IDs to provide some NVO3-aware firewall that would filter on the VNI IDs to provide some
defense in depth inside or across NVO3 datacenters. defense in depth inside or across NVO3 datacenters.
A question for the IETF is whether we should document what to do or A question for the IETF is whether we should document what to do or
what not to do in such middleboxes. This document touches on areas what not to do in such middleboxes. This document touches on areas
of OAM and ECMP as it relates to middleboxes and it might make sense of OAM and ECMP as it relates to middleboxes and it might make sense
to document how encapsulation-aware middleboxes should avoid to document how encapsulation-aware middleboxes should avoid
unintended consequences in those (and perhaps other) areas. unintended consequences in those (and perhaps other) areas.
In summary: In summary:
skipping to change at page 34, line 28 skipping to change at page 34, line 19
21. Acknowledgements 21. Acknowledgements
The authors acknowledge the comments from Alia Atlas, Fred Baker, The authors acknowledge the comments from Alia Atlas, Fred Baker,
David Black, Bob Briscoe, Stewart Bryant, Mike Cox, Andy Malis, Radia David Black, Bob Briscoe, Stewart Bryant, Mike Cox, Andy Malis, Radia
Perlman, Carlos Pignataro, Jamal Hadi Salim, Michael Smith, and Lucy Perlman, Carlos Pignataro, Jamal Hadi Salim, Michael Smith, and Lucy
Yong. Yong.
22. Open Issues 22. Open Issues
o Middleboxes: o Middleboxes:
* Due to OAM there are constraints on middleboxes in general. If * Due to OAM there are constraints on middleboxes in general. If
middleboxes inspect the packet past the outer IP+UDP and middleboxes inspect the packet past the outer IP+UDP and
encapsulation header and look for inner IP and TCP/UDP headers, encapsulation header and look for inner IP and TCP/UDP headers,
that might violate the assumption that OAM packets will be that might violate the assumption that OAM packets will be
handled the same as regular data packets. That issue is handled the same as regular data packets. That issue is
broader than just QoS - applies to firewall filters etc. broader than just QoS - applies to firewall filters etc.
* Firewalls looking at inner payload? How does that work for OAM * Firewalls looking at inner payload? How does that work for OAM
frames? Even if it only drops ... TRILL approach might be an frames? Even if it only drops ... TRILL approach might be an
option? Would that encourage more middleboxes making the option? Would that encourage more middleboxes making the
network more fragile? network more fragile?
* Editorially perhaps we should pull the above two into a * Editorially perhaps we should pull the above two into a
separate section about middlebox considerations? separate section about middlebox considerations?
o Next-protocol indication - should it be common across different o Next-protocol indication - should it be common across different
encapsulation headers? We will have different ways to indicate encapsulation headers? We will have different ways to indicate
the presence of the first encapsulation header in a packet (could the presence of the first encapsulation header in a packet (could
be a UDP destination port, an Ethernet type, etc depending on the be a UDP destination port, an Ethernet type, etc depending on the
outer delivery header). But for the next protocol past an outer delivery header). But for the next protocol past an
encapsulation header one could envision creating or adoption a encapsulation header one could envision creating or adoption a
skipping to change at page 35, line 48 skipping to change at page 35, line 38
o Added text on architectural considerations when it might make o Added text on architectural considerations when it might make
sense to define an additional header/protocol as opposed to using sense to define an additional header/protocol as opposed to using
the extensibility mechanism in the existing encapsulation the extensibility mechanism in the existing encapsulation
protocol. protocol.
o Clarified the "unconstrained TLVs" in the hardware friendly o Clarified the "unconstrained TLVs" in the hardware friendly
section. section.
o Clarified the text around checksum verification and full vs. o Clarified the text around checksum verification and full vs.
header checksums. header checksums.
o Added wording that the considerations might apply for encaps o Added wording that the considerations might apply for encaps
outside of the routing area. outside of the routing area.
o Added references to draft-ietf-pwe3-congcons, o Added references to draft-ietf-pwe3-congcons, draft-ietf-tsvwg-
draft-ietf-tsvwg-rfc5405bis, RFC2473, and RFC7325 rfc5405bis, RFC2473, and RFC7325
o Removed reference to RFC3948. o Removed reference to RFC3948.
o Updated the acknowledgements section. o Updated the acknowledgements section.
o Added this change log section. o Added this change log section.
24. References 24. References
24.1. Normative References 24.1. Normative References
[I-D.ietf-tsvwg-rfc5405bis] [I-D.ietf-tsvwg-rfc5405bis]
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", draft-ietf-tsvwg-rfc5405bis-02 (work in Guidelines", draft-ietf-tsvwg-rfc5405bis-10 (work in
progress), April 2015. progress), March 2016.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405,
November 2008. DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010. Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011. Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<http://www.rfc-editor.org/info/rfc6438>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013,
<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>.
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake, [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
"Transparent Interconnection of Lots of Links (TRILL) 3rd, "Transparent Interconnection of Lots of Links (TRILL)
Operations, Administration, and Maintenance (OAM) Operations, Administration, and Maintenance (OAM)
Framework", RFC 7174, May 2014. Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014,
<http://www.rfc-editor.org/info/rfc7174>.
[RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A., and [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
C. Pignataro, "MPLS Forwarding Compliance and Performance and C. Pignataro, "MPLS Forwarding Compliance and
Requirements", RFC 7325, August 2014. Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014. Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
and M. Napierala, "Problem Statement: Overlays for Network Kreeger, L., and M. Napierala, "Problem Statement:
Virtualization", RFC 7364, October 2014. Overlays for Network Virtualization", RFC 7364,
DOI 10.17487/RFC7364, October 2014,
<http://www.rfc-editor.org/info/rfc7364>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, October 2014. Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>.
24.2. Informative References 24.2. Informative References
[I-D.briscoe-conex-data-centre] [I-D.briscoe-conex-data-centre]
Briscoe, B. and M. Sridharan, "Network Performance Briscoe, B. and M. Sridharan, "Network Performance
Isolation in Data Centres using Congestion Policing", Isolation in Data Centres using Congestion Policing",
draft-briscoe-conex-data-centre-02 (work in progress), draft-briscoe-conex-data-centre-02 (work in progress),
February 2014. February 2014.
[I-D.farrelll-mpls-opportunistic-encrypt] [I-D.farrelll-mpls-opportunistic-encrypt]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", draft-farrelll-mpls-opportunistic-encrypt-05 Networks", draft-farrelll-mpls-opportunistic-encrypt-05
(work in progress), June 2015. (work in progress), June 2015.
[I-D.gross-geneve] [I-D.gross-geneve]
Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I.,
Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve:
Generic Network Virtualization Encapsulation", Generic Network Virtualization Encapsulation", draft-
draft-gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), October 2014.
[I-D.herbert-gue] [I-D.herbert-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-herbert-gue-03 (work in progress), Encapsulation", draft-herbert-gue-03 (work in progress),
March 2015. March 2015.
[I-D.herbert-remotecsumoffload] [I-D.herbert-remotecsumoffload]
Herbert, T., "Remote checksum offload for encapsulation", Herbert, T., "Remote checksum offload for encapsulation",
draft-herbert-remotecsumoffload-01 (work in progress), draft-herbert-remotecsumoffload-02 (work in progress),
November 2014. March 2016.
[I-D.ietf-mpls-in-udp] [I-D.ietf-mpls-in-udp]
Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", draft-ietf-mpls-in-udp-11 "Encapsulating MPLS in UDP", draft-ietf-mpls-in-udp-11
(work in progress), January 2015. (work in progress), January 2015.
[I-D.ietf-nvo3-arch] [I-D.ietf-nvo3-arch]
Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Overlay Networks (NVO3)", Narten, "An Architecture for Overlay Networks (NVO3)",
draft-ietf-nvo3-arch-03 (work in progress), March 2015. draft-ietf-nvo3-arch-04 (work in progress), October 2015.
[I-D.ietf-pwe3-congcons] [I-D.ietf-pwe3-congcons]
Stein, Y., Black, D., and B. Briscoe, "Pseudowire Stein, Y., Black, D., and B. Briscoe, "Pseudowire
Congestion Considerations", draft-ietf-pwe3-congcons-02 Congestion Considerations", draft-ietf-pwe3-congcons-02
(work in progress), July 2014. (work in progress), July 2014.
[I-D.ietf-sfc-architecture] [I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-09 (work (SFC) Architecture", draft-ietf-sfc-architecture-11 (work
in progress), June 2015. in progress), July 2015.
[I-D.ietf-sfc-problem-statement] [I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-13 Problem Statement", draft-ietf-sfc-problem-statement-13
(work in progress), February 2015. (work in progress), February 2015.
[I-D.ietf-trill-oam-fm] [I-D.ietf-trill-oam-fm]
Senevirathne, T., Finn, N., Salam, S., Kumar, D., Senevirathne, T., Finn, N., Salam, S., Kumar, D.,
Eastlake, D., Aldrin, S., and L. Yizhou, "TRILL Fault Eastlake, D., Aldrin, S., and L. Yizhou, "TRILL Fault
Management", draft-ietf-trill-oam-fm-11 (work in Management", draft-ietf-trill-oam-fm-11 (work in
progress), October 2014. progress), October 2014.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-01 (work in progress), draft-ietf-tsvwg-circuit-breaker-13 (work in progress),
March 2015. February 2016.
[I-D.ietf-tsvwg-gre-in-udp-encap] [I-D.ietf-tsvwg-gre-in-udp-encap]
Crabbe, E., Yong, L., Xu, X., and T. Herbert, "GRE-in-UDP Yong, L., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP
Encapsulation", draft-ietf-tsvwg-gre-in-udp-encap-07 (work Encapsulation", draft-ietf-tsvwg-gre-in-udp-encap-11 (work
in progress), July 2015. in progress), March 2016.
[I-D.ietf-tsvwg-port-use] [I-D.ietf-tsvwg-port-use]
Touch, J., "Recommendations on Using Assigned Transport Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", draft-ietf-tsvwg-port-use-11 (work in Port Numbers", draft-ietf-tsvwg-port-use-11 (work in
progress), April 2015. progress), April 2015.
[I-D.quinn-sfc-nsh] [I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Surendra, S., Smith, M., Quinn, P., Guichard, J., Surendra, S., Smith, M.,
Henderickx, W., Nadeau, T., Agarwal, P., Manur, R., Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman, Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
D., Garg, P., McConnell, B., Wright, C., and K. Kevin, D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
"Network Service Header", draft-quinn-sfc-nsh-07 (work in "Network Service Header", draft-quinn-sfc-nsh-07 (work in
progress), February 2015. progress), February 2015.
[I-D.saldana-tsvwg-simplemux] [I-D.saldana-tsvwg-simplemux]
Saldana, J., "Simplemux. A generic multiplexing protocol", Saldana, J., "Simplemux. A generic multiplexing protocol",
draft-saldana-tsvwg-simplemux-02 (work in progress), draft-saldana-tsvwg-simplemux-04 (work in progress),
January 2015. January 2016.
[I-D.shepherd-bier-problem-statement] [I-D.shepherd-bier-problem-statement]
Shepherd, G., Dolganow, A., and a. Shepherd, G., Dolganow, A., and a.
arkadiy.gulko@thomsonreuters.com, "Bit Indexed Explicit arkadiy.gulko@thomsonreuters.com, "Bit Indexed Explicit
Replication (BIER) Problem Statement", Replication (BIER) Problem Statement", draft-shepherd-
draft-shepherd-bier-problem-statement-02 (work in bier-problem-statement-02 (work in progress), February
progress), February 2015. 2015.
[I-D.sridharan-virtualization-nvgre] [I-D.sridharan-virtualization-nvgre]
Garg, P. and Y. Wang, "NVGRE: Network Virtualization using Garg, P. and Y. Wang, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", Generic Routing Encapsulation", draft-sridharan-
draft-sridharan-virtualization-nvgre-08 (work in virtualization-nvgre-08 (work in progress), April 2015.
progress), April 2015.
[I-D.wei-tsvwg-tunnel-congestion-feedback] [I-D.wei-tsvwg-tunnel-congestion-feedback]
Wei, X., Zhu, L., Deng, L., and B. Briscoe, "Tunnel Wei, X., Zhu, L., Deng, L., and B. Briscoe, "Tunnel
Congestion Feedback", Congestion Feedback", draft-wei-tsvwg-tunnel-congestion-
draft-wei-tsvwg-tunnel-congestion-feedback-04 (work in feedback-04 (work in progress), June 2015.
progress), June 2015.
[I-D.wijnands-bier-architecture] [I-D.wijnands-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-wijnands-bier-architecture-05 (work in Replication", draft-wijnands-bier-architecture-05 (work in
progress), March 2015. progress), March 2015.
[I-D.wijnands-mpls-bier-encapsulation] [I-D.wijnands-mpls-bier-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", Replication in MPLS Networks", draft-wijnands-mpls-bier-
draft-wijnands-mpls-bier-encapsulation-02 (work in encapsulation-02 (work in progress), December 2014.
progress), December 2014.
[I-D.xu-bier-encapsulation] [I-D.xu-bier-encapsulation]
Xu, X., Somasundaram, S., Jacquenet, C., and R. Raszuk, Xu, X., Somasundaram, S., Jacquenet, C., and R. Raszuk,
"BIER Encapsulation", draft-xu-bier-encapsulation-02 (work "BIER Encapsulation", draft-xu-bier-encapsulation-03 (work
in progress), February 2015. in progress), October 2015.
[IEEE802.1Q-2014] [IEEE802.1Q-2014]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE Std 802.1Q- networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2014, 2014, 2014, 2014,
<http://www.ieee802.org/1/pages/802.1Q-2014.html>. <http://www.ieee802.org/1/pages/802.1Q-2014.html>.
(Access Controlled link within page) (Access Controlled link within page)
[RFC0033] Crocker, S., "New Host-Host Protocol", RFC 33, [RFC0033] Crocker, S., "New Host-Host Protocol", RFC 33,
February 1970. DOI 10.17487/RFC0033, February 1970,
<http://www.rfc-editor.org/info/rfc33>.
Authors' Addresses Authors' Addresses
Erik Nordmark Erik Nordmark
Arista Networks Arista Networks
5453 Great America Parkway 5453 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: nordmark@arista.com Email: nordmark@arista.com
 End of changes. 50 change blocks. 
117 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/