One document matched: draft-lamparter-isis-p2mp-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-lamparter-isis-p2mp-01" ipr="trust200902">
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IS-IS Point-to-Multipoint operation"
>IS-IS Point-to-Multipoint operation</title>
<author fullname="Christian Franke" initials="C."
surname="Franke">
<organization>NetDEF</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<code></code>
<city>Leipzig</city>
<region></region>
<country>DE</country>
</postal>
<email>chris@opensourcerouting.org</email>
</address>
</author>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street/>
<code>04103</code>
<city>Leipzig</city>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<author initials="C." surname="Hopps" fullname="Christian E. Hopps">
<organization>Deutsche Telekom</organization>
<address>
<email>chopps@chopps.org</email>
</address>
</author>
<date day="19" month="October" year="2015" />
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>IS-IS Multipoint Multicast</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The core functionality of the protocol outlined in this document
consists of an additional Subnetwork dependent function per <xref
target="IS-IS">Section 8 of ISO/IEC 10589:2002</xref>.
In that regard, the next section can be understood as new section "8.5
Point-to-multipoint networks".</t>
<t>The outlined protocol is remotely similar to the derelict section
"8.3 ISO 8208 subnetworks" <xref target="X.25"/> in that multiple
point-to-point adjacencies are established on an interface.</t>
<t>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.</t>
</section>
<?rfc needLines="5" ?>
<section anchor="pseudocirc" title="Point-To-Multipoint Pseudocircuits">
<t>In place of <xref target="CLNS">ISO 8473 call management</xref>
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.</t>
<t>Each pseudocircuit operates, aside from subnetwork attachment
procedures, exactly as a P2P (Point-to-Point) link.</t>
<t>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.</t>
<section title="Pseudocircuit behaviour">
<t>An implementation maintains a set of pseudocircuits per P2MP
interface. Each pseudocircuit is uniquely identified by the local
interface and peer's SNPA address.</t>
<t>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.</t>
<t>Unnumbered media are not supported by this protocol. Each
participant on a link MUST have an unique SNPA address on that
link.</t>
<section title="Representation in LSPs">
<t>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.</t>
</section>
<section title="Forwarding">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Neighbor IS discovery">
<t>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.</t>
<t>A neighbors presence on the candidate list may be supported
by multiple sources. These sources are described in the
following sections</t>
<t>The IS-IS implementation SHOULD provide user configuration
to disable or filter individual sources.</t>
<section title="Manual configuration">
<t>A list of neighbor IS MAY be configured by the user, providing
possible neighbor's SNPAs on an interface.</t>
</section>
<section title="Lower layer autodiscovery">
<t>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.</t>
</section>
<section title="Multicast autodiscovery">
<t>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.</t>
<t>A multicast autodiscovery packet is defined as a P2P IIH
which is multicast over the LAN media as defined in <xref
target="RFC5309"/>. Additionally it must include a Three-Way
Adjacency TLV as defined in <xref target="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.</t>
<t>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.</t>
<t>If either passive or full multicast autodiscovery is enabled,
receiving a unicast autodiscovery PDU also adds the neighbor to
the candidate list.</t>
<!--
<t>[Ed: XXX chopps: should we consider automatic application of mesh
groups <xref target="RFC2973"/> as well?]</t>
-->
</section>
</section>
<section title="Adjacency formation">
<t>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.</t>
<t>To prevent different pseudocircuits from "bleeding" into each other,
implementations of this protocol MUST enable <xref target="RFC5303"/>
on all P2MP pseudocircuits, with changes as follows:
<list style="symbols">
<t>Received IIH PDUs on P2MP pseudocircuits without the
Point-to-Point Three-Way Adjacency option MUST be discarded.</t>
</list>
</t>
</section>
<section title="Pseudocircuit teardown">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="model" title="Configuration model">
<t>TODO: YANG model
<!-- maybe we can just get them to include us :). --></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TODO.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>TODO.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Acknowledge Les Ginsberg for pointing out that P2P Hellos
rather than LAN hellos could and should be used.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="October 2015 [-01]:">Moved from new P2MP Hello PDU to
using existing P2P PDU.</t>
<t hangText="July 2015 [-00]:">Initial Version</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IS-IS">
<front>
<!-- [IS-IS] ISO/IEC 10589:2002, Second Edition, "", 2002. -->
<title>Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the Protocol
for Providing the Connectionless-mode Network Service (ISO
8473)</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
<?rfc include="reference.RFC.5303"?>
<?rfc include="reference.RFC.5309"?>
</references>
<references title="Informative References">
<reference anchor="X.25">
<front>
<title>X.25 Packet Layer Protocol for Data Terminal Equipment</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2000"/>
</front>
<seriesInfo name="ISO/IEC" value="8208:2000"/>
</reference>
<reference anchor="CLNS">
<front>
<title>Protocol for providing the connectionless-mode network
service: Protocol specification</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ISO/IEC" value="8473-1:1998"/>
</reference>
<!-- rfc include="reference.RFC.2973" -->
<?rfc include="reference.RFC.7176"?>
<?rfc include="reference.RFC.7356"?>
</references>
<section anchor="Misconfig" title="Misconfiguration With P2P over LAN">
<t>TODO.</t>
<!--
<t>As this specification utilizes the same initial P2P IIH PDU
as <!- - xref target="RFC" - -> for discovering neighbors it is possible
that it could interact with an adjacent (XXX better word
co-connected/participatin/...?) LAN interface that has been
mis-configured for P2P over LAN operation. We examine the
possible results given this scenario</t>
<t>There are 4 cases to consider, whether or not the neighbor
acts on our subsequent unicast PDUs and whether it has 3-way
adjacency TLV configured. In all cases the neighbor will receive
our discovery multicast DOWN state P2P IIH PDU and may enter
INIT or UP state. We examine the cases in the following
sections.</t>
<t>In none of the cases will a P2MP router consider itself UP
with the misconfigured P2P router and so will not advertise the
adjacency. As only 1/2 of the adjacency will be announced the
2-way connectivity check will fail, and no packets will forward
between the 2 routers.</t>
<t>Every misconfiguration case is detectable (as IIHs missing
3-way or IIHs multicast with non DOWN 3-way TLV will be seen). A
P2MP router SHOULD use whatever means appropriate to alert the
operator to the misconfiguration.</t>
<section anchor="Mcast3Way" title="3-Way Enabled Unicast Ignored">
<t>In the case where the neighbor has 3-way enabled and
unicast packets are ignored the neighbor will enter 3-way INIT
state with the first P2P discovery IIH it receives. It will
ignore other routers P2P discovery IIH while in this state (ref
p2poe). It will never progress to the UP state as it will
never receive a P2P IIH (unicast) indicating it has been seen.</t>
<t>The result is that no adjacency will be seen on this link.</t>
</section>
<section anchor="Ucast3Way" title="3-Way Enabled Unicast Processed">
<t>In the case where the neighbor has 3-way enabled and
unicast packets are processed the neighbor will enter 3-way
INIT state with the first P2P discovery IIH it receives. It
will ignore other routers P2P discovery IIH while in this
state (ref p2poe). We will ignore the neighbors "reply" P2P
IIH indicating INIT state because it is multicast instead of
unicast, and so will not enter into the UP state.</t>
<t>Likewise we may enter INIT state with the P2P neighbor and
begin to send unicast P2P IIHs indicating this. This will
cause the neighbor to enter the UP state; however, our
subsequent P2P discovery IIH indicating DOWN will bring the
adjacency down.</t>
<t>The result is that a flapping (and changing) adjacency may
be advertised by the neighbor</t>
</section>
<section anchor="twoWay" title="3-Way Disabled">
<t>If a neighbor is not configured for 3-way operation,
regardless of unicast processing, a P2MP router will never
transition to INIT or UP state with it as it's IIH
lacks a 3-way TLV.</t>
<t>The neighbor neighbor will transition to the UP state with
the first P2MP discovery IIH it receives which may be us. It
will discard P2MP discovery PDUs from other P2MP neighbors
(according to section 4.5 of P2PoLAN).</t>
<t>The result is that a steady adjacency may be advertised by
the neighbor</t>
</section>
-->
</section>
</back>
</rfc>
<!-- vim: sw=2 ts=2 et
-->
| PAFTECH AB 2003-2026 | 2026-04-23 04:53:19 |