The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

         Hi,

         Whenever a standards track document is available
which thoroughly outlines (not just alludes to) how
bi-directional tunnels are defined for MPLS, we will
add support for such a mechanism at that time. Our
mandate from the MPLS working group is to produce
a MIB which reflects the currently defined standards
for MPLS Traffic Engineering.

         --Tom


>The bi-directionality in draft-lang-mpls-rsvp-oxc provides a good model for
>bi-directional LSPs in optical and non-optical networks.
>In a network built on ATM hardware it is also necessary to know whether the
>full bi-directionality of the switching will be used since it is often
>possible to reserve resources in such hardware in a uni-directional sense.
>Such function will also require an extension to the signaling protocol (or
>carnal knowledge amongst the switches) and draft-lang-mpls-rsvp-oxc could
>provide such a mechanism (although is perhaps heavy handed for this use).





>Adrian
>--
>Adrian Farrel  mailto:af@datcon.co.uk
>Network Convergence Group
>Data Connection Ltd., Chester, UK
>http://www.datcon.co.uk/
>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>
>
> >-----Original Message-----
> >From: Jonathan Lang [mailto:jplang@calient.net]
> >Sent: Thursday, June 22, 2000 11:07 PM
> >To: 'Eric Gray'; Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric
> >Rosen'
> >Cc: Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> >Subject: RE: MPLS Architecture Issue
> >
> >
> >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
> >>
> >