Internet DRAFT - draft-brissette-pals-pw-fec-label-request
draft-brissette-pals-pw-fec-label-request
PALS Working Group Patrice Brissette
Internet Draft Kamran Raza
Intended Status: Proposed Standard Sami Boutros
Expires: April 26, 2015 Cisco Systems, Inc.
Nick Del Regno
Matthew Turlington
Verizon
June 29, 2015
Handling Incoming Label Request for PW FEC Types
draft-brissette-pals-pw-fec-label-request-01
Abstract
This document clarifies the behavior of an LSR PE upon receiving an
LDP Label Request message for Pseudowire (PW) FEC types. Furthermore,
this document specifies the procedures to be followed by the LSR PE
in order to answer such requests for a given PW FEC type.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Brissette, et. al Expires April 26, 2015 [Page 1]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Convention
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].
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 PWid FEC (FEC128) . . . . . . . . . . . . . . . . . . . . . 5
3.2 Generalized PWid FEC (FEC129): . . . . . . . . . . . . . . . 5
3.3 Common to PWid and Generalized PWid FEC . . . . . . . . . . 5
3.4 P2MP PW Upstream FEC (FEC130): . . . . . . . . . . . . . . . 5
3.5 P2MP PW Downstream FEC (FEC132): . . . . . . . . . . . . . . 5
3.5 PW Typed Wildcard FEC . . . . . . . . . . . . . . . . . . . 5
4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1 Normative References . . . . . . . . . . . . . . . . . . . 7
7.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Brissette, et. al Expires April 26, 2015 [Page 2]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
1 Introduction
Label Distribution Protocol (LDP) base specification [RFC5036]
defines different LDP message types and their procedures for
advertising label bindings. These procedures are generic and
inherited by any FEC type that is advertised using these message
types. For a given FEC type, any difference in behavior, compared to
what is already specified in RFC 5036, needs to be spelled out
clearly in the corresponding specification in which the FEC type is
being introduced or extended.
[RFC4447] specifies mechanisms to setup pseudowires (PWs) using LDP.
[RFC4447] does not specify any behavior change with regards to label
binding distribution for PW FEC types in response to a corresponding
Label Request message from a peer LSR PE. This implies that [RFC4447]
inherits the base procedures defined in [RFC5036] for Label Request
and associated response for a PW FEC type. The lack of specification
in the area of Label Request in [RFC4447] has led to some
interoperability issues between vendors due to different
interpretation. For example, there are some implementations which do
not honor and do not respond to an incoming Label Request for a PW
FEC type, resulting in functionality impact. Some of these problems
are very critical for the deployment of PW technologies. The
following is a non-exhaustive list of some of the problems and
potential breakages that may result due to the lack of support of
incoming Label Request for a PW FEC:
- An LSR PE can not restart forwarding of packet with sequence
number 1 as specified in section 4.1 of [RFC4385] with regards
to Control Word Sequencing.
- An LSR PE may not be able to perform a PW consistency check as
defined in section 4.1 of [RFC6667], resulting in LSR PEs
becoming out-of-sync.
- Some implementations of LSR PE do not checkpoint PW label
bindings learnt from peer(s) in their persistent memory and
hence are not able to recover any peer state after their own
restarts or switchovers. Such implementations typically require
re-learning of peer's label bindings after their own failure
and rely on Label Request mechanisms.
- The combination of Downstream Unsolicited mode and Conservative
Label retention (used due to memory limitations) can lead
to a situation where an LSR PE releases the label learnt from a
peer for a PW that it may need later. Label Request is used to
solve this issue. For example, consider an LSR PE operating in
Label Conservative mode receiving a label binding for a
Brissette, et. al Expires April 26, 2015 [Page 3]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
non-locally configured/known PW. This LSR PE ignores such a
label binding and later tries to re-learn it via Label Request
procedure once PW is locally configured. The authors will like
to remind the readers about the following fact: [RFC4447] does
not mandate to use Label Liberal mode. Therefore it is possible
that some implementation used Label Conservative mode.
This document clarifies the use of Label Request message and its
procedures for PW FEC types and re-enforces the acceptable behavior
to be implemented by an LSR PE.
2. Requirements
This document recommends the following action to be implemented by an
LSR PE that supports a PW FEC Type (P2P or P2MP type):
- An LSR PE MUST respond to an incoming Label Request message
for a PW FEC by sending its local binding for the PW via a
Label Mapping message. If no such binding is available, the
LSR PE SHOULD respond by sending a new status code "No PW"
in a Notification message.
- An LSR PE MUST respond to an incoming Label Request message
for a Wildcard FEC [RFC5036] by sending its local bindings for
all its PWs via Label Mapping messages. This is in addition to
label bindings corresponding to any other LDP FEC types
configured and available at the LSR.
- An LSR PE MUST respond to an incoming Label Request message
for a Typed Wildcard PW FEC [RFC6667] by sending its local
bindings for all its PWs for the given FEC type via Label
Mapping messages. For a given PW FEC type, this advertisement
is to be scoped either for a specific PW type or for all
PW types according to the received PW Typed Wildcard FEC.
3. Procedures
This document re-enforces the Label Request generic procedures, as
defined by RFC 5036, for PW FEC types, and hence strongly recommends
that an LSR PE receiving the PW Label Request message should respond
either by sending its label binding in Label Mapping message(s) or
with a Notification message indicating why it cannot satisfy the
request.
An LSR PE should respond to a Label Request when corresponding PW FEC
is resolved locally. The following sub sections define the meaning of
a "resolution" for a given PW FEC type.
Brissette, et. al Expires April 26, 2015 [Page 4]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
3.1 PWid FEC (FEC128)
A PWid FEC is resolved when a local label binding has been allocated
after local configuration application.
[RFC6073] does not preclude setting up MS-PWs using FEC-128,
therefore this procedure is also applicable to PEs acting as S-PEs.
3.2 Generalized PWid FEC (FEC129):
A Generalized PWid FEC is resolved at an ST-PE when SAII is locally
configured, TAII is learnt statically or dynamically via discovery
mechanisms, and a local label binding has been allocated.
This FEC is resolved at an TT-PE when SAII is locally configured,
TAII is learnt statically or dynamically via discovery mechanisms,
remote label binding is received, and a local label binding has been
allocated.
Whereas, this FEC is resolved at an S-PE when remote label binding is
received for PW segment, TAII is learnt statically or dynamically via
discovery mechanisms, and a local label binding has been allocated.
3.3 Common to PWid and Generalized PWid FEC
A FEC is resolved at an S-PE when remote label binding is received
for PW segment.
In the case of Generalized PWid FEC, TAII is learnt statically or
dynamically via discovery mechanisms, and a local label binding has
been allocated. Whereas PWid FEC is resolved when a local binding has
been allocated.
3.4 P2MP PW Upstream FEC (FEC130):
Editor Note: Deferred for further study.
3.5 P2MP PW Downstream FEC (FEC132):
Editor Note: Deferred for further study.
3.5 PW Typed Wildcard FEC
The rules defined for individual PW FEC types apply equally when they
are used under a PW Typed Wildcard FEC [RFC6667].
4 Acknowledgements
Brissette, et. al Expires April 26, 2015 [Page 5]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
The authors would like to thank for Alexander Vainshtein its
reviews and comments of this document.
5 Security Considerations
This document does not introduce any additional security constraints.
6 IANA Considerations
This document requires the assignment of a new LDP Status Code to be
used in a Notification message to notify a peer LSR if lookup fails
at receiving LSR for a PW FEC received in a Label Request message.
The value requested from the IANA managed LDP registry "LDP Status
Code Name Space" is:
Brissette, et. al Expires April 26, 2015 [Page 6]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
Range/Value E Description
----------- --- -----------
0x00000032 0 No PW
7 References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC6667] Raza, K., Boutros, S., and Pignataro, C., "LDP Typed
Wildcard FEC for PWid and Generalized PWid FEC", RFC 6667,
July 2012.
7.2 Informative References
Authors' Addresses
Patrice Brissette
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON K2K-3E8, Canada.
EMail: pbrisset@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON K2K-3E8, Canada.
EMail: skraza@cisco.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way,
San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com
Nick Del Regno
Brissette, et. al Expires April 26, 2015 [Page 7]
Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015
Verizon
400 International Pkwy
Richardson, TX 75081, USA.
E-mail: nick.delregno@verizon.com
Matthew Turlington
Verizon
400 International Pkwy
Richardson, TX 75081, USA.
E-mail: matt.turlington@verizon.com
Brissette, et. al Expires April 26, 2015 [Page 8]