The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Attached are the minutes.  Many thanks to Andy Malis for taking such
detailed notes.

Also if you have not yet forwarded me your presentation for the
proceedings, please do so now.

...George

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

======================================================================
MPLS Working Group minutes

Chairs: George Swallow <swallow@cisco.com>, Loa Andersson <loa@pi.se>

1.  Agenda bashing
    
2.  Fast Reroute

2a. Fast Reroute Extensions to RSVP-TE for LSP Tunnels
    draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt
    Alia Atlas
    
This document defines extensions to and describes the use of RSVP-TE
to establish backup LSP tunnels for local repair of LSP tunnels.  It
is a "consensus" draft that resulted from the combination of
multiple prior drafts.

Since the -00 version the draft was reorganized to describe LER/LSR
behavior for each role in fast-reroute.  Details were combined which
were the same, regardless of technique used (one-to-one or facility
backup) and removed redundancy.  Behavior was clarified to facilitate
interoperability between techniques.  A number of technical
modifications were made as well (see the presentation in the
proceedings).

The authors believe the draft is ready for working group last call.
Multiple implementations currently exist.  The have resolved the
issues found in interoperability testing at Isocore and elsewhere.
There was consensus in the room, and last call will be issued
following the IETF meeting.

2b. Sven Van den Bosch
    Backup Record Route for Fast Reroute Techniques in RSVP-TE
    draft-decnodder-mpls-ero-rro-fastreroute-02.txt

MPLS fast reroute is considered as a solution to protect traffic
against link and node failures by re-directing the traffic locally to
a backup LSP. A backup LSP can be either a detour LSP or a bypass
tunnel. This document describes two methods to optimize the routing of
detour LSPs such that they merge faster, a distributed method and a
centralized method. The distributed method uses the Backup Record
Route Object (BRRO) and the centralized method uses the Backup
Explicit Route Object (BERO).

There were several issues raised about the draft that were addressed
in this revision.  The first was support of distributed detour
computation by allowing BERO to use loose hops, and the second was
regarding the object length - messages could become very long.  The
BERO may now be "compressed" by only specifying relevant nodes.  The
third issue was operation with inter-area LSPs, and that was addressed
with a change to the BRRO procedures.  The next steps are
implementation, future investigation of performance gain and label
state for different network topologies.  Further comments are invited
on the list.  They requested that this become a working group
document.  Scott Bradner, SUB-IP Area Director, said that any call for
a working group draft in this WG must mention what in the charter it
is addressing.  The response is that it enhances the fast reroute
extensions, which is in the charter.  There was little interest in
this draft expressed in the room; it will be further discussed on the
list.

2c. Distinguishing link and node failures using RSVP Hellos 
    draft-vasseur-mpls-linknode-failure-00.txt
    Jean-Phillipe Vasseur

The aim of this draft is to provide a method to distinguish a link
failure from a node failure using RSVP hello extensions.  The ability
to make this distinction is important when re-using link bandwidth to
provide multiple protection paths (assuming that only one failure will
occur at a time), which results in significant bandwidth savings.  See
the presentation in the proceedings for an animated tutorial on the
draft's mechanisms.

It also fits in the charter as a part of the fast reroute work item.
The draft was requested to be accepted as a working group document.
George asked if there are new procedures, or if this would be an
informational draft.  The answer is that it would be an information
draft.  Lou Berger asked how this is related to the work in GMPLS to
detect node and link failures - it seems that this duplicates that
work.  JP said that they are complementary - you can run one or the
other.  It's an alternative.  Scott said that given that we already
have something that does this, there should be only one.  Scott also
said that complicated technology proposals shouldn't be made in a
short presentation - people should read the draft and discuss it on
the list.  He would like to see discussion on the list first.

Yakov Rekhter said that hello mechanisms have been overloaded to
detect the liveness of both control and data planes, and he is
concerned by such overloading - he feels that they should be unbundled
into separate mechanisms.

There was a question on how fast link or node failure can be detected.
There's no way to do it faster than a round trip time, so you can't
always guarantee 50 ms or any other particular time.

Further discussion will be taken to the list.


3.  Encapsulation

    Encapsulating MPLS in IP or GRE
    draft-rosen-mpls-in-ip-or-gre-00.txt
    Eric Rosen

In various MPLS applications, label stacks with multiple entries are
used.  In some cases, it is possible to replace the top label of the
stack with an IP-based encapsulation, thereby enabling the application
to run over networks which do not have MPLS enabled in their core
routers.  This draft specifies two IP-based encapsulations,
MPLS-in-IP, and MPLS-in-GRE.  Each of these is applicable in some
circumstances.

This allows two LSRs to be "adjacent" when they are separated by an
MPLS-less IP backbone.  It servers a clear need for network
transitions.

Eric noted that the WG charter allows work in "MPLS-in-foo", so it
fits in the charter.

The issues are the IP encapsulation does require a "scarce" protocol
number, and the GRE encapsulation doesn't use the key field or the
checksum.  For both, there are also MTU, TTL, QoS, and DSCP issues
that are discussed.  There has been support expressed on the list, and
no objections.  Eric proposed that it be moved forward for Proposed
Standard.  Scott complemented him on his presentation and said it
should go ahead.  We had strong consensus to make it a WG item.
    

4.  OAM

4a. A Framework for MPLS User Plane OAM
    draft-allan-mpls-oam-frmwk-03.txt
    Dave Allan

This draft discusses many of the issues associated with user plane OAM
for MPLS. The goal is to provide tools to perform "in service"
maintenance of LSPs. Included in this discussion is some of the
implications of the MPLS architecture on the ability to support fault,
diagnostic and performance management OAM applications, potential
solutions for distinguishing user plane OAM, and a summary of what the
authors believe can be achieved in addressing all aspects of the MPLS
architecture.

In his presentation, he replaced the words "user plane" with "data
plane".  The motivations for the draft were to explore all issues
associated with instrumenting MPLS LSPs.  The document outcome is to
see what can be done in any given MPLS "level", and what can be done
by leveraging the entire architecture.  Topics covered include
mechanisms for distinguishing OAM flows, return path, multi-provider
issues, and OAM applications.  The changes since the last version are
a new section on OAM probe state association, new section on the use
of hierarchy to simplify OAM, enhanced security section, and minor
editorial changes.

The current state of the document is that the authors feel it is
largely complete.  They proposed that it be adopted as a WG draft - it
contains common MPLS WG input into both WG and ITU-T SG 13 efforts,
and is a useful survey of the space.  It would be even better with
additional WG input, then it can be put to bed.  Tom Nadeau said that
it's a pretty reasonable document.

4b. IP-based Tool Requirements for MPLS Networks
    draft-nadeau-ip-basedtool-requirements-00.txt
    Tom Nadeau

This memo describes requirements for operations and management based
on IP-based tools for MPLS networks. The document scope is
requirements for IP-based tools for fault detection, diagnostics,
statistic reporting, and security management.

The motivation is that providers have been coming to the authors with
OAM requirements that differed from those that were available from
both the IETF and the ITU-T, and there was a concern that current
requirements did not reflect real operational environments.  There
were also disparately located requirements for MPLS-related OAM
scattered about, and they felt it would be best to put these together
into one place.  The base message from providers is that they wanted
an evolutionary approach rather than a revolutionary approach that
might have new hardware requirements and require fork-lift upgrades in
their networks (sensitive to both OPEX and CAPEX).  Since they
published the draft, they have received comments that will result in
revisions, and they would like to move the requirements from Dave
Allan's framework document, and make it a WG document.  Tom asked
Scott if he agreed that the requirements be combined in one place, and
Scott agreed that sounded like a good idea.  Jerry Ash said that some
service providers have provided requirements against MPLS MIBs, and
should those requirements also be applied to OAM?  Tom said that some
of the requirements were specific to MIB changes, but some of the
others were overall requirements that do apply here as well.  Dimitri
Papadimitriou would like a discussion of how data plane OAM interacts
with control plane mechanisms like fast reroute.  Dave Allan supports
getting all of the requirements in one place.

4c. Detecting MPLS Data Plane Liveness
    draft-ietf-mpls-lsp-ping-01.txt
    Kireeti Kompella

This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS LSPs.  There are two parts
to this document: information carried in an MPLS "echo request" and
"echo reply" for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply.

Changes from the last revision were the packet format was changed and
a version number field was added, a "Don't Reply" reply mode was
added, the reply flags were removed, and return codes were extended.
RSVP session formats were modified, VPN IPv4/v6 formats were defined,
L2 VPN endpoint and L2 circuits were defined, downstream mapping
format was changed, and PAD and Error Code TLVs were introduced.

The next step is that the base document is done for base MPLS tunnels
as well as applications such as VPNs, and it is time to get it out and
go to WG last call.  Tom Nadeau had two questions - there's no
reference in the document for the encapsulation type, and the document
needs clarified on what is required to be implemented and what is
optional - what's the base implementation?  Kireeti said that the
draft already does that, and it will be improved.  Shahram Davari
asked if there were requirements for this work, and Kireeti said they
were implied in the draft, and there is a real problem in that we need
to know if our MPLS networks are working.  Tom Nadeau said the
requirements draft he discussed previously also covers this draft.
Kireeti also said that if something is missing, we can add it
later. There was consensus for last call, and it will be issued
following the meeting.

George said that for the framework and requirements, he would not want
them to become WG documents yet; rather, the authors should get
together and see what information should go into each document and
produce new higher quality revisions that can then become WG drafts.
We agreed that will be the plan.
    

5.  Load Balancing

    Guidelines for MPLS Load Balancing
    draft-allan-mpls-loadbal-00.txt
    Dave Allan

RFC 3031 permits MPLS load balancing while making no specific
representations as to implementation requirements. This has
subsequently become an issue with respect to the reliability of path
test mechanisms. Load balancing algorithms may separate path test
probes from the path of interest. This draft proposes guidelines for
implementation of load balancing such that path test mechanisms are
not impacted.

The motivation is that it is desirable that when multiple NHLFEs
exist, that both the user traffic and any OAM probes follow the same
path through the network.  The goal is consistency in monitoring and
fault isolation.

The draft requires that for next hop selection, you not use reserved
labels, don't include the "S" bit, and don't include TTL.

The proposal is to obtain the sense of the WG that some solution is
required, and to adopt the draft as a WG starting point.

Kireeti said that this violates the principal of reproductive freedom
- what's in my body is mine, and don't tell me what to do with it.
This is similar to allowing implementations to do what they want for
SPF.  You can tell me what to put on the wire, but not how to
implement it in my box.  Dave agreed that what's in your box is your
business, but the externally observable behavior of your box IS the
issue here and is important to service providers.  Kireeti said that
this should be information if it is published at all, but certainly
not standards track or a BCP.  Dave said that anything that bounds
detection time of problems in the network is good, and carriers want
bounded detection times.  Kireeti kept arguing that this is a paradigm
change to the forwarding path.  We have ECMP and it works, and it's up
to each vendor to decide how they implement it.  Dave said that is
going to be important for PWE3 as well, since you need to bound the
detection time for failures on pseudo-wires as well as for the
transport LSPs.  Kireeti also doesn't want any limits on label depth
that were discussed in the draft.  Not looking at the S bit is also
bogus.

Eric Rosen agrees with Kireeti's comments.  While its a good OAM
requirement that OAM packets need to follow the data packets, he
doesn't agree with the way the document tries to do it by imposing the
restrictions it does.

Alia Atlas also agreed - this is a revolutionary approach rather than
evolutionary approach due to the required changes in the forwarding
path.  It's bad to adversely affect ECMP in order to support OAM.  In
some cases, you don't know that length of the label stack.  Dave said
that the only reason he discussed label stack depth in the draft was
an attempt to keep it simple.  He also wanted measurement consistency
on a per-node basis rather than a per-LSP basis.

Shahram Davari said that this probably breaks MPLS ping.

Kireeti asked the ADs at what point do we stop intruding into boxes?
This came up not just here, but also in the routing area discussion on
SPF implementation.  He suggested that this just be published as an
information RFC saying "this is a good idea".  Scott said that this is
really an IAB/IESG plenary discussion rather than something that
should be discussed here.  If the WG believes that something is wrong
with the way something was done in the boxes, and the WG consists of
box builders, than that's the consensus.  Be he hasn't seen a
consensus at the microphone for this point.

There was considerable opposition to this being a WG document.  Further
comments will be taken to the list.


6.  Bi-directional LSPs

    Bi-directional LSPs for Classical MPLS
    draft-dube-bidirectional-lsp-00.txt
    Rohit Dube

This draft proposes extensions to support bi-directional LSPs for
classical MPLS. Specifically, RSVP-TE is extended with objects similar
to those in GMPLS to allow establishment of bi-directional LSPs.  It's
a pretty simple protocol extension to make this work.

Kireeti disagrees that GMPLS is different from MPLS - it is a superset
of MPLS, and bidirectional as defined in GMPLS works in MPLS as well,
so this draft is unnecessary.  Kireeti and Rohit discussed some the
differences between the two approaches, but Kireeti felt that the
GMPLS approach is sufficient for the requirements.

Rahul Aggarwal had a second comment along the same lines - just use
what was already done for GMPLS.

George added that while it's simple to do an extension for
bidirectional, it's harder to make sure it works for fast reroute and
make-before-break.  So he wants some though on how these other
mechanisms would be supported for bidirectional as well as just the
data flow.  Rohit agreed that these could require some additional
work.  Discussion will be continued on the list.


7.  MPLS Security

    Analysis of the Security of the MPLS Architecture 
    draft-behringer-mpls-security-03.txt
    Michel Behringer

This document analyses the security of the BGP/MPLS VPN architecture
as described in RFC 2547, especially in comparison with other VPN
technologies such as ATM and Frame Relay. The document consists of two
main parts: the requirements for security in VPN services are defined,
and MPLS is examined with respect to these requirements. The analysis
shows that MPLS VPN networks can be equally secured as traditional
layer-2 VPN networks such as ATM and Frame Relay.

This was originally written as a white paper for customer consumption,
and he decided to also make it available as an internet draft.

The question being answered by the draft is can you operate an MPLS
backbone in a secure manner.  What secure means here is address space
and routing separation, hiding the MPLS core structure, resistance to
attacks, and impossibility of VPN spoofing.  This allows MPLS to be a
replacement for L2 services, like ATM and Frame Relay.  It does NOT
address the security of the operations of RFC 2547, such as
misconfiguring VPNs and security of the implementations due to bugs.
He was concentrating on the security of the architecture, but it's
still possible to shoot yourself in the foot.

It does not yet include Inter-AS operations.  It's pretty stable.
There is one open issue - during rerouting, one label too many might
get popped for a short time.  He's still researching this to see if
it's a bug in the implementation, or a bug in the protocol.

Questions: Is this useful?  What is missing?  Does it fit in this WG?
His goal is to publish it as an informational RFC.

Eric Rosen said that this addresses the issue as to whether a VPN
implementation fits the requirements, and he feels it belongs in the
PPVPN working group.  Michael asked if this document could become a
security section for RFC 2547?  Eric wasn't sure if he would take that
approach, but in any event, he still thinks it should be in the PPVPN
WG.

Dave McDysan said that this draft was used to help with the PPVPN
requirements document, and he also would like to see it in the PPVPN
WG - it's already been referenced.  Michael said that he's already
presented it there, and the answer was no at that time.  Dave said
that it's already been included in the PPVPN requirements.

Loa said that a question heard from customers is - Is the MPLS
architecture, and VPNs on top of it, secure enough to replace L2 VPN
networks?  Loa feels that this work is important and needed.

Yakov said that this document would be a great replacement for the
security section in rfc2547bis - that security section should just be
a pointer to this document.

Ananth Nagarajan said that this needs to be expended to cover the
carriers of carriers case.

Marco Carugi (PPVPN co-chair) agreed with Yakov's comments, and that
it should be generalized into a complete security framework for all of
the PPVPNs technologies, not just rfc2547.

Scott agreed with Marco.  But George feels that when it comes to
security, it's better to be specific than general.

George said that discussion of this document should be moved to the
PPVPN email list.


8.  Multicast 

    Extended RSVP-TE for Multicast LSP Tunnels
    draft-yasukawa-mpls-rsvp-multicast-01.txt
    Allan Kullberg

This document specifies extensions and mechanisms to RSVP-TE in order
to support MPLS point-to-multipoint LSPs.

The changes from -01 were:

 - All tree modifications via changed TERO
 - Always from sender node via Path message
   - Avoids race conditions
 - Supports Graft/Prune
   - Leaf Initiated Join/Leave
   - Leaf node sends Join/Leave message directly to sender node
   - Sender node sends changed TERO
   - Looks like single node Graft/Prune
 - Sequence number in TERO hop (Saves comparing entire TERO)
 - Terminating node flag in TERO hop
   - Allows node to be branch and leaf
 - MulticastNotify message for error indications
 - Error handling description

The future directions are:
 - Add sequence # to TRRO (Saves compare of entire TRRO)
 - GMPLS Notify instead of McastNotify? (Reuse is good)

Allan requested that this become a WG draft.

Rahul said that there is a draft that describes how to do multicast in
tunnels using PIM, and seems less complex.  Allan said that this draft
doesn't require the use of a multicast routing protocol.

George asked what's the driving need that this is trying to satisfy?
Allan said that this to support multicast without requiring the use of
an IP multicast address as the destination.

Discussion will continue on the list.


9.  LDP FT/Restart
    draft-farrel-mpls-ldp-restart-applic-01.txt
    Adrian Farrell

There are two drafts for recovery of LDP sessions after failures,
draft-ietf-mpls-ldp-ft-06.txt and
draft-ietf-mpls-ldp-restart-05.txt. These drafts have completed WG
last call and have moved forward to IESG review.  There is a need for
information indicating which draft should be implemented and when.  In
addition, draft-ietf-mpls-ldp-ft also has options.  Implementation
choices are complex, so this draft was written to give guidance on
when it is advisable to implement a LDP restart mechanism and which
approach might be more suitable.  The draft has expanded to contain
additional background information. The draft is stable, but has a few
updates still needed - in particular, Yakov had some comments that
Adrian is working on.

Adrian requested that this become a WG document with a view to moving
forward as an informational draft.

George spoke in favor of the draft.  But it was a late addition to the
agenda, and people need more time to read it.  So people are
encouraged to read it and discuss it on the list.


10.  Workgroup Status

10a. LDP to Draft Standard status
     Loa Andersson

Loa presented the current results from the LDP implementation survey.
The full presentation appears in the proceedings.  Some highlights
follow:

12 Responses
- 10 Public, 2 Anonymous.
- 10 Product; 2 Beta
- 11 On sale; 1 Other
- Implementation Approach
7 From spec;
4 Purchased/free code + additions;
1 Purchased code.

Highlights
- Every item in survey questionnaire implemented by at least 2 respondents.
- Each of the 8 Label Distribution Modes implemented and tested;

Legend

  T	Tested against another independent implementation
  I	Implemented by not tested against another independent implementation
  N	Not implemented.

 T  I  N				 T  I  N
 =======                                 =======
 8  2  2   DU, Ord Cntl, Lib Reten       6  1  5   DU, Ord Cntl, Con Reten
 7  1  4   DU, Ind Cntl, Lib Reten	 6  0  6   DU, Ind Cntl, Con Reten
 7  1  4   DoD Ord Cntl, Cons Reten	 4  3  5   DoD, Ord Cntl, Lib Reten
 6  1  5   DoD, Ind Cntl, Cons Reten	 4  2  6   DoD, Ind, Cntl, Lib Reten

- Platform and Interface Label Spaces both widely supported.

 T  I  N				 T  I  N
 =======                                 =======
12  0  0   Per Platform	                 7  1  4   Per Interface

- Basic and Targeted Sessions both widely supported.

 T  I  N				 T  I  N
 =======                                 =======
12  0  0   Basic/Directly Connected	11  1  0   Targeted

- TCP MD5 Option not widely implemented.

 T  I  N				
 =======                            
 3  1  8

- Interface Types

 T  I  N				
 =======                                
12  0  0   Packet
 6  2  4   ATM
 2  3  7   Frame Relay

This will continue to be updated as responses come in, and a draft
will be written summarizing how LDP is being used and if anything
should be removed in order for it to become a Draft Standard.


10b. MPLS MIB review meeting report
     Joan Cucchiara & Tom Nadeau

There was an open MPLS MIB meeting held this past Saturday in Atlanta.
The agenda was:

- Review of  Final Changes for MIBs requested by MIB Doctors
- Review Interaction between MIBs:
  MPLS-TC, MPLS-LSR, MPLS-LDP, MPLS-TE, MPLS-FTN, TE-TE, LINK-BUNDLING
  MPLS MIB Overview draft
- FINAL ACTION Items for Authors

Complete detail of changes are recorded at the IETF ID Tracker Site: 
https://datatracker.ietf.org/public/pidtracker.cgi 
- Many minor changes
   DESCRIPTION clauses
   Clarification of examples
   Editorial in nature (split REFS, IPR statement)
- Very few significant changes

See the presentation in the proceedings for the complete list of
changes to each of the MIBs.

Next steps:
- Goal is to update MIBs and Overview by 12/15  (MIB co-authors) 
- Depends on
  - IESG Comments on latest MIBs
  - Resolution of issues on email list
  - Additional Working Group "LAST, LAST, LAST Call" at that time?  

Tom asked for clarification from the chairs on whether we need another
WG last call.  Loa said yes, but it would only be on the changes since
the last WG last call, and on the MIBs as a group.  So all six MIBs
need to be ready at the same time.  The overview document will be last
called at the same time.

If there are any additional comments that people have, please make
them this week so that the MIBs can be updated by the above deadline.

Loa thanked everyone that participated in the MIB review, and the MIB
authors, for all of their hard work in getting the MIBs done.


10c. Status of MPLS WG Internet Drafts 
     George Swallow
 
George presented the status of all MPLS wg documents.  The
presentation is included in the proceedings.

Among the drafts awaiting updates from authors was:

   MTU Signalling Extensions for LDP
     <draft-ietf-mpls-ldp-mtu-extensions-00.txt>

Kireeti said that the draft needs to be redone based on received
comments.  There should be a new version by the second week of
December.

George also note that it's time to move forward on draft status for
the architecture, encapsulation, ATM VC switching, and RSVP-TE RFCs.

Loa said that the CR-LDP decision was documented in an individual
draft, was reviewed by the IESG (which returned comments), and there
was a general comment on grammar.  Scott will be reviewing it for
grammar, after which it will be sent to the RFC Editor.