The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Apr> msg00061



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

Draft MPLS minutes

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Thu, 03 Apr 2003 10:03:22 -0500
  • Cc: mpls@UU.NET

At 05:01 PM 4/2/2003 -0800, Rahul Aggarwal wrote:

>Hi George,
>
>A few comments inline:
>
>[snipped]
>
>On Fri, 28 Mar 2003, George Swallow wrote:
>
> > MPLS Working Group
> >
> > WG Chairs: George Swallow <swallow@cisco.com>, Loa Andersson
> > <loa.andersson@utfors.se>
> >
> > George chaired the meeting.  Andy Malis took the minutes.
> > (Thanks Andy!)
> >
> >
> > Reoptimization of explicit loosely routed MPLS TE paths
><>
>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt
> > Jean-Philippe Vasseur, jpv@cisco.com
> >
> >
> > Rahul Aggarwal suggested an improvement in one of the mechanisms in
> > the draft to simply the operation in some situations.  JP agreed with
> > the suggestion.
>
>More specifically the suggestion was that the head-end can attempt a
>re-optimization using make before break without first triggering a
>re-evaluation. Hence the steps : a)head end triggers re-evaluation b)
>loose hops signals to head end that it has a better path c) head end
>performs make before break can be simplified to a) head end triggers make
>before break.
>
>As JP mentioned there are pros and cons to both approaches.
>
> >
> > Rahul said that there is a lot of value in LSP-PING in L3 VPNs.
> > Kireeti said that just IP ping works fine for this application.  Rahul
> > talked about why LSP-PING is valuable in this situation.  George said
> > that a good place to discuss this issue is in the framework document
> > (which doesn't exist) or in the requirements document.  George is
> > going to propose in the sub-IP meeting that such a document be
> > developed in this WG.
> >
>
>The comment was that for L3 VPNs an IP ping still has lot of value and if
>that fails, LSP ping could be used. This should be specified somewhere and
>George talked about the framework document..

         I think it was an OAM framework document to
be precise.

         --Tom



> > 6.  Explicitly routed Multicast
> >
> > Requirements for Point-to-Multipoint capability extension
> >
>http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt
>
> >Seisho Yasukawa, yasukawa.seisho@lab.ntt.co.jp
>
>I made a comment that it is possible to come up with a P2MP TE LSP set up
>approach that can be used by different applications. MPLS WG should only
>specify the P2MP TE LSP setup. Applications (multicast etc) will have
>to specify how this is used, in other WGs.
>
>regards,
>rahul
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X