The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Attached are the minutes.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 497-8143
                        250 Apollo Drive
                        Chelmsford, Ma 01824



======================================================================
MPLS WG meeting minutes       Salt Lake City                  12/10/01
======================================================================

1.  "MTU Signalling Extensions for LDP" 
      <draft-black-ldp-mtu-extensions-02.txt>

      Kireeti Kompella 

There was a very brief prsentation to update the workgroup
on changes since the last document, concluding with a request 
to go to last call.

Discussion:

Pradgesh: This draft only addresses a part of the problem: MTU
discovery for LDP. What do we do for RSVP?
Kireeti: RSVP is done.
Prad: why do we have a separate draft?
K: 2 drafts are okay.
Lou: The RSVP info is in the original draft.

K: George, can we check the room for consensus for last call? What
does the room think?

Room: More for than against, but George wants to see a little more
enthusiasm. George will issue a WG last call shortly.


2.  "TTL Processing in MPLS Networks" 
      <draft-agarwal-mpls-ttl-01.txt>

    Puneet Agarwal 

Puneet: Made a short presentation, followed by a request to adopt the
draft as WG document.

George: Do people in the room believe this draft is a good idea. Do I
see any nods for yet/no?  Some clarifications on this would help for
interoperability of this. There seems to be a consensus for such
documents. 

Anonymous: 

Provides useful clarification, but would like to know how you know 
which model of TTL decrment to use?  

Puneet: Signaling is out of the scope of this document. If the group
wants to address this, the chair needs to address this.

Scott Bradner: The documents going into being WG documents need to be
items that are in the charter, or the charter needs to be re-spun to
change. We need more WG support short for this document before it can
be accepted.

George: This document is just a document to clarify how things are
being done.  It does not represent new protocol work.
We decided it would be informational in London.

The document was accepted as a WG document.


3.  Restart/Recovery

Three drafts were presented on Restart/Recovery, adjudication was
withheld until all were presented.

    "Graceful Restart Mechanism for BGP with MPLS" 
     <draft-rekhter-bgp-mpls-restart-00.txt> 

    Yakov Rekhter 

Yakov:  Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: What is the required restart time.

Yakov: User configurable.

Anonymous: BGP has a specific timer.

Y: You should look at the BGP proposal; whatever BGP does this does too.

Y: Any other questions?


    "Graceful Restart Mechanism for LDP" 
     <draft-leelanivas-ldp-restart-01.txt>

     Yakov Rekhter

Yakov: Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: Why previous BGP restart should be done in IDR?

Y: Distribution of BGP labels has been done in this WG, so we should
do this here.


    "Graceful Restart Mechanism for LDP" 
     <draft-smith-mpls-ldp-restart-00.txt>

     Andy Malis / Toby Smith 

Toby: Presentation. Detailed difference between this proposal and Yakov's.

Anonymous: Discuss different proposals?

George: Drafts have not been accepted, so we need to get to the bottom
of that. Lets discuss this for a few minutes.

Eric Gray: This draft does not compete with Yakov's draft. Yakov's is
focused on BGP MPLS. This draft proposes a difference between what is
in the IESG queue for a year now.  The LDP fault tolerance draft had
looked at stuff like this drafts. The problems are that these
assumptions do not work in all deployments unless all LSRs agree to do
this fault tolerant mode. It doesn't do any good to support any LSPs
that are not supported in any other segments in the network.

Andy: First comment: this only goes on between LDP peers, so if you
are running lDP throughout the network and you have an outage between
two peers, those should come up okay and should not affect other peers
elsewhere. Comment two: it is all or none.

Luca: I would like to see these approaches get together. 

Andy: We already have plans to meet with the other authors.

Anonymous: The assumption that was made that checkpoint information
can be kept can be a problem with regard to resources.

Andy: This is a problem with all of the approaches.

Phil: After querying about the number of implementations of the
existing draft, I have not heard of any problems with this
approach. There are apparently 2 implementations of the existing fault
tolerant draft.

Andy: There is no problem with the difficulty to implement these or
the new approaches; just the implementation complexity.

Kireeti: This draft is nice because it is light, but I am afraid that
two end points of the connection can loose state. If you exchange
control messages, you are assured that things are in sync.  The IDR
approach does exchange control messages. Just an important point to
understand.

Anonymous: A few points. The BGP restart drafts pretty much learn
their state from the network. With this approach, you have the
possibility of loosing state. The main difference between the two
approaches is that one approach caches state, and the other doesn't.

Andy: We considered that LDP runs over TCP, so we have a reliable and
sequenced path. You know that the receiver knows that they received
control messages. We are pretty clear that things should work pretty
well. All should read the current draft, and send email to the list.

George: Requested that the group having lunch please send email to the
        list.


4.  Fast Reoute

    "Fast Reroute Techniques in RSVP-TE" 
      <draft-ping-rsvp-fastreroute-00.txt>

      Ping Pan 

Ping: Presentation

George: Would like this accepted as a WG document?

Ping: Yes.

Question: I could not figure out how one approach complements the others.

Ping: We would like to combine the request mechanism from all drafts,
so that any router in the network based on local configuration can
construct a back-up path.  We haven't finished integrating these.

Question: I think the case when the backup path LSP fails behavior is
not specified. There should be recommendations/considerations of what
should be done. Now, if the backup LSP fails what do we do?

Question2: Generalizing the applicability for this (i.e.:
bi-directional LSPs)?

Ping: I think in the case of GMPLS this is already done.


    "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute" 
     <draft-atlas-rsvp-local-protect-interop-02.txt>

     Alia Atlas 

Note: Alia is also one of the co-authors of the draft presented by
Ping.  Her draft is intended to allow some of the open issues in that
draft to be aired before the workgroup.

Alia: Presentation

A lively discusion between Ping and Alia ensued, particularly over the
issue of make-before-break on backup tunnels.

George: Any objection to accepting the Ping draft as a WG document?
Note that the issues that Alia raised should contunied to be disussed
on the mailing list.  How many people think this should be added to
the WG?

George: The I's have it.   


5.  "Multiprotocol Label Switching (MPLS) Management Overview" 
     <draft-ietf-mpls-mgmt-overview-00.txt>

     Tom Nadeau 

George:  This draft was requested by ADs.  It 
shows relationship of various MIBs.

Tom: Presentation

Kireeti: Include TE-MIB?

Tom: Yes.

George: WG draft?

Group: Lots of hands. No objections.

George: Draft will be last called after IESG process on MPLS
LSR/TE/LDP/FTN MIBs has progressed and any changes that emerge from
that process are inculded.


6.  "IPv6 Traffic Engineering Tunnel" 
     <draft-ishii-ipv6-te-tunnel-00.txt>

     Hiroki Ishibashi 

George: This next presentation is out of the scope of the WG, and is more
of an application of MPLS.

Hiroki: Presentation.

Francois: This work belongs to the NG-trans WG. There is a draft
there for this work already. LSPs are constraint based routed. There
is a lot of overlap between this draft and the draft being progressed
there.

George: (to Hiroki) The point is that the discussion belongs in the
other WG, not here.


7.  Document Status

George: Presented drafts that are in IESG last call, are on IESG queue.

Yakov: There are some changes to the unnumbered draft for CR-LDP that
 need to be done.

George: Any comments on mpls-te-feedback-draft

Don Fedyk: We were looking to progress this document.

George: I will send it to last call.

We now want to shift gears and talk about which RFCs that can be
progressed onto the standards track.  Scott, please comment on
architecture document.

Scott: Beats me.  In general, architecture documents are not standards
track documents.

George: Enaps draft. There are quite a few implementations of that
that interoperate. What we need is for people to collect interop
information.

Lou: a while back when this draft was coming out, there were MTU
discovery interop issues.  The discussion was that when it came time
to advance the document until these issues are addressed.

George: Dig up old email and start a new discussion. 

Lou: Hopefully it will be just what we agreed to 2 years ago and put
it into the draft.

George: LDP draft. Has many different flavors. In order to progress,
only those things for which there are 2 or more interop
implementations can be progressed, and the rest removed. A survey
effort needs to happen and documentation of what is there and what is
not.

Joel Halpern: Are you going to make the list or is someone else?

George: I am not going to do it. Volunteers? Loa, you showed interest
in this in the past.

Loa: I will help out if Bob Thomas doesn't have time.

George: Technology-specific drafts (ATM). There are multiple
implementations, not sure about interop of them. Need to get to the
bottom of this. The (FR) drafts: don't know of any implementations, so
it will stay proposed (forever).  BGP draft: there are interoperable
implementations of this, so this can be progressed.  I will send the
list of these drafts/status to the list.