The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

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.