< draft-ietf-msdp-spec-05.txt   draft-ietf-msdp-spec-06.txt >
Network Working Group Dino Farinacci Network Working Group Dino Farinacci
INTERNET DRAFT Procket Networks INTERNET DRAFT Procket Networks
Yakov Rekhter Yakov Rekhter
David Meyer David Meyer
Cisco Systems Cisco Systems
Peter Lothberg Peter Lothberg
Sprint Sprint
Hank Kilmer Hank Kilmer
Jeremy Hall Jeremy Hall
UUnet UUnet
Category Standards Track Category Standards Track
February, 2000 July, 2000
Multicast Source Discovery Protocol (MSDP) Multicast Source Discovery Protocol (MSDP)
<draft-ietf-msdp-spec-05.txt> <draft-ietf-msdp-spec-06.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
Each entry in an SA Cache has an associated SA-State-Timer. A Each entry in an SA Cache has an associated SA-State-Timer. A
(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
received by a caching MSDP peer. The timer is reset to [SA-State- received by a caching MSDP peer. The timer is reset to [SA-State-
Period] if another (S,G)-SA message is received before the (S,G)-SA- Period] if another (S,G)-SA message is received before the (S,G)-SA-
State-Timer expires. [SA-State-Period] MUST NOT be less than 90 State-Timer expires. [SA-State-Period] MUST NOT be less than 90
seconds. seconds.
8.4. SA-Hold-Down-Timer 8.4. SA-Hold-Down-Timer
A caching MSDP peer SHOULD NOT forward an SA message it has received The per-(S,G) timer is set to [SA-Hold-Down-Period] when forwarding
in during the previous [SA-Hold-Down-Period] seconds. [SA-Hold-Down- an SA message, and a SA message MUST only be forwarded when it's
Period] SHOULD be set to 30 seconds. The per-SA message timer is set associated timer is not running. [SA-Hold-Down-Period] SHOULD be set
to [SA-Hold-Down-Period] when forwarding an (S,G)-SA message, and a to 30 seconds. A caching MSDP peer MUST NOT forward a (S,G)-SA
(S,G)-SA message MUST only be forwarded when it's associated timer is message it has received in during the previous [SA-Hold-Down-Period]
not running. Finally, the timer is deleted when the (S,G)-SA cache seconds. Finally, the timer is deleted when the SA cache entry is
entry is deleted. deleted.
8.5. KeepAlive Timer 8.5. KeepAlive Timer
The KeepAlive timer is used by the active connect side of the MSDP The KeepAlive timer contols when to send MSDP KeepAlive messages. In
connection to track the state of the passive-connect side of the particular, the KeepAlive timer is used to reset the TCP connection
connection. In particular, the KeepAlive timer is used to reset the when the passive-connect side of the connection goes down. The
TCP connection when the passive-connect side of the connection goes KeepAlive timer is set to [KeepAlive-Period] when the passive-connect
down. The KeepAlive timer is set to [KeepAlive-Period] when the peer comes up. [KeepAlive-Period] SHOULD NOT be less that 75 seconds.
passive-connect peer comes up. [KeepAlive-Period] SHOULD NOT be less The timer is reset to [KeepAlive-Period] upon receipt of an MSDP
that 75 seconds. The timer is reset to [KeepAlive-Period] upon message from peer, and deleted when the timer expires or the
receipt of an MSDP message from peer, and deleted when the timer passive-connect peer closes the connection.
expires or the passive-connect peer closes the connection.
8.6. ConnectRetry Timer 8.6. ConnectRetry Timer
The ConnectRetry timer is used by an MSDP peer to transition from The ConnectRetry timer is used by an MSDP peer to transition from
INACTIVE to CONNECTING states. There is one timer per peer, and the INACTIVE to CONNECTING states. There is one timer per peer, and the
[ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is [ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is
initialized to [ConnectRetry-Period] when an MSDP peer's active initialized to [ConnectRetry-Period] when an MSDP peer's active
connect attempt fails. When the timer expires, the peer retries the connect attempt fails. When the timer expires, the peer retries the
connection and the timer is reset to [ConnectRetry-Period]. It is connection and the timer is reset to [ConnectRetry-Period]. It is
deleted if either the connection transitions into ESTABLISHED state deleted if either the connection transitions into ESTABLISHED state
skipping to change at page 7, line 23 skipping to change at page 7, line 22
As the number of (S,G) pairs increases in the Internet, an RP may As the number of (S,G) pairs increases in the Internet, an RP may
want to filter which sources it describes in SA messages. Also, want to filter which sources it describes in SA messages. Also,
filtering may be used as a matter of policy which at the same time filtering may be used as a matter of policy which at the same time
can reduce state. Only the RP co-located in the same domain as the can reduce state. Only the RP co-located in the same domain as the
source can restrict SA messages. Note, however, that MSDP peers in source can restrict SA messages. Note, however, that MSDP peers in
transit domains should not filter SA messages or the flood-and-join transit domains should not filter SA messages or the flood-and-join
model can not guarantee that sources will be known throughout the model can not guarantee that sources will be known throughout the
Internet (i.e., SA filtering by transit domains can cause undesired Internet (i.e., SA filtering by transit domains can cause undesired
lack of connectivity). In general, policy should be expressed using lack of connectivity). In general, policy should be expressed using
MBGP [RFC2283]. This will cause MSDP messages will flow in the MBGP [RFC2283]. This will cause MSDP messages to flow in the desired
desired direction and peer-RPF fail otherwise. An exception occurs at direction and peer-RPF fail otherwise. An exception occurs at an
an administrative scope [RFC2365] boundary. In particular, a SA administrative scope [RFC2365] boundary. In particular, a SA message
message for a (S,G) MUST NOT be sent to peers which are on the other for a (S,G) MUST NOT be sent to peers which are on the other side of
side of an administrative scope boundary for G. an administrative scope boundary for G.
11. SA Requests 11. SA Requests
If an MSDP peer decides to cache SA state, it MAY accept SA-Requests If an MSDP peer decides to cache SA state, it MAY accept SA-Requests
from other MSDP peers. When an MSDP peer receives an SA-Request for a from other MSDP peers. When an MSDP peer receives an SA-Request for a
group range, it will respond to the peer with a set of SA entries, in group range, it will respond to the peer with a set of SA entries, in
an SA-Response message, for all active sources sending to the group an SA-Response message, for all active sources sending to the group
range requested in the SA-Request message. The peer that sends the range requested in the SA-Request message. The peer that sends the
request will not flood the responding SA-Response message to other request will not flood the responding SA-Response message to other
peers. See section 17 for discussion of error handling relating to SA peers. See section 17 for discussion of error handling relating to SA
skipping to change at page 8, line 46 skipping to change at page 8, line 46
14.1. Peer-RPF Forwarding Rules 14.1. Peer-RPF Forwarding Rules
An SA message originated by an MSDP originator R and received by a An SA message originated by an MSDP originator R and received by a
MSDP router from MSDP peer N is accepted if N is the appropriate RPF MSDP router from MSDP peer N is accepted if N is the appropriate RPF
neighbor for originator R (the RP in the SA message), and discarded neighbor for originator R (the RP in the SA message), and discarded
otherwise. otherwise.
The RPF neighbor is chosen using the first of the following rules The RPF neighbor is chosen using the first of the following rules
that matches: that matches:
(i). R is the RPF neighbor if we have an MSDP peering with R. (i). R is the RPF neighbor if we have an MSDP peering with R,
and R is the next hop towards the prefix covering the RP
in the SA message.
(ii). The external MBGP neighbor towards which we are (ii). The external MBGP neighbor towards which we are
poison-reversing the MBGP route towards R is the RPF neighbor poison-reversing the MBGP route towards R is the RPF neighbor
if we have an MSDP peering with it. if we have an MSDP peering with it.
(iii). If we have any MSDP peerings with neighbors in the first (iii). If we have any MSDP peerings with neighbors in the first
AS along the AS_PATH (the AS from which we learned this AS along the AS_PATH (the AS from which we learned this
route), but no external MBGP peerings with them, route), but no external MBGP peerings with them,
the neighbor with the highest IP address is the RPF neighbor. the neighbor with the highest IP address is the RPF neighbor.
(vi). The internal MBGP advertiser of the router towards R is (iv). The internal MBGP advertiser of the router towards R is
the RPF neighbor if we have an MSDP peering with it. the RPF neighbor if we have an MSDP peering with it.
(v). If none of the above match, and we have an MSDP (v). If none of the above match, and we have an MSDP
default-peer configured, the MSDP default-peer is default-peer configured, the MSDP default-peer is
the RPF neighbor. the RPF neighbor.
14.2. MSDP default-peer semantics 14.2. MSDP default-peer semantics
An MSDP default-peer is much like a default route. It is intended to An MSDP default-peer is much like a default route. It is intended to
be used in those cases where a stub network isn't running BGP or be used in those cases where a stub network isn't running BGP. An
MBGP. An MSDP peer configured with a default-peer accepts all SA MSDP peer configured with a default-peer accepts all SA messages from
messages from the default-peer. Note that a router running BGP or the default-peer. Note that a router running BGP SHOULD NOT allow
MBGP SHOULD NOT allow configuration of default peers, since this configuration of default peers, since this allows the possibility for
allows the possibility for SA looping or black-holes to occur. SA looping or black-holes to occur.
14.3. MSDP mesh-group semantics
A MSDP mesh-group is a operational mechanism for reducing SA
flooding, typically in an intra-domain setting. In particular, when
some subset of a domain's MSDP speakers are fully meshed, then can be
configured into a mesh-group. The semantics of the mesh-group are as
follows:
(i). If a member R of a mesh-group M receives a SA message from an
MSDP peer that is also a member of mesh-group M, R accepts the
SA message and forwards it to all of it's peers that are not
part of any mesh-group. R MUST NOT forward the SA message to
other members of mesh-group M.
(ii). If a member R of a mesh-group M receives a SA message from an
MSDP peer that is not a member of mesh-group M, and the SA
message passes the peer-RPF check, then R forwards the SA
message to all members of mesh-group M.
Note that since mesh-groups suspend peer-RPF checking of SAs received
from a mesh-group member ((i). above), they allow for mis-
configuration to cause SA looping.
15. MSDP Connection Establishment 15. MSDP Connection Establishment
MSDP messages will be encapsulated in a TCP connection. An MSDP peer MSDP messages will be encapsulated in a TCP connection. An MSDP peer
listens for new TCP connections on port 639. One side of the MSDP listens for new TCP connections on port 639. One side of the MSDP
peering relationship will listen on the well-known port and the other peering relationship will listen on the well-known port and the other
side will do an active connect to the well-known port. The side with side will do an active connect to the well-known port. The side with
the higher peer IP address will do the listen. This connection the higher peer IP address will do the listen. This connection
establishment algorithm avoids call collision. Therefore, there is no establishment algorithm avoids call collision. Therefore, there is no
need for a call collision procedure. It should be noted, however, need for a call collision procedure. It should be noted, however,
skipping to change at page 13, line 32 skipping to change at page 14, line 32
16.2.2. IPv4 Source-Active Request TLV 16.2.2. IPv4 Source-Active Request TLV
The Source-Active Request is used to request SA-state from a caching The Source-Active Request is used to request SA-state from a caching
MSDP peer. If an RP in a domain receives a PIM Join message for a MSDP peer. If an RP in a domain receives a PIM Join message for a
group, creates (*,G) state and wants to know all active sources for group, creates (*,G) state and wants to know all active sources for
group G, and it has been configured to peer with an SA-state caching group G, and it has been configured to peer with an SA-state caching
peer, it may send an SA-Request message for the group. peer, it may send an SA-Request message for the group.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 8 | Gprefix Len | | 2 | 8 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address Prefix | | Group Address Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
IPv4 Source-Active Request TLV is type 2. IPv4 Source-Active Request TLV is type 2.
Gprefix Len Reserved
The route prefix length associated with the group address prefix. Must be transmitted as zero and ignored on receipt.
Group Address Group Address
The group address the MSDP peer is requesting. The group address the MSDP peer is requesting.
16.2.3. IPv4 Source-Active Response TLV 16.2.3. IPv4 Source-Active Response TLV
The Source-Active Response is sent in response to a Source-Active The Source-Active Response is sent in response to a Source-Active
Request message. The Source-Active Response message has the same Request message. The Source-Active Response message has the same
format as a Source-Active message but does not allow encapsulation of format as a Source-Active message but does not allow encapsulation of
multicast data. multicast data.
skipping to change at page 18, line 8 skipping to change at page 19, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 16 |O| 2 | | 5 | 16 |O| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Reserved | Gprefix Len | | 1 | Reserved | Gprefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gprefix | | Gprefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address | | Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
y.fi
If a caching MSDP peer receives a request for an invalid If a caching MSDP peer receives a request for an invalid group, it
group, it returns the following notification: returns the following notification:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 16 |O| 2 | | 5 | 16 |O| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Reserved | Gprefix Len | | 2 | Reserved | Gprefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gprefix | | Gprefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalid Group Address | | Invalid Group Address |
skipping to change at page 22, line 42 skipping to change at page 24, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\ |C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header
| Checksum (optional) | Reserved1 |/ | Checksum (optional) | Reserved1 |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating RP IPv4 Address |\ | Originating RP IPv4 Address |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| (S,G) Data Packet .... / | (S,G) Data Packet .... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSDP-GRE-ProtocolType is set to 0x876C, pending IANA approval
[ETYPES,RFC1700].
18.2.1. Encapsulation and Path MTU Discovery [RFC1191] 18.2.1. Encapsulation and Path MTU Discovery [RFC1191]
Existing implementations of GRE, when using IPv4 as the Delivery Existing implementations of GRE, when using IPv4 as the Delivery
Header, do not implement Path MTU discovery and do not set the Don't Header, do not implement Path MTU discovery and do not set the Don't
Fragment bit in the Delivery Header. This can cause large packets to Fragment bit in the Delivery Header. This can cause large packets to
become fragmented within the tunnel and reassembled at the tunnel become fragmented within the tunnel and reassembled at the tunnel
exit (independent of whether the payload packet is using PMTU). If a exit (independent of whether the payload packet is using PMTU). If a
tunnel entry point were to use Path MTU discovery, however, that tunnel entry point were to use Path MTU discovery, however, that
tunnel entry point would also need to relay ICMP unreachable error tunnel entry point would also need to relay ICMP unreachable error
messages (in particular the "fragmentation needed and DF set" code) messages (in particular the "fragmentation needed and DF set" code)
back to the originator of the packet, which is not required by the back to the originator of the packet, which is not required by the
GRE specification [GRE]. Failure to properly relay Path MTU GRE specification [RFC2784]. Failure to properly relay Path MTU
information to an originator can result in the following behavior: information to an originator can result in the following behavior:
the originator sets the don't fragment bit, the packet gets dropped the originator sets the don't fragment bit, the packet gets dropped
within the tunnel, but since the originator doesn't receive proper within the tunnel, but since the originator doesn't receive proper
feedback, it retransmits with the same PMTU, causing subsequently feedback, it retransmits with the same PMTU, causing subsequently
transmitted packets to be dropped. transmitted packets to be dropped.
18.3. TCP Data Encapsulation 18.3. TCP Data Encapsulation
As discussed earlier, encapsulation of data in SA messages MAY be As discussed earlier, encapsulation of data in SA messages MAY be
supported for backwards compatibility with legacy MSDP peers. supported for backwards compatibility with legacy MSDP peers.
skipping to change at page 23, line 36 skipping to change at page 26, line 8
natively. Route filtering will remain unchanged. However packet natively. Route filtering will remain unchanged. However packet
filtering at a firewall requires either that a firewall look inside filtering at a firewall requires either that a firewall look inside
the GRE packet or that the filtering is done on the GRE tunnel the GRE packet or that the filtering is done on the GRE tunnel
endpoints. In those environments in which this is considered to be a endpoints. In those environments in which this is considered to be a
security issue it may be desirable to terminate the tunnel at the security issue it may be desirable to terminate the tunnel at the
firewall. firewall.
20. Acknowledgments 20. Acknowledgments
The authors would like to thank Bill Nickless, John Meylor, Liming The authors would like to thank Bill Nickless, John Meylor, Liming
Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, and Cristina Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, Cristina
Radulescu-Banu for their design feedback and comments. In addition to Radulescu-Banu and IJsbrand Wijnands for their design feedback and
many other contributions, Tom Pusateri helped to clarify the comments. In addition to many other contributions, Tom Pusateri
connection state machine, Dave Thaler helped to clarify the helped to clarify the connection state machine, Dave Thaler helped to
Notification message types, and Bill Fenner helped to clarify the clarify the Notification message types, and Bill Fenner helped to
Peer-RPF rules. clarify the Peer-RPF rules.
21. Author's Address: 21. Author's Address:
Dino Farinacci Dino Farinacci
Procket Networks Procket Networks
3850 No. First St., Ste. C 3850 No. First St., Ste. C
San Jose, CA 95134 San Jose, CA 95134
Email: dino@procket.com Email: dino@procket.com
Yakov Rehkter Yakov Rehkter
skipping to change at page 25, line 7 skipping to change at page 28, line 7
Email: jhall@uu.net Email: jhall@uu.net
David Meyer David Meyer
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
Email: dmm@cisco.com Email: dmm@cisco.com
22. REFERENCES 22. REFERENCES
[GRE] Farinacci, D., et al., "Generic Routing Encapsulation [ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
(GRE)", draft-meyer-gre-update-03.txt, January,
2000. Work in Progress. [RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
October, 1994.
[RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation
(GRE)", RFC 2784, March 2000.
[RFC768] Postel, J. "User Datagram Protocol", RFC 768, August, [RFC768] Postel, J. "User Datagram Protocol", RFC 768, August,
1980. 1980.
[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
RFC 1191, November 1990. RFC 1191, November 1990.
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
 End of changes. 18 change blocks. 
48 lines changed or deleted 77 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/