IS-IS Point-to-Multipoint operation
draft-lamparter-isis-p2mp-02

Abstract

This document describes a new mode operation for IS-IS. In addition to the existing LAN and point-to-point modes of operation, a point-to-multipoint mode is defined. This mode is useful for operation both on networks with more than two routers where multicast is expensive in comparison to unicast, as well on networks where creating a LAN pseudonode cannot adequately reflect metrics.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 19, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Point-To-Multipoint Pseudocircuits
• 2.1. Pseudocircuit behaviour
• 2.1.1. Representation in LSPs
• 2.1.2. Forwarding
• 2.2. Neighbor IS discovery
• 2.2.1. Manual configuration
• 2.2.2. Lower layer autodiscovery
• 2.2.3. Multicast autodiscovery
• 2.3. Adjacency formation
• 2.4. Pseudocircuit teardown
• 3. Configuration model
• 4. Security Considerations
• 5. Privacy Considerations
• 6. Acknowledgements
• 7. Change Log
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Misconfiguration With P2P over LAN
• Authors' Addresses

1. Introduction

The core functionality of the protocol outlined in this document consists of an additional Subnetwork dependent function per Section 8 of ISO/IEC 10589:2002 [IS-IS]. In that regard, the next section can be understood as new section "8.5 Point-to-multipoint networks".

The outlined protocol is remotely similar to the derelict section "8.3 ISO 8208 subnetworks" [X.25] in that multiple point-to-point adjacencies are established on an interface.

Point-to-multipoint operation of IS-IS is thus not a new idea; in fact section 6.2 already mentions "multipoint links." This document re-enables the concept.

2. Point-To-Multipoint Pseudocircuits

In place of ISO 8473 call management [CLNS] establishing sessions, this document establishes pairwise "pseudocircuits" between two IS on a common medium. Multiple such pseudocircuits can normally exist on one P2MP (Point-To-Multipoint) interface.

Each pseudocircuit operates, aside from subnetwork attachment procedures, exactly as a P2P (Point-to-Point) link.

It should be noted that while the Multicast autodiscovery mechanism requires broadcast capability, no other part of the protocol does. The P2MP interface type can be used on non-transitive and/or non-broadcast interfaces.

2.1. Pseudocircuit behaviour

An implementation maintains a set of pseudocircuits per P2MP interface. Each pseudocircuit is uniquely identified by the local interface and peer's SNPA address.

Each participating system MUST use a consistent SNPA address per local interface. A change in SNPA address results in all neighbors treating the interface as distinct from the previous one. A system MAY support multiple SNPA addresses per interface by treating them as distinct interfaces.

Unnumbered media are not supported by this protocol. Each participant on a link MUST have an unique SNPA address on that link.

2.1.1. Representation in LSPs

Pseudocircuits are represented in LSPs as a regular P2P circuit would be. As a result, their treatment in SPF calculations is also identical to P2P circuits.

2.1.2. Forwarding

In scenarios where pseudocircuits do not form a full mesh of all participants on a medium, the best path for a packet may be through the same interface as the one it was received on.

Systems implementing this specification MUST therefore support forwarding packets on the same interface that they were received on. This applies only to interfaces configured for P2MP operation.

2.2. Neighbor IS discovery

The discovery machinery produces as output a "candidate neighbor list," which is a list of possible neighbor's SNPAs and is maintained per P2MP interface. Adding and removing entries to the candidate neighbor list results in pseudocircuit creation and deletion.

A neighbors presence on the candidate list may be supported by multiple sources. These sources are described in the following sections

The IS-IS implementation SHOULD provide user configuration to disable or filter individual sources.

2.2.1. Manual configuration

A list of neighbor IS MAY be configured by the user, providing possible neighbor's SNPAs on an interface.

2.2.2. Lower layer autodiscovery

Lower protocol layers (VPLS, IEEE 802.11) may be able to provide a list of attached neighbors. This list MAY be fed into the candidate neighbor list.

2.2.3. Multicast autodiscovery

For broadcast capable networks, this document defines an autodiscovery mechanism based on multicasting Hello packets. This mechanism MAY be disabled by the user, but MUST be implemented for all lower layer link types with (limited or full) broadcast capability.

A multicast autodiscovery packet is defined as a P2P IIH which is multicast over the LAN media as defined in [RFC5309]. Additionally it must include a Three-Way Adjacency TLV as defined in [RFC5303] indicating the circuit is in the DOWN state (i.e., 1 octet of value indicating the DOWN state). Receiving such a Hello places the sending IS on the candidate list for as long as the PDU's holdtime indicates.

A system MAY implement a receive-only passive multicast autodiscovery mode where it adds candidates (forms pseudocircuits) on receiving autodiscovery PDU, but does not send such PDUs itself.

If either passive or full multicast autodiscovery is enabled, receiving a unicast autodiscovery PDU also adds the neighbor to the candidate list.

2.3. Adjacency formation

Since there may be no underlying protocol layer partitioning the link into actual P2P circuits in this case, additional handling is required on bringing up the individual pseudocircuit adjacencies.

To prevent different pseudocircuits from "bleeding" into each other, implementations of this protocol MUST enable [RFC5303] on all P2MP pseudocircuits, with changes as follows:

• Received IIH PDUs on P2MP pseudocircuits without the Point-to-Point Three-Way Adjacency option MUST be discarded.

2.4. Pseudocircuit teardown

Pseudocircuits are destroyed when their P2P state machine has transitioned into "Down" state and they are no longer supported as a candidate by any discovery mechanism.

As long as a pseudocircuit is present, its P2P state machine will, as expected for P2P circuits, trigger transmission of further Hello PDUs, even when it is in Down state.

3. Configuration model

TODO: YANG model

4. Security Considerations

TODO.

5. Privacy Considerations

TODO.

6. Acknowledgements

Acknowledge Les Ginsberg for pointing out that P2P Hellos rather than LAN hellos could and should be used.

7. Change Log

April 2016 [-02]:

(no changes/keepalive)

October 2015 [-01]:

Moved from new P2MP Hello PDU to using existing P2P PDU.

July 2015 [-00]:

Initial Version

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Misconfiguration With P2P over LAN

TODO.

Authors' Addresses