The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	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

On Mon, 10 Nov 2003, Luca Martini wrote:

> so what is wrong with using the IBGP, and 3 label MPLS stack , while
> leaving LDP out of the routing business ?
>
> Luca
>
> Ina Minei wrote:
>
> >      Please see answers innline, marked ###.
> >
> >                          Thank you,
> >
> >                                  Ina
> >
> >On Mon, 10 Nov 2003, jason rusmisel wrote:
> >
> >
> >
> >>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 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.
> >
> >
> >
> >>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?
> >>
> >>
> >>
> >
> >### 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.
> >
> > > 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: Internet-Drafts@ietf.org
> >>>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:
> >>>	mailserv@ietf.org.
> >>>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.
> >>>
> >>>
> >>>
> >
> >
> >
>
>