The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi George,

One comment inline:

On Fri, 19 Dec 2003, George Swallow wrote:

> 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?
>

More specifically I had asked why is it not enough to use the RRO.

thanks,
rahul

>   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
>
>
>
>
>
>
>
>