Routing Area Working Group (rtgwg) Internet Drafts


      
 BGP Prefix Independent Convergence
 
 draft-ietf-rtgwg-bgp-pic-21.txt
 Date: 07/07/2024
 Authors: Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra
 Working Group: Routing Area Working Group (rtgwg)
In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup.
 A YANG Data Model for ARP
 
 draft-ietf-rtgwg-arp-yang-model-04.txt
 Date: 30/06/2024
 Authors: Feng Zheng, Bo Wu, Robert Wilton, Fan Zhang, Yongqing Zhu, Xiaojian Ding
 Working Group: Routing Area Working Group (rtgwg)
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics.
 A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
 
 draft-ietf-rtgwg-atn-bgp-27.txt
 Date: 23/09/2024
 Authors: Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno
 Working Group: Routing Area Working Group (rtgwg)
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on industry-standard BGP to address the ATN/IPS requirements.
 Topology Independent Fast Reroute using Segment Routing
 
 draft-ietf-rtgwg-segment-routing-ti-lfa-19.txt
 Date: 22/11/2024
 Authors: Ahmed Bashandy, Stephane Litkowski, Clarence Filsfils, Pierre Francois, Bruno Decraene, Dan Voyer
 Working Group: Routing Area Working Group (rtgwg)
This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options.
 Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices
 
 draft-ietf-rtgwg-net2cloud-problem-statement-41.txt
 Date: 19/08/2024
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet, Mehmet Toy, Kausik Majumdar
 Working Group: Routing Area Working Group (rtgwg)
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems.
 SRv6 Path Egress Protection
 
 draft-ietf-rtgwg-srv6-egress-protection-17.txt
 Date: 17/11/2024
 Authors: Tao He, Zhibo Hu, Huaimo Chen, Mehmet Toy, Chang Cao
 Working Group: Routing Area Working Group (rtgwg)
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path.
 Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)
 
 draft-ietf-rtgwg-vrrp-p2mp-bfd-10.txt
 Date: 25/11/2024
 Authors: Greg Mirsky, Jeff Tantsura, Gyan Mishra
 Working Group: Routing Area Working Group (rtgwg)
This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568.
 Multi-segment SD-WAN via Cloud DCs
 
 draft-ietf-rtgwg-multisegment-sdwan-01.txt
 Date: 27/06/2024
 Authors: Kausik Majumdar, Linda Dunbar, Venkit Kasiviswanathan, Ashok Ramchandra, Aseem Choudhary
 Working Group: Routing Area Working Group (rtgwg)
This document describes a method for SD-WAN CPEs using GENEVE Encapsulation (RFC8926) to encapsulate the IPsec encrypted packets and send them to their closest Cloud GWs, who can steer the IPsec encrypted payload through the Cloud Backbone without decryption to the egress Cloud GWs which then forward the original IPsec encrypted payload to the destination CPEs. This method is for Cloud Backbone to connect multiple segments of SD-WAN without the Cloud GWs decrypting and re- encrypting the payloads.
 Destination/Source Routing
 
 draft-ietf-rtgwg-dst-src-routing-revive-02.txt
 Date: 21/10/2024
 Authors: David Lamparter, Anton Smirnov, Jen Linkova, Shu Yang, Mingwei Xu
 Working Group: Routing Area Working Group (rtgwg)
This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously.
 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
 
 draft-ietf-rtgwg-vrrp-rfc8347bis-00.txt
 Date: 06/11/2024
 Authors: Acee Lindem, Xufeng Liu, Athanasios Kyparlis, Ravi Parikh, Mingui Zhang
 Working Group: Routing Area Working Group (rtgwg)
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. To avoid YANG non-backward compatible change restrictions, the YANG module will have desigination ietf-vrrp-2.yang rather than ietf-vrrp.yang. This document obsoletes RFC 8347.


data-group-menu-data-url="/group/groupmenu.json">

Skip to main content

Routing Area Working Group (rtgwg)

WG Name Routing Area Working Group
Acronym rtgwg
Area Routing Area (rtg)
State Active
Charter charter-ietf-rtgwg-05 Approved
Document dependencies
Additional resources Issue tracker, Wiki, Zulip Stream
Personnel Chairs Jeff Tantsura, Yingzhen Qu
Area Director Jim Guichard
Mailing list Address rtgwg@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/rtgwg
Archive https://mailarchive.ietf.org/arch/browse/rtgwg/
Chat Room address https://zulip.ietf.org/#narrow/stream/rtgwg

Charter for Working Group

The Routing Area working group (RTGWG) is chartered to provide a
venue to discuss, evaluate, support and develop proposals for
new work in the Routing Area and may work on specific small topics
that do not fit with an existing working group.

Options for handling new work include:

  • Directing the work to an existing WG (including RTGWG)
  • Developing a proposal for a BoF.
  • Developing a charter and establishing consensus for a new WG. This
    option will primarily be used with fairly mature and/or well-defined efforts.
  • Careful evaluation, leading to deferring or rejecting work.

It is expected that the proposals for new work will only include items which
are not aligned with the work of other WGs or that may span multiple WGs.
The Area Directors and WG Chairs can provide guidance if there is any
doubt whether a topic should be discussed in RTGWG.

A major objective of the RTGWG is to provide timely, clear
dispositions of new efforts. Where there is consensus to take
on new work, the WG will strive to quickly find a home for it.
Reconsideration of proposals which have failed to gather consensus
will be prioritized behind proposals for new work which have not
yet been considered. In general, requests for reconsideration
should only be made once a proposal has been significantly
revised.

If RTGWG decides that a particular topic should be addressed by
a new WG, the chairs will recommend the work to the Routing ADs
with a summary of the evaluation. The Routing ADs may then choose
to follow the normal IETF chartering process (potential BoF, IETF-wide
review of the proposed charter, etc.).

Guiding principles for evaluation of new work by RTGWG will include:

  1. Providing a clear problem statement for proposed new work.

  2. Prioritizing new efforts to manage the trade-offs between urgency,
    interest, and available resources in the Routing Area.

  3. Looking for commonalities among ongoing efforts.
    Such commonalities may indicate the need to develop more
    general, reusable solutions.

  4. Ensuring appropriate cross-WG and cross-area review.

  5. Protecting the architectural integrity of the protocols developed
    in the Routing Area and ensuring that work has significant applicability.

RTGWG may also work on specific small topics that do not fit with an existing working group. An example of a small topic is a draft that might otherwise be AD-sponsored but which could benefit from the review and consensus that RTGWG can provide.

RTGWG may work on larger topics, but must be explicitly rechartered to add the topic. The specific larger topics that RTGWG is currently chartered to work on:

  • Enhancements to hop-by-hop distributed
    routing (e.g., multicast, LDP-MPLS, unicast routing) related to
    fast-reroute and loop-free convergence. A specific goal of
    fast-reroute mechanisms is to provide up to complete coverage when
    the potential failure would not partition the network. All work in
    this area should be specifically evaluated by the WG in terms of
    practicality and applicability to deployed networks.

  • Routing-related YANG models that are not appropriate for other RTG working
    groups.

The working group milestones will be updated as needed to reflect the
proposals currently being worked on and the target dates for their
completion.

Milestones

Date Milestone Associated documents
Feb 2024 SUBMITTED: Topology Independent Fast Reroute using Segment Routing draft-ietf-rtgwg-segment-routing-ti-lfa