Subject: RE: MPLS Architecture Issue

From: Adrian Farrel <[email-masked]>
Date: Fri, 23 Jun 2000 02:08:48 +0100

Sorry,

Playing catch-up and my previous mail on this subject lags behind the
discussion...

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:[email-masked]
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:[email-masked]]
>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:[email-masked]]
>> 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
>> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 23 Jun 2000 13:39:21 -0400

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