draft-lamparter-isis-p2mp.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-02" 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>04229</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="17" month="April" year="2016" />

    <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" ?>

    <!-- TODO DL: glossary, maybe? -->

    <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>
        <!-- TODO DL: unnumbered IPv4? -->

        <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>
          -->

          <!-- XXX DL: ARP / ND?  guess not, but might want to say that -->
        </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 "packet processing"

      DL: broken bridges rewriting the destination MAC will break P2MP
      systems' capability to discern discovery IIHs and pseudocircuit IIHs;
      the discovery will reset the link to down.  Might want to just ignore
      "down" IIHs?  Need to describe behaviour on receiving that anyway.

      receive IIH w/o 3way:     discard
      receive IIH 3way Down:    discovery handling, MUST NOT process on pseudocircuit
      receive IIH 3way Init/Up: check IDs, process on pseudocircuit

      a P2MP circuit has only 1 extended local circuit ID, same for all pseudocircuits

      all in all, might not really need to check the L2 destination address
      on IIHs for proper operation (=> a SHOULD?).  doesn't really break
      LSPs either.
    -->
    <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="April 2016 [-02]:">(no changes/keepalive)</t>
          <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>

      [XXX DL: multicast autodiscovery can be put into passive mode or
      disabled; peers might be discovered from other sources.]

      <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
           [XXX DL: really? can't find anything in 5303 on what neighbor IDs
           to send if IIHs from multiple systems are seen.  nonetheless, end
           result is the same.]
        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>If the P2MP system sends no discovery packets (passive mode),
        it will passively discover the P2P system and send unicast IIHs,
        which will be ignored.  The P2P system will be in 3way down (no
        neighbor seen) state instead of 3way-init.</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>

        [DL: If P2MP discovery is passive, P2P system will stay in UP
        and "lock on" to the first P2MP system it sees.  This can be used
        as hitless migration from P2P to P2MP mode if the P2MP system
        accepts multicast packets (=> full adjacency coming up).

        If there's more than 2 P2P systems on the link, adjacencies will be
        random by timing.]

        [DL: If the link is a private vlan (RFC5517) or some other kind of
        NBMA with a single broadcast-capable node, a P2MP system on that port
        ("promisc" in 5517) will work with multiple P2P.  IMHO should be
        mentioned in an appendix and declared explicitly out of scope
        ("warranty void").  With all-P2MP systems this is in scope as NBMA
        link with partial broadcast capability and should work as intended.]
      </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>

        [DL: P2MP passive: P2MP system receives IIH w/o 3way, discards;
        since no IIHs are being sent, P2PoL system will stay down.]
      </section>
      -->
    </section>
  </back>
</rfc>
<!-- vim: sw=2 ts=2 et
-->