< draft-ietf-bier-isis-extensions-04.txt   draft-ietf-bier-isis-extensions-05.txt >
Internet Engineering Task Force L. Ginsberg, Ed. Internet Engineering Task Force L. Ginsberg, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track A. Przygienda Intended status: Standards Track A. Przygienda
Expires: September 28, 2017 Juniper Networks Expires: January 28, 2018 Juniper Networks
S. Aldrin S. Aldrin
Google Google
J. Zhang J. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
March 27, 2017 July 27, 2017
BIER support via ISIS BIER support via ISIS
draft-ietf-bier-isis-extensions-04 draft-ietf-bier-isis-extensions-05
Abstract Abstract
Specification of an ISIS extension to support BIER domains and sub- Specification of an ISIS extension to support BIER domains and sub-
domains. domains.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017. This Internet-Draft will expire on January 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4
4.2. Advertising BIER Information . . . . . . . . . . . . . . 5 4.2. Advertising BIER Information . . . . . . . . . . . . . . 5
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Enabling a BIER Sub-Domain . . . . . . . . . . . . . . . 5 5.1. Enabling a BIER Sub-Domain . . . . . . . . . . . . . . . 5
5.2. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5 5.2. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 6
5.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. Label advertisements for MPLS Encapsulation . . . . . . . 6 5.5. Label advertisements for MPLS Encapsulation . . . . . . . 6
5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6
5.7. Reporting Misconfiguration . . . . . . . . . . . . . . . 6 5.7. Reporting Misconfiguration . . . . . . . . . . . . . . . 7
5.8. Flooding Reduction . . . . . . . . . . . . . . . . . . . 7 5.8. Flooding Reduction . . . . . . . . . . . . . . . . . . . 7
6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7
6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8
6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9
6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 9 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) Bit Index Explicit Replication (BIER)
[I-D.draft-ietf-bier-architecture-05] defines an architecture where [I-D.draft-ietf-bier-architecture-07] defines an architecture where
all intended multicast receivers are encoded as bitmask in the all intended multicast receivers are encoded as bitmask in the
Multicast packet header within different encapsulations such as Multicast packet header within different encapsulations such as
[I-D.draft-ietf-bier-mpls-encapsulation-06]. A router that receives [I-D.draft-ietf-bier-mpls-encapsulation-07]. A router that receives
such a packet will forward the packet based on the Bit Position in such a packet will forward the packet based on the Bit Position in
the packet header towards the receiver(s), following a precomputed the packet header towards the receiver(s), following a precomputed
tree for each of the bits in the packet. Each receiver is tree for each of the bits in the packet. Each receiver is
represented by a unique bit in the bitmask. represented by a unique bit in the bitmask.
This document presents necessary extensions to the currently deployed This document presents necessary extensions to the currently deployed
ISIS for IP [RFC1195] protocol to support distribution of information ISIS for IP [RFC1195] protocol to support distribution of information
necessary for operation of BIER domains and sub-domains. This necessary for operation of BIER domains and sub-domains. This
document defines a new TLV to be advertised by every router document defines a new TLV to be advertised by every router
participating in BIER signaling. participating in BIER signaling.
2. Terminology 2. Terminology
Some of the terminology specified in Some of the terminology specified in
[I-D.draft-ietf-bier-architecture-05] is replicated here and extended [I-D.draft-ietf-bier-architecture-07] is replicated here and extended
by necessary definitions: by necessary definitions:
BIER: Bit Index Explicit Replication (The overall architecture of BIER: Bit Index Explicit Replication (The overall architecture of
forwarding multicast using a Bit Position). forwarding multicast using a Bit Position).
BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn
about BFER's). about BFER's).
BFR: Bit Forwarding Router (A router that participates in Bit Index BFR: Bit Forwarding Router (A router that participates in Bit Index
Multipoint Forwarding). A BFR is identified by a unique BFR- Multipoint Forwarding). A BFR is identified by a unique BFR-
skipping to change at page 4, line 22 skipping to change at page 4, line 26
This document adds the following new sub-TLV to the registry of sub- This document adds the following new sub-TLV to the registry of sub-
TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236
[RFC5305],[RFC5308]. [RFC5305],[RFC5308].
Value: 32 (suggested - to be assigned by IANA) Value: 32 (suggested - to be assigned by IANA)
Name: BIER Info Name: BIER Info
This document also introduces a new registry for sub-sub-TLVs for the This document also introduces a new registry for sub-sub-TLVs for the
BIER Info sub-TLV added above. The registration policy is Expert BIER Info sub-TLV added above. The registration policy is Expert
Review as defined in [RFC5226]. This registry is part of the "IS-IS Review as defined in [RFC8126]. This registry is part of the "IS-IS
TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs
for BIER Info sub-TLV". The defined values are: for BIER Info sub-TLV". The defined values are:
Type Name Type Name
---- ---- ---- ----
1 BIER MPLS Encapsulation 1 BIER MPLS Encapsulation
2 BIER sub-domain Tree Type 2 BIER sub-domain Tree Type
3 BIER sub-domain BSL conversion 3 BIER sub-domain BSL conversion
4. Concepts 4. Concepts
skipping to change at page 5, line 7 skipping to change at page 5, line 11
which <MT,SD> pairs are supported by a router. The mapping of sub- which <MT,SD> pairs are supported by a router. The mapping of sub-
domains to topologies MUST be consistent within a BIER flooding domains to topologies MUST be consistent within a BIER flooding
domain. domain.
Each BIER sub-domain has as its unique attributes the encapsulation Each BIER sub-domain has as its unique attributes the encapsulation
used and the type of tree it is using to forward BIER frames used and the type of tree it is using to forward BIER frames
(currently always SPF). Additionally, per supported bitstring length (currently always SPF). Additionally, per supported bitstring length
in the sub-domain, each router will advertise the necessary label in the sub-domain, each router will advertise the necessary label
ranges to support it. ranges to support it.
At present, IS-IS support for a given BIER domain/sub-domain is
limited to a single area - or to the IS-IS L2 sub-domain.
4.2. Advertising BIER Information 4.2. Advertising BIER Information
BIER information advertisements are associated with a new sub-TLV in BIER information advertisements are associated with a new sub-TLV in
the extended reachability TLVs. BIER information is always the extended reachability TLVs. BIER information is always
associated with a host prefix which MUST be a node address for the associated with a host prefix which MUST be a node address for the
advertising node. The following restrictions apply: advertising node. The following restrictions apply:
o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6
prefix prefix
skipping to change at page 5, line 33 skipping to change at page 5, line 40
5. Procedures 5. Procedures
5.1. Enabling a BIER Sub-Domain 5.1. Enabling a BIER Sub-Domain
A given sub-domain with identifier SD with supported bitstring A given sub-domain with identifier SD with supported bitstring
lengths MLs in a multi-topology MT [RFC5120] is denoted further as lengths MLs in a multi-topology MT [RFC5120] is denoted further as
<MT,SD,MLs> and does not have to be advertised by default by BFRs to <MT,SD,MLs> and does not have to be advertised by default by BFRs to
preserve the scaling of the protocol (i.e. ISIS carries no TLVs preserve the scaling of the protocol (i.e. ISIS carries no TLVs
containing any of the elements related to <MT,SD>). The containing any of the elements related to <MT,SD>). The
advertisement may be triggered e.g. by a first BIER sub-TLV advertisement may be triggered e.g. by a first BIER sub-TLV
(Section 6.1) containing <MT,SD> advertised into the area. The (Section 6.1) containing <MT,SD> advertised into the Level 1 area (or
specific trigger itself is outside the scope of this RFC but can be the Level 2 IS-IS sub-domain). The specific trigger itself is
for example a VPN desiring to initiate a BIER sub-domain as MI-PMSI outside the scope of this RFC but can be for example a VPN desiring
[RFC6513] tree or a pre-configured BFER (since BFERs will always to initiate a BIER sub-domain as MI-PMSI [RFC6513] tree or a pre-
advertise the BIER sub-TLV to make sure they can be reached). It is configured BFER (since BFERs will always advertise the BIER sub-TLV
outside the scope of this document to describe what trigger for a to make sure they can be reached). It is outside the scope of this
router capable of participating in <MT,SD> is used to start the document to describe what trigger for a router capable of
origination of the necessary information to join into it. participating in <MT,SD> is used to start the origination of the
necessary information to join into it.
5.2. Multi Topology and Sub-Domain 5.2. Multi Topology and Sub-Domain
A given sub-domain is supported within one and only one topology. A given sub-domain is supported within one and only one topology.
All routers in the flooding scope of the BIER sub-TLVs MUST advertise All routers in the flooding scope of the BIER sub-TLVs MUST advertise
the same sub-domain within the same multi-topology. A router the same sub-domain within the same multi-topology. A router
receiving an <MT,SD> advertisement which does not match the locally receiving an <MT,SD> advertisement which does not match the locally
configured pair MUST report a misconfiguration of the received <MT, configured pair MUST report a misconfiguration of the received <MT,
SD> pair. All received BIER advertisements associated with the SD> pair. All received BIER advertisements associated with the
conflicting <MT, SD> pair MUST be ignored. conflicting <MT, SD> pair MUST be ignored.
skipping to change at page 6, line 30 skipping to change at page 6, line 40
no tree type is advertised tree type 0 is assumed. The supported no tree type is advertised tree type 0 is assumed. The supported
tree type MUST be consistent for all routers supporting a given tree type MUST be consistent for all routers supporting a given
<MT,SD>. <MT,SD>.
5.5. Label advertisements for MPLS Encapsulation 5.5. Label advertisements for MPLS Encapsulation
A router that desires to participate in <MT,SD> MUST advertise for A router that desires to participate in <MT,SD> MUST advertise for
each bitstring length it supports in <MT,SD> a label range size that each bitstring length it supports in <MT,SD> a label range size that
guarantees to cover the maximum BFR-id injected into <MT,SD> (which guarantees to cover the maximum BFR-id injected into <MT,SD> (which
implies a certain maximum set id per bitstring length as described in implies a certain maximum set id per bitstring length as described in
[I-D.draft-ietf-bier-architecture-05]). Any router that violates [I-D.draft-ietf-bier-architecture-07]). Any router that violates
this condition MUST be excluded from BIER BFTs for <MT,SD>. this condition MUST be excluded from BIER BFTs for <MT,SD>.
5.6. BFR-id Advertisements 5.6. BFR-id Advertisements
Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-id that it Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-id that it
has administratively chosen. A valid BFR-id MUST be unique within has administratively chosen. A valid BFR-id MUST be unique within
the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST
detect advertisement of duplicate valid BFR-IDs for a given <MT, SD>. detect advertisement of duplicate valid BFR-IDs for a given <MT, SD>.
When such duplication is detected all of the routers advertising When such duplication is detected all of the routers advertising
duplicates MUST be treated as if they did not advertise a valid BFR- duplicates MUST be treated as if they did not advertise a valid BFR-
skipping to change at page 7, line 42 skipping to change at page 8, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: as indicated in IANA section. Type: as indicated in IANA section.
Length: 1 octet. Length: 1 octet.
Reserved: MUST be 0 on transmission, ignored on reception. May be Reserved: MUST be 0 on transmission, ignored on reception. May be
used in future versions. 8 bits used in future versions. 8 bits
subdomain-id: Unique value identifying the BIER sub-domain. 1 octet subdomain-id: Unique value identifying the BIER sub-domain. 1 octet
BFR-id: A 2 octet field encoding the BFR-id, as documented in BFR-id: A 2 octet field encoding the BFR-id, as documented in
[I-D.draft-ietf-bier-architecture-05]. If no BFR-id has been [I-D.draft-ietf-bier-architecture-07]. If no BFR-id has been
assigned this field is set to the invalid BFR-id. assigned this field is set to the invalid BFR-id.
6.2. BIER MPLS Encapsulation sub-sub-TLV 6.2. BIER MPLS Encapsulation sub-sub-TLV
This sub-sub-TLV carries the information for the BIER MPLS This sub-sub-TLV carries the information for the BIER MPLS
encapsulation including the label range for a specific bitstring encapsulation including the label range for a specific bitstring
length for a certain <MT,SD>. It is advertised within the BIER Info length for a certain <MT,SD>. It is advertised within the BIER Info
sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times
within a single BIER info sub-TLV. within a single BIER info sub-TLV.
On violation of any of the following conditions, the receiving router On violation of any of the following conditions, the receiving router
MUST ignore the encapsulating BIER Info sub-TLV. MUST ignore the encapsulating BIER Info sub-TLV.
o Label ranges in multiple sub-sub-TLV MUST NOT overlap. o Label ranges in multiple sub-sub-TLV MUST NOT overlap.
o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical.
o The sub-sub-TLV MUST include the required bitstring lengths o The sub-sub-TLV MUST include the required bitstring lengths
encoded in precisely the same way as in encoded in precisely the same way as in
[I-D.draft-ietf-bier-mpls-encapsulation-06]. [I-D.draft-ietf-bier-mpls-encapsulation-07].
o The label range size MUST be greater than 0. o The label range size MUST be greater than 0.
o All labels in the range MUST represent valid label values o All labels in the range MUST represent valid label values
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lbl Range Size|BS Len | Label | | Lbl Range Size|BS Len | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: value of 1 indicating MPLS encapsulation. Type: value of 1 indicating MPLS encapsulation.
Length: 1 octet. Length: 1 octet.
Local BitString Length (BS Len): Encoded bitstring length as per [I- Local BitString Length (BS Len): Encoded bitstring length as per [I-
D.draft-ietf-bier-mpls-encapsulation-06]. 4 bits. D.draft-ietf-bier-mpls-encapsulation-07]. 4 bits.
Label Range Size: Number of labels in the range used on Label Range Size: Number of labels in the range used on
encapsulation for this BIER sub-domain for this bitstring length, encapsulation for this BIER sub-domain for this bitstring length,
1 octet. 1 octet.
Label: First label of the range, 20 bits. The labels are as defined Label: First label of the range, 20 bits. The labels are as defined
in [I-D.draft-ietf-bier-mpls-encapsulation-06]. in [I-D.draft-ietf-bier-mpls-encapsulation-07].
6.3. Optional BIER sub-domain Tree Type sub-sub-TLV 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV
This sub-sub-TLV carries the information associated with the This sub-sub-TLV carries the information associated with the
supported BIER tree type for a <MT,SD> combination. It is carried supported BIER tree type for a <MT,SD> combination. It is carried
within the BIER Info sub-TLV (Section 6.1) that the router within the BIER Info sub-TLV (Section 6.1) that the router
participates in as BFR. This sub-sub-TLV is optional and its absence participates in as BFR. This sub-sub-TLV is optional and its absence
has the same semantics as its presence with Tree Type value 0 (SPF). has the same semantics as its presence with Tree Type value 0 (SPF).
When Tree Type 0 is used it is recommended that this sub-sub-TLV be When Tree Type 0 is used it is recommended that this sub-sub-TLV be
omitted in order to reduce the space consumed in the parent TLV. omitted in order to reduce the space consumed in the parent TLV.
skipping to change at page 10, line 22 skipping to change at page 10, line 25
7. Security Considerations 7. Security Considerations
Implementations must assure that malformed TLV and Sub-TLV Implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard protocol permutations do not result in errors which cause hard protocol
failures. failures.
8. Acknowledgements 8. Acknowledgements
The RFC is aligned with the The RFC is aligned with the
[I-D.draft-ietf-bier-ospf-bier-extensions-05] draft as far as the [I-D.draft-ietf-bier-ospf-bier-extensions-07] draft as far as the
protocol mechanisms overlap. protocol mechanisms overlap.
Many thanks for comments from (in no particular order) Hannes Many thanks for comments from (in no particular order) Hannes
Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers.
9. Normative References 9. References
[I-D.draft-ietf-bier-architecture-05] 9.1. Normative References
Wijnands et al., IJ., "Stateless Multicast using Bit Index
Explicit Replication Architecture", internet-draft draft-
ietf-bier-architecture-05.txt, Oct 2016.
[I-D.draft-ietf-bier-mpls-encapsulation-06] [I-D.draft-ietf-bier-mpls-encapsulation-07]
Wijnands et al., IJ., "Bit Index Explicit Replication Wijnands et al., IJ., "Bit Index Explicit Replication
using MPLS encapsulation", internet-draft draft-ietf-bier- using MPLS encapsulation", internet-draft draft-ietf-bier-
mpls-encapsulation-06.txt, Dec 2016. mpls-encapsulation-07.txt, Jun 2017.
[I-D.draft-ietf-bier-ospf-bier-extensions-05] [I-D.draft-ietf-bier-ospf-bier-extensions-07]
Psenak et al., P., "OSPF Extension for Bit Index Explicit Psenak et al., P., "OSPF Extension for Bit Index Explicit
Replication", internet-draft draft-ietf-bier-ospf-bier- Replication", internet-draft draft-ietf-bier-ospf-bier-
extensions-05.txt, Mar 2017. extensions-07.txt, Jul 2017.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>. December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>. <http://www.rfc-editor.org/info/rfc5120>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<http://www.rfc-editor.org/info/rfc5308>. <http://www.rfc-editor.org/info/rfc5308>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <http://www.rfc-editor.org/info/rfc7794>. March 2016, <http://www.rfc-editor.org/info/rfc7794>.
Authors' Addresses [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
9.2. Informative References
[I-D.draft-ietf-bier-architecture-07]
Wijnands et al., IJ., "Stateless Multicast using Bit Index
Explicit Replication Architecture", internet-draft draft-
ietf-bier-architecture-07.txt, Jun 2017.
Authors' Addresses
Les Ginsberg (editor) Les Ginsberg (editor)
Cisco Systems Cisco Systems
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Tony Przygienda Tony Przygienda
Juniper Networks Juniper Networks
 End of changes. 29 change blocks. 
41 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/