Subject: MPLS WG Minutes

From: George Swallow <[email-masked]>
Date: Fri, 19 Dec 2003 16:34:34 -0500

MPLS Working Group

WG Chairs:  George Swallow <[email-masked]>, 
            Loa Andersson <[email-masked]>

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 Concludes