RFC 8361 on Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new Request for Comments is now available in online RFC libraries.

        
        RFC 8361

        Title:      Transparent Interconnection of Lots of 
                    Links (TRILL): Centralized Replication for Active-Active 
                    Broadcast, Unknown Unicast, and Multicast (BUM) 
                    Traffic 
        Author:     W. Hao,
                    Y. Li,
                    M. Durrani,
                    S. Gupta,
                    A. Qu
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2018
        Mailbox:    haoweiguo@huawei.com, 
                    liyizhou@huawei.com, 
                    mdurrani@equinix.com,
                    sujay.gupta@ipinfusion.com, 
                    laodulaodu@gmail.com
        Pages:      17
        Characters: 40095
        Updates:    RFC 6325

        I-D Tag:    draft-ietf-trill-centralized-replication-13.txt

        URL:        https://www.rfc-editor.org/info/rfc8361

        DOI:        10.17487/RFC8361

In Transparent Interconnection of Lots of Links (TRILL) active-active
access, a Reverse Path Forwarding (RPF) check failure issue may occur
when using the pseudo-nickname mechanism specified in RFC 7781.  This
document describes a solution to resolve this RPF check failure issue
through centralized replication.  All ingress Routing Bridges
(RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM)
traffic to a centralized node with unicast TRILL encapsulation.  When
the centralized node receives the BUM traffic, it decapsulates the
packets and forwards them to their destination RBridges using a
distribution tree established per the TRILL base protocol (RFC 6325).
To avoid RPF check failure on an RBridge sitting between the ingress
RBridge and the centralized replication node, some change in the RPF
calculation algorithm is required.  RPF checks on each RBridge MUST
be calculated as if the centralized node was the ingress RBridge,
instead of being calculated using the actual ingress RBridge.  This
document updates RFC 6325.

This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux