MPLS Working Group

 WG Chairs:  George Swallow <swallow@cisco.com>,    Loa Andersson 
<loa@pi.se>

 Tom Nadeau took the minutes - Thanks Tom!   NOTE: [NNG] means that the 
speakers name was not given at the mike.



1.  Agenda Bashing/Update      

   Loa  -- MPLS has been rechartered within routing area.  MIB 
modules/management overview have been sent to the IESG.



2.  Encoding of Attributes for LSP Establishment Using RSVP-TE        

<draft-farrel-mpls-rsvpte-attributes-00.txt>       Adrian Farrel

   Adrian -- Asked to make this a WG document?   George -- Room 
support? (no hands) non-support (no hands) Continue discussion on the 
list.



3.  RSVP Graceful Restart Extension        

<draft-rahman-rsvp-restart-extensions-00.txt>
      Reshad Rahman

   Adrian Farrel -- Should this be in CCAMP?

   George -- They didn't ask me, but I suggest it goes in CCAMP. The only 
rationale for MPLS might be that there is slightly lower work load here.

   Rahul -- Why isn't it enough to just recover. Why do we need this?

   Reshad -- If a node preforms ERO expansion prior to the restart, it may 
not have sufficient information to construct the some ERO expansion.

   After a bit of discussion and polling the room, it would appear that   
there is a fair amount of interest and that the work belongs in   CCAMP.



4.  TTL-Based Security Option for LDP Hello Message        
<draft-chen-ldp-ttl-00.txt>
     Albert Tian

   Alex Zinin -- You cannot negotiate security messages with an 
insecure mechanism. There are DOS attack potentials.

   Albert -- The multicast addresses are harder to spoof.

   Alex -- I understand how the TTL hack works. But the fact that you are 
trying to negotiate the usage using insecure messages is the problem.

   Albert -- "secure" is relative here.

   Alex -- Take to list.

   George -- are there any SPs that feel there is a need for this? 
(silence)



5.  LDP signaled LSPs for external prefixes        
<draft-minei-mpls-ldp-external-00.txt>
      Ina Minei

   Eric -- I see no advantage to do this. Dangerous to distribute 
routing information w/ non-routing protocols.  

   Yakov -- We have seen this movie before. There are no issues with 
overloading LDP.

   Luca -- You are adding more state to your core routers to support this. 
Why not use iBGP to do this?

   George -- Asked a question about label withdraw times in the event of a 
failue.  Won't that slow convergence?  

   Alex -- If you have more than one originator injecting more than one 
FEC, how do you break the tie?  

   Ina  -- You consider this and do something smarter at the tail end.        
 
   Alex -- External prefixes are injected into LDP. Have you compared the 
overhead of this versus that of using IGPs?  

   Ina  -- don't see why this is an issue.  

   Alex -- This assumes external prefixes are injected into an IGP.  How 
much state will routers have to maintain versus in the normal ibgp case.  

   Ina  -- If you are trying to compare an IGP to an LDP solution.  

   Luca -- Clarification. In an IBGP you don't have to run this 
anywhere but in the edge routers (BGP free core).  There is less state in 
the core. Using your solution you add more state to the core.  

   Ina  -- but it has more danger of misconfiguring your 
distribution.        
 
   Vach -- Best for Luca to resubmit his BGP short-cuts draft which would 
fix this problem.  If I wanted such a solution I would rather do this than 
the current one.  

   George -- Continue this on the list.        
 
 

 6.  Requirements for Point to Multipoint extension to RSVP-TE        

<draft-yasukawa-mpls-p2mp-requirement-00.txt>        
      Seisho Yasukawa

   Loa  -- Comments?

   Yiqun Cai -- ID is taqlking about requirement of P2MP lsps (TE), but 
also describes an extension to RSVP-TE. This seems that the WG has 
already decided to extend RSVP_TE. The better way would be to split them, 
and address both requirements separately. Second, this talks about mcast 
deployment in a service provider environment. I think this needs to be 
presented in the MWG and discussed.

   Dave Meyer -- I had discussed this with George, but ran out of agenda 
time. This should be discussedin MWG.

   James Miles -- Dmitri's earlier point talked about whether this was a 
requirements document? Are we going to extend this? What is the scope of the 
document? Seems that the next step is that providers need to run RSVP-Te to 
the edge.

   Loa  -- When we wrote this it was to describe how p2mp TE LSPs 
worked. 

   Loa  -- Could I see the support in the room to make this a WG 
document. A fiar number.  Oppositoion. A few.  Need to confirm on the list 
that there is good support w/ a few opposing.  People that were opposed 
should speak at the Mike.

   Toerless -- I don't understand how this framework is supposed to work.   
The document seems to jump over one architectural element (p2mp).  

   Yiqun -- The document tries to address mcast vpn and other items. We 
need to discuss whether or not this best solves this problem usiung p2mp 
RSVP-TE LSPs or something else.

   George -- I would tend to agree with that last comment.



7.  Extended RSVP-TE for Point-to-Multipoint LSP Tunnels        
<draft-yasukawa-mpls-rsvp-p2mp-03.txt>
     Seisho Yasukawa/Allan Killberg

   [Update on state of draft]

   George -- Can't do anything on this on the next draft until we get        
 
the requirments accepted.



8.  IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core        
<draft-raggarwa-pim-sm-mpls-te-00.txt>
       Rahul Aggarawal

   George -- When the RPE gets an indication of the interface, how does  
that count?

   Rahul -- The SPE sends a joint ack message.

   George -- what goes into it?

   Rahul -- it contains a set of messages including the PTMP ids.

   George --- you are keeping labels at the last hop to keep context?

   Rahul -- this is just the session object.

   George -- If you have more than one tunnel, you would have to turn PHP 
off.

   [NNG] -- Are the labels interface or global space?

   Rahul -- doesn't matter. 

   [NNG]   -- The way you use labels to distinguish label states.  Does 
this support PIMSM, but you did not describe how these are forwarded.

   Rahul -- Sure, I can add that.

   George -- Please show up at 1 to continue discussion (PIM?)



9.  Requirements for multicast service using a group label over MPLS        

<draft-choi-mpls-grouplabel-requirement-01.txt>        
     Min Suk Sung

   George -- Discussion on the draft...       Andy Malis -- When we 
sections 4.5, this is not a requirements draft; it contains protocol 
specifications.  There are requirements in section 4.3, but these assume a 
mechanism (group label) and just reverse engineer that.  Really doesn't 
talk about requirements.  

   George -- Other point that Loa made is that originally when we 
started MPLS, we made an architectural decision to not have globally 
unique labels. We would need to change this to accomodate this draft.

   Min  -- We tried to consider where is the relevant location of the 
labels.  

   George -- Continue on list.



10. MPLS over Layer 2 Tunneling Protocol (Version 3)        
<draft-townsley-l2tpv3-mpls-00.txt>        
      Mark Townsley

   Yakov -- One significant subtle distinction between GRE and L2TP. 
Neither IP or GRE require signaling, but L2TP requires signaling. Don't 
combine into two documents.

   Loa  -- I rule that out betcause we have IP/GRE document in WG last 
call.

   Yakov -- To have a multi-vendor interop implementation requires  
specification of both signaling and protocol in standards track at same 
time.

   Mark -- Both are specified in two documents in IDR.

   Yakov -- They are not WG documents. If you want to provide BGP as a 
signaling mechanism for L2TPvp3.

   Mark -- There is a section on this. Please read the document.

   Yakov -- In this case, 2547 is just an example of p2mp signaling (so is 
VPLS). When you do this, so should signaling be done in BGP?

   Mark -- Depends on what your VPLS network is using for signling. In 
general when you want to reach a PE over IP and you say "this is the IP 
addr of my PE" and you use BGP or wahthave you to signal this, even w/o 
L2TPv3 encap, when you advertise this normally -- you imply use this PE IP 
address w/ this protocol ID.  I am also saying to also use the cookie in 
addition to these things.

   Yakov -- Need another document ot explain that BGP can be used for 
signaling.  On your last point: talk about security that L2TP 
provides.  Before this is a WG document, the security team should review 
this to make sure that the statements are ok.

   Eric -- I would like a very small document that explained the encap. Put 
cookie stuff into security considerations.  I disagree w/ Yakov's 
statement. The cookie value is different depending on how it is 
signaled. We don't want to start an L2TP signaling paradigm.

   Yakov -- this document doesn't have to contain signaling. doesn't make 
sense to progress encap w/ signaling document.

   Eric -- Signaling is application dependent.

   George -- Get a sense of the room, not for this draft, but for 
MPLS/L2TP as an encap type. How many think we need to do this.  We have 
several opposed and several in favor. Continue on list.



11. A Framework for MPLS Data Plane OAM
<draft-allan-mpls-oam-frmwk-05.txt>
      Don Fedyk



  Eric Rosen -- This is taking MPLS and trying to make it ATM.  I 
recommend starting over.

   Tom  -- I agree w/ Eric.   Lets start over.

   George -- I don't think that we need to throw away everything, but we 
should be focusing on describing a framework within which we can define 
tools that meet operational requirements.

   Loa  -- This is why I wanted Dave/Tom to do the edits.

   Jerry -- I think the document covers the entire solution space.

   Craig White -- I would like to underscore what the chairs just said. I am 
not particularly interested in where the technology comes from, but more of 
what does it do for me. I feel like we are going to end up with hacks to 
address requirements, but lets document this somewhere.

   Loa will work to form a design team to create a combined draft   
between this and the nadeau draft.



12. Detecting MPLS Data Plane Failures        
<draft-ietf-mpls-lsp-ping-04.txt>
      Kireeti Kompella / George Swallow

   Kireeti -- Reviewed latest changes.  Draft is nearly complete.  A new 
version will be posted resolving the last few issues. Hope to go to last 
call prior to Seoul



13. LSR Self Test        
<draft-ietf-mpls-lsr-self-test-01.txt>
     George Swallow

   George -- The draft is mostly complete.  A few issues are hanging 
contigent on the lsp ping draft.  More discussion on list.  

 14. BFD For MPLS LSPs        
<draft-raggarwa-mpls-bfd-00.txt>
     Rahul Aggarawal

   Rahul -- Since BFD is light weight, you can turn on 
fault-detection on a larger number of LSPs.  Subsecond fault detection can be 
possible (i.e.: bypass LSPs).

   Alex -- Did you think through the convergence issues w/ subsecond 
detection and IGP level second-level detection? How are you going to react to 
the failures found by BFD. 



  Rahul -- The answer is the same as with LSP ping.  The operator can take 
the same action.


  Alex -- We need to think throught the case where IGPs are notified.


  Yakov -- One possible scenario. When bypass tunnels go away, you can use 
the other one.


  [NNG] -- Since you are doing this over multiple hops. How do you handle 
congestion in the network and variable delays?


  George -- BFD allows you to adjust your timers.  Lets continue on list.



15. A Supplementary History Module for the MPLS LDP-MIB     
<draft-lai-mpls-ldp-hist-mib-00.txt>                  
    Wai Sum Lai


  Tom  -- There have been scalability and other technical concerns raised on 
the list. I suggest that we hear from other SPs.


  Waisum -- Can you give an example?


  Tom  -- PE with 800 directed LDP sessions. That seems to be a lot of 
memory/processing to keep track of this, especially over a long period of 
time.


  Waisum -- But we are only adding 5 counters.


  George -- Well, there is more to it than just 5 counters. You are 
asking us to hold informations forever on expired sessions. The long term 
implications for memory and CPU need to be considered.


  Craig White -- I would rather count packets/bytes than fwd packets. 
However, I don't want to eat all of the memory to do this. I don't want to 
have fewer VRFs on a PE to keep track of this stuff, for example.


  Bert -- If you want to look at the scalability of keeping the 
information needs to be seriously examined.


  George -- The sense of the room is that something along these lines is 
useful, but we need to refine the requirements on the list.



16. Hybrid data forwarding for Economy Class Services in MPLS   
<draft-hpark-hybrid-forwarding-00.txt>     
      Hyeon Park 


  George - We're out of time - discuss on the list.



Meeting