The MPLS WG Archive

[Jonathan Lang <jplang@calient.net>]

Eric,

There were two drafts presented at the last meeting in Adelaide that
proposed bi-directional LSPs (draft-lang-mpls-rsvp-oxc-00.txt and
draft-saha-rsvp-optical-signaling-00.txt).  These were primarily a result of
optical constraints, but there is no reason they couldn't be used for
regular LSPs.

Jonathan

Calient Networks                     

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Thursday, June 22, 2000 1:46 PM
> To: Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen'
> Cc: Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> Subject: MPLS Architecture Issue
> 
> 
> Eric (et al),
> 
>     Tom earlier made the point that none of the
> MPLS drafts appear to introduce - let alone 
> discuss or specify - the notion of bi-directional
> association of LSPs.  There is the notion of use
> of Labels under circumstances in which specific
> hardware uses "labels" (VPI/VCI, and possibly
> DLCI, values) in both directions, but this is not
> the same thing.
> 
>     In an off-line discussion, we talked about the
> fact that the TE Requirements RFC (RFC2702) talks 
> about the idea of bi-directional traffic trunks.  
> It describes behaviors which might be hard for an 
> NMS to model without being able to determine that 
> an LSP-pair is used as a bidirectional LSP tunnel.
> But it is "only" an informational RFC.
> 
> 	The Framework draft briefly mentions use of
> bi-directional LSPs as a possible solution to error
> reporting problems, but - as far as I know - none
> of the current set of "standards track" MPLS drafts
> addresses the concept of pairing of LSPs to form a
> bi-directional tunnel or trunk.
> 
> 	Is it possible to add this to the Architecture
> at this point, do we need to create a standards track
> draft specifically for this purpose or is it enough 
> to simply add appropriate "stuff" to the TE-MIB based
> on the informational RFC?
> 
> --
> Eric Gray
>