The MPLS WG Archive

[Vijay Srinivasan <vijay@torrentnet.com>]

Here are the meeting notes from the Chicago IETF.  Thanks to
Loa Andersson and Steve Silverman for taking minutes.

- Vijay


MPLS Meeting, Chicago Aug 24/25

Meeting summary
---------------
I.  LDP Specification

In order to make progress on the LDP specificaton, a number of
decisions were made.

1.  The loop prevention mechanisms will be removed from the current
draft.  This will allow completion of the base LDP mechanisms.

The working group will continue to evaluate and compare the two
leading contenders.  We expect that we will pick one of these methods
and add it to a later version of the LDP specification as the standard
loop prevention option.

2.  For this version of the LDP specification we have settled on the
path vector mechanism for loop detection.  This could be revisited at
the time that loop prevention is settled.  Also, a maximum limit on
the number of elements in that vector (~100) will be chosen.

3.  The explicit path setup in LDP will be moved to a separate
document.


II.  VPNs

Two drafts on VPNs were presented.  It was decided that the generic
VPN requirements should be addressed in the VPN wg.  The MPLS wg will
concentrate only on VPNs as they apply to MPLS.


III.  Traffic engineering 

Three drafts were presented.  Two,
draft-awduche-mpls-traffic-eng-00.txt and
draft-swallow-mpls-rsvp-trafeng-00.txt were accepted as wg drafts.
The third, draft-widjaja-mpls-mate-00.txt, was presented for
information.  The authors expect to continue to refine this draft.


IV.  ATM

Draft-davie-mpls-atm-01.txt was presented and accepted as a wg draft.


V.  LDP MIB

Draft-cucchiara-mpls-ldp-mib-00.txt was presented and accepted as a wg
draft.


VI.  Virtual Circuit Identification    

Draft-ietf-mpls-vcid-atm-01.txt was presented.  This draft is now
mature and will either become part of the LDP spec or to go to last
call on it's own.  The authors of the respective drafts will decide.


VII.  Schedule

1.  A last call on the MPLS Encapsulation will be issued following this
meeting.

2.  The LDP spec will be updated by Nov. 6, at which time a last call
will be issued.

3.  The authors of the RSVP document expect to issue another version
by October 1.  A last call is expected shortly there after.

4.  Last calls are expected on the ATM and FR drafts prior to
December.

5.  The Orlando meeting will focus on resolving last call issues with
first priority given to LDP, encaps, and traffic engineering.  Other
topics will be addressed on a time available basis.

------------------------------------------------------------------

Meeting notes

Notes from the IETF MPLS meeting in Chicago Aug. 24/25, 1998 

1. Agenda bashing (George/Vijay)

2. draft-ietf-mpls-ldp-00.txt (Bob Thomas)
Bob Thomas gave an overview of progress and changes since the
meeting in LA. This included explicit routing, an error handling mechanism, 
handling of unknown messages and unknown TLVs, as well as vendor 
private features.

Refinement of support for explicit routing, two messages defined: 
- Explicit Route Request Message:
                unique LSP ID..both loose and strict routing supported.
- Explicit Route Response Message

Definition of error handling mechanism
- two kinds of event notification

Elaboration in a number of areas, including more balanced support for
technologies other than ATM
        Frame Relay
        generic; e.g., PPP, Ethernet
  Simplification, e.g., reduction in number of FEC types
  Extensive rework of Section 3 protocol spec.
        Detailed encodings
        reorg with goal of making it more "user friendly"
Integration of comments from mailing list
Addition of Open Issues section

Section 3 - Protocol specification has been reworked with the 
intention of taking out complexity.

Addition of Open Issues section:
There are still some open issues, e.g. if loop prevention/detection 
should be included in the spec or not, and if it is which 
scheme (path vector or color) that should be used. Another open
question is whether support for explicitly routed LSPs should
be part of the spec and whether anything else
is needed for traffic engineering.  Other open issues include
addition of security requirements for LDP, number of FECs that
we need to define, and the support of multicast.

The LDP DT agrees that the LDP spec is close to being stable and 
implementable and suggested that a version of the spec should be created now
that could be used for implementation.  The stable portions that can
be "frozen" now include downstream and downstream on demand label
allocation, and conservative and liberal label retention.  The less
stable parts include support for loop prevention/detection, and
FEC types other than simple prefix.

It was noted that on some issues the the LDP spec is moving ahead
of the Architecture spec, but that this has been done in full 
cooperation with the Architecture team.

The Area Director, Rob Coltun, made that point that we
want to see some real progress at this meeting, and that we must not
let the LDP work drag out unnecessarily. 

3. LDP Issues (Rosen)

Eric Rosen discussed two issues that he considered needed to 
be modified in LDP, numbers and types of FECs and the loop prevention/
detection scheme in LDP.
The FEC discussion was already settled on the mailing list:
the different types of FECs will
be included, but it will not be a requirement to be able to
generate them.

Eric considered the path vector scheme as it is described in the LDP 
spec to be difficult to implement, as it requires that a node must
store that path vector in or to be able recreate a path-vector message.
This could lead to instability and congestive collapse (as depicted
in an example by Eric).

Eric proposed to remove any requirements on passing path vectors 
around.  Ross Callon made the point that RSVP also uses path
vectors for explicit routing.  
 
4. draft-obha-mpls-loop-prevention-01.txt (Rosen/Katsube)
The color scheme was presented by Eric Rosen, who stated that it
is really more simple than the path-vector.  The method
has been simplified since the last time it was presented.
Eric contended that the scheme requires less state and has no need
for times.  The "color" is a 32 a bit node ID + some number of bits.
The concern was raised from several members of the audience that the
color scheme was too complex and difficult to understand.

Curtis Villamizar suggested that the simplest thing might be to remove 
all loop prevetnion/detection from the LDP spec and make it 
optional and have two separate documents, path vector and color, 
and let vendors implement both, either or none. 

Nancy Feldman questioned if the hop count will find the loop in a timely 
manner, as will the path vector scheme.

Vijay Srinivasan reported that two thirds of the respondents on the
mailing list favored moving loop prevention out to a separate document.

5. draft-heinanen-generic-vpn-mpls-00.txt (Heinanen)
After the presentation in LA, observations were made on that
most of the mechanisms were not directly related to mpls, but were more
general in nature. The spec as it stands today tries to create 
a general mechanism that works in networks using mpls and
those that do not. Only the edge routers need to be aware of the
VPNs, the backbone routers need not to be trusted.
As there needs to be manual configuration of which VPNs 
belong to which stub link, there are several alternatives to
support reachability: directory look up, routing protocols or LDP.
This work will be moved to the VPN working group.

6. draft-jamieson-mpls-vpn-00.txt (Jamoussi)
Virtual Private networking architecture, presented by Bilel Jamoussi. 
The draft describes the requirements, the benefits, the architecture 
and the logical building blocks of this proposal. 

Proposed that the draft be adopted as a working group document. It was
found that there are many commonalities between the proposal from 
Juha and this draft, to be considered in the VPN WG.

7. draft-jamoussi-mpls-sin-00.txt (Jamoussi)
Ships In the Night operation was presented by Bilel. The document describes
the requirements, the benefits and the architecture of the proposal. 
It was recognized that the draft covers an area in which the 
arcitecture draft is weak.  The draft needs to be discussed with the
architecture team and possibly included in or having an impact of the
architecture draft.

8. draft-ramakrishnan-mpls-unite-00.txt (Ramakrishnan)
KK Ramakrishnan presented a proposal for a lightweight signalling 
protocol for ATM called unite.  Connectivity is set up with a single 
cell, while everything else is done inband.  Loop prevention mechanism 
include via an flow-id included in the micro-setup. The QoS setup 
could be "delayed" and done while data is transferred on the connection.
The delta to introduce multicast is small. The unite scheme could
potentially be used to distribute labels for mpls.


--- end of the monday meeting ----

--- tuesday meeting ---

1. Working group status
The WG co-chairs reported from a meeting that had been called on the
initiative af the Area Director, Rob Coltun, to address the lack 
of progress on LDP. Attending the meeting were the LDP design team
(excluding Paul, Andre and Loa), the architecture team, the 
MPLS working group co-chairs and the Area Director.
The following decisions were taken at this meeting. Loop prevention 
is to be excluded from LDP for the time being, and moved to a separate
document.  A decision on whether it should be included in LDP again,
and in that case which method to use, will be 
taken later.  Loop detection will be done by the path-vector mechanism,
although the size of the path vector will be bounded by ~100 nodes.
Explicit routing will be excluded from the LDP specification and 
moved to a separate document, with the option to include it in LDP
later.

2. draft-awduche-mpls-traffic-eng-00.txt (Daniel Awduche)
Daniel Awduche presented requirements for trafic engineering over 
mpls, and provided motivations and needed actions as seen from an
operators point of view.
UUnet is expanding its network the coming two years. The objective
is performance optimization and is mainly seen as a control problem.
MPLS, diff serv and constrainted based routing are seen as key
requirements. A set of attributes, needed for traffic engineering,
for the LSPs is given in the draft. 

Some of the key points Daniel made related to traffic engineering were:
- There is more to traffic engineering than mere load balancing.  
- Need to consider cost structure & revenue models impact.
- The criteria of interest include: minimize packet loss, 
  congestion, delay, maximize goodput.
- Control Problem: anticipatory and/or reactive.  Intervention thru configuration mgmt.
- Internet IGPs are inadequate for TE, don't consider network load or
  resource availability in net (capacity constraints).

Daniel concluded by inviting the WG attendees to a workshop on MPLS in November.

Daniel's draft was accepted as WG draft.

3. draft-swallow-mpls-rsvp-traffeng-00.txt (George Swallow and Tony Li)
George and Tony described the extensions to RSVP to support MPLS.  These
are tunnel identification, tunnel parameter negotiation, routing policy 
distribution, routing debugging information, scalability improvements and
LSP merging.

The overhead associated with RSVP refreshes for the soft state
is perhaps the most acute scaling issue for RSVP. There are several
ways to address this: (1) aggregate several refreshes into 
one packet, (2) use a refresh digest ala IS-IS or (3) run
RSVP on top of TCP.  The question of
LSP merging is addressed in the draft but need further study.
Merge: Automatic merging of compatible of LSPs, voluntarily merging.

The Working Group agreed to promote the draft to a WG draft.

4. draft-widaja-mpls-mate-00.txt (Indra Widjaja)
This draft suggests that multiple equivalent LSPs can be created,
and traffic can be distributed among these LSPs based on adaptive
mapping according to network state.  Only 
best effort traffic is dealt with in the draft, other QoS classes are 
to be dealt with in the future.  Probe packets can be used to
determine delays and loss rates.

5. draft-davie-mpls-atm-01.txt
Eric Rosen presented the changes to the draft and stated that
the intention is to move the document to a working group document.
Since MPLS uses multipoint-to-point trees and most ATM switches
cannot support this, label distribution is done using the downstream
on demand scheme.  

The draft was moved to a working group document and is up for working 
group last call.

6. draft-ooms-multicast-00.txt (Dirk Ooms)
The intention is that the draft shall be a framework for multicast
in mpls. No design choices have been made. A taxonomy for IP multicast
protocols is defined, e.g.:
- trees, source tree, shared unidirectional tree, shared bidirectional 
  tree
- triggers, request driven, topology driven, traffic driven. 

The concept of "mixed L2/L3 forwarding" was discussed.
This might be useful if the  next hops at a point there traffic on the 
multicast tree uses forwarding where the next hops are a mix of LSRs
and other routers (outside the mpls cloud).  The draft covers some of
the "white areas" in multicast mpls, and is intended as a starting 
point for further discussiion.  Other topics discussed were piggybacking
of MPLS information on routing protocols and explicit routing.

7. draft-cucchiara-mpls-ldp-mib-00.txt (Joan Cucchiara)
Joan presented the draft and stated that the concept of the LDP session 
is the center of MIB, the LDP entity LDP peers are listed. The draft
has been modelled on the Bay - Ericsson implementation that was
demoed at Supercom in Atalanta. The draft was promoted to a working 
group draft.

8. draft-ietf-mpls-vcid-atm-01.txt (Hiroshi Esaki)
Hiroshi presented the requirements, on LDP, that the VCID method of 
setting up LSPs generate. The needed messages types and object formats 
were listed and will be addressed by the LDP design team.
The proposal is to add 4 message types to LDP:
VCID In-band Propose, VCID Propose, VCID ACK, VCID NAK.  
This is an optional feature for mpls.

9. Report from th ITU-T SG11 meeting
Muneyoshi Suzuki reported from the ITU SG11 on the status of B-ISDN 
support for MPLS VCID. SG11 will add a generic identifier to support
internet protocols, including mpls. The information element coding
is supposed to be frozen at the SG11 meeting in March 1999.
Awaiting review text of QS.2941.2 at 
www.nal.ecl.net/SG11WP1/itu-t-sg11-tmp-doc-td55r2/