Subject: MPLS WG Meeting Minutes

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2001 18:47:17 -0500

MPLS WG Meeting Thursday, March 22, 2001

Agenda Bashing

George provided document status on existing documents which are in last call.

Mpls-bgp4-mpls-05: Not sure what the current state is.

Applicability statement for extensions to rsvp for lsp-tunnels: some minor 
edits needed.

Rsvp-te extensions to rsvp for lsp tunnels

LDP “boxed” set: Needs some editorial changes. Eric Gray needs to do some 
editing.

MPLS-LSR/LDP MIB are currently working on IESG changes. Another round of 
last call probably not required.

MPLS DiffServ Update: Francois L. provided an update. Last call finished in 
diffServ WG. Mostly minor comments to fix. Re-issue a final version which 
gets sent over to the IESG. Who to hand it over to? Rob Coltun: Hand it 
over to Scott/Bert.

Framework for IP Multicast in MPLS: read for IESG last call.

Generalized MPLS Signaling drafts: join last call with CCAMP. Updated by 
Kireeti. There were a few changes in CCAMP. Lou Berger needs to make a few 
changes. Some changes to spin Sonet documents off into another document, 
and will then be ready to go to last call. This is related to the TSPEC for 
Sonet. George, should we go to last call? No hands opposed. Consensus to 
send to last call.

Framework for multicast recovery. Authors feel it is ready to go to wg last 
call.

Unnumbered, Bundle, Hierarchy documents will remain as wg drafts in MPLS.

Accept draft-kompella-mpls-undle-05.txt as working group draft. Modify the 
draft slightly as draft-mpls-bundle-00.txt. Draft will then go to wg last 
call. None opposed; consensus.

Kellstrand  MPLS recovery framework --  draft-ietf-mpls-recovery-framework

Gave update on progress of document. This document was presented to TE WG. 
Many comments received on this document. Minor changes were required 
(editorial). Updated WG on current updates to the document.  Outlined 
recovery principles: initiation of the recovery path setup: 
pre-established, prequalified, established-on-demand.  Recovery principles 
covered.  Asked to send to WG last call and move it to
an informational RFC. No questions from crowd.

George asked Ads to move this forward to wg last call.

Scott wants to wait until TE wg design teams return their results before we 
bring this to wg last call, but doesn’t want to hold the document.

Kellstrand noted that this document was on hold for 2 meetings, and wants 
to move forward with bringing it to last call.

Will send out on TE WG mailing list and ask for comments.

George: TE WG design teams can use this document for their work.

Question A:  Are there any performance benchmarks provided for recovery or 
should this be somewhere in the requrirements?

Kellstrand: No, there are no benchmarking in draft.

Question A: Performance benchmarks need to be added.

George: This document contains things in a much higher level than this.

Curtis:  This document is a little too complete. This document is useful 
regardless and advanced anyway while the TE wg can progress with its own work.

George: This document is really a taxonomy.

Scott: There might be a taxonomy, but the te wg might want to use it.

Kellstrand: we can include additional minor changes during last call.

Curtis: Rename as “taxonomy”?

Scott: Wants to take a sense of the room, and then get comments from the 
mailing list for last call, but still wants te design team to make sure 
that they don’t want to add to it. Don’t want to wait for more than a month.

George: Any objections on moving to last call within a month? None were voiced.

Swallow  MPLS Resilience

Objective is to do FRR in MPLS to allow for temporary routing around a 
failed link or node while the head-end is reoptimizing the lsp. Rerouting 
under 50ms. Scalable. Allows for sonnet-speed recovery times. Two 
mechanisms provided in draft: use rsvp to signal backup paths, or a 
frame-based switch using the global label space can simply record labels in 
the rro. Although linkstate changes may be the primary means of adding need 
to notify the head end.

Draft available for the past 1.5 years. It is purely informational; doesn’t 
propose anything new. Would like to publish as a wg informational draft.

Scott (as chair): Is there support in the room for this. No objections.

Question A: Does not see quite how it works if wanting to route around a 
few hops versus routing around a few links.

George: The assumption is that you set up a tunnel to the hop around the 
one being protected.

Q A: No, the outer tunnel needs to use one of the outer tunnels  to get around?

George: Lets take it offline and I will explain the details.

Q B: If the tunnel follows the green tunnel, then the RSVP object is set to 
this object.

George: Explains how messages are sent.

Q B: Two path messages are sent?

George: Yes, two path messages are sent.

Q B: More clarification requested…

George: Lets take it offline.

Q C: There are two objectives: 50ms + large numbers of LSPs backed up. How 
are these both achieved.

George: All information is in each router at the time of failure. 
Scalability by allowing many tunnels allowed to be backed up by a single 
tunnel.

Scott: Confusion needs to be set up. Support seems to be there. Bert and I 
will take a look at the draft.

Matthews  LDP Fault Tollerance  draft-ietf-mpls-ldp-ft-01.txt

Summarized draft. Discussed changes between last version and current 
version. Expect to ask for wg last call soon. Requested comments now or via 
mailing list.

George: Consensus to put this draft to a wg last call. Luca Martini opposes 
wg last call; no other objections.

Luca: Since ldp is not a controlling protocol, why bother making it fault 
tolerant?

Matthews: Enhance software upgrades and you don’t want to disrupt the LSPs 
that are running over the network.

Luca: But other protocols need to be made redundant too.

Matt: OSPF etc… are being made fault tolerant. We stole this proposal from IDR.

George: Last call to be issued.

Scott: Shouldn’t we wait until the work on the routing protocols is 
finished before we finish this up?

George: The idea is for this state to be useful, this work needs to be 
done. The state of this protocol needs to be done, and can be done in parallel.

Scott: Should we serialize them?

George: There is no hardm.

Curtis: There was some work in OSPF that helped quicken the detection of 
faults in the database. Prevents premature changes in database. Are those 
applicable to this draft?

Matt: That is true. This is useful by itself because you can use this to 
upgrade your LDP software. For OSPF it is not clear how this will work.

Curtis: A router is loading software takes a long time relative to changes 
in the routing protocol. The static tables in hardware should be okay. If 
there are changes in the network, then there can be problems.

Matt: I don’t see this being used this way. If you use hot standby 
hardware, then there is no disruption. You need to sift information across 
between cards. It is easier to do at the ldp level than at the tcp level.

Eric: there is a lot of interaction between ldp and routing protocols. It 
is orthogonal between what is used to modify the routing protocols. We can 
get into a problem if we mix routing protocols in this specification. Lets 
not worry about OSPF, ISIS, etc…

Curtis: The issue is not to do the same as ospf. If there is a small 
router, should this be in the protocol to handle the overhead of this 
switchover?

Matt: We want to support this ability?

Curtis: OSPF/IDR changes were intended to use for switchovers. It might be 
better to abort graceful restart and just assume the router is down.

Q: There are applications of LDP that do not depend on upgrades to other 
protocols.

Scott: Is there an applicability statement in this document to show where 
it can be used?

M: There are, but there are not which describe where it should not be used.

Scott: It might benefit from this. There doesn’t seem like there is a lot 
of support for this.

George: Lets continue this discussion on the mailing list. If no resolution 
there, we can talk about it later.

Curtis: If there is no problem in last call, just move it forward? Small 
changes may be required to support OSPF/RTP changes.

George: that is okay with me. We will do a last call, raise these issues 
and try to close them. If closed, then document is finished.

Sharma  Vishal  Expanded ERO for RSVP-TE

Overview. Lets make this an informational document on how to form EROs and 
move it forward that way.

George: Questions?

Matt: Asked to clarify.

Vishal: Yes.

George: Turn another draft and will ask later.

Qa: Don’t want to move it forward.

G: Isn’t being moved forward. We will re-spin another version of this 
document. Come to London for more information.

Agarawal  TTL Processing in MPLS Networks

Draft covers different ways of processing TTL. Overview. Would like to 
update according to comments from list and move forward to last call.

Matt: Document is useful and technical content is good. Figures would be 
useful. Document is difficult to read. Pipe/Hose model are mixed in 
document. Put them in a their own places in the document?

Q1: I don’t see how TTLs are specified in NTAPs draft.

A: Some models are not described in that document.

Q1: There might be some difficulty with your approach.

Rosen: There is already a document that specifies how TTL processing works. 
Lets just put pipe model in here only, otherwise we duplicate things 
explained in RFC 3032.
I think that we need to organize the discussion around the point of the 
organization of this document (what is not covered and what is).

E: You don’t need a separate procedure for nested procedure; already 
covered in 3032. Discussion did not complete on mailing list. There is a 
lot that needs to be clarified.

A: What are you proposing?

E: I think that you are proposing changes and additions (specified and 
unspecified). Need to specified which is which. Need to reach consensus on 
whether or not they are necessary. Do we need a document that obsoletes 
pieces of rfc3033.

George:  this is an information proposal. We cannot contradict something 
that is in a standard. Lets continue this discussion on the mailing list.

Egray: I was going to say what george just said. Define something in a 
standard specification and explain something in an informational.

George: Cannot contradict what was in the rfc. Take it to the list.

Matsushima  ttl processing expansion for 1 hop lsp

Overview. Next steps: merge with Puneet’s ttl draft. Would like to become a 
wg draft.  Need signaling extensions for 1-hop lsp.

George: Discussion?

Rosen: There are two schools of thought on TTL processing. Don’t think 
there is a need to specify TTL on a per-lsp basis. I don’t think that there 
is a problem that we need to solve here.

Matt: I agree with eric. The terminology for a 1-hop lsp is different from 
what they define.

Luca: I agree with Eric’s comments. I don’t see the use of specifying the 
behavior on a per-lsp basis.

Q: I don’t think that this is what ttl was designed for.

George: Continue discussion on mailing list.

Paridaens  End to End Authentication for ldp

Overview. Presented requirements. What we are asking is that this be 
adopted as a wg draft. This work is part of the charter, so it should be 
accepted.

Scott: What operators have expressed interest in this technology and have 
the security geeks looked at this?

Q: I don’t see any carriers looking at this. This method is expensive.

Parid: The cost is not so heavy.

Q: The other routing protocols work fine without authentication. If that is 
not a problem there, then why is this necessary here?

Paris: There are options as part of other protocols for authentication. It 
is necessary in other protocols and applications of them.

Q: All vendors are required to implement these drafts, and I don’t think 
that it is necessary. I would like to see the requirements document for 
this sort of work.

George: I would like to see a clear indication from the carriers that this 
is necessary.

Q: We had this discussion in San Diego. The consensus there was that this 
is overkill. Similar mechanisms are already available in TCP.

George: The charter items must not be worked on, they can be worked on.

Q: There is no explicit “why” about doing this from carriers.

Qb: I am not comfortable with this solution, but there seemed to be a clear 
statement in San Diego for non-hop-by-hop authentication.

George: Can some of those people speak up?

Qd: I made this proposal. There was some support at this time.

Qe: This looks like S-BGP which was roundly rejected because it was 
overkill/unfeasible. There is precident for this not being what vendors want.

George: We need to figure out what providers want first. We don’t have 
consensus.

Qf: Providers want security, but this is not really what we are looking for.

George: Lets get some carriers to give us some contributions for what they 
would like to see in this space. Continue discussion on this mailing list.

Black  Update on LDP Path MTU  black-ldp-mtu-extensions-00.txt

Overview. Simple extension to ldp to allow automatic signaling of mtu 
detection. Allows proper fragmentation of packets within the MPLS domain. 
Support RFC1191 too. Version 00 has been out for some time. Lots of 
comments received. Asked that this be accepted as a wg document.

George: discussion

Curtis: What happens if along the way, one hop is inside a hierarchtical 
tunnel or if bypass tunnels are used. In both cases, the router negotiating 
a hop is not aware that somewhere in the middle that a bypass exists.

Black: If hierarchtical, the outermost tunnel’s mtu is used.  There is an 
lsr somewhere that can see the bypass which can unsolicited signal the mtu 
change. It will pick the lesser of the two’s path.

George: Anything that causes an impulse into signaling during a failure is bad.

Rosen: In practice, a typical situation a packet with dm bit set, packets 
go through Firewalls that strip the tos bits off the packet. This solution 
does not solve the problem.

Black: In some cases, path MTU signaling in some cases is not valid to not 
solve the problem altogether. Second, there are other reasons for doing 
this: packets being fragmented in/out of MPLS domain.

Rosen: Both packets have df bits set.

Curtis: There are places where this is necessary: no NATs and high 
performance IP.

Matt: I haven’t seen demands from the carriers for this functionality, 
eventhough I like it.

Scott: Process point: is this in the charter?

George: Gray area. We should work to get MPLS to work.

Scott: WG can change charter if necessary. Charter is description of what 
we should be doing within a certain time period.

Q1: Carriers are interested in this.

Black: RSVP has this functionality.

George: We now have three presentations that are not in the gray area. They 
are outside of the charter. We are going into “BOF” mode to see if there is 
interest to expand the charter.

Senevirath -- Secure MPLS  draft-tsenevir-smpls-01, tsenevir-smpls-doi-00
Overview. Applications: Most metro applications use MPLS.

Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. 
Which country are you talking about?

Sen: US.

Q1: Do you know which vendors are supporting MPLS in the metro area.

Q2: Most operators use f/r links. The law prohibits them from monitoring 
authentications. Can authentications be monitored on MPLS. Even if we have 
mpls security on a backbone. MPLS is an end-to-end problem. This does not 
seem to be useful unless it is end to end.

Bilel J: Where are you getting the requirements for this draft.

Sen: These requirements are coming from the optical development going on in 
the world.

George: Take the discussion to the mailing list.

Disk Ooms  MPLS multicast Traffic Engineering

Overview. Questions.

George: This work was started a long time ago. There was no interest in 
this at that time. What has changed?

Disk: Now there is SSMulticast.

George: I think that you should change the name of your document to 
“support for SSM”. Describe your document in this way.

Disk: this is an alternative to SSM, not a tunnel through it.

George: I guess the amount of time we have left, we should see if there is 
interest on the mailing list.

Rosen: As far as SSM, there are other solutions to the problem of passing 
multicast packets back to the root.

Disk: There are other solutions, but they are undocumented as of yet.

Q1: I wasn’t clear why SSM makes this more interesting. Also it isn’t clear 
how you distribute the labels using TE. Where is the definition of TE is 
not clearly defined in the draft.

Disk: Traffic engineering allows you to construct a tree, which deviates 
from the one created in unicast.

George: The interest in SSM is more interesting than general multicast, and 
it is an easier problem to solve. Lets continue discussion on the mailing list.

Davari  MPLS OAM  draft-harrison-mpls-oam-00.txt
Overview.  Status of this document: ITU SG14-Q3. Requirements are defined. 
Availability is defined. OAM Packets are defined. Connectivity verification 
is worked out.  Future work: LSP performance work. Summary: OAM is 
necessary for user-plane, independent of control-plane. This draft 
introduces OAM requirements and simple OAM functions. Determining 
connectivity/availability. MPLS OAM was previously defined in MPLS charter. 
If interested, it should be added to charter and document accepted as a 
work item.

Q: I think this work is very useful. It will increase the performance of 
the MPLS network. Recovery framework is applicable. Performance 
benchmarking applies. This is useful for fault-tollerance.

Curtis: How does this apply to the Bonica work? We should go to the TE Wg 
and see what their requirements are for this.

Rosen: I think that some of the stuff in the beginning is important. I 
think this document is not a good piece of work that are not defined in the 
IETF. It has a very ATM-flavor. It does not handle a lot of stuff like 
multi-point-to-point. Even if we were to add measurement to charter, lets 
not accept this document to the charter.

Davari  This is optional. Carriers want this.

Q2: I don’t think that this is useful. I think that it is not useful in an 
LSR. I can see this to be useful if GSMP is being used.  Useful in 
detecting configuration errors, otherwise lets assume that the LSR works okay.

Q3: I second that. I don’t buy the argument that software is broken, so we 
need to add more software.

Scott: My problem with the document is that it mixes light requirements 
with lots of suggestions. It would be useful to have a clear requirements 
document (TE WG) that specifies what it is that you are trying to find out 
with this approach. That would be helpful for TE WG.

Q4: I think that the notion at the MPLS Layer is a useful construct for 
fault diagnosis.

Q5: The ITU is working on this. Can you send a pointer to this information 
on the ITU.

Davari: The information at the ITU is exactly the same information. ITU 
study group SG-13

Q6: I am not sure if the finding of errors is to be found in the te wg.

Davari: is it in the charter of te?

Scott: Thinking is in the charter of te. Management of this kind is not in 
the charter. However, if requirements can come forward and hint at which 
tools they could have would be a good thing.

Q6: I am not sure that availability is specified.

Davari: What we have done is take this from ATM and reduce most of what was 
there, and kept the best %1.

George: End of the agenda. See you in London.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 23 Mar 2001 20:13:44 +0100

Tom , George,

> diffServ WG.

A clarification:
the last call that just finished was actually an MPLS WG Last Call. This Last
Call was for the resolution of comments sent earlier during the Diff-Serv WG
Last Call.

>
>  Mostly minor comments to fix. Re-issue a final version which gets sent over
> to the IESG. Who to hand it over to? Rob Coltun: Hand it over to Scott/Bert.

thanks

FRancois
PLEASE NOTE NEW CONTACT DETAILS - See below

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                  [email-masked]
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bâtiment T3
06 410   BIOT 
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________