wdiff rfc7887.original rfc7887.txt

Network Working Group
Internet Engineering Task Force (IETF) S. Venaas
Internet-Draft
Request for Comments: 7887 J. Arango
Updates: 5384 (if approved) Cisco Systems
Intended status:
Category: Standards Track I. Kouvelas
Expires: October 27, 2016
ISSN: 2070-1721 Arista Networks
April 25,
May 2016

Hierarchical Join/Prune Attributes
draft-ietf-pim-hierarchicaljoinattr-08.txt

Abstract

This document defines a hierachical hierarchical method of encoding Join
attributes, providing Join/Prune
attributes that provides a more efficient encoding when the same
attribute values need to be specified for multiple sources in a PIM
Join/Prune message. This document updates RFC 5384 by renaming the
Encoding Type
encoding type registry specified there.

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 an Internet Standards Track document.

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

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 27, 2016.
http://www.rfc-editor.org/info/rfc7887.

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
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Hierarchical Join/Prune Attribute Definition . . . . . . . . 3
4. PIM Address Encoding Types . . . . . . . . . . . . . . . . . 6
5. Hierarchical Join/Prune Attribute Hello Option . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

PIM Join attributes as defined in [RFC5384] allow for specifying a
set of attributes for each of the joined or pruned sources in a PIM
Join/Prune message. Attributes must be separately specified for each
individual source in the message. However, in some cases cases, the same
attributes and values need to be specified for some, or even all, the
sources in the message. The attributes and their values then need to
be repeated for each of the sources where they apply.

This document provides a hierarchical way of encoding attributes and
their values in a Join/Prune message, message so that if the same attribute
and value is to apply for all the sources, it needs only needs to be
specified once in the message. Similarly, if all the sources in a
specific group set share a specific attribute and value, it needs only
needs to be specified once for the entire group set.

This document extends [RFC5384] by specifying that the encoding type
defined there also applies to Encoded-Unicast and Encoded-Group
formats. This document also updates RFC 5384 [RFC5384] by renaming the PIM "PIM
Encoded-Source Address Encoding Type Field Field" registry to be a PIM "PIM Address
Encoding Type registry. Types". The content of the registry remains the same. The
encoding type used for Join attributes is however is, however, still limited to be used
use in Join/Prune messages. Note that Join attributes, as they are
referred to in [RFC5384], also apply to pruned sources in a Join/Prune Join/
Prune message. Thus Thus, the more correct name
Join/Prune attributes "Join/Prune attributes"
will be used throughout the rest of this document.

This document allows Join/Prune attributes to be specified in the
Upstream Neighbor Address field, and also in the Multicast Group
Address field, of a Join/Prune message. It defines how this is used
to specify the same Join/Prune attribute and value for multiple
sources. This document also defines a new Hello Option to indicate
support for the hierarchical encoding specified.

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

3. Hierarchical Join/Prune Attribute Definition

The format of a PIM Join/Prune message is defined in [RFC7761] as
follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Neighbor Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message contains a single Upstream Neighbor Address, Address and one or
more group sets. Each group set contains a Group Address and two
source lists, lists: the Joined Sources and the Pruned Sources. The
Upstream Neighbor Address, the group addresses addresses, and the source
addresses are encoded in Encoded-Unicast format, Encoded-Group format
format, and Encoded-Source format, respectively. This document
extends the use of the source address encoding defined in [RFC5384]
to also apply to the Upstream Neighbor Address and the Group Address fields, see
fields (see Section 4. 4).

For a Join/Prune message message, a hierarchy of Join/Prune attributes is
defined. Attributes at the highest level, that which is the least
specific, apply to every source in the message. These are encoded in
the Upstream Neighbor Address. Attributes at the next more specific next, more-specific
level apply to every source in a group set. They are encoded in a
Group Address. And finally finally, there are attributes that apply to a
single source, source and are encoded in the source address as defined in
[RFC5384].

The complete set of attributes that apply to a given source is
obtained by combining the message wide message-wide attributes, the attributes of
the group set that the source belongs to, and the source specific source-specific
attributes. However, if the same attribute is specified at multiple
levels, then the one at the most specific level overrides the other
instances of the attribute. Note that the set of attributes and
their values is formed before processing the attributes. Hence Hence, a
value that is invalid for a given type might override a valid value
at a higher level.

As an example, say that for a given source source, we have attributes T_1
with value V_1, T_2 with value V_2, and T_3 with value V_3. Also
assume that in the Group Address of the source's group set set, we have
attributes T_1 with value V_6, V_6 and T_4 with value V_4. And assume
that we in the Upstream Neighbor Address have encoded the attributes
T_1 with value V_7, T_4 with value V_8, and T_5 with value V_5. The
attributes applied to the given source will be T_1 with value V_1,
T_2 with value V_2, T_3 with value V_3, T_4 with value V_4 V_4, and T_5
with value V_5. Here we have T_1 with different values at each
level, so we use the value specified at the source level. Also Also, we
have T_4 with different values at the group and message levels, so we
use the value at the group level. Here it could be that V_1 is not a
valid value for T_1, but it still overrides the values at the higher
levels as we do not process the attributes until after forming the
set.

Note that Join/Prune attributes are still applied to sources as
specified in [RFC5384]. This document does not change the meaning of
any attributes, attributes; it is simply a more compact way of encoding an
attribute when the same attribute and value applies to multiple
sources. E.g.,
sources, e.g., with the example above, we would have the exact same
meaning if we instead had encoded all the attributes T1, ..., T5 with
the respective values V1, ..., V5 in the source address.

4. PIM Address Encoding Types

Addresses in PIM messages are specified together with an address
family and an encoding type. This applies to Encoded-Unicast,
Encoded-Group
Encoded-Group, and Encoded-Source addresses. The encoding types
allow the address to be encoded according to different schemes. An
encoding type indicates how an address is encoded irrespective of
address type, Encoded-Unicast, Encoded-Group Encoded-Group, or Encoded-Source. It
is possible that there will be future encoding types that do not
apply to all address types though. This means that as currently
defined, 0 is native encoding, encoding [RFC7761], and 1 is Join/Prune
attributes
encoding, encoded according to encoding [RFC5384]. Note that as specified in [RFC5384],
a type 1 Encoded Address MUST contain at least one Join/
Prune Join/Prune
attribute.

5. Hierarchical Join/Prune Attribute Hello Option

A PIM router indicates that it supports the mechanism specified in
this document by including the Hierarchical Join/Prune Attribute
Hello Option in its PIM Hello message. When this new Hello Option is
included, it MUST also include the Join-Attribute Join Attribute Hello option Option as
specified in [RFC5384]. The format of the Hierarchical Join/Prune
Attribute Hello Option is defined to be:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = TBD 36 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OptionType = TBD, 36, OptionLength = 0. Note that there is no option
value included.

A PIM router MUST NOT send a Join/Prune message with Join/Prune
attributes encoded in the Upstream Neighbor Address or any of the
group addresses out of any interface on which there is a PIM neighbor
that has not included this option in its Hellos. Even a router that
is not the upstream neighbor must be able to parse the message in
order to perform Join suppression and Prune override.

6. Security Considerations

This document specifies a more compact encoding of Join/Prune
attributes. Use of the encoding has no impact on security aside from
using the encoding in [RFC5384]. For instance instance, an attack with a
forged message with certain attribute values is equally difficult
independent of which encoding is used. If an attribute that applies
to the entire message is wrong, then that may cause an issue for all
the sources in the message. But without this encoding, one would
instead include that attribute for every single source, and that
would also cause an issue for all the sources in the message.

7. IANA Considerations

The current PIM

IANA has renamed the "PIM Encoded-Source Address Encoding Type Field Field"
registry
needs to be renamed to a PIM "PIM Address Encoding Type registry. The
content of the registry remains the same. Types".

The Hierarchical Join/
Prune Join/Prune Attribute Hello Option needs to be (36) has been added to the PIM-Hello
Options registry, and TBD above must be replaced by the assigned
value.
"PIM-Hello Options" registry.

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<http://www.rfc-editor.org/info/rfc5384>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.

Authors' Addresses

Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
United States

Email: stig@cisco.com
Jesus Arango
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
United States

Email: jearango@cisco.com

Isidor Kouvelas
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
USA
United States

Email: kouvelas@arista.com