Protocol Action: 'An Interface ID Hello Option for PIM' to Proposed Standard (draft-ietf-pim-hello-intid-01.txt)

[The IESG <[e-mail]>]

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