Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)

From: jason rusmisel <[email-masked]>
Date: Mon, 10 Nov 2003 12:16:25 -0500

A question for you:

If I understand correctly, the motivation for this draft is to allow LDP 
to be the single mechanism to distribute reachability rather than 
counting on a 2547bis-like mechanism.
The overall approach of carrying the External FEC in the FEC TLV 
guarantees that these label mappings will not be propagated in a network 
of mixed LDP implementations.  Have you considered this situation? 

Jason Rusmisel.

Ina Minei wrote:

>   This document describes a mechanism that allows the creation of LDP
>signaled LSPs for prefixes which are not present in the routing table.
>
>   Comments welcome,
>
>		Thank you,
>
>			Ina Minei
>
>---------- Forwarded message ----------
>Date: 7 Oct 03 15:00:15 GMT
>From: [email-masked]
>To: IETF-Announce:  ;
>Newsgroups: jnx.ext.ietf.announce
>Subject: I-D ACTION:draft-minei-mpls-ldp-external-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: LDP signaled LSPs for external prefixes
>	Author(s)	: L. Fang, et. al.
>	Filename	: draft-minei-mpls-ldp-external-00.txt
>	Pages		: 6
>	Date		: 2003-10-7
>
>In order to create forwarding state for a FEC received from a downstream
>LSR, LDP requires the presence of a matching entry in the routing table.
>This document describes a mechanism that allows the creation of LDP
>signaled LSPs for prefixes which are not present in the routing table.
>This draft is applicable to address prefix FECs and host FECs associated
>with either IPv4 or IPv6 prefixes.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-external-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-minei-mpls-ldp-external-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-minei-mpls-ldp-external-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>

---

From: Ina Minei <[email-masked]>
Date: Mon, 10 Nov 2003 12:12:27 -0800 (PST)

Please see answers innline, marked ###.

                          Thank you,

                                  Ina

> counting on a 2547bis-like mechanism.

### The motivation for this draft is to allow establishment of LDP
signaled LSPs without having to inject routes for them in the IGP.
The 2547bit scenario is an example of using the proposed extension.

> of mixed LDP implementations.  Have you considered this situation?

### In a mixed network, LSPs for external FECs will be established only
through nodes that support this functionality, thus ensuring consistent
establishment of the LSPs. Note that since we don't have routing table
entries for these FECs, nodes not supporting the extension would not
propagate mappings for them anyway.

---

From: Luca Martini <[email-masked]>
Date: Mon, 10 Nov 2003 19:56:57 -0700

so what is wrong with using the IBGP, and 3 label MPLS stack , while 
leaving LDP out of the routing business ?

Luca

---

From: Ina Minei <[email-masked]>
Date: Tue, 11 Nov 2003 06:38:11 -0800 (PST)

There is nothing wrong in that. The mechanism described in the
draft is a general mechnism, the vpn scenario is a usage example.

				Thank you,

					Ina

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 11 Nov 2003 08:10:33 -0800

There is a technique which avoids external routes altogether.  The basic
technique is to run IBGP between PE routers only, to do your normal
application of policy, costing, route selection, etc. that BGP gives
you.  Once you pick the BGP next hop that is the best route, you
normally turn to your IGP to get to the BGP next hop.  Instead, what you
do is that you figure out the LDP path to that BGP next hop, and tunnel
the IP packet there.  For want of a better term, let's call this the BGP
shortcuts method.

So there are several issues I'd like you to address, with ref to the
IBGP mesh-avoidance technique:

1. is it less costly?
   - your solution requires all external routes in the LDP database
   - the BGP shortcuts method does not

2. is it more "correct"?
   - since your normal approach to dealing with external routes is to
apply BGP route selection, by sending the external route via LDP without
the BGP attributes, you aren't quite doing what you used to, when you
used IBGP.  I'd suggest that there should be an opaque TLV that carries
BGP attributes so the PEs can do similar route selection.

3. does it converge faster?
   - I highly doubt it: you potentially have BGP, IGP and LDP that need
to converge

So, Luca, could you please resurrect your draft, and let's have some
discussions focussed around that solution?

-Vach 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ina Minei
> Sent: Tuesday, November 11, 2003 6:38 AM
> To: Luca Martini
> Cc: jason rusmisel; [email-masked]
> Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
> 
> 
> 
> 	There is nothing wrong in that. The mechanism described 
> in the draft is a general mechnism, the vpn scenario is a 
> usage example.
> 
> 				Thank you,
> 
> 					Ina
>