The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

MPLS WG Meeting Thursday, March 22, 2001
========================================

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

1.  Carrying Label Information in BGP-4          (awaiting publication)
      <draft-ietf-mpls-bgp4-mpls-05.txt>

    On RFC editor's queue


2.  RSVP-TE                                      (awaiting publication)

    Applicability Statement for Extensions to RSVP for LSP-Tunnels 
      <draft-ietf-mpls-rsvp-tunnel-applicability-01.txt>

    RSVP-TE: Extensions to RSVP for LSP Tunnels 
      <draft-ietf-mpls-rsvp-lsp-tunnel-08.txt>

    Note: the latter draft needs some final edits.  This will be handled as 
    part of the RFC editors last authors comments.


3.  LDP "boxed set"                              (awaiting publication)

    LDP State Machine 
      <draft-ietf-mpls-ldp-state-03.txt>

    Applicability Statement for CR-LDP 
      <draft-ietf-mpls-crldp-applic-01.txt>

    Constraint-Based LSP Setup using LDP 
      <draft-ietf-mpls-cr-ldp-04.txt>

    LSP Modification Using CR-LDP
      <draft-ietf-mpls-crlsp-modify-02.txt>

    These are awaiting a Table of Contents for LDP State machine.  As
    of this writing, Eric Gray has supplied an updated draft.


4.  MIBs                                           (in IESG last call)

    Definitions of Managed Objects for the Multiprotocol Label Switching, 
      Label Distribution Protocol (LDP) 
      <draft-ietf-mpls-ldp-mib-07.txt>

    MPLS Label Switch Router Management Information Base Using SMIv2 
      <draft-ietf-mpls-lsr-mib-07.txt>

    Authors are in the process addressing comments from the IESG.
    Another round of last calls is probably not required.


5.  Framework for IP Multicast in MPLS 
      <draft-ietf-mpls-multicast-05.txt> 

    Will be sent to IESG for last call.


6.  MPLS Support of Differentiated Services 
      <draft-ietf-mpls-diff-ext-08.txt>

    Francois needs to turn a new draft incorporating updates from the
    recent WG last call after which it will go for IESG last call.


7.  Generalized MPLS Signaling drafts

    These drafts are nearly complete.  They will be updated based on
    the results of CCAMP.  Once updated they will be sent for joint
    CCAMP and MPLS WG last call.  Consensus to do the MPLS WG last call
    was reached in this meeting.

8.  Unnumbered, Bundle, Hierarchy drafts

    After the "sub IP" re-org, these drafts remain in MPLS.

    Proposal:  Accept draft-kompella-mpls-undle-05.txt as working group 
    draft. Update the draft as draft-mpls-bundle-00.txt.  Some of the
    other drafts will also be updated.  Once updated a WG last call
    will be issued.  None opposed; consensus.


II. MPLS Recovery Framework                       Fifi Hellstrand       
  <draft-ietf-mpls-recovery-frmwrk-02.txt>

This document provides a high-level overview of protection mechanisms
which could be employed by MPLS.  The document was also presented to
the TE wg.  Many comments received on this document. Minor changes were required
(editorial).  Fifi requested that the document be sent to WG last call and move it to
an informational RFC. No questions from crowd.

Within the sub IP area, the TEWG has the charter to come up with an
overall recovery framework.  George therefore asked the ADs if a WG
last call for this document could be done at this time.

Scott: Wants to take a sense of the room, and then get comments from the
mailing list for last call, but still wants the 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.  The document will be sent to the TE WG mailing list for
comments to facilitate the process outlined by Scott.


III.  RSVP Label Allocation for Backup Tunnels      George Swallow    
        <draft-swallow-rsvp-bypass-label-01.txt>

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. The
technique uses a bypass tunnel to the node two hops down the path.
All tunnels between the current node and that node may share the same
bypass tunnel.  Rerouting is done locally and thus can be done in < 50ms.

In order to use this, a label needs be obtained for the hop across the
bypass tunnel.  Two mehanism are described in the draft.  A separate
RSVP Path message can be generated.  This applies in all cases.  If
the tail of the bypass tunnel is a frame-based switch using the global
label space, then labels can simply be recorded in the RRO.

The draft has been 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.
A WG last call will be issued after which it will be forwarded to
Scott and Bert for IESG review.


IV.  LDP Fault Tollerance                          Philip Matthews  
  <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.

A long discussion enused on the relationship of LDP recovery to
recovery of information from other protocols.  There is work in
progress on this in OSPF and IDR.  In fact the LDP recovery is based
on BGP recovery.  Details of this discussion can be found in the raw
minutes sent by Tom Nadeau.

The result of all the discussion was that the issue of the
relationship of LDP recovery to other stateful recovery will be
handled in the last call.  Scott commented that the applicability
section of the document should be enhanced to reflect this.

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


V.  An Expanded ERO for RSVP-TE                   Vishal Sharma
      <draft-akyol-mpls-exp-ero-00.txt>

Given the recent changes in the unnumber draft, the mechanism proposed
in this draft is no longer necessary.  The authors therefore propose
to turn this draft into an informational document on how to form EROs
and move it forward that way.


VI.  TTL Processing in MPLS networks               Puneet Agarwal    
       <draft-agarwal-mpls-ttl-00.txt>

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=92t 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.


VII. TTL Processing expansion for 1-hop LSP         Satoru Matsushima   
       <draft-satoru-mpls-1hop-lsp-00.txt>

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?

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

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

George: Continue discussion on mailing list.


VIII. LDP End-to-end Authorization                  Olivier Paridaens
        <draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt>

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?

A general discussion ensued on what was required and what had been
discussed in San Diego.

Several carriers and vendors spoke up saying that the proposal on the
table was expensive and over-kill.  This was counter with a statement
that the method was not all that expensive and that the feature is
optional.  It was also claimed that carriers voiced support in San
Diego.

Another speaker pointed out that optional pertained to use and that
vendors most likely would be required to implement.  Before committing
to such a course they would like to see the requirements document for
this sort of work.

George: We need to figure out what providers want first. We don't have
any consensus at this point.  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.


IX.  Update on LDP Path MTU                          Ben Black
       <draft-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=92s 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=92s path.

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

Eric Rosen pointed out that in practice, firewalls often thwart Path
MTU discovery by dropping ICMP messages.

Ben Black said that simply because it wouldn't work in some cases, was
no reason not to work on solving the problem where it would work.

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.

Discussion will be continued on the list.


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


X.  Secure MPLS                                Tissa Senevirath    
      <draft-tsenevir-smpls-01.txt>
      <draft-tsenevir-smpls-doi-00.txt>

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.


XI.  Multicast Traffic Engineering                 Dirk Ooms        
       <draft-ooms-mpls-multicast-te-00.txt>

Overview. Questions.

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

Dirk: Now there is SSMulticast.

George: Perhaps you should change the name of your document to
"support for SSM". 

Dirk: this is an alternative to SSM.

Rosen: As far as SSM, there are other solutions to the problem of knowing
the source of a packet.

Dirk: 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.

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

George: Given the time, lets continue discussion on the mailing list.



XII.  MPLS OAM                                      Shahram Davari  
        <draft-harrison-mpls-oam-00.txt>

Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview.  Status of
this document: ITU SG13-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.  What we have done is taken this from ATM
and reduced most of what was there, and kept the best %1.  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 relate to the Bonica draft on tunnel trace? We
should go to the TE Wg and see what there are 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.  There are many terms
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 that specifies what it is that you are
trying to accomplish with this approach. The requirements document
should be taken to 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.



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