draft-ietf-pim-rpf-vector-07.txt   draft-ietf-pim-rpf-vector-08.txt 
PIM WG IJ. Wijnands PIM WG IJ. Wijnands
Internet-Draft A. Boers Internet-Draft A. Boers
Intended status: Standards Track E. Rosen Intended status: Standards Track E. Rosen
Expires: July 9, 2009 Cisco Systems, Inc. Expires: July 19, 2009 Cisco Systems, Inc.
January 5, 2009 January 15, 2009
The RPF Vector TLV The RPF Vector TLV
draft-ietf-pim-rpf-vector-07 draft-ietf-pim-rpf-vector-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2009. This Internet-Draft will expire on July 19, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Abstract Abstract
This document describes a use of the PIM Join Attribute as defined in This document describes a use of the PIM Join Attribute as defined in
draft-ietf-pim-join-attributes [RFC5384] which enables PIM to build draft-ietf-pim-join-attributes [RFC5384] which enables PIM to build
multicast trees through an MPLS-enabled network, even if that multicast trees through an MPLS-enabled network, even if that
network's IGP does not have a route to the source of the tree. network's IGP does not have a route to the source of the tree.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Specification of Requirements . . . . . . . . . . . . . . . . . 3
2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4 3. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . . 4
2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 3.1. Attribute and shared tree joins . . . . . . . . . . . . . . 4
2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 3.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5
2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 3.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5
2.3.2. Processing a Received Vector Attribute . . . . . . . . 5 3.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5
2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5 3.3.2. Processing a Received Vector Attribute . . . . . . . . 5
2.3.4. Vector Attribute and Join suppression . . . . . . . . 6 3.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 6
3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7 3.3.4. Vector Attribute and Join suppression . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Specification of Requirements
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].
2. Introduction
It is sometimes convenient to distinguish the routers of a particular It is sometimes convenient to distinguish the routers of a particular
network into two categories: "edge routers" and "core routers". The network into two categories: "edge routers" and "core routers". The
edge routers attach directly to users or to other networks, but the edge routers attach directly to users or to other networks, but the
core routers attach only to other routers of the same network. If core routers attach only to other routers of the same network. If
the network is MPLS-enabled, then any unicast packet which needs to the network is MPLS-enabled, then any unicast packet which needs to
travel outside the network can be "tunneled" via MPLS from one edge travel outside the network can be "tunneled" via MPLS from one edge
router to another. To handle a unicast packet which must travel router to another. To handle a unicast packet which must travel
outside the network, an edge router needs to know which of the other outside the network, an edge router needs to know which of the other
edge routers is the best exit point from the network for that edge routers is the best exit point from the network for that
packet's destination IP address. The core routers, however, do not packet's destination IP address. The core routers, however, do not
need to have any knowledge of routes which lead outside the network; need to have any knowledge of routes which lead outside the network;
as they handle only tunneled packets, they only need to know how to as they handle only tunneled packets, they only need to know how to
reach the edge routers and the other core routers. reach the edge routers and the other core routers.
Consider, for example, the case where the network is an Autonomous Consider, for example, the case where the network is an Autonomous
System (AS), the edge routers are EBGP speakers, the core routers may System (AS), the edge routers are EBGP speakers, the core routers may
be said to constitute a "BGP-free core". The edge routers must be said to constitute a "BGP-free core". The edge routers distribute
distribute BGP routes to each other, but not to the core routers. BGP routes to each other, but not to the core routers.
However, when multicast packets are considered, the strategy of However, when multicast packets are considered, the strategy of
keeping the core routers free of "external" routes is more keeping the core routers free of "external" routes is more
problematic. When using PIM-SM[RFC4601], PIM-SSM[RFC4607] or PIM- problematic. When using PIM Sparse-Mode (PIM-SM) [RFC4601], PIM
BIDIR[RFC5015] to create a multicast distribution tree for a Source-Specific Mode (PIM-SSM) [RFC4607] or Bidirectional PIM (BIDIR-
PIM) [RFC5015] to create a multicast distribution tree for a
particular multicast group, one wants the core routers to be full particular multicast group, one wants the core routers to be full
participants in the PIM protocol, so that multicasting can be done participants in the PIM protocol, so that multicasting can be done
efficiently in the core. This means that the core routers must be efficiently in the core. This means that the core routers must be
able to correctly process PIM Join messages for the group, which in able to correctly process PIM Join messages for the group, which in
turn means that the core routes must be able to send the Join turn means that the core routers must be able to send the Join
messages towards the root of the distribution tree. If the root of messages towards the root of the distribution tree. If the root of
the tree lies outside the network's borders (e.g., is in a different the tree lies outside the network's borders (e.g., is in a different
AS), and the core routers do not maintain routes to external AS), and the core routers do not maintain routes to external
destinations, then the PIM Join messages cannot be processed, and the destinations, then the PIM Join messages cannot be processed, and the
multicast distribution tree cannot be created. multicast distribution tree cannot be created.
In order to allow PIM to work properly in an environment where the In order to allow PIM to work properly in an environment where the
core routers do not maintain external routes, a PIM extension is core routers do not maintain external routes, a PIM extension is
needed. When an edge router sends a PIM Join message into the core, needed. When an edge router sends a PIM Join message into the core,
it must include in that message a "Vector" which specifies the IP it MUST include in that message a "Vector" which specifies the IP
address of the next edge router along the path to the root of the address of the next edge router along the path to the root of the
multicast distribution tree. The core routers can then process the multicast distribution tree. The core routers can then process the
Join message by sending it towards the specified edge router (i.e., Join message by sending it towards the specified edge router (i.e.,
toward the Vector). In effect, the Vector serves as an attribute, toward the Vector). In effect, the Vector serves as an attribute,
within a particular network, for the root of the tree. within a particular network, for the root of the tree.
This document defines a new TLV in the PIM Join Attribute message This document defines a new TLV in the PIM Join Attribute message
[RFC5384]. It consists of a single Vector which identifies the exit [RFC5384]. It consists of a single Vector which identifies the exit
point of the network. point of the network.
2. Use of the RPF Vector TLV 3. Use of the RPF Vector TLV
Before we can start forwarding multicast packets we need to build a Before a router can start forwarding multicast packets, it is
forwarding tree by sending PIM Joins hop by hop. Each router in the necessary to build a forwarding tree by sending PIM Joins hop by hop.
path creates a forwarding state and propagates the Join towards the Each router in the path creates a forwarding state and propagates the
root of the forwarding tree. The building of this tree is receiver Join towards the root of the forwarding tree. The building of this
driven. See Figure 1. tree is receiver driven. See Figure 1.
------------------ BGP ----------------- ------------------ BGP -----------------
| | | |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
<--- (S,G) Join <--- (S,G) Join
Figure 1 Figure 1
In this example, the 2 edge routers are BGP speakers. The core In this example, the 2 edge routers are BGP speakers. The core
routers are not BGP speakers and do not have any BGP distributed routers are not BGP speakers and do not have any BGP distributed
skipping to change at page 4, line 35 skipping to change at page 4, line 43
interface leading to S, and sends a PIM Join to the upstream router. interface leading to S, and sends a PIM Join to the upstream router.
In this example, though, the upstream router is a core router, with In this example, though, the upstream router is a core router, with
no route to S. Without the PIM extensions specified in this document, no route to S. Without the PIM extensions specified in this document,
the core router cannot determine where the send the Join, so the tree the core router cannot determine where the send the Join, so the tree
cannot be constructed. cannot be constructed.
To allow the core router to participate in the construction of the To allow the core router to participate in the construction of the
tree, the Edge 2 router will include an attribute field in the PIM tree, the Edge 2 router will include an attribute field in the PIM
Join. In this example, the Attribute field will contain the IP Join. In this example, the Attribute field will contain the IP
address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1.
The intermediate core routers do their RPF check on the Attribute (IP The intermediate core routers do their RPF (Reverse Path Forwarding)
address of Edge 1) rather than the Source, this allows the tree to be check [RFC4601] on the Attribute (IP address of Edge 1) rather than
constructed. the Source, this allows the tree to be constructed.
2.1. Attribute and shared tree joins 3.1. Attribute and shared tree joins
In the example above we build a source tree to illustrate the In the example above we build a source tree to illustrate the
attribute behavior. The attribute is however not restricted to attribute behavior. The attribute is however not restricted to
source tree only. The tree may also be constructed towards a source tree only. The tree may also be constructed towards a
Rendezvous Point (RP) IP address. The RP IP address is used in a Rendezvous Point (RP) IP address. The RP IP address is used in a
similar way as the Source in the example above. PIM Attribute similar way as the Source in the example above. PIM Attribute
procedures defined for sources are equally applicable to (*,G) and procedures defined for sources are equally applicable to (*,G) and
(*,*,RP) joins unless otherwise noted. (*,*,RP) joins unless otherwise noted.
2.2. Attribute and Bootstrap messages 3.2. Attribute and Bootstrap messages
The RPF vector does not apply to BSR bootstrap messages. To allow The RPF vector does not apply to BSR bootstrap messages. To allow
BSR messages to be forwarded across a core where the BSR IP address BSR messages to be forwarded across a core where the BSR IP address
is not routable in the core a solution needs to be developed for BSR. is not routable in the core a solution needs to be developed for BSR.
2.3. The Vector Attribute 3.3. The Vector Attribute
2.3.1. Inserting a Vector Attribute in a Join 3.3.1. Inserting a Vector Attribute in a Join
In the example of Figure 1, when the Edge 2 router looks up the route In the example of Figure 1, when the Edge 2 router looks up the route
to the source of the multicast distribution tree, it will find a BGP- to the source of the multicast distribution tree, it will find a BGP-
distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks
up the route to Edge 1 to find interface and PIM adjacency which is up the route to Edge 1 to find interface and PIM adjacency which is
the next hop to the source, namely Core 2. the next hop to the source, namely Core 2.
When Edge 2 sends a PIM Join to Core 2, it includes a Vector When Edge 2 sends a PIM Join to Core 2, it includes a Vector
Attribute specifying the address of Edge 1. Core 2, and subsequent Attribute specifying the address of Edge 1. Core 2, and subsequent
core routers, will forwarding the Join along the Vector (i.e, towards core routers, will forwarding the Join along the Vector (i.e, towards
Edge 1) instead of trying to forward it towards S. Edge 1) instead of trying to forward it towards S.
Whether an attribute is actually needed depends on whether the Core Whether an attribute is actually needed depends on whether the Core
routers have a route to the source of the multicast tree. How the routers have a route to the source of the multicast tree. How the
Edge router knows whether or not this is the case (and thus how the Edge router knows whether or not this is the case (and thus how the
Edge router determines whether or not to insert an attribute field) Edge router determines whether or not to insert an attribute field)
is outside the scope of this document. is outside the scope of this document.
2.3.2. Processing a Received Vector Attribute 3.3.2. Processing a Received Vector Attribute
When processing a received PIM Join which contains a Vector When processing a received PIM Join which contains a Vector
Attribute, a router must first check to see if the Vector IP address Attribute, a router MUST first check to see if the Vector IP address
is one of its own IP addresses. If so, the Vector Attribute is is one of its own IP addresses. If so, the Vector Attribute is
discarded, and not passed further upstream. Otherwise, the Vector discarded, and not passed further upstream. Otherwise, the Vector
Attribute is used to find the route to the source, and is passed Attribute is used to find the route to the source, and is passed
along when a PIM Join is sent upstream. Note that a router which along when a PIM Join is sent upstream. Note that a router which
receives a Vector Attribute must use it, even if that router happens receives a Vector Attribute MUST use it, even if that router happens
to have a route to the source. A router which discards a Vector to have a route to the source. A router which discards a Vector
Attribute may of course insert a new Vector Attribute. This would Attribute MAY of course insert a new Vector Attribute. This would
typically happen if a PIM Join needed to pass through a sequence of typically happen if a PIM Join needed to pass through a sequence of
Edge routers, each pair of which is separated by a core which does Edge routers, each pair of which is separated by a core which does
not have external routes. In the absence of periodic refreshment, not have external routes. In the absence of periodic refreshment,
Vectors expire along with the corresponding (S,G) state. Vectors expire along with the corresponding (S,G) state.
2.3.3. Vector Attribute and Asserts 3.3.3. Vector Attribute and Asserts
In a PIM Assert message we include the routing protocol's "metric" to A PIM Assert message includes the routing protocol's "metric" to the
the source of the tree. This information is used in the selection of source of the tree. This information is used in the selection of the
the assert winner. If a PIM Join is being sent towards a Vector, assert winner. If a PIM Join is being sent towards a Vector, rather
rather than towards the source, the Assert message must have the than towards the source, the Assert message MUST have the metric to
metric to the Vector instead of the metric to the source. The Assert the Vector instead of the metric to the source. The Assert message
message however does not have an attribute field and does not mention however does not have an attribute field and does not mention the
the Vector. Vector.
A router may change its upstream neighbor on a particular multicast A router may change its upstream neighbor on a particular multicast
tree as the result of receiving Assert messages. However a Vector tree as the result of receiving Assert messages. However a Vector
Attribute should not be sent in a PIM Join to an upstream neighbor Attribute MUST NOT be sent in a PIM Join to an upstream neighbor
which is chosen as the result of an assert winner and different from which is chosen as the result of an Assert processing, if that
the original upstream neighbor (the upstream neighbor for the neighbor is different than the original upstream neighbor.
multicast route not influenced by the assert). Reachability of the Reachability of the Vector is only guaranteed by the router that
Vector is only guaranteed by the router that advertises reachability advertises reachability to the Vector in its IGP. If the assert
to the Vector in its IGP. If the assert winner upstream is not our winner upstream is not the real preferred next-hop, it is possible
real preferred next-hop, we can't be sure this router knows the path that the assert winner does not know the path to the Vector. In the
to the Vector. In the worst case the assert winner has a route to worst case the assert winner has a route to the Vector that is on the
the Vector that is on the same interface where the assert was won. same interface where the assert was won. That will point the RPF
That will point the RPF interface to that interface and will result interface to that interface and will result in the O-list being NULL.
in the O-list being NULL. The Vector attribute is not inserted if The Vector attribute therefore MUST NOT be inserted if the RPF
the RPF neighbor was chosen via an assert process and the RPF neighbor was chosen via an assert process and the RPF neighbor is
neighbor is different from the RPF neighbor that would have been different from the RPF neighbor that would have been selected via the
selected via the local routing table. In all other cases the Vector local routing table. In all other cases the Vector MUST be included
has to be included in the Join message. in the Join message.
2.3.4. Vector Attribute and Join suppression 3.3.4. Vector Attribute and Join suppression
If a router receives a PIM join on the upstream LAN interface for a If a router receives a PIM join on the upstream LAN interface for a
particular multicast state, join suppression may be applied if that particular multicast state, join suppression may be applied if that
PIM join is targeted to the same upstream neighbor. Which router(s) PIM join is targeted to the same upstream neighbor. Which router(s)
will suppress their PIM join is depending on timing and is will suppress their PIM join is dependant on timing and is
unpredictable. Downstream routers on a LAN may include different RPF unpredictable. Downstream routers on a LAN MAY include different RPF
vectors in the PIM joins. Therefore an upstream router on that LAN vectors in the PIM joins. Therefore an upstream router on that LAN
may receive and use different RPF vectors over time to reach the may receive and use different RPF vectors over time to reach the
destination (depending on which downstream router(s) suppressed their destination (depending on which downstream router(s) suppressed their
Join). To make the upstream router behavior more predictable the RPF Join). To make the upstream router behavior more predictable the RPF
vector address MUST be used as additional condition to the join vector address MUST be used as additional condition to the join
suppression logic. Only if the RPF vector in the PIM join matches suppression logic. Only if the RPF vector in the PIM join matches
the RPF vector in the multicast state, the suppression logic is the RPF vector in the multicast state, the suppression logic is
applied. It is also possible to disable join suppression on that applied. It is also possible to disable join suppression on that
LAN. LAN.
3. Vector Attribute TLV Format 4. Vector Attribute TLV Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|S| Type | Length | Value |F|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit F bit
----- -----
Forward Unknown TLV. If this bit is set the TLV is forwarded Forward Unknown TLV. If this bit is set the TLV is forwarded
skipping to change at page 7, line 36 skipping to change at page 7, line 36
The Vector Attribute type is 0. The Vector Attribute type is 0.
Length Length
------ ------
Length depending on Address Family of Encoded-Unicast address. Length depending on Address Family of Encoded-Unicast address.
Value Value
----- -----
Encoded-Unicast address. Encoded-Unicast address.
4. IANA Considerations 5. IANA Considerations
An new attribute type from the "PIM Join Attribute Types" registry An new attribute type from the "PIM Join Attribute Types" registry
needs to be assigned by IANA for the RPF Vector. The propose value needs to be assigned by IANA for the RPF Vector. The proposed value
is 0. is 0.
5. Security Considerations 6. Security Considerations
Security of the RPF Vector Attribute is only guaranteed by the Security of the RPF Vector Attribute is only guaranteed by the
security of the PIM packet, so the security considerations for PIM security of the PIM packet, so the security considerations for PIM
join packets as described in PIM-SM [RFC4601] apply here. join packets as described in PIM-SM [RFC4601] apply here.
6. Acknowledgments 7. Acknowledgments
The authors would like to thank Yakov Rekhter and Dino Farinacci for The authors would like to thank Yakov Rekhter and Dino Farinacci for
their initial ideas on this topic and Su Haiyang for the comments on their initial ideas on this topic and Su Haiyang for the comments on
the draft. the draft.
7. References 8. Normative References
7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008. RFC 5384, November 2008.
7.2. Informative References
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
skipping to change at page 10, line 4 skipping to change at line 352
Barcelona 08034 Barcelona 08034
Spain Spain
Email: aboers@cisco.com Email: aboers@cisco.com
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, Ma 01719 Boxborough, Ma 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
 End of changes. 35 change blocks. 
80 lines changed or deleted 96 lines changed or added

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