Nobo Akiya | 29 Mar 03:36 2015

Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse

Hi Authors,

I have couple of comments from OAM perspective.
(using email instead of mic since we were very short on time)

Section 2

   best case scenario is complete overlap of the two paths end to end;
   in which case there is no need for any label changes and LFIB
   updates, both in the transit as well as in the ingress routers.  In
   this scenario there is also no need to perform data plane
   verification for the new tunnel instance.

Being a paranoid OAM person, the statement "no need to perform data plane
verification" makes me a bit nervous. There's a big difference between
"there should be no data plane impact" to "there is no data plane impact",
particularly because code changes required are to not change existing data
plane via label sharing by multiple LSPs. That implies that any
bugs/timing-issues/etc in that specific code space can cause existing data
plane to actually purged [accidently]. I would feel more comfortable if the
document did not imply that everything about the new LSP is perfectly happy
w/o any OAM to verify it.

   For the case where the two
   paths overlaps only from a certain transit router (rather than from
   the ingress), label reuse starts at that router and continues all the
   way to the egress router.  In this case the existing data plane
   verification method can still be used to verify new tunnel instance
   as before.
(Continue reading)

S. Davari | 27 Mar 19:11 2015



In order to carry a Flow ID end-to-end it means that the SFL labels can't merge, Then how does this work in  the MP2P or ECMP?  Does it require a downstream LSR to distribute many SFL labels (one per flow) for the same FEC to the same upstream node? How is this done? does it require new LDP or RSVP signaling?

Also this is different from RFC6374 since data and OAM are now combined in one packet. A section to describe the required behavior will be useful.


mpls mailing list
mpls <at>
Nobo Akiya | 27 Mar 17:01 2015


Hi Authors,

I went through the document [briefly] and had some comments.

1. In resultInfo, it is critical that we include Return Code and Return
Subcode so that the users will know the nature of the error when problems
are encountered.

2. Similar to the first comment, it is also important to include the source
IP address of the received MPLS Echo Reply in the resultInfo, so that when a
non-success MPLS Echo Reply is received back by the initiating node, users
will know which network node sent that packet.

3. Frequency and ProbeCount is part of the Control Information, but the
mechanism also allows the Schedule Parameters to specify when to start/stop.
This will become ambiguous as the "operation" is done when MPLS Echo Request
is sent ProbeCount times at the Frequency specified but the endTest can also
defines the data/time when the operation should terminate. A clear
description of the relationship/rule of them will be helpful.

4. The Control Information allows specifying of an outgoing interface but
you'll also want to specify the nexthop address.

5. Being able to specify the TTL will be beneficial.

6. You'll also want to have some control over the ECMP, by being able to
specify the destination IP address (i.e., 127/8) or inclusion of ELI/EL and
the value of the EL. For the exact syntax, this is an aspect which will be
helpful to talk to multiple vendors. For example, I know of an
implementation which allows specifying of a _range_ of entropy set to be
used, so that a single Ping operation sweeps the entropy set. Whether such
capability is included in the yang definition or kept outside of it is a
good discussion to have.

7. Before going too far forward with just the Ping, it'll be good to add the
mechanism for Traceroute as well. Specifically how do we notify the
information in the received DSMAP/DDMAP (with various Sub-TLVs of the

8. Related to comment 7, even the Ping operation may want to allow inclusion
of a DSMAP/DDMAP. This will be useful when used together with a specific TTL



mpls mailing list
mpls <at>

Qin Wu | 27 Mar 12:36 2015

Re: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Hi, Authors of draft-ietf-mpls-lsp-ping-reply-mode-simple-01:
I have read draft-ietf-mpls-lsp-ping-reply-mode-simple-01 and think it is ready to go for publication.
Here are few editorial comments on this draft.
1.section 3.2 said:
4.  If a responder LSR understands the Reply Mode Order TLV and the
       TLV is valid, then the responder LSR MUST consider Reply Mode
       values described in the TLV and MUST NOT use the value described
       in the Reply Mode field of received MPLS echo request.
I think the value carried in the Reply mode Order TLV overrides the value included in the Reply Mode field of
MPLS echo request message header, would it be good to make this more clear and explicit.

2. section 3.2 also said:
5.  If a responder LSR understands the Reply Mode Order TLV but the
       TLV is not valid (due to conditions  listed below), then the
       responder LSR MUST only use the value described in the Reply Mode
       field of received MPLS echo request.
Not sure where the conditions are specified, suggest to provide a link to the conditions specified in this document

3.section 4.1 said:
[RFC7110] has defined that the "Reply Path TLV" can include Sub-TLVs
   describing multiple FECs, from which the responder LSR can chose  the
   FEC to send the MPLS echo reply message on .  
send the MPLS echo reply message on?
What does "on" mean here? Remove "on" from this sentence?

4. section 4.1.2 said:
   Then the MPLS echo request message is to carry:

   o  The Reply Mode Order TLV carrying Reply Modes  {5, 2, 5}
Reply mode 5 is not defined in RFC4379.Where reply mode 5 is defined?

5. section 4.2 said:
The mechanism defined in this document will work with Proxy LSP Ping
   defined by [I-D.ietf-mpls-proxy-lsp-ping].  MPLS proxy ping request
   can carry a Reply Mode value and  the Reply Mode Order TLV with list
   of Reply Mode values.

Suggest To distinct reply mode value carried In the message header and reply mode value carried in the Reply
mode order TLV here

6. section 4.2 said:
With these procedures, Reply Mode used by the MPLS echo
   reply sender is propagated in the Reply Mode field to the sender of
   MPLS proxy ping request.
I am totally confused by this last sentence.
what does " sender" in"the MPLS echo reply" means? Are you saying reply mode value in the echo rely is
propagated to proxy ping request? Or propagated to proxy ping reply?
How the sender of MPLS proxy ping request is related to initiator LSR or responder LSR or responding node
used in the document?
It will be nice to have a consistence terminologies use.

-------- Forwarded Message --------
Subject: 	working group last call for
Date: 	Fri, 20 Mar 2015 14:03:52 +0000
From: 	Ross Callon <rcallon <at>>
To: 	mpls <at> <mpls <at>>
CC: 	mpls-chairs <at> <mpls-chairs <at>>, George
Swallow (swallow) <swallow <at>>, Carlos Pignataro (cpignata) <cpignata <at>>, Loa
Andersson <loa <at>>, Mach Chen <mach.chen <at>>, <at> < <at>>

Working Group,
This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
Because this WGLC will span the IETF in Dallas, it will be extended to three weeks.
Please send your comments to the mpls wg mailing list (_mpls <at> ietf.org_ <mailto:mpls <at>>).
There are no IPR disclosures against this document. All the authors have stated that they are not aware of
any IPR that relates to this draft.
This working group last call ends Friday  April 10, 2015.
for the MPLS WG chairs

mpls mailing list
mpls <at>

Santosh Esale | 27 Mar 00:07 2015

Re: New Version Notification for draft-esale-mpls-ldp-node-frr-00.txt

We have submitted a new draft that describes fast re-route for
node protection in LDP based LSPs. Please let us know if you have
any questions or comments.

Santosh (on behalf of authors)

On 3/25/15, 3:09 PM, "internet-drafts <at>" <internet-drafts <at>>

>A new version of I-D, draft-esale-mpls-ldp-node-frr-00.txt
>has been successfully submitted by Santosh Esale and posted to the
>IETF repository.
>Name:		draft-esale-mpls-ldp-node-frr
>Revision:	00
>Title:		Fast Reroute for Node Protection in LDP-based LSPs
>Document date:	2015-03-24
>Group:		Individual Submission
>Pages:		7
>   This document describes procedures to support node protection for
>   (unicast) Label Switched Paths(LSPs) established by LDP("Label
>   Distribution Protocol"). In order to protect a node N, the Point of
>   Local Repair (PLR) of N must discover the Merge Points(MPTs) of node
>   N such that traffic can be redirected to them in case node N fails.
>   Redirecting the traffic around the failed node N depends on existing
>   point-to-point LSPs originated from the PLR to the MPTs while
>   bypassing the protected node N.  The procedures described in this
>   document are topology independent in a sense that they provide node
>   protection in any topology.
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at
>The IETF Secretariat

mpls mailing list
mpls <at>

IETF Secretariat | 26 Mar 20:11 2015

ID Tracker State Update Notice: <draft-ietf-mpls-proxy-lsp-ping-05.txt>

IESG state changed to RFC Ed Queue from Approved-announcement sent
ID Tracker URL:

mpls mailing list
mpls <at>

IETF Secretariat | 26 Mar 16:05 2015

ID Tracker State Update Notice: <draft-ietf-mpls-proxy-lsp-ping-05.txt>

IANA action state changed to In Progress
ID Tracker URL:

mpls mailing list
mpls <at>

Robert Raszuk | 26 Mar 01:00 2015

Hello Luyuan,


"The HSDN forwarding architecture in the underlay network isbased on four main concepts: 1. Dividing the DC and DCI in ahierarchically-partitioned structure; 2. Assigning groups ofUnderlay Border Nodes in charge of forwarding within each partition; 3. Constructing HSDN MPLS label stacks to identify the end points according to the HSDN structure; and 4. Forwarding using the HSDN MPLS labels."
Can you provide any reasoning for going to such complexity when trying to use MPLS as transport within and between DCs as compared with using IP based transport ? Note that IP based transport native summarization provides unquestionable forwarding FIB compression.

"HSDN is designed to allow the physical decoupling ofcontrol and forwarding, and have the LFIBs configuredby a controller according to a full SDN approach. Th controller-centric approach is described in this document."
+ Quote:
"2) The network nodes MUST support MPLS forwarding."

Please kindly note that to the best of my knowledge number of ODMs routers used to construct IP CLOS Fabric does not really have control plane which supports MPLS transport. Neither distributed nor centrally ie via controller managed.

"The key observation is that it is impractical, uneconomical, and ultimately unnecessary to use a fully connected Clos-based topology in a large scale DC."
That is an interesting statement. I think however that one should distinguish interconnected regions with proper CLOS fabric from some sort of CLOS fabric want-to-be type of topologies. In any case it has no bearing on the main points of the scalable interconnect discussion.

- - - 
While we could go via number of other comments let's cut it short. 
Your draft states that HSDN works with IPv4 transport in the below statement:
"Although HSDN can be used with any forwarding technology, including IPv4 and IPv6,"
1. Can you summarise reasons what problems do you see with IPv4/IPv6 based underlay in the DCs that drove you to provide this document to be based on MPLS ? 
(Note that tenant mobility is the overlay task and nothing to do with underlay.)
2. Can you describe how are you going to distribute MPLS stack to be used for forwarding in the underlay to servers ?
3. How are you going to provide efficient ECMP intra-dc ? I see no trace of entropy labels in your document.
4. For TE is there anything missing in the below document ?

Many thx,r.
mpls mailing list
mpls <at>
The IESG | 25 Mar 23:24 2015

Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt)

The IESG has approved the following document:
- 'Proxy MPLS Echo Request'
  (draft-ietf-mpls-proxy-lsp-ping-05.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working

The IESG contact persons are Alia Atlas and Adrian Farrel.

A URL of this Internet Draft is:

Technical Summary

   This document defines a means of remotely initiating Multiprotocol
   Label Switched Protocol Pings on Label Switched Paths. An MPLS Proxy
   Ping Request is sent to any Label Switching Router along a Label
   Switched Path. The primary motivations for this facility are first to
   limit the number of messages and related processing when using LSP
   Ping in large Point-to-Multipoint LSPs, and second to enable leaf to
   leaf/root tracing.

Working Group Summary

     The working group process has been smooth. We had comparatively few 
     comments (all of the supportive) during the WGLC, but had a good
     discussion during the MPLS-RT review (April 2013). No points of 
     particular rough consensus: the working group is behind this document.

Document Quality

     We  know of  implementations of this specification.


      Loa Andersson is the Document Shepherd.
      Adrian Farrel is the responsible AD

mpls mailing list
mpls <at>

IETF Secretariat | 25 Mar 23:24 2015

ID Tracker State Update Notice: <draft-ietf-mpls-proxy-lsp-ping-05.txt>

IESG has approved the document and state has been changed to Approved-announcement sent
ID Tracker URL:

mpls mailing list
mpls <at>

Adrian Farrel | 25 Mar 23:14 2015

Approved draft-ietf-mpls-proxy-lsp-ping


The authors have revised this document to address my Discuss and the various
IESG Comments to my satisfaction.

No notes are needed.

This document is approved.

Secretariat (bcc) please advance the  document.


mpls mailing list
mpls <at>