The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS WG Minutes
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 Concludes
|
|