Hi, Acee,
On Aug 15, 2016, at 9:02 PM, Acee Lindem (acee)
<acee(_at_)cisco(_dot_)com<mailto:acee(_at_)cisco(_dot_)com>> wrote:
Hi Carlos,
From: mpls
<mpls-bounces(_at_)ietf(_dot_)org<mailto:mpls-bounces(_at_)ietf(_dot_)org>> on
behalf of "Carlos Pignataro (cpignata)"
<cpignata(_at_)cisco(_dot_)com<mailto:cpignata(_at_)cisco(_dot_)com>>
Date: Monday, August 15, 2016 at 8:24 PM
To: IETF discussion list
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>
Cc: mpls <mpls(_at_)ietf(_dot_)org<mailto:mpls(_at_)ietf(_dot_)org>>,
"draft-ietf-mpls-entropy-lsp-ping(_at_)ietf(_dot_)org<mailto:draft-ietf-mpls-entropy-lsp-ping(_at_)ietf(_dot_)org>"
<draft-ietf-mpls-entropy-lsp-ping(_at_)ietf(_dot_)org<mailto:draft-ietf-mpls-entropy-lsp-ping(_at_)ietf(_dot_)org>>,
mpls-chairs
<mpls-chairs(_at_)ietf(_dot_)org<mailto:mpls-chairs(_at_)ietf(_dot_)org>>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-entropy-lsp-ping-04.txt> (Label
Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using
Entropy Labels (EL)) to Proposed Standard
Hi,
One outstanding issue with this document is revisiting and getting to a
deliberate position on which RFCs (if any) this document “Updates” (if
approved). Currently:
Updates: 4379, 6424, 6790 (if approved)
The authors, shepherd, chairs, and responsible AD have discussed this (i.e.,
which document(s) are actually “Updated" by
draft-ietf-mpls-entropy-lsp-ping-04). We agree that only RFC 6970 is actually
“Updated" by this I-D. The relationship between RFC 4379, RFC 6424 and
draft-ietf-mpls-entropy-lsp-ping is that the the I-D extends functionality from
those “base” RFCs, without updating text or changing meaning from either.
The draft adds a new multi-path information type to the DDMAP TLV as defined in
RFC 6424. So, why doesn’t it update this RFC as well????
If RFC A defines a TLV space, and RFC B adds one more Type to that TLV, is that
an “Update”? (???)
Our view is that it is not — it’s a natural extension of a protocol (defined to
be extended by defining new types) but the procedures of the former are not
changed by the existence of the new Type defined in the latter.
Section 1.2 states that the update is applicable to RFC 6424.
It says that RFC 6424 can use the new Multipath Information Type defined. It
does not say that the procedures in RFC 6424 change. (that text can be updated
though)
Does defining a new OSPF RI TLV update RFC4970/7770? (???)
As an aside, what constitutes an “Update” could use some more precision,
perhaps.
Thanks,
— Carlos.
Thanks,
Acee
Thanks,
— Carlos.
On Aug 12, 2016, at 11:35 AM, The IESG
<iesg-secretary(_at_)ietf(_dot_)org<mailto:iesg-secretary(_at_)ietf(_dot_)org>>
wrote:
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS
Network using Entropy Labels (EL)'
<draft-ietf-mpls-entropy-lsp-ping-04.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by
2016-08-26. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> instead. In
either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping
and Traceroute are methods used to test Equal-Cost Multipath (ECMP)
paths. Ping is known as a connectivity verification method and
Traceroute as a fault isolation method, as described in RFC 4379.
When an LSP is signaled using the Entropy Label (EL) described in RFC
6790, the ability for LSP Ping and Traceroute operations to discover
and exercise ECMP paths is lost for scenarios where LSRs apply
different load balancing techniques. One such scenario is when some
LSRs apply EL-based load balancing while other LSRs apply non-EL
based load balancing (e.g., IP). Another scenario is when an EL-
based LSP is stitched with another LSP which can be EL-based or non-
EL based.
This document extends the MPLS LSP Ping and Traceroute multipath
mechanisms in RFC 6424 to allow the ability of exercising LSPs which
make use of the EL. This document updates RFC 4379, RFC 6424, and
RFC 6790.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-lsp-ping/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-lsp-ping/ballot/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/2802/
https://datatracker.ietf.org/ipr/2305/
https://datatracker.ietf.org/ipr/2546/
https://datatracker.ietf.org/ipr/2221/