draft-ietf-mpls-ldp-dod-04.txt | draft-ietf-mpls-ldp-dod-05.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: Standards Track B. Decraene | |||
Expires: August 7, 2013 France Telecom | Expires: August 29, 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. | |||
February 3, 2013 | February 25, 2013 | |||
LDP Downstream-on-Demand in Seamless MPLS | LDP Downstream-on-Demand in Seamless MPLS | |||
draft-ietf-mpls-ldp-dod-04 | draft-ietf-mpls-ldp-dod-05 | |||
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 August 7, 2013. | This Internet-Draft will expire on August 29, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 43 | skipping to change at page 3, line 43 | |||
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 26 | 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 26 | |||
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 | 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 27 | 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
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 . . . . . . . 28 | 6.1.2. Network to access packet flow direction . . . . . . . 28 | |||
6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 | 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 | |||
6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 | 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 | 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 . . . . . . . . . . . . . . . . . . 31 | |||
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. | |||
skipping to change at page 19, line 14 | skipping to change at page 19, line 14 | |||
part of global-repair. In turn ANs should also sent Label Withdraw | part of global-repair. In turn ANs should also sent Label Withdraw | |||
messages for affected /32 FECs to their upstream ANs. | messages for affected /32 FECs to their upstream ANs. | |||
If access IGP is used, and AGN1x gets completely isolated from the | If access IGP is used, and AGN1x gets completely isolated from the | |||
core network, it should stop advertising the default route 0/0 into | core network, it should stop advertising the default route 0/0 into | |||
the access IGP. | the access IGP. | |||
4. LDP DoD Procedures | 4. LDP DoD Procedures | |||
Label Distribution Protocol is specified in [RFC5036], and all LDP | Label Distribution Protocol is specified in [RFC5036], and all LDP | |||
Downstream-on-Demand implementations MUST follow this specification. | Downstream-on-Demand implementations MUST follow [RFC5036] | |||
specification. | ||||
In the MPLS architecture [RFC3031], network traffic flows from | In the MPLS architecture [RFC3031], network traffic flows from | |||
upstream to downstream LSR. The use cases in this document rely on | upstream to downstream LSR. The use cases in this document rely on | |||
the downstream assignment of labels, where labels are assigned by the | the downstream assignment of labels, where labels are assigned by the | |||
downstream LSR and signaled to the upstream LSR as shown in Figure 7. | downstream LSR and signaled to the upstream LSR as shown in Figure 7. | |||
+----------+ +------------+ | +----------+ +------------+ | |||
| upstream | | downstream | | | upstream | | downstream | | |||
------+ LSR +------+ LSR +---- | ------+ LSR +------+ LSR +---- | |||
traffic | | | | address | traffic | | | | address | |||
skipping to change at page 27, line 13 | skipping to change at page 27, line 16 | |||
/32 static route with LDP DoD label request policy configured. | /32 static route with LDP DoD label request policy configured. | |||
d. If the route next-hop changed, and the label does not point to | d. If the route next-hop changed, and the label does not point to | |||
the best or alternate next-hop. | the best or alternate next-hop. | |||
e. If it receives a label withdraw from a downstream DoD session. | e. If it receives a label withdraw from a downstream DoD session. | |||
4.7. Local Repair | 4.7. Local Repair | |||
To support local-repair with ECMP and IPFRR LFA, access LSR/ABR MUST | To support local-repair with ECMP and IPFRR LFA, access LSR/ABR MUST | |||
request labels on both best next-hop and alternate next-hop LDP DoD | request labels on both the best next-hop and the alternate next-hop | |||
sessions as specified in the label request procedures in Section 4.4. | LDP DoD sessions, as specified in the label request procedures in | |||
Section 4.4. If remote LFA is enabled, access LSR/ABR needs a label | ||||
from its alternate next-hop toward the PQ node and needs a label from | ||||
the remote PQ node toward its FEC/destination. If access LSR/ABR | ||||
doesn't already know those labels, it MUST request them. | ||||
This will enable access LSR/ABR to pre-program the alternate | This will enable access LSR/ABR to pre-program the alternate | |||
forwarding path with the alternate label(s), and invoke IPFRR LFA | forwarding path with the alternate label(s), and invoke IPFRR LFA | |||
switch-over procedure if the primary next-hop link fails. | switch-over procedure if the primary next-hop link fails. | |||
5. IANA Considerations | 5. IANA Considerations | |||
5.1. LDP TLV TYPE | 5.1. LDP TLV TYPE | |||
This document uses a new a new Optional Parameter Queue Request TLV | This document uses a new a new Optional Parameter Queue Request TLV | |||
in the Label Request message defined in Section 4.4.3. IANA already | in the Label Request message defined in Section 4.4.3. IANA already | |||
End of changes. 7 change blocks. | ||||
9 lines changed or deleted | 15 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/ |