Network Working Group                                            D. Ward
Internet-Draft                                                  R. White
Expires: May 3, 2009                                        D. Farinacci
                                                             A. Banerjee
                                                           Cisco Systems
                                                              R. Perlman
                                                        Sun Microsystems
                                                        November 3, 2008


                  Carrying Attached Addresses in IS-IS
                          draft-ward-l2isis-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 3, 2009.

Abstract

   This draft specifies the IS-IS extensions necessary to support multi-
   link IPv4 and IPv6 networks, as well as to provide true link state
   routing to any protocols running directly over layer 2.  While
   supporting this concept involves several pieces, this document only
   describes extensions to IS-IS.  We leave it to the systems using
   these IS-IS extensions to explain how the information carried in
   IS-IS is used.




Ward, et al.               Expires May 3, 2009                  [Page 1]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


1.  Overview

   There are a number of systems (for example, [RBRIDGES]) which have
   proposed using layer 2 addresses carried in a link state routing
   protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
   2 routing in specific environments.  This draft proposes a set of
   TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new
   PDU types, to support these proposed systems.

   This draft does not propose new forwarding mechanisms using this
   additional information carried within IS-IS.  There is a short
   section included on two possible ways to build a shortest path first
   tree including this information, to illustrate how this information
   might be used.


2.  Proposed Enhancements to IS-IS

   This draft proposes additional TLVs, to carry unicast and multicast
   attached address information.  It also proposes additional sub-tlvs
   to carry information regarding building trees for Layer 2 networks.
   This draft proposes three new IS-IS PDUs, the Multicast Group
   (MGROUP) PDU, for carrying a list of attached or joined multicast
   groups.  The Multicast Group Complete Sequence Number (MGROUP-CSNP)
   PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU
   packets are also defined to be used with the new MGROUP-PDU to
   perform database exchange on the MGROUP PDU packets.

2.1.  The MAC-Reachability TLV

   The MAC-Reachability (MAC-RI) sub-TLV is IS-IS TLV type 141 and has
   the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type= MAC-RI  | Length        |              Vlan-Id          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MAC (1)            |             MAC (2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (2)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       .................                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Ward, et al.               Expires May 3, 2009                  [Page 2]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   o  Type: TLV Type, set to 141 (MAC-RI).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV.
   o  MAC(i): This is the 48-bit MAC address reachable from the IS that
      is announcing this TLV.

   The MAC-RI TLV is carried in a standard Level 1 link state PDU.  It
   MUST contain only unicast addresses.

2.2.  The Group Address TLV

   The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the
   following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = GADDRTLV| Length        |              sub-tlvs         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to GADDR-TLV 142 [TBD].
   o  Length: Total number of octets contained in the TLV, including the
      length of the sub-tlvs carried in this TLV.
   o  sub-tlvs: The following sub-TLVs are defined.

   The GADDR TLV is carried within Multicast Group Level 1 link state
   PDU.

2.2.1.  The Group MAC Address sub-TLV

   The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS TLV type 1 and has
   the following format:

   +-+-+-+-+-+-+-+-+
   | Type=GMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Ward, et al.               Expires May 3, 2009                  [Page 3]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   where each group record is of the form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV.
   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this TLV.
   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It then has a
      48-bit multicast Group Address followed by 48-bit source MAC
      addresses.  An address being a group multicast address or unicast
      source address can be checked using the multicast bit in the
      address.

   The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.2.2.  The Group IP Address sub-TLV

   The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has
   the following format:















Ward, et al.               Expires May 3, 2009                  [Page 4]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   +-+-+-+-+-+-+-+-+
   | Type=GIP-ADDR |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 2 (GIP-ADDR).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent IPv4 source or group addresses in this TLV.
   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this TLV.
   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
      addresses.

   The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried
   in a standard Level 1 link state MGROUP PDU.






Ward, et al.               Expires May 3, 2009                  [Page 5]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


2.2.3.  The Group IPv6 Address sub-TLV

   The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and
   has the following format:

   +-+-+-+-+-+-+-+-+
   |Type=GIPv6-ADDR|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address        (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 3 (GIPV6-ADDR).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent IPv6 source or group addresses in this TLV.
   o  Number of Group Records: This of length 1 byte and lists the
      number of group records in this TLV.
   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 128-bit multicast IPv6 Group Address followed by 128-bit
      source IPv6 addresses.




Ward, et al.               Expires May 3, 2009                  [Page 6]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.3.  Sub-TLVs for the Capability TLV

   The Capability TLV is an optional TLV [RFC 4971] that may be
   generated by the originating IS.  We introduce these additional sub-
   TLVs that are carried within it.  These sub-tlvs announce the
   capabilities of the router for the entire IS-IS routing domain.

2.3.1.  The Device ID sub-TLV

   The Device ID (DEVID) sub-TLV carries information about the identity
   of the advertising device, along with information about device
   priority.  The Device-Id sub-TLV MUST be carried within the
   CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the
   originating IS.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type          | Length        |    Reserved   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |          Device Id            |
   +---------------------------------------------------------------+

   o  Type: TLV Type, set to 5 (DEVID).
   o  Length: Total number of octets contained in the TLV.
   o  Reserved: Set to 0.
   o  Priority: Set to application dependent values.
   o  Device ID: Left padded device ID or alias.

2.3.2.  The Root Priority sub-TLV

   The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV
   in a level-1 non-pseudo-node LSP generated by the originating IS.
   Each device announces a broadcast root-priority and the number of
   trees it expects all other nodes to compute if it does become the
   broadcast root.  Once a node receives a new LSP, it runs an election
   algorithm, independently of the other nodes in the network, to
   determine the broadcast root.  The node that announced the lowest
   broadcast priority becomes the root of the broadcast tree.  If two
   devices advertise the same broadcast priority, the device with the
   lower system ID becomes the root of the broadcast tree.  The elected
   broadcast-root decides on the multicast-roots to be used in the
   network domain and their roots.  This announcement takes place in the
   roots identifier sub-TLV.





Ward, et al.               Expires May 3, 2009                  [Page 7]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   +-+-+-+-+-+-+-+-+
   |Type = ROOT-PRI|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Broadcast Root Pri        |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num of multi-destination trees |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 6 (ROOT-PRI).
   o  Length: Total number of octets contained in the TLV.
   o  Br Root Pri: This gives the value of the priority with which this
      node wants to be the broadcast root node in the Layer-2 domain.
   o  Num of multi-destination trees: This gives the number of
      distribution trees for multi-destination frames that will be in
      use in the Layer-2 domain, excluding the broadcast tree rooted at
      itself, if this device becomes the broadcast root in the domain.

2.3.3.  The Root Identifier Sub-tlv

   The root identifier sub-tlv is populated by the root of the broadcast
   tree.  If this is also announced by other nodes in the network, it
   implies that the specific node that is advertising it will only
   restrict traffic to the common set of the trees in its announcement
   and the ones announced by the broadcast root.  It is carried within
   the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type= ROOT-IDs | Length        | Broadcast Root System  Id...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ... Broadcast Root System  Id                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Multicast Root System  Id  ...                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... Multicast Root System  Id |   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 7 (ROOT-IDs).
   o  Length: Total number of octets contained in the TLV.
   o  Broadcast Root System Id: The Broadcast Root System ID at which a
      broadcast tree is rooted.  It is of length 6 bytes.
   o  Multicast Root System Id: The Multicast Root System ID at which a
      multicast tree is rooted.  It is of length 6 bytes.
   A locally significant hash is used by edge devices to determine which
   multicast root (or set of multicast roots) is used to send traffic
   for a specific multicast group.  If there is a discrepancy between



Ward, et al.               Expires May 3, 2009                  [Page 8]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   the number of multi-destination trees the broadcast-root has
   announced, and the number of roots the root-identifier carries, nodes
   should compute trees on the additional roots.


3.  The Multicast Group PDU

   The systems that this draft is concerned with want to carry not only
   layer-2 unicast information in the link state protocols, but also
   multicast information.  This draft has defined a new Multicast Group
   (MGROUP) PDU that can be used to advertise a set of attached, or
   joined, multicast groups.  Accordingly, it has also introduced a
   couple more PDUs as described in the next sections for the flooding
   and update process to work seamlessly.

   In the Layer-2 environment, it is expected the join/leave frequency
   of the multicast members will be much higher than unicast topology
   changes.  It is efficient to separate the updates for the group
   membership change information from the remainder of the information
   by placing this information in a separate PDU.  This enables
   reachability information, that would trigger an SPF, to be not
   impacted at all.  Furthermore, during SPF runs, TLVs being on
   different PDUs which do not affect SPF need not be inspected during
   processing.

   The choice of a different PDU also opens the LSP-space to another 256
   fragments to carry a large number of groups.  This additional space
   can be used judiciously to carry only multicast information.

   The Multicast Group (MGROUP) PDU can be used to advertise a set of
   attached, or joined, multicast groups.  The MGROUP PDU is formatted
   identical to a Level 1 Link State PDU, as described in Section 9.3 of
   [IS-IS].  One field, PDU Type, is changed to 19 [TBD], to signify
   this PDU is carrying multicast group information, rather than unicast
   reachability information.

   The Multicast Group PDU carries TLVs indicating multicast membership
   information.  There are three sub-TLVs of the GADDR TLV defined in
   this document, that MAY be present in this PDU, namely, GMAC-ADDR,
   GIP-ADDR, and GIPV6-ADDR TLVs.

   One or more TLVs MAY be carried in a single MGROUP PDU.  Future
   multicast address TLVs MAY be defined using other type codes, and be
   carried in an MGROUP PDU.







Ward, et al.               Expires May 3, 2009                  [Page 9]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


3.1.  The Multicast Group Partial Sequence Number PDU

   The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
   to reliably flood the MGROUP PDU following the base protocol
   specifications.

3.2.  The Multicast Group Complete Sequence Number PDU

   The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
   used to reliably flood the MGROUP PDU following the base protocol
   specifications.

3.3.  Enhancements to the flooding process

   This draft proposes that the information contained in the MGROUP-PDU
   is in a parallel database and its update mechanisms mimic that of the
   regular database.  Nodes running IS-IS in an L2 domain MUST support
   these additional MGROUP PDUs defined in this draft.  In general, the
   flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP-
   CSNP PDUs uses the same update procedures as defined for the regular
   LSP, PSNP, and CSNP PDUs.

   For example, on P2P links CSNP is exchanged on the formation of an
   adjacency.  In a similar fashion a MGROUP-CSNP MUST also be exchanged
   between the neighbors at the same time.  This gets the initial
   MGROUP-database synchronization going.  After this similar actions of
   the base protocol specifications for the regular database
   synchronization will be maintained to keep the MGROUP-database
   synchronized.

   Similarly, on LAN links the DIS is responsible for sending periodic
   CSNP transmissions.  The DIS in the L2 IS-IS network domain will also
   be responsible for sending periodic MGROUP-CSNP transmissions.  The
   update and flooding process will work in parallel for the two
   databases and there is no further synchronization between them.

   In general, the database synchronization is performed in parallel
   with no interactions between the messages.  However, the initial
   triggers that start a CSNP exchange are correlated, in the sense it
   also triggers a MGROUP-CSNP exchange.  For example, during graceful
   restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange
   and update process will be run for the MGROUP-PDUs and restart
   process completes after both databases have been received.


4.  Considerations for Using L2 Information in IS-IS

   While this document does not specify the way in which addresses



Ward, et al.               Expires May 3, 2009                 [Page 10]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   carried in these TLVs is used in IS-IS, two general areas of concern
   are considered in this section: building the SPF tree when using this
   information, and the election of designated intermediate systems
   (DIS) in an environment using this information.

4.1.  Building SPF Trees with Layer 2 Information

   Each IS which is part of a single broadcast domain from a layer 2
   perspective will build multiple SPF trees (SPT) for every IS that is
   announced by the IS deemed to be the broadcast root.

   We assume some mechanism for forwarding traffic to these attached
   addresses added to the SPT is provided for in the mechanism proposing
   the use of these extension TLVs.

4.2.  Designated Intermediate Routers

   A single DIS SHOULD be elected as described in [IS-IS] for each layer
   2 broadcast domain (VLAN) for which information is being carried in
   IS-IS.  This reduces the amount of work required to flood and
   maintain synchronized databases over the underlying media on which
   IS-IS is running and providing layer 2 forwarding information for.


5.  Acknowledgements

   The authors would like to thank Les Ginsberg for his useful comments.


6.  Security Considerations

   This document adds no additional security risks to IS-IS, nor does it
   provide any additional security for IS-IS.


7.  IANA Considerations

   This document creates three new PDU types, namely the MCAST PDU,
   MCAST-CSNP PDU, and the MCAST-PSNP PDU.  IANA SHOULD assign a new PDU
   type to the level-1 PDUs described above and reflect it in the PDU
   registry.

      MCAST-PDU        Level-1 PDU Type: 19
      MCAST-CSNP-PDU   Level-1 PDU Type: 22
      MCAST-PSNP-PDU   Level-1 PDU Type: 29

   This document requires the definition a set of new ISIS TLVs, the
   MAC-Reachability TLV (type 141), and the Group Address TLV (type 142)



Ward, et al.               Expires May 3, 2009                 [Page 11]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


   that needs to be reflected in the ISIS TLV code-point registry.

   This document creates a number of new sub-TLV in the numbering space
   for the Group Address TLV and the Capability TLV.  The TLV and sub-
   TLVs are given below:

                                             IIH  LSP  SNP MCAST MCAST
                                                            LSP   SNP
      MAC-RI TLV  (141)                       -    X    -    -     -

      GADDR-TLV   (142)                       -    -    -    X     -
      GADDR-TLV.GMAC-ADDR      sub-tlv  1     -    -    -    X     -
      GADDR-TLV.GMAC-IP        sub-tlv  2     -    -    -    X     -
      GADDR-TLV.GMAC-IPV6      sub-tlv  3     -    -    -    X     -

      CAPABILITY.Device ID     sub-tlv  5     -    X    -    X     -
      CAPABILITY.Root Priority sub-tlv  6     -    X    -    -     -
      CAPABILITY.Roots         sub-tlv  7     -    X    -    -     -
   IANA SHOULD manage the remaining space using the consensus method.


8.  References

8.1.  Normative References

   [IS-IS]    ISO/IEC 10589, "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)", 2005.

   [RFC 1195]
              Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
              Dual Environments", 1990.

   [RFC 3847]
              Shand, M. and L. Ginsberg, "Restart Signaling for
              Intermediate System to Intermediate System (IS-IS)", 2004.

   [RFC 4971]
              Vasseur, JP. and N. Shen, "Intermediate System to
              Intermediate System (IS-IS) Extensions for Advertising
              Router Information", 2007.

8.2.  Informative References

   [RBRIDGES]
              Perlman, R. and J. Touch, "Transparent Interconnection of
              Lots of Links (TRILL):  Problem and Applicability



Ward, et al.               Expires May 3, 2009                 [Page 12]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


              Statement", 2008.


Authors' Addresses

   David Ward
   Cisco Systems

   Email: wardd@cisco.com


   Russ White
   Cisco Systems

   Email: riw@cisco.com


   Dino Farinacci
   Cisco Systems

   Email: dino@cisco.com


   Ayan Banerjee
   Cisco Systems

   Email: ayabaner@cisco.com


   Radia Perlman
   Sun Microsystems

   Email: Radia.Perlman@Sun.com


















Ward, et al.               Expires May 3, 2009                 [Page 13]


Internet-Draft    Carrying Attached Addresses in IS-IS      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Ward, et al.               Expires May 3, 2009                 [Page 14]