idnits 2.17.1 

draft-pdutta-mpls-multi-ldp-instance-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The abstract seems to contain references ([RFC5036]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (April 05, 2012) is 4403 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'LDP-ADJ-CAP' is mentioned on line 217, but not
     defined

  == Outdated reference: A later version (-08) exists of
     draft-ietf-mpls-mldp-in-band-signaling-05

  -- Obsolete informational reference (is this intentional?): RFC 4447
     (Obsoleted by RFC 8077)


     Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	MPLS Working Group                                              P. Dutta
3	Internet-Draft                                               M. Aissaoui
4	Intended status: Standards Track                          Alcatel-Lucent
5	Expires: October 7, 2012                                  April 05, 2012

7	                         Multiple LDP Instances
8	                draft-pdutta-mpls-multi-ldp-instance-00

10	Abstract

12	   This document defines an extension to Label Distribution Protocol
13	   (LDP) [RFC5036] for implementation of multiple LDP instances in a
14	   network node, where all such instances share the common data plane.
15	   Multiple LDP instances provide a method for operators for fate
16	   separation of various LDP FEC Types as well as for network
17	   segmentation.  The methods defined in this extension are backward
18	   compatible with procedures defined in [RFC5036]

20	Requirements Language

22	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
23	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
24	   document are to be interpreted as described in RFC 2119 [RFC2119].

26	Status of this Memo

28	   This Internet-Draft is submitted in full conformance with the
29	   provisions of BCP 78 and BCP 79.

31	   Internet-Drafts are working documents of the Internet Engineering
32	   Task Force (IETF).  Note that other groups may also distribute
33	   working documents as Internet-Drafts.  The list of current Internet-
34	   Drafts is at http://datatracker.ietf.org/drafts/current/.

36	   Internet-Drafts are draft documents valid for a maximum of six months
37	   and may be updated, replaced, or obsoleted by other documents at any
38	   time.  It is inappropriate to use Internet-Drafts as reference
39	   material or to cite them other than as "work in progress."

41	   This Internet-Draft will expire on October 7, 2012.

43	Copyright Notice

45	   Copyright (c) 2012 IETF Trust and the persons identified as the
46	   document authors.  All rights reserved.

48	   This document is subject to BCP 78 and the IETF Trust's Legal
49	   Provisions Relating to IETF Documents
50	   (http://trustee.ietf.org/license-info) in effect on the date of
51	   publication of this document.  Please review these documents
52	   carefully, as they describe your rights and restrictions with respect
53	   to this document.  Code Components extracted from this document must
54	   include Simplified BSD License text as described in Section 4.e of
55	   the Trust Legal Provisions and are provided without warranty as
56	   described in the Simplified BSD License.

58	Table of Contents

60	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
61	   2.  Multiple LDP Instances . . . . . . . . . . . . . . . . . . . .  4
62	     2.1.  Procedures for multi-instance peering  . . . . . . . . . .  4
63	       2.1.1.  Case 1 . . . . . . . . . . . . . . . . . . . . . . . .  5
64	       2.1.2.  Case 2 . . . . . . . . . . . . . . . . . . . . . . . .  6
65	       2.1.3.  Case 3 . . . . . . . . . . . . . . . . . . . . . . . .  7
66	       2.1.4.  Case 4 . . . . . . . . . . . . . . . . . . . . . . . .  8
67	   3.  Detection of multi-instance peering  . . . . . . . . . . . . .  8
68	   4.  LDP Address Distribution with multi-instance peering . . . . .  9
69	   5.  LDP State Sharing between instances  . . . . . . . . . . . . .  9
70	   6.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  9
71	   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
72	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
73	   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
74	   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
75	     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
76	     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
77	   Appendix A.  An Appendix . . . . . . . . . . . . . . . . . . . . . 11
78	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

80	1.  Introduction

82	   The Multi-Protocol Label Switching (MPLS) architecture is described
83	   in [RFC3031].  Label Distribution Protocol (LDP) is a signaling
84	   protocol for setup and maintenance of MPLS LSPs (Label Switched
85	   Paths) and the protocol specification is defined in [RFC5036].

87	   Two Label Switched Routers (LSR) that use LDP to exchange label/FEC
88	   mapping information are known as "LDP Peers" with respect to that
89	   information, and we speak of there being an "LDP Session" between
90	   them.  A single LDP session allows each peer to learn the other's
91	   label mappings.  Each LSR is indentified by an LDP identifier.  An
92	   LDP Identifier is a six octet quantity used to identify an LSR label
93	   space.  The 4 octets identify the LSR and is a globally unique value,
94	   such as a 32-bit router Id assigned to the LSR.  The last two octets
95	   identify a specific label space within the LSR.  The last two octets
96	   of LDP Indentifers for platform-wide label spaces are always both
97	   zero.  This document uses the following representation for LDP
98	   Indentifiers:

100	   <LSR Id> : <label space id>

102	   e.g, lsr171:0, lsr19:2 etc

104	   As per [RFC5036] an LSR that manages and advertises multiple label
105	   spaces uses a different LDP Identifier for each such label space.
106	   This means for a single label space there can be only one router-id
107	   that is can be assigned to the node that exclusively owns that label
108	   space.  For example, it is not possible to have two LSRs like
109	   lsr100:0 and lsr200:0 to be created in the a single node.

111	   A LDP peering session between two LSRs may exchange labels for
112	   setting up LSPs that may belong to different FEC types.  Operators
113	   may need the flexiblity for fate separation of different FEC types in
114	   LDP protocol signaling when all such fec types share the same common
115	   label space.  This is not possible with the current paradigm of
116	   single peering session between two LSRs and it requires one session
117	   per fate separated group of FEC types to exchange labels.  Thus
118	   multiple LDP sessions are required between two peering nodes.  One
119	   example could be fate separation between IP transport network and the
120	   overlay network of Pseudowires (PW).  Procedures for PW set-up and
121	   maintenance using LDP are defined in [RFC4447].  It may be also
122	   desirable for fate separation IPv4 and IPv6 LSP set-up and
123	   maintenance in LDP in case of which two separate LDP sessions need to
124	   be formed between two peering nodes.

126	   Although [RFC5036] does not specify that the 4 byte router-id of the
127	   LDP identifier be routable IP addresses, for various operational
128	   simplicity implementations may map the 32 bit router-id to a IPv4
129	   address configured in the node which is routable.  In that way
130	   uniqueness of the 4 byte router-id can be achieved over a single
131	   routing domain.  Interior Gateway Protocols (IGPs) like OSPF provide
132	   the option of creation of multiple instances for segmentation of a
133	   network into multiple routing domains.  When LDP is deployed in such
134	   networks it is required to segment LDP network to align with multiple
135	   routing domains.  When a node is connected to multiple such domains,
136	   LDP peering sessions over all such domains cannot use a common IPv4
137	   router-id which is local to that node, since the IPv4 mapped
138	   router-id may not be routable across all such domains for security
139	   purposes.  There are applications such as BGP Autodiscovery of L2VPNs
140	   or Dynamic MS-PW set-up that may auto-instantiate Targeted LDP
141	   sessions where BGP IPv4 next-hop addresses for respective NLRIs are
142	   mapped to peer LDP identifiers.  Suc next-hop addresses may not be
143	   routable between two routing domains.Thus there is need to host
144	   multiple LSRs by a network node that shares the same label space but
145	   each with unique router-ids.

147	   This document describes a method to implement multiple instances of
148	   LDP in a network node that shares same label space.  The method is
149	   generic and is backward compatible with nodes that supports
150	   procedures defined in [RFC5036] but does not support the procedures
151	   defined in this document.  The procedures defined in this document
152	   would be referred as "Multi-Instance LDP".

154	2.  Multiple LDP Instances

156	   The solution defines the concept of implementing multiple LDP
157	   instances on a single network node that shares the single label space
158	   and thus shares the common data plane.  Each such LDP instance is
159	   identified by a unique 4 byte router-id but same label space.  Since
160	   the multi-instance procedures use same LDP Indentifer as defined in
161	   [RFC5036], it makes the node running multiple instances to be
162	   backward compatible with the node that support the multi-instance LDP
163	   procedures.

165	2.1.  Procedures for multi-instance peering

167	   When multiple LDP instances are set-up between two peering nodes for
168	   fate separation reasons then there can be various ways Hello
169	   adjacencies can be formed over the interfaces between the nodes.
170	   Further multi-instance peering for fate separation results in
171	   multiple parallel sessions between two peering nodes.

173	   While running parallel multi-instance LDP sessions between two
174	   peering nodes,
175	   1.  Each peering sesssion MUST use separate transport address.

177	   2.  The FEC label mappings exchanged over each peering session MUST
178	   be a disjoint set from one another.

180	   The above rules does not apply between multi-instance LDP sessions
181	   with different peering LDP nodes.

183	   This document describes the following cases and defines the rules and
184	   procedures with each case.

186	2.1.1.  Case 1

188	           Node - A                                    Node - B
189	       +-------------+                            +--------------+
190	       |   LSR-A1:0--|============IF 1============|---LSR-B1:0   |
191	       |           \ |                            | /            |
192	       |   LSR-A2:0  |============IF 2============|   LSR-B2:0   |
193	       +-------|-----+                            +-------|------+
194	               +---------------t-LDP Adj------------------+

196	                                   Figure 1.

198	   In this case the operator wants to separate the fate of FECs
199	   exchanged between the nodes into two separate groups - Group 1 and
200	   Group 2.  For example Group 1 can contain all transport specific FEC
201	   types such as IPV4 FEC Element Type and LDP Multi-point (MP) FEC
202	   types etc.  LDP Multi-point FEC types are described in [RFC6388] .
203	   Group 2 contains various Pseudowire (PW) FEC types.  PW setup and
204	   maintenance using LDP is described in [RFC4447].

206	   Two separate LSR-IDs are provisioned in each node - one LSR is
207	   dedicated for FEC Group 1 and another for FEC Group 2.

209	   There are two parallel interfaces between Node-A and Node-B as IF1
210	   and IF2 respectively.

212	   The traffic for LSPs set-up for FEC Group 1 may use both IF1 and IF2.
213	   Thus both IF1 and IF2 would exchange Hello Packets using LSR-A1:0 and
214	   LSR-A2:0 for setting up Hello adjacency for the LDP instance assigned
215	   for FEC Group 1.  The Hello messages exchanged over IF1 and IF2 MUST
216	   carry the LDP Adjacency Capabilities for each FEC Types in FEC Group
217	   1.  LDP Adjacency Capabilities are defined in [LDP-ADJ-CAP].  This
218	   would result in formation of a LDP session between Node A and Node B
219	   for the instance indentified by LSR-A1:0 and LSR-B1:0 respectively.
220	   The LDP session SHOULD be set-up with Capabilities of FEC Group 1.

222	   LDP session specific capability negotiation is described in [RFC5561]

224	   A Targeted LDP (t-LDP) hello adjacency would be formed between node A
225	   and node B using LSR-A2:0 and LSR-B2:0 respectively.  The t-Ldp Hello
226	   Messages exchanged between the nodes MUST carry the LDP Adjacency
227	   Capabilities for each FEC Types in FEC Group 2.  This would result in
228	   a LDP session between Node A and Node B for the instance identified
229	   by LSR-A2:0 and LSR-B2:0 respectively.  The LDP session SHOULD be
230	   set-up with capabilities of FEC Group 2.

232	2.1.2.  Case 2

234	          Node - A                                   Node - B
235	       +-------------+                           +--------------+
236	       |   LSR-A1:0--|===========IF 1============|---LSR-B1:0   |
237	       |           x |                           | x            |
238	       |   LSR-A2:0--|===========IF 2============|---LSR-B2:0   |
239	       |             |                           |              |
240	       |   LSR-A3:0  |---------t-LDP Adj---------|   LSR-B3:0   |
241	       +-------------+                           +--------------+

243	                                   Figure 2.

245	   This is a variant of case 1 where the operator may choose to further
246	   separate the fate of IPV4 FEC Element Type and MP FEC Element types
247	   into "Unicast" and "Multicast" Groups.  Thus there are three FEC
248	   Groups here and fate separation is required for all three FEC Groups.

250	   FEC Group 1 : IPv4 FEC Element Type.

252	   FEC Group 2: MP FEC Element Types.

254	   FEC Group 3: PW FEC Element Types.

256	   LDP Instance 1: The LDP instance with peering LSR-A1:0 and LSR-B1:0
257	   are assigned for FEC Group 1.

259	   LDP Instance 2: The LDP Instance with peering LSR-A2:0 and LSR-B2:0
260	   are assigned for FEC Group 2.

262	   LDP Instance 3: The LDP instance with peering LSR-A3:0 and LSR-B3:0
263	   are assigned for FEC Group 3.

265	   In this case, both IF1 and IF2 are associated with LDP instances 1
266	   and 2.  Each of IF1 and IF2 would originate two separate Hello
267	   Messages using the same source IP address, one Hello Message for each
268	   instance .  This would result in two hello adjacencies per interface
269	   - one for Instance 1 and Instance 2.  Each Hello Adjacncies SHOULD
270	   advertise capabilities using rules described in case 1.

272	   Such case may also arise when operator wants to do fate separation of
273	   IPV4 and IPV6 LDP based LSPs but IF1 and IF2 are single stack
274	   interfaces only - that is either IPV4 or IPV6.  Thus an operator may
275	   provision single stack interfaces IF1 and IF2 and yet can provision
276	   fate separation of IPV4 and IPV6 LSPs.

278	   The t-Ldp Hello Adjacency would be formed for LDP Instance 3 using
279	   the PW Capabilities.

281	2.1.3.  Case 3

283	           Node - A                                     Node - B
284	       +-------------+                              +--------------+
285	       |   LSR-A1:0--|============IF 1==============|---LSR-B1:0   |
286	       |           x |                              | x            |
287	       |   LSR-A2:0--|============IF 2==============|---LSR-B2:0   |
288	       |             |                              |              |
289	       +-------------+                              +--------------+

291	                                    Figure 3.

293	   This case a a variant of case 2 where, both interfaces IF1 and IF2
294	   are dual-stack (IPV4 and IPV6) interfaces and operator wants fate
295	   separation of IPV4 and IPV6 LSPs.  Without loss of generality,
296	   herebys IPv4 or IPV6 FECs may include all FEC types that are
297	   associated with IPV4 or IPV6.  For example,
298	   [I-D.ietf-mpls-mldp-in-band-signaling] defines several in-band MP FEC
299	   Types that may be classified into IPV6.

301	   LDP Instance 1: The LDP instance with peering LSR-A1:0 and LSR-B1:0
302	   are assigned for IPV4 FEC Types.

304	   LDP Instance 2: The LDP Instance with peering LSR-A2:0 and LSR-B2:0
305	   are assigned for IPV6 FEC Types.

307	   Both the interfaces IF1 and IF2 are associated with each of the LDP
308	   instances 1 and 2 respectively.  Here the operator may choose to use
309	   IPv4 addresses on the interfaces for sending Hello Messages for
310	   Instance 1 and IPv6 addresses on the interfaces for sending Hello
311	   Messages for Instance 2.

313	2.1.4.  Case 4

315	   This case is variant of case 3 where inteface IF1 is dedicated for
316	   IPV4 LSP Types and IF2 is dedicated for IPV6 LSP Types.  This
317	   provides fate-separation of both control plane and data plane for LSP
318	   types.

320	3.  Detection of multi-instance peering

322	   While running parallel multi-instance LDP sessions between two
323	   peering nodes, it is important to detect that such sessions with the
324	   same peer node.  If a node receives the same FEC label maping from
325	   parallel multi-lsr peering sessions it may result in a loop for some
326	   applications.  An example of such application can be LDP based
327	   Virtual Private LAN Service (VPLS)described [RFC4762].  So it is
328	   important to detect and prevent such loops.

330	   This document defines a new LDP Node-ID TLV that uniquely indentifies
331	   the node that hosts multiple LDP instances.  The LDP Node ID TLV is
332	   OPTIONAL and is carried in LDP Hello Messages sent out by the node in
333	   its Optional Parameters.  The encoding of the LDP Node ID TLV is as
334	   follows:

336	        0                   1                   2                   3
337	        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
338	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
339	       |1|0| Node ID Tlv (TBD)         |            Length (6)         |
340	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
341	       |                             Value                             |
342	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
343	       |        Value (contd)          |
344	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345	                                     Figure 4

347	   The Value field is a 48 bit identifier and MUST be unique identifer
348	   across the network.

350	   1.  All the multi-instance LDP LSRs MUST advertise the same LDP
351	   Node-ID TLV in all Hello Messages originated by that node.  One
352	   example of the value can be a IEEE Vendor specific MAC Address that
353	   can uniquely indentify a node in the network.

355	   2.  When a LSR receives a FEC label mapping from a peering session
356	   but same FEC mapping has been already receiver over another peering
357	   session associated with same Node-ID then the receiving LSR MUST send
358	   a Label Release to the peering session with statuc code
359	   LOOP_DETECTED.

361	4.  LDP Address Distribution with multi-instance peering

363	   An LSR maintains learned labels in a Label Information Base (LIB).
364	   When operating in Downstream Unsolicited mode, the LIB entry for an
365	   address prefix associates a collection of (LDP Identifier, label)
366	   pairs with the prefix, one such pair for each peer advertising a
367	   label for the prefix.  When the next hop for a prefix changes, the
368	   LSR retrieves the label advertised by the new next hop from the LIB
369	   for use in forwarding.  To retrieve the label, the LSR should be able
370	   to map the next hop address for the prefix to an LDP Identifier.
371	   Similarly, when the LSR learns a label for a prefix from an LDP peer,
372	   it should be able to determine whether that peer is currently a next
373	   hop for the prefix to determine whether it needs to start using the
374	   newly learned label when forwarding packets that match the prefix.
375	   To make that decision, the LSR should be able to map an LDP
376	   Identifier to the peer's addresses to check whether any are a next
377	   hop for the prefix.  To enable LSRs to map between a peer LDP
378	   Identifier and the peer's addresses, LSRs advertise their addresses
379	   using LDP Address and Withdraw Address messages as per procedures
380	   defined in [RFC5036]

382	   However while running multi-instance LDP peering between two nodes,
383	   it is possible that all such sessions would distribute same set of
384	   local addresses in each node.  An implementation MAY segregate the
385	   local address space in each node among the multiple ldp instances to
386	   avoid duplication of address distribution.

388	5.  LDP State Sharing between instances

390	   TBD.

392	6.  Applicability

394	   This solution described in this document is applicable for multi-
395	   instance LDP sessions for fate separation as well as for segmentation
396	   of LDP network domains.  More details would be covered in next
397	   revisions of the document.

399	7.  IANA Considerations

401	   This document requests the following code points:

403	   - LDP Node-ID TLV type.

405	   Note to RFC Editor: this section may be removed on publication as an
406	   RFC.

408	8.  Security Considerations

410	   [I-D.ietf-mpls-mpls-and-gmpls-security-framework] describes the
411	   security framework for MPLS networks. whereas [RFC5036] describes the
412	   security considerations that apply to the base LDP specification.
413	   The same security framework and considerations apply to the
414	   capability mechansim described in this document.

416	9.  Acknowledgements

418	   The authors would like to thank Wim Henderickx for insightful
419	   comments and probing questions.

421	10.  References

423	10.1.  Normative References

425	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
426	              Requirement Levels", BCP 14, RFC 2119, March 1997.

428	   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
429	              Label Switching Architecture", RFC 3031, January 2001.

431	   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
432	              Specification", RFC 5036, October 2007.

434	   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
435	              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

437	   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
438	              "Label Distribution Protocol Extensions for Point-to-
439	              Multipoint and Multipoint-to-Multipoint Label Switched
440	              Paths", RFC 6388, November 2011.

442	10.2.  Informative References

444	   [I-D.ietf-mpls-mldp-in-band-signaling]
445	              Wijnands, I., Eckert, T., Leymann, N., and M. Napierala,
446	              "Multipoint LDP in-band signaling for Point-to-Multipoint
447	              and Multipoint- to-Multipoint Label Switched Paths",
448	              draft-ietf-mpls-mldp-in-band-signaling-05 (work in
449	              progress), December 2011.

451	   [I-D.ietf-mpls-mpls-and-gmpls-security-framework]
452	              Fang, L. and M. Behringer, "Security Framework for MPLS
453	              and GMPLS Networks",
454	              draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work
455	              in progress), March 2010.

457	   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
458	              Heron, "Pseudowire Setup and Maintenance Using the Label
459	              Distribution Protocol (LDP)", RFC 4447, April 2006.

461	   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
462	              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
463	              RFC 4762, January 2007.

465	Appendix A.  An Appendix

467	Authors' Addresses

469	   Pranjal Kumar Dutta
470	   Alcatel-Lucent
471	   701 E Middlefield Road
472	   Mountain View, California  94043
473	   USA

475	   Phone:
476	   Fax:
477	   Email: pranjal.dutta@alcatel-lucent.com

479	   Mustapha Aissaoui
480	   Alcatel-Lucent
481	   600 May Road
482	   Kanata, ON
483	   Canada

485	   Phone:
486	   Fax:
487	   Email: mustapha.aissaoui@alcatel-lucent.com
488	   URI: