draft-ietf-mpls-ldp-dod-01.txt | draft-ietf-mpls-ldp-dod-02.txt | |||
---|---|---|---|---|
Network Working Group T. Beckhaus | Network Working Group T. Beckhaus | |||
Internet-Draft Deutsche Telekom AG | Internet-Draft Deutsche Telekom AG | |||
Intended status: Informational B. Decraene | Intended status: Informational B. Decraene | |||
Expires: September 13, 2012 France Telecom | Expires: January 16, 2013 France Telecom | |||
K. Tiruveedhula | K. Tiruveedhula | |||
Juniper Networks | Juniper Networks | |||
M. Konstantynowicz | M. Konstantynowicz | |||
L. Martini | L. Martini | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
March 12, 2012 | July 15, 2012 | |||
LDP Downstream-on-Demand in Seamless MPLS | LDP Downstream-on-Demand in Seamless MPLS | |||
draft-ietf-mpls-ldp-dod-01 | draft-ietf-mpls-ldp-dod-02 | |||
Abstract | Abstract | |||
Seamless MPLS design enables a single IP/MPLS network to scale over | Seamless MPLS design enables a single IP/MPLS network to scale over | |||
core, metro and access parts of a large packet network infrastructure | core, metro and access parts of a large packet network infrastructure | |||
using standardized IP/MPLS protocols. One of the key goals of | using standardized IP/MPLS protocols. One of the key goals of | |||
Seamless MPLS is to meet requirements specific to access, including | Seamless MPLS is to meet requirements specific to access, including | |||
high number of devices, their position in network topology and their | high number of devices, their position in network topology and their | |||
compute and memory constraints that limit the amount of state access | compute and memory constraints that limit the amount of state access | |||
devices can hold.This can be achieved with LDP Downstream-on-Demand | devices can hold.This can be achieved with LDP Downstream-on-Demand | |||
skipping to change at page 2, line 8 | skipping to change at page 2, line 8 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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." | |||
This Internet-Draft will expire on September 13, 2012. | This Internet-Draft will expire on January 16, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 | 3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 | |||
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 | 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 | 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 | |||
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 | 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 | |||
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 | 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 | |||
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 | 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 | |||
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 | 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 | |||
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 | 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 | |||
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 | 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 | |||
4.1. LDP Label Distribution Control and Retention Modes . . . . 20 | 4.1. LDP Label Distribution Control and Retention Modes . . . . 20 | |||
4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 21 | 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 | 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 | |||
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 | 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23 | |||
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 | 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23 | |||
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 | 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24 | |||
4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 | 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 | |||
4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 | 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 | |||
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 | 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 | |||
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 | 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 | 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 | 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 | |||
6.1.1. Access to network packet flow direction . . . . . . . 28 | 6.1.1. Access to network packet flow direction . . . . . . . 28 | |||
6.1.2. Network to access packet flow direction . . . . . . . 29 | 6.1.2. Network to access packet flow direction . . . . . . . 29 | |||
6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 | 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 | |||
6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 | 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
1. Introduction | 1. Introduction | |||
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single | Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single | |||
IP/MPLS network to scale over core, metro and access parts of a large | IP/MPLS network to scale over core, metro and access parts of a large | |||
packet network infrastructure using standardized IP/MPLS protocols. | packet network infrastructure using standardized IP/MPLS protocols. | |||
One of the key goals of Seamless MPLS is to meet requirements | One of the key goals of Seamless MPLS is to meet requirements | |||
specific to access, including high number of devices, their position | specific to access, including high number of devices, their position | |||
in network topology and their compute and memory constraints that | in network topology and their compute and memory constraints that | |||
skipping to change at page 13, line 15 | skipping to change at page 13, line 15 | |||
3.1.2. AN with Access IGP | 3.1.2. AN with Access IGP | |||
If access IGP is used, AN(s) advertise their loopbacks over the | If access IGP is used, AN(s) advertise their loopbacks over the | |||
access IGP with configured metrics. AGN1x advertise a default route | access IGP with configured metrics. AGN1x advertise a default route | |||
over the access IGP. | over the access IGP. | |||
Similarly to the static route case, upstream AN/AGN1x should request | Similarly to the static route case, upstream AN/AGN1x should request | |||
labels over LDP DoD session(s) from downstream AN/AGN1x for all /32 | labels over LDP DoD session(s) from downstream AN/AGN1x for all /32 | |||
or /128 routes received over the access IGP. | or /128 routes received over the access IGP. | |||
Routers request labels over LDP DoD session(s) according to their | ||||
needs for MPLS connectivity (LSPs). In particular if AGNs, as per | ||||
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute | ||||
routes from the IGP into BGP labeled unicast [RFC3107], they should | ||||
request labels over LDP DoD session(s) for those routes. | ||||
Identically to the static route case, downstream AN/AGN1x should | Identically to the static route case, downstream AN/AGN1x should | |||
respond to the label request from the upstream AN/AGN1x with a label | respond to the label request from the upstream AN/AGN1x with a label | |||
mapping (if the requested route is present in its RIB, and there is a | mapping (if the requested route is present in its RIB, and there is a | |||
valid label binding from its downstream), and must install the | valid label binding from its downstream), and must install the | |||
advertised label as an incoming label in its LIB and LFIB. Upstream | advertised label as an incoming label in its LIB and LFIB. Upstream | |||
AN/AGN1x must also install the received label as an outgoing label in | AN/AGN1x must also install the received label as an outgoing label in | |||
their LIB and LFIB. | their LIB and LFIB. | |||
Identically to the static route case, in order to facilitate ECMP and | Identically to the static route case, in order to facilitate ECMP and | |||
IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD | IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD | |||
skipping to change at page 21, line 6 | skipping to change at page 21, line 10 | |||
decision to bind a label to the FEC independently from | decision to bind a label to the FEC independently from | |||
distributing that label binding to its label distribution peers. | distributing that label binding to its label distribution peers. | |||
A new FEC is recognized whenever a new route becomes valid on the | A new FEC is recognized whenever a new route becomes valid on the | |||
LSR. | LSR. | |||
o Ordered mode - an LSR binds a label to a particular FEC if it is | o Ordered mode - an LSR binds a label to a particular FEC if it is | |||
the egress router for that FEC or if it has already received a | the egress router for that FEC or if it has already received a | |||
label binding for that FEC from its next-hop LSR for that FEC. | label binding for that FEC from its next-hop LSR for that FEC. | |||
Using independent label distribution control with LDP DoD and access | Using independent label distribution control with LDP DoD and access | |||
static routing will prevent the access LSRs from propagating label | static routing would prevent the access LSRs from propagating label | |||
binding failure along the access topology, making it impossible to | binding failure along the access topology, making it impossible for | |||
switchover to an alternate path, even if such a path exists. | upstream LSR to be notified about the downstream failure and for an | |||
application using the LSP to switchover to an alternate path, even if | ||||
such a path exists. | ||||
LDP protocol specification [RFC5036] defines two modes for label | LDP protocol specification [RFC5036] defines two modes for label | |||
retention, following the definitions in MPLS architecture [RFC3031]: | retention, following the definitions in MPLS architecture [RFC3031]: | |||
o Liberal mode - LSR retains every label mappings received from a | o Liberal mode - LSR retains every label mappings received from a | |||
peer LSR, regardless of whether the peer LSR is the next-hop for | peer LSR, regardless of whether the peer LSR is the next-hop for | |||
the advertised mapping. This mode allows for quicker adaptation | the advertised mapping. This mode allows for quicker adaptation | |||
to routing changes. | to routing changes. | |||
o Conservative mode - LSR retains advertised label mappings only if | o Conservative mode - LSR retains advertised label mappings only if | |||
they will be used to forward packets, that is only if they are | they will be used to forward packets, that is only if they are | |||
received from a valid next-hop LSR according to routing. This | received from a valid next-hop LSR according to routing. This | |||
mode allows LSR to maintain fewer labels, but slows down LSR | mode allows LSR to maintain fewer labels, but slows down LSR | |||
adaptation to routing changes. | adaptation to routing changes. | |||
Using conservative label retention mode with LDP DoD will prevent the | Due to the fact that according to LDP protocol specification | |||
access LSRs (AN and AGN1x nodes) from implementing IPFRR LFA | [RFC5036] conservative label retention mode calls for allocating and | |||
alternate based local-repair, as label mapping request can not be | maintaining label mappings only if they are used for the forwarding | |||
sent to alternate next-hops. | of data, when used with LDP DoD the conservative label retention mode | |||
would prevent LSRs operating in this mode to request and maintain | ||||
label mappings for any backup routes that are not used for | ||||
forwarding. This in turn would prevent the access LSRs (AN and AGN1x | ||||
nodes) from implementing IPFRR LFA alternate based local-repair, as | ||||
label mapping request can not be sent to alternate next-hops. | ||||
Adhering to the overall design goals of Seamless MPLS | Adhering to the overall design goals of Seamless MPLS | |||
[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network | [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network | |||
scale without compromising fast service restoration, all access LSRs | scale without compromising fast service restoration, all access LSRs | |||
(AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: | (AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: | |||
o Ordered label distribution control - enables propagation of label | o Ordered label distribution control - enables propagation of label | |||
binding failure within the access topology. | binding failure within the access topology. | |||
o Liberal label retention - enables pre-programming of alternate | o Liberal label retention - enables pre-programming of alternate | |||
next-hops with associated FEC labels. | next-hops with associated FEC labels. | |||
In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an | In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an | |||
access ABR connecting access and metro domains. To enable failure | access ABR connecting access and metro domains. To enable failure | |||
propagation between those domains, access ABR MUST implement ordered | propagation between those domains, access ABR MUST implement ordered | |||
label distribution control when redistributing access static routes | label distribution control when redistributing routes/FEC between the | |||
and/or access IGP routes into the network-side BGP labeled unicast | access-side (using LDP DoD and static or access IGP) and the network- | |||
[RFC3107] or core IGP with LDP Downstream Unsolicited label | side ( using BGP labeled unicast [RFC3107] or core IGP with LDP | |||
advertisement. | Downstream Unsolicited label advertisement. | |||
4.2. IPv6 Support | 4.2. IPv6 Support | |||
Current LDP protocol specification [RFC5036] defines procedures and | Current LDP protocol specification [RFC5036] defines procedures and | |||
messages for exchanging FEC-label bindings over IPv4 and/or IPv6 | messages for exchanging FEC-label bindings over IPv4 and/or IPv6 | |||
networks. However number of IPv6 usage areas are not clearly | networks. However number of IPv6 usage areas are not clearly | |||
specified including: packet to LSP mapping for IPv6 destination | specified including: packet to LSP mapping for IPv6 destination | |||
router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 | router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 | |||
multicast address, separate LSPs for IPv4 and IPv6, and others. | multicast address, separate LSPs for IPv4 and IPv6, and others. | |||
skipping to change at page 23, line 6 | skipping to change at page 23, line 16 | |||
label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. | label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. | |||
4.4. Label Request Procedures | 4.4. Label Request Procedures | |||
4.4.1. Access LSR/ABR Label Request | 4.4.1. Access LSR/ABR Label Request | |||
Upstream access LSR/ABR will request label bindings from adjacent | Upstream access LSR/ABR will request label bindings from adjacent | |||
downstream access LSR/ABR based on the following trigger events: | downstream access LSR/ABR based on the following trigger events: | |||
a. Access LSR/ABR is configured with /32 static route with LDP DoD | a. Access LSR/ABR is configured with /32 static route with LDP DoD | |||
label request policy in line with intitial network setup use case | label request policy in line with initial network setup use case | |||
described in Section 3.1. | described in Section 3.1. | |||
b. Access LSR/ABR is configured with a service in line with service | b. Access LSR/ABR is configured with a service in line with service | |||
use cases described in Section 3.2 and Section 3.3. | use cases described in Section 3.2 and Section 3.3. | |||
c. Access LSR/ABR link to adjacent node comes up and LDP DoD session | c. Configuration with access static routes - Access LSR/ABR link to | |||
is established. In this case access LSR should send label | adjacent node comes up and LDP DoD session is established. In | |||
request messages for all /32 static routes configured with LDP | this case access LSR should send label request messages for all | |||
DoD policy and all /32 routes related to provisioned services | /32 static routes configured with LDP DoD policy and all /32 | |||
that are not covered by default route. In line with use cases | routes related to provisioned services that are covered by | |||
described in Section 3.5. | default route. | |||
d. In all above cases requests MUST be sent to next-hop LSR(s) and | d. Configuration with access IGP - Access LSR/ABR link to adjacent | |||
node comes up and LDP DoD session is established. In this case | ||||
access LSR should send label request messages for all /32 routes | ||||
learned over the access IGP and all /32 routes related to | ||||
provisioned services that are covered by access IGP routes. | ||||
e. In all above cases requests MUST be sent to next-hop LSR(s) and | ||||
alternate LSR(s). | alternate LSR(s). | |||
Downstream access LSR/ABR will respond with label mapping message | Downstream access LSR/ABR will respond with label mapping message | |||
with a non-null label if any of the below conditions are met: | with a non-null label if any of the below conditions are met: | |||
a. Downstream access LSR/ABR - requested FEC is an IGP or static | a. Downstream access LSR/ABR - requested FEC is an IGP or static | |||
route and there is an LDP label already learnt from the next- | route and there is an LDP label already learnt from the next- | |||
next-hop downstream LSR (by LDP DoD or LDP DU). If there is no | next-hop downstream LSR (by LDP DoD or LDP DU). If there is no | |||
label for the requested FEC and there is an LDP DoD session to | label for the requested FEC and there is an LDP DoD session to | |||
the next-next-hop downstream LSR, downstream LSR MUST send a | the next-next-hop downstream LSR, downstream LSR MUST send a | |||
skipping to change at page 31, line 49 | skipping to change at page 32, line 8 | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP | [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP | |||
Specification", RFC 5036, October 2007. | Specification", RFC 5036, October 2007. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-mpls-ldp-ipv6] | [I-D.ietf-mpls-ldp-ipv6] | |||
Pignataro, C., Asati, R., Papneja, R., and V. Manral, | Asati, R., Manral, V., Papneja, R., and C. Pignataro, | |||
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 | "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07 | |||
(work in progress), January 2012. | (work in progress), June 2012. | |||
[I-D.ietf-mpls-seamless-mpls] | [I-D.ietf-mpls-seamless-mpls] | |||
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, | Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, | |||
M., and D. Steinberg, "Seamless MPLS Architecture", | M., and D. Steinberg, "Seamless MPLS Architecture", | |||
draft-ietf-mpls-seamless-mpls-01 (work in progress), | draft-ietf-mpls-seamless-mpls-01 (work in progress), | |||
March 2012. | March 2012. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001. | Label Switching Architecture", RFC 3031, January 2001. | |||
skipping to change at page 32, line 43 | skipping to change at page 33, line 10 | |||
Synchronization", RFC 5443, March 2009. | Synchronization", RFC 5443, March 2009. | |||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, June 2010. | Authentication Option", RFC 5925, June 2010. | |||
Authors' Addresses | Authors' Addresses | |||
Thomas Beckhaus | Thomas Beckhaus | |||
Deutsche Telekom AG | Deutsche Telekom AG | |||
Heinrich-Hertz-Strasse 3-7 | Heinrich-Hertz-Strasse 3-7 | |||
Darmstadt, 64307 | Darmstadt 64307 | |||
Germany | Germany | |||
Phone: +49 6151 58 12825 | Phone: +49 6151 58 12825 | |||
Fax: | ||||
Email: thomas.beckhaus@telekom.de | Email: thomas.beckhaus@telekom.de | |||
URI: | ||||
Bruno Decraene | Bruno Decraene | |||
France Telecom | France Telecom | |||
38-40 rue du General Leclerc | 38-40 rue du General Leclerc | |||
Issy Moulineaux cedex 9, 92794 | Issy Moulineaux cedex 9 92794 | |||
France | France | |||
Phone: | ||||
Fax: | ||||
Email: bruno.decraene@orange.com | Email: bruno.decraene@orange.com | |||
URI: | ||||
Kishore Tiruveedhula | Kishore Tiruveedhula | |||
Juniper Networks | Juniper Networks | |||
10 Technology Park Drive | 10 Technology Park Drive | |||
Westford, Massachusetts 01886 | Westford, Massachusetts 01886 | |||
USA | USA | |||
Phone: 1-(978)-589-8861 | Phone: 1-(978)-589-8861 | |||
Fax: | ||||
Email: kishoret@juniper.net | Email: kishoret@juniper.net | |||
URI: | ||||
Maciek Konstantynowicz | Maciek Konstantynowicz | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
10 New Square Park, Bedfont Lakes | ||||
London | ||||
United Kingdom | ||||
Phone: | Email: maciek@cisco.com | |||
Fax: | ||||
Email: maciek@bgp.nu | ||||
URI: | ||||
Luca Martini | Luca Martini | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
9155 East Nichols Avenue, Suite 400 | 9155 East Nichols Avenue, Suite 400 | |||
Englewood, CO 80112 | Englewood, CO 80112 | |||
USA | USA | |||
Phone: | ||||
Fax: | ||||
Email: lmartini@cisco.com | Email: lmartini@cisco.com | |||
URI: | ||||
End of changes. 29 change blocks. | ||||
48 lines changed or deleted | 58 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |