Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-05
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7988.
|
|
---|---|---|---|
Authors | Eric C. Rosen , Karthik Subramanian , Zhaohui (Jeffrey) Zhang | ||
Last updated | 2016-10-06 (Latest revision 2016-08-15) | ||
Replaces | draft-rosen-l3vpn-ir | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-03)
by Paul Kyzivat
Ready w/issues
GENART Last Call review
(of
-03)
by Paul Kyzivat
Ready w/issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Thomas Morin | ||
Shepherd write-up | Show Last changed 2016-04-25 | ||
IESG | IESG state | Became RFC 7988 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Alvaro Retana | ||
Send notices to | aretana@cisco.com | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
draft-ietf-bess-ir-05
quot; functionality, the child node needs to continue to accept packets from the old UMH for a period of time. After this period, it will discard any packets from the given IR P-tunnel that it receives from the old UMH, and will only accept such packets from the new UMH. Once the child node modifies the RT of its Leaf A-D route, it MUST run a timer (the "switch-parents-delay" timer). This timer SHOULD default to 30 seconds, and SHOULD be configurable. The child node MUST continue to accept packets of the given IR P-tunnel from the old UMH until the timer expires. However, once the child node receives a packet of the given IR P-tunnel from the new UMH, it MAY consider the switch-parents-delay timer to have expired. The "parent-continues" timer MUST be longer than the "switch-parents- delay" timer. Note that both timers are specific to a given IR P-tunnel. 11. IANA Considerations This document contains no actions for IANA. 12. Acknowledgments The authors wish to thank Yakov Rekhter for his contributions to this work. We also wish to thank Huajin Jeng and Samir Saad for their contributions, and to thank Thomas Morin for pointing out (both before and after the document was written) some of the issues that needed further elaboration. We also thank Lucy Yong for her review and comments. Section 7.1 discusses the importance of having an MPLS label allocation policy that, when ingress replication is used, allows an egress PE to infer the identity of a received packet's ingress PE. This issue was first raised in earlier work by Xu Xiaohu. 13. Security Considerations No security considerations are raised by this document beyond those already discussed in [RFC6513] and [RFC6514]. 14. References 14.1. Normative References Rosen, et al. Expires February 16, 2017 [Page 20] Internet-Draft IR Tunnels in MVPN August 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>. [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <http://www.rfc-editor.org/info/rfc6515>. 14.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>. [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <http://www.rfc-editor.org/info/rfc7524>. Rosen, et al. Expires February 16, 2017 [Page 21] Internet-Draft IR Tunnels in MVPN August 2016 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <http://www.rfc-editor.org/info/rfc7582>. [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., and D. Pacella, "Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures", RFC 7716, DOI 10.17487/RFC7716, December 2015, <http://www.rfc-editor.org/info/rfc7716>. [RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication", RFC 7740, DOI 10.17487/RFC7740, January 2016, <http://www.rfc-editor.org/info/rfc7740>. [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, <http://www.rfc-editor.org/info/rfc7900>. Authors' Addresses Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States Email: erosen@juniper.net Karthik Subramanian Sproute Networks Email: karthik@sproute.com Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States Email: zzhang@juniper.net Rosen, et al. Expires February 16, 2017 [Page 22]