The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00029



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Luca Martini <lmartini@cisco.com>
  • Date: Mon, 10 Nov 2003 19:56:57 -0700
  • CC: jason rusmisel <jason.rusmisel@alcatel.com>, mpls@UU.NET
  • Organization: Cisco Systems
  • User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721
  • X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)

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.
>>>
>>>      
>>>
>
>  
>