Loa Andersson | 27 Nov 06:54 2014

MPLS Yang team(s)

Working Group,

We got a mail asking about the status of the MPLS Yang teams.

The background is that the authors of the mpls-yang IDs were asked
to prepare a joint presentation at the Honolulu meeting. The authors
(and other interested) met during the week and came up with

We very much appreciate the work done by everyone involved. And believe
it will form a good base to move ahead on.

At the end of the presentation the relation of this work to generic
yang-attempts were brought up. The answer was pretty much that we do
not know yet.

The YANG teams are not formalized working group design teams. We will
need to see the effects of getting the rtg-area tuning fully in place

For the time being they are individual initiatives, pretty much as an
individual draft, however the output from the teams are there out in the
open and can be discussed, and will serve as a basis if and when we
decide on design teams.

The coordination points that can be seen now, and what the teams should
be aware of and take into consideration.

High level OAM model (LIME)
   - probably not that much impact on MPLS TE and LDP yang models
(Continue reading)

internet-drafts | 26 Nov 20:01 2014

I-D Action: draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : mLDP In-Band Signaling with Wildcards
        Authors         : IJsbrand Wijnands
                          Eric C. Rosen
                          Arkadiy Gulko
                          Uwe Joorde
                          Jeff Tantsura
	Filename        : draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt
	Pages           : 15
	Date            : 2014-11-26

   There are scenarios in which an IP multicast tree traverses an MPLS
   domain.  In these scenarios, it can be desirable to convert the IP
   multicast tree "seamlessly" to an MPLS multipoint label switched path
   (MP-LSP) when it enters the MPLS domain, and then to convert it back
   to an IP multicast tree when it exits the MPLS domain.  Previous
   documents specify procedures that allow certain kinds of IP multicast
   trees (either "Source-Specific Multicast" trees or "Bidirectional
   Multicast" trees) to be attached to an MPLS Multipoint Label Switched
   Path (MP-LSP).  However, the previous documents do not specify
   procedures for attaching IP "Any Source Multicast" trees to MP-LSPs,
   nor do they specify procedures for aggregating multiple IP multicast
   trees onto a single MP-LSP.  This document specifies the procedures
   to support these functions.  It does so by defining "wildcard"
   encodings that make it possible to specify, when setting up an MP-
   LSP, that a set of IP multicast trees, or a shared IP multicast tree,
(Continue reading)

Loa Andersson | 26 Nov 11:34 2014

Change of Guards, Martin to leave as the mpls wg secretary, Tarek to step in

Working Group,

We regret to announce that Martin is stepping down as MPLS
WG secretary. Afte a long term, Martin is now moving on to
new challenges as the co-chair of the newly formed BESS
Working Group.

Martin has set the bar very high for not only his successor, but
for all IETF WG Secretaries.  Much of what Martin does is behind
the scenes and the chairs want you to know what a great job he
has done in supporting us.  Martin has contributed greatly to
draft-secretaries-good-practices.  A substantial part of that draft
is based on his experiences in supporting the MPLS Working Group.

Martin has also been (and has promised to continue to be) a very
active member of the MPLS WG.

At the same time we are happy to announce that we found a replacement.
Tarek Saad will step in as our new secretary and Martin has promised
to effect a smooth transition.

Please join the working group chairs in thanking Martin and in welcoming 

Loa, Ross and George
MPLS WG co-chairs


Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
(Continue reading)

Kamran Raza (skraza | 26 Nov 05:25 2014

Yang model for LDP/mLDP


We would like to bring into your kind notice that a multi-vendor team has started working on the design of the Yang model for LDP/mLDP.  Currently, the team comprise following members:

  Robin Li - lizhenbin <at> huawei.com (Huawei)
  Jescia Chen - jescia.chenxia <at> huawei.com (Huawei)
  Kamran Raza  - skraza <at> cisco.com (Cisco)
  Reshad Rahman - rrahman <at> cisco.com (Cisco)
  Santosh Esale - sesale <at> juniper.net (Juniper)
  Vishnu Pavan Beeram - vbeeram <at> juniper.net (Juniper)
  Himanshu Shah - hshah <at> ciena.com (Ciena)

The team had our first formal meeting today and we have scheduled calls to meet weekly to make progress on LDP yang model in upcoming weeks. We will keep MPLS WG and rtg-yang-coord alias posted with regards to our progress, as well as, solicit input as/when required.
[ P.S.:  If you wish to contribute to the design of LDP/mLDP yang model, please let me know accordingly by sending an email and I will add you to the team / meeting invite]

FYI, following is the summary of the main points discussed/agreed in our first meeting:

1- The scope of our work (and document) includes:
- LDP, mLDP, and Multi-topology (LDP/mLDP)
        - Config, Operational State, Notifications, and RPCs

2- We have broken the effort into following phases:
       ph1- Overall config model/hierarchy (keeping LDP/mLDP/MT in mind)
       ph2- LDP: cfg, notifs, rpcs
       ph3- mLDP: cfg, notifs, rpcs
       ph4- LDP: state
       ph5- mLDP: state
       ph6- Multi-topology (everything)

3- The plan is to have the ph1-3 completed before next IETF and the draft posted with the update.

4- In the meantime (and in parallel), we will continue to attend MPLS level Yang meetings (to be arranged by Tarek) 
    to define MPLS common base, and leverage LDP yang accordingly.

5- The next meeting/call for LDP Yang will be on Tue Dec 2nd with the following agenda:
     - Complete discussions on ph1.
     - Deep dive into ph2 (define overall LDP cfg tree, followed by expansion of each container)

(on behalf of LDP Yang team)
mpls mailing list
mpls <at> ietf.org
IETF Secretariat | 26 Nov 03:43 2014

Milestones changed for mpls WG

Changed milestone "Submit draft-ietf-mpls-ipv6-only-gap for
publication", resolved as "Done".

URL: http://datatracker.ietf.org/wg/mpls/charter/

mpls mailing list
mpls <at> ietf.org

Nobo Akiya (nobo | 26 Nov 02:28 2014

Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)


As agreed at IETF91, we would like to keep the MPLS WG involved with draft-grmas-bfd-rfc5884-clarifications.

The document clarifies the procedures of BFD on MPLS. If this topic is of your interest, please do read and
provide comments.

Note, the WG adoption poll for draft-grmas-bfd-rfc5884-clarifications was just kicked off today (and
ends on Dec. 12, 2014).


-Nobo and Jeff

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces <at> ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, November 25, 2014 7:50 PM
> To: rtg-bfd <at> ietf.org
> Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends
> December 12, 2014)
> Working Group,
> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was
> presented at IETF-91 in Honolulu and was positively received.  We'd like to
> ask the Working Group whether we should formally adopt this draft as a
> Working Group item.
> Please indicate your support or lack thereof to the mail list by December 12,
> 2014.
> Also, please supply feedback to the authors.  I believe the perception of this
> document is that it's very nearly complete and thus should have a short
> lifetime prior to publication as an RFC.
> -- Jeff & Nobo.

mpls mailing list
mpls <at> ietf.org

internet-drafts | 26 Nov 02:11 2014

I-D Action: draft-ietf-mpls-ipv6-only-gap-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Gap Analysis for Operating IPv6-only MPLS Networks
        Authors         : Wesley George
                          Carlos Pignataro
	Filename        : draft-ietf-mpls-ipv6-only-gap-04.txt
	Pages           : 27
	Date            : 2014-11-25

   This document reviews the Multiprotocol Label Switching (MPLS)
   protocol suite in the context of IPv6 and identifies gaps that must
   be addressed in order to allow MPLS-related protocols and
   applications to be used with IPv6-only networks.  This document is
   intended to focus on gaps in the standards defining the MPLS suite,
   and not to highlight particular vendor implementations (or lack
   thereof) in the context of IPv6-only MPLS functionality.

   In the data plane, MPLS fully supports IPv6 and MPLS labeled packets
   can be carried over IPv6 packets in a variety of encapsulations.
   However, support for IPv6 among MPLS control plane protocols, MPLS
   applications, MPLS Operations, Administration, and Maintenance (OAM),
   and MIB modules is mixed, with some protocols having major gaps.  For
   most major gaps work is in progress to upgrade the relevant

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

mpls mailing list
mpls <at> ietf.org

IETF Secretariat | 25 Nov 22:29 2014

State changed: charter-ietf-mpls-06-08

State changed to External review.

URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/

mpls mailing list
mpls <at> ietf.org

IETF Secretariat | 25 Nov 22:28 2014

Telechat update notice: <charter-ietf-mpls-06-08.txt>

Telechat date has been changed to 2014-12-04 from 2014-11-25
ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/

mpls mailing list
mpls <at> ietf.org

The IESG | 25 Nov 22:28 2014

WG Review: Multiprotocol Label Switching (mpls)

The Multiprotocol Label Switching (mpls) working group in the Routing
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2014-12-02.

Multiprotocol Label Switching (mpls)
Current Status: Active WG

  Loa Andersson <loa <at> pi.nu>
  George Swallow <swallow <at> cisco.com>
  Ross Callon <rcallon <at> juniper.net>

  Martin Vigoureux <martin.vigoureux <at> alcatel-lucent.com>

Assigned Area Director:
  Adrian Farrel <adrian <at> olddog.co.uk>

Mailing list
  Address: mpls <at> ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/mpls
  Archive: http://www.ietf.org/mail-archive/web/mpls/


The MPLS working group is responsible for standardizing 
technology for label switching and for the implementation of
label-switched paths over packet based link-level 

The working group's responsibilities include procedures and 
protocols for the distribution of labels between Label Switching
Routers (LSRs), MPLS packet encapsulation, and for Operation,
Administration, and Maintenance (OAM) including the necessary 
management objects expressed as YANG models or MIB modules.

The current WG focus areas and work items are: 

- Maintain existing MPLS requirements, mechanisms, and protocols,
  as currently documented in RFCs, in coordination with other 
  working groups that work in overlapping areas including the
  working groups.

- Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE
  for packet networks, and LSP Ping to meet new requirements.

- Document MPLS-specific aspects of traffic engineering including
  for multi-areas/multi-AS scenarios in cooperation with the TEAS 
  working group.

- Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases
  where there is an overlap, generic parts will be done by the TEAS
  working group, MPLS data plane specific parts will be done by the
  MPLS working group, and support for any other specific data planes
  will be done by the CCAMP working group. The TEAS working group acts
  as the hub for coordinating this work, and the MPLS working group 
  will track agreements about work to be done in this working group
  through milestones in this charter.

- Define data models for MPLS working group related solutions.
  YANG models and MIB modules may be considered. Coordinate with
  the LIME and NETMOD working groups for core YANG models.

- Define an overall OAM framework for topology-driven, traffic
  engineered, and transport profile MPLS applications.

- Define the necessary extensions for MPLS key protocols for dual-
  stack and IPv6-only networks.

- Document current implementation practices for MPLS load sharing.

- Document mechanisms for securing MPLS protocols and data plane.

- Document mechanisms for adding multi-topology support to existing
  MPLS protocols.

- Define the necessary protection protocols and scenarios for transport
  profile MPLS applications

- Document use cases for MPLS protocols.



mpls mailing list
mpls <at> ietf.org

Pete Resnick | 25 Nov 17:24 2014

Pete Resnick's No Objection on charter-ietf-mpls-06-07: (with COMMENT)

Pete Resnick has entered the following ballot position for
charter-ietf-mpls-06-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


Some bits I think should be clarified, but can wait until external

   The working group's responsibilities include procedures and protocols

What do you mean by "procedures"? Operational guidance?

   - Determine MPLS-specific aspects of traffic engineering including
     for multi-areas/multi-AS scenarios in cooperation with the TEAS 
     working group.

As with the CCAMP charter, I'm a bit mystified by the word "Determine"
here. What exactly does the WG do on this point?

mpls mailing list
mpls <at> ietf.org