The IESG has approved the following document: - 'An Interface ID Hello Option for PIM' (draft-ietf-pim-hello-intid-01.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ Technical Summary This document defines a new PIM Hello option to advertise an interface identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. Working Group Summary There is consensus within the PIM WG to publish the document. The participation has been with individuals from a variety of vendors and providers. The authors made minor changes based upon feedback during the wglc. Document Quality There exists at least one implementation of this protocol for which IANA early allocation was performed. Personnel Mike McBride is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note Section1 New final paragraph NEW All multi-byte integers in this specification are transmitted in network byte order (i.e. most-significant byte first). END Section 2 OLD The Interface Identifier option is used to identify which interface of a neighboring router a PIM Hello [RFC4601] is sent on. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. NEW The Interface Identifier option is used to identify through which interface of a neighboring router a PIM Hello [RFC4601] was sent. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. END Section 2.1 OLD The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. Many systems make use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]. NEW The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. If a node goes down and comes up again. the Identifier for each interface MAY change. Many systems make use of an ifIndex [RFC2863] as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may have messages that optionally reference an Interface Identifier, and they may use the value of 0 to show that no Interface Identifier is being referenced. Note that the value of 0 is not a valid ifIndex as defined in [RFC2863]. END Section 2.2 OLD The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifier, but MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 bit identifiers for routers. One may use the same identifier to construct the Interface Identifier option, provided it meets the stability and uniqueness requirements of protocols making use of this option. NEW The 32 bit Router Identifier may be used to uniquely identify the router. The requirements for the scope in which the Router Identifier needs to be unique depend on the protocols that utilize it. It may need to be unique within some administrative domain, or it may possibly be globally unique. A router implementation selects a Router Identifier according to a configured policy that defines the uniqueness scope. Thus, an implementation MAY be configured to choose an IPv4 unicast address assigned to the router as the Router Identifier, but the implementation MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols that make use of 32 bit identifiers for routers. Provided that the stability and uniqueness requirements of the protocols that make use of the Router Identifier are met, an implementation MAY use the same identifier as is used by other protocols. END Section 3 Definition of Router Identifier ADD The field MUST contain a valid Router Identifier or the value zero. END Section 7.2 OLD [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. NEW [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2863] McCloghrie, K. and Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. END _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
