GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7358

Internet Engineering Task Force (IETF) K. Raza Request for Comments: 7358 S. Boutros Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini Category: Standards Track Cisco Systems, Inc. ISSN: 2070-1721 N. Leymann

                                                      Deutsche Telekom
                                                          October 2014
                   Label Advertisement Discipline
           for LDP Forwarding Equivalence Classes (FECs)

Abstract

 The label advertising behavior of an LDP speaker for a given
 Forwarding Equivalence Class (FEC) is governed by the FEC type and
 not necessarily by the LDP session's negotiated label advertisement
 mode.  This document updates RFC 5036 to make that fact clear.  It
 also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the
 label advertisement mode for all currently defined LDP FEC types.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7358.

Raza, et al. Standards Track [Page 1] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

Copyright Notice

 Copyright (c) 2014 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.  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.

Table of Contents

 1. Introduction ....................................................2
 2. Label Advertisement Discipline ..................................3
    2.1. Update to RFC 5036 .........................................3
    2.2. Specification for LDP FECs .................................4
 3. Security Considerations .........................................4
 4. IANA Considerations .............................................4
 5. References ......................................................6
    5.1. Normative References .......................................6
    5.2. Informative References .....................................7
 Acknowledgments ....................................................8
 Authors' Addresses .................................................8

1. Introduction

 The Label Distribution Protocol (LDP) [RFC5036] allows label
 advertisement mode negotiation at the time of session establishment.
 The LDP specification also dictates that only a single label
 advertisement mode be negotiated, agreed upon, and used for a given
 LDP session between two Label Switching Routers (LSRs).
 The negotiated label advertisement mode defined in RFC 5036 and
 carried in the LDP Initialization message is only indicative.  It
 indicates how the LDP speakers on a session will advertise labels for
 some Forwarding Equivalence Classes (FECs), but it is not a rule that
 restricts the speakers to behave in a specific way.  Furthermore, for
 some FEC types the advertising behavior of the LDP speaker is
 governed by the FEC type and not by the negotiated behavior.
 This document updates [RFC5036] to make that fact clear.  It also
 updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to
 indicate, for each FEC type that has already been defined, whether

Raza, et al. Standards Track [Page 2] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

 the label binding advertisements for the FEC are constrained by the
 negotiated label advertisement mode or not.  Furthermore, this
 document specifies the label advertisement mode to be used for all
 currently defined FECs.

2. Label Advertisement Discipline

 To remove any ambiguity and conflict regarding a label advertisement
 discipline among different FEC types sharing a common LDP session,
 this document specifies a label advertisement discipline for FEC
 types.
 This document introduces the following types for specifying a label
 advertisement discipline for a FEC type:
  1. DU (Downstream Unsolicited)
  2. DoD (Downstream on Demand)
  3. As negotiated (DU or DoD)
  4. Upstream ([RFC6389])
  5. Not applicable
  6. Unknown

2.1. Update to RFC 5036

 Section 3.5.3 of [RFC5036] is updated to add the following two
 statements under the description of "A, Label Advertisement
 Discipline":
  1. Each document defining an LDP FEC must state the applicability of

the negotiated label advertisement discipline for label binding

    advertisements for that FEC.  If the negotiated label
    advertisement discipline does not apply to the FEC, the document
    must also explicitly state the discipline to be used for the FEC.
  1. This document defines the label advertisement discipline for the

following FEC types:

       +----------+----------+--------------------------------+
       | FEC Type | FEC Name | Label Advertisement Discipline |
       +----------+----------+--------------------------------+
       | 0x01     | Wildcard | Not applicable                 |
       | 0x02     | Prefix   | As negotiated (DU or DoD)      |
       +----------+----------+--------------------------------+

Raza, et al. Standards Track [Page 3] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

2.2. Specification for LDP FECs

 The label advertisement discipline for currently defined LDP FEC
 types is listed in Section 4.
 This document updates the respective RFCs in which these FECs are
 introduced and defined.

3. Security Considerations

 This document only clarifies the applicability of an LDP session's
 label advertisement mode and hence does not add any LDP security
 mechanics and considerations to those already defined in the LDP
 specification [RFC5036].

4. IANA Considerations

 This document mandates the specification of a label advertisement
 discipline for each defined FEC type and hence IANA's "Forwarding
 Equivalence Class (FEC) Type Name Space" registry under IANA's "Label
 Distribution Protocol (LDP) Parameters" registry has been extended as
 follows:
  1. Added a new column titled "Label Advertisement Discipline" with

the following possible values:

       o  DU
       o  DoD
       o  As negotiated (DU or DoD)
       o  Upstream
       o  Not applicable
       o  Unknown
  1. Made this document an additional reference for the registry itself

and for all affected registrations.

  1. Kept other columns of the registry in place and populated as they

were.

Raza, et al. Standards Track [Page 4] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

 For the currently assigned FEC types, the updated registry looks
 like:
 +=====+====+===============+==============+===========+============+
 |Value|Hex | Name          |Label         | Reference |Notes/      |
 |     |    |               |Advertisement |           |Registration|
 |     |    |               |Discipline    |           |Date        |
 +=====+====+===============+==============+===========+============+
 | 0   |0x00|Reserved       |              |           |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 1   |0x01|Wildcard       |Not applicable| [RFC5036] |            |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 2   |0x02|Prefix         |As negotiated | [RFC5036] |            |
 |     |    |               |(DU or DoD)   | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 4   |0x04|CR-LSP         |DoD           | [RFC3212] |            |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 5   |0x05|Typed Wildcard |Not applicable| [RFC5918] |            |
 |     |    |FEC Element    |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 6   |0x06|P2MP           |DU            | [RFC6388] |            |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 7   |0x07|MP2MP-up       |DU            | [RFC6388] |            |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 8   |0x08|MP2MP-down     |DU            | [RFC6388] |            |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 9   |0x09|HSMP-upstream  |DU            | [RFC7140] | 2014-01-09 |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 10  |0x0A|HSMP-downstream|DU, Upstream  | [RFC7140] | 2014-01-09 |
 |     |    |               |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 128 |0x80|PWid           |DU            | [RFC4447] |            |
 |     |    |FEC Element    |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 129 |0x81|Generalized    |DU            | [RFC4447] |            |
 |     |    |PWid           |              | [RFC7358] |            |
 |     |    |FEC Element    |              |           |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 130 |0x82|P2MP PW        |Upstream      | [P2MP-PW] | 2009-06-03 |
 |     |    |Upstream       |              | [RFC7358] |            |
 |     |    |FEC Element    |              |           |            |
 +-----+----+---------------+--------------+-----------+------------+

Raza, et al. Standards Track [Page 5] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

 +-----+----+---------------+--------------+-----------+------------+
 | 131 |0x83|Protection     |DU            |[FAST-PROT]| 2010-02-26 |
 |     |    |FEC Element    |              | [RFC7358] |            |
 +-----+----+---------------+--------------+-----------+------------+
 | 132 |0x84|P2MP PW        |DU            | [P2MP-PW] | 2014-04-04 |
 |     |    |Downstream     |              | [RFC7358] |            |
 |     |    |FEC Element    |              |           |            |
 +-----+----+---------------+--------------+-----------+------------+

5. References

5.1. Normative References

 [RFC3212]   Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
             Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette,
             A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
             Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
             January 2002, <http://www.rfc-editor.org/info/rfc3212>.
 [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,
             <http://www.rfc-editor.org/info/rfc4447>.
 [RFC5036]   Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
             "LDP Specification", RFC 5036, October 2007,
             <http://www.rfc-editor.org/info/rfc5036>.
 [RFC5918]   Asati, R., Minei, I., and B. Thomas, "Label Distribution
             Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
             (FEC)", RFC 5918, August 2010,
             <http://www.rfc-editor.org/info/rfc5918>.
 [RFC6388]   Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
             Thomas, "Label Distribution Protocol Extensions for
             Point-to-Multipoint and Multipoint-to-Multipoint Label
             Switched Paths", RFC 6388, November 2011,
             <http://www.rfc-editor.org/info/rfc6388>.
 [RFC6389]   Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
             Assignment for LDP", RFC 6389, November 2011,
             <http://www.rfc-editor.org/info/rfc6389>.
 [RFC7140]   Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP
             Extensions for Hub and Spoke Multipoint Label Switched
             Path", RFC 7140, March 2014,
             <http://www.rfc-editor.org/info/rfc7140>.

Raza, et al. Standards Track [Page 6] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

5.2. Informative References

 [FAST-PROT] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
             "PW Endpoint Fast Failure Protection", Work in Progress,
             draft-ietf-pwe3-endpoint-fast-protection-01, July 2014.
 [P2MP-PW]   Sivabalan, S., Ed., Boutros, S., Ed., Martini, L.,
             Konstantynowicz, M., Del Vecchio, G., Nadeau, T., Jounay,
             F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M.,
             Ciavaglia, L., Delord, S., and K. Raza, "Signaling
             Root-Initiated Point-to-Multipoint Pseudowire using LDP",
             Work in Progress, draft-ietf-pwe3-p2mp-pw-04, March 2012.

Raza, et al. Standards Track [Page 7] RFC 7358 Label Advert. Discipline for LDP FECs October 2014

Acknowledgments

 We acknowledge Eric Rosen and Rajiv Asati for their initial review
 and input on the document.

Authors' Addresses

 Kamran Raza
 Cisco Systems, Inc.
 2000 Innovation Drive
 Ottawa, ON K2K-3E8
 Canada
 EMail: skraza@cisco.com
 Sami Boutros
 Cisco Systems, Inc.
 3750 Cisco Way
 San Jose, CA  95134
 United States
 EMail: sboutros@cisco.com
 Luca Martini
 Cisco Systems, Inc.
 9155 East Nichols Avenue, Suite 400
 Englewood, CO  80112
 United States
 EMail: lmartini@cisco.com
 Nicolai Leymann
 Deutsche Telekom AG
 Winterfeldtstrasse 21
 Berlin 10781
 Germany
 EMail: N.Leymann@telekom.de

Raza, et al. Standards Track [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7358.txt · Last modified: 2014/10/06 21:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki