From nobody Mon Jan 4 05:40:27 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12C1A88CA; Mon, 4 Jan 2016 05:40:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160104134024.3534.91683.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 05:40:24 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 13:40:24 -0000 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 : Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) Authors : Nobo Akiya George Swallow Carlos Pignataro Andrew G. Malis Sam Aldrin Filename : draft-ietf-mpls-entropy-lsp-ping-02.txt Pages : 21 Date : 2016-01-04 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal-Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC 6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when 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 mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of the Entropy Label. This document updates RFC 4379, RFC 6424, and RFC 6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-lsp-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-entropy-lsp-ping-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-entropy-lsp-ping-02 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 4 19:10:28 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B71ACED8; Mon, 4 Jan 2016 19:10:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 19:10:27 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:10:27 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The text related to when the URO is used of not clear, and I think it could even result in technical incompatibility. I don't think that this main concern raises to the level of a DISCUSS since it should be resolved easily (but it might be close). In short, it is not completely clear when the URO should be considered in light of the rules in RFC6374; it is not completely clear if the rules in RFC6374 always take precedence. Here are the specifics of my concern: Section 4.2. (Receiving an MPLS PM Query Request) says that "in addition" to the processing in RFC6374, "with a URO present, then the responder SHOULD use that IP address and UDP port to send MPLS-PLDM response back to querier." RFC6374 says that the "Source Address of a query message SHOULD be used as the destination for an out-of-band response unless some other out-of-band response mechanism has been configured, and unless a Return Address object is present, in which case the Return Address specifies the target of the response." Several questions/observations: * What does the phrase "in addition" mean in 4.2? I'm interpreting it as adding rules to what RFC6374 says. IOW, this document seems to be updating what RFC6374 says (or at least adding extra rules if the URO is present). Is that the intent? * As far as I can tell, there is no restriction for having both a Return Address object and the URO in the same query, right? If so, and if the intent is *not* to update RFC6374, then it seems (from the text in RFC6374) that the URO would never be used (if a Return Address object is also present). * Nitpicking a little at the meaning/interpretation of "configuration". RFC6374 mentions (from above) "some other out-of-band response mechanism has been configured", but as you imply in (i.e as I interpret) Section 5. (Manageability Considerations) the mechanism in this document is signaling, not configuration: "Nothing in this document precludes the use of a configured UDP/IP return path in a deployment in which configuration is preferred to signalling." Yes, you could configure the system to prefer the URO signaling.. * The point with all this is that it is not clear what exactly is meant, and that the current text can result in more than one (defensible) interpretation. * Small nit from the text quoted above in section 4.2: the response may in fact not go back to the querier. I have a couple of other minor comments: 1. Section 3. (Solution Overview) says (in the first sentence) that if the URO "is present in a MPLS-PLDM Query, the responder MUST use the IP address and UDP port in the URO to reply back to the querier". Clearly related to the comments above, but also an incomplete statement: as explained in 4 and 4.1, the Control Code should also be set to "Out-of-band Response Requested". Comments/questions: * [Nit] I don't think there's anything explicitly wrong with that first sentence, but it just doesn't sound right because of the conditional MUST ("unless configured otherwise"). You might want to consider something like this instead: "This document specifies that if the Control Code of the MPLS-PLDM query is set to "Out-of-band Response Requested", and a UDP Return Object (URO) is present in a MPLS-PLDM Query, the responder SHOULD use the IP address and UDP port in the URO to reply back to the querier." * What happens the URO is received in a query that doesn't have the correct Control Code? 2. Section 3.1. (UDP Return Object) * What happens if the URO contains an address not supported by the receiver? * "The URO MUST NOT appear in a response." What should the receiver do if it does? Should it ignore the URO or the whole datagram? 3. s/MPLS-PM (and MPLS PM)/MPLS-PLDM From nobody Mon Jan 4 23:56:29 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7F1B2C43; Mon, 4 Jan 2016 23:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrbjXdaUunfR; Mon, 4 Jan 2016 23:56:27 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5171B2BB4; Mon, 4 Jan 2016 23:56:27 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.203.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4D65A180137F; Tue, 5 Jan 2016 08:56:23 +0100 (CET) To: "mpls@ietf.org" , draft-ietf-mpls-entropy-lsp-ping@ietf.org From: Loa Andersson Message-ID: <568B7723.3000705@pi.nu> Date: Tue, 5 Jan 2016 15:56:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 07:56:28 -0000 Working Group, The authors of draft-ietf-mpls-entropy-lsp-ping has told us that the document is ready to be considered for working last call. We will start an IPR poll prior to the start of the wglc. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-entropy- lsp-ping? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are three IPR disclosures filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 5 08:37:15 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED81A87BB; Tue, 5 Jan 2016 08:37:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105163714.22863.53937.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 08:37:14 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Alia Atlas' Yes on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 16:37:14 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: Yes 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The introduction uses a MUST for the receiver to use the URO, but the later text uses SHOULD. Could you please clarify and make them the same? From nobody Tue Jan 5 08:44:58 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D91A8A15; Tue, 5 Jan 2016 08:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJTeOffc0P5L; Tue, 5 Jan 2016 08:44:56 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A371A8A20; Tue, 5 Jan 2016 08:44:56 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id o62so272012269oif.3; Tue, 05 Jan 2016 08:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rCOM/DhaB1Y2cY6lQZwRtlgoUUpcOvqdj2m5frFlfhA=; b=mYuDLJV7868GwdZQ5HWqQe5OMTRuOhP3ShTQGojGCMM6ex4NBshtvpozxYf241W2Xt 8InZ/S6rJdhX2e/2EM9v0tpyniGzL7oDkVbOn/RV3mcl6ojvplMzO1/H5lNea7Tz91VZ oue9Zi59/xQtuCVoao8oByuGZZG5SGAywDMnLHTAwkP5DcmOJil7LS/eg7Ku8U0FQj4W b22wPG/wApfpvSkKqR7Ayu2o9LuT8sBDWVIlNtQyWhqHpbozjHw93iXTDpvfrc6pHtoM k5GPLDPycWZ7E0cdwR3ND6ypuyoyacxL2+tmk8PC7mHBstOVPGsk8DS3uZRpAy1/64wj RSig== X-Received: by 10.202.104.156 with SMTP id o28mr65391870oik.126.1452012295434; Tue, 05 Jan 2016 08:44:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.41 with HTTP; Tue, 5 Jan 2016 08:44:36 -0800 (PST) In-Reply-To: <568B7723.3000705@pi.nu> References: <568B7723.3000705@pi.nu> From: "Andrew G. Malis" Date: Tue, 5 Jan 2016 11:44:36 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a114099b41437b6052898f52f Archived-At: Cc: "mpls@ietf.org" , draft-ietf-mpls-entropy-lsp-ping@ietf.org, "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 16:44:57 -0000 --001a114099b41437b6052898f52f Content-Type: text/plain; charset=UTF-8 Loa, I am not aware of any IPR that applies to this draft. Thanks, Andy On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson wrote: > Working Group, > > The authors of draft-ietf-mpls-entropy-lsp-ping has told us that > the document is ready to be considered for working last call. > > We will start an IPR poll prior to the start of the wglc. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-entropy- > lsp-ping? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There are three IPR disclosures filed directly against this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a114099b41437b6052898f52f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

I am not aware of any IPR that app= lies to this draft.

Thanks,
Andy


On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

The authors of draft-ietf-mpls-entropy-lsp-ping has told us that
the document is ready to be considered for working last call.

We will start an IPR poll prior to the start of the wglc.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-entropy-
lsp-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There are three IPR disclosures filed directly against this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a114099b41437b6052898f52f-- From nobody Tue Jan 5 09:01:08 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0F61ACE9B; Tue, 5 Jan 2016 09:01:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105170104.3818.25141.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 09:01:04 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Stephen Farrell's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 17:01:05 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There were changes that seem to have been agreed as as result of the secdir review. [1] Some of those could I think nearly but not quite be discuss level, but as they aren't and the discussion seems to have started, I'll ballot no-objection but I do hope that the promised changes get made, and I'd recommend cycling back to the secdir reviewer (Sandy Murphy) as it wasn't clear to me that the discussion reached closure just before the holidays. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06296.html - Could this be used as a way to nicely disguise a DoS? I'm not sure if that's new to this or not though. - Thanks for the applicability statement in the security considerations. Makes me wonder about MPLS/UDP but sure. - Saving a single bit to distinguish address families via length seems unwise here, as everywhere. From nobody Tue Jan 5 11:13:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA60E1A0636; Tue, 5 Jan 2016 11:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqB6-XBJpamM; Tue, 5 Jan 2016 11:13:24 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A741A036D; Tue, 5 Jan 2016 11:13:24 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id p203so302307745lfa.0; Tue, 05 Jan 2016 11:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0KvZwlNr7i2g6hmHurisOhZU/gCKKc9/rxVRhrGC5Jk=; b=r6aAPeV3TMOtydFKAgY1g17m+b0/rzsK58ge64QXfkdoX58hwWF55PH67ONH9zM1AX Up7nOjcMiCryYm92N7s/QIrHtel10jVCyivm6QIhkTYxYLZV/oJIPXMkxEOfNoSgwarS C53Axtuh2bCs35bVFwAmvBYAvpDPfUF+ELQZNj+MoOPGi9qIYK2NMJcPR94M0iE6nFBl HQqeTce8BF3HWoIrVL/64ZilZtxrm6TjxX7838Wb5bzCvmAZQ7NjXcKYct1r6sFMd1Ih knqMt96fqvKM9VChXF5g3i/kvJh1YG440v5+nB88MpSTjubBm8S89EqDJZDmt+GjNcdg MBbw== MIME-Version: 1.0 X-Received: by 10.25.145.81 with SMTP id t78mr34355357lfd.86.1452021202508; Tue, 05 Jan 2016 11:13:22 -0800 (PST) Received: by 10.112.5.37 with HTTP; Tue, 5 Jan 2016 11:13:22 -0800 (PST) In-Reply-To: References: <568B7723.3000705@pi.nu> Date: Tue, 5 Jan 2016 11:13:22 -0800 Message-ID: From: Sam Aldrin To: "Andrew G. Malis" Content-Type: multipart/alternative; boundary=001a1140043cfb63ee05289b07d3 Archived-At: Cc: "mpls@ietf.org" , draft-ietf-mpls-entropy-lsp-ping@ietf.org, "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:13:26 -0000 --001a1140043cfb63ee05289b07d3 Content-Type: text/plain; charset=UTF-8 I am not aware of any IPR related to this draft. -sam On Tue, Jan 5, 2016 at 8:44 AM, Andrew G. Malis wrote: > Loa, > > I am not aware of any IPR that applies to this draft. > > Thanks, > Andy > > > On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson wrote: > >> Working Group, >> >> The authors of draft-ietf-mpls-entropy-lsp-ping has told us that >> the document is ready to be considered for working last call. >> >> We will start an IPR poll prior to the start of the wglc. >> >> This mail starts the IPR poll. >> >> Are you aware of any IPR that applies to draft-ietf-mpls-entropy- >> lsp-ping? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> There are three IPR disclosures filed directly against this document. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> >> /Loa >> mpls wg co-chair >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > > --001a1140043cfb63ee05289b07d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this draft.

<= /div>
-sam

On Tue, Jan 5, 2016 at 8:44 AM, Andrew G. Malis = <agmalis@gmail.co= m> wrote:
= Loa,

I am not aware of any IPR that applies to this draf= t.

Thanks,
Andy


On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson <loa@pi.nu<= /a>> wrote:
Working Group,

The authors of draft-ietf-mpls-entropy-lsp-ping has told us that
the document is ready to be considered for working last call.

We will start an IPR poll prior to the start of the wglc.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-entropy-
lsp-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There are three IPR disclosures filed directly against this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64


--001a1140043cfb63ee05289b07d3-- From nobody Tue Jan 5 12:43:24 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8172D1A90F9; Tue, 5 Jan 2016 12:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU5Ng9TlQjLK; Tue, 5 Jan 2016 12:43:21 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2541A90EE; Tue, 5 Jan 2016 12:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7865; q=dns/txt; s=iport; t=1452026601; x=1453236201; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5fAQDueh9qlflhn8BE/bz3fttCeEu2DDW0Fpnnml5/8=; b=TmS6QZ52aclRWEnXyColM0pFVWuSFNfLdWLgQKLt5Dp/n5dZJZL2NeRZ AKuhzQBpBRAg1FDCc0P86h9ufVtLYHN5owViwDGkbhw4Ooks91SyKhF3t 2v4Vaiv8jc6HnXtuNFgIVt82QtiWIIXkHNX54trYYhEIa6Sj3O4Xhsvh9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgAiKoxW/5tdJa1egm5MgT8GiFOza?= =?us-ascii?q?QENgWSGDwKBHzgUAQEBAQEBAYEKhDQBAQEEawMGBQ4CAgEIEQMBAigHGwYRFAk?= =?us-ascii?q?IAgQBDQWIGgMSv0INgmsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBItRgk+BVxACA?= =?us-ascii?q?SMbhEUFkwqDfgGLWoF4gVyER4hahmeHWQEgAQFChApyhFmBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,526,1444694400"; d="scan'208,217";a="223864574" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2016 20:43:20 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u05KhKwp003138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 20:43:20 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 14:43:19 -0600 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 14:43:19 -0600 From: "George Swallow (swallow)" To: Sam Aldrin , "Andrew G. Malis" Thread-Topic: IPR poll on draft-ietf-mpls-entropy-lsp-ping Thread-Index: AQHRR46WpGw1IvtkuUiSpM7X/pcHTZ7thjAAgAApkQD//8VOgA== Date: Tue, 5 Jan 2016 20:43:19 +0000 Message-ID: References: <568B7723.3000705@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.212.3] Content-Type: multipart/alternative; boundary="_000_D2B194B012F7BDswallowciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-lsp-ping@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:43:23 -0000 --_000_D2B194B012F7BDswallowciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR for the subject draft other than that which was d= isclosed in IPR statement 2546. George From: Sam Aldrin > Date: Tuesday, January 5, 2016 at 2:13 PM To: "Andrew G. Malis" > Cc: Loa Andersson >, "mpls@ietf.org" >, "draft-ietf-mpls-entropy= -lsp-ping@ietf.org" >, "mpls-chairs@ietf.org" > Subject: Re: IPR poll on draft-ietf-mpls-entropy-lsp-ping I am not aware of any IPR related to this draft. -sam On Tue, Jan 5, 2016 at 8:44 AM, Andrew G. Malis > wrote: Loa, I am not aware of any IPR that applies to this draft. Thanks, Andy On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson >= wrote: Working Group, The authors of draft-ietf-mpls-entropy-lsp-ping has told us that the document is ready to be considered for working last call. We will start an IPR poll prior to the start of the wglc. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-entropy- lsp-ping? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are three IPR disclosures filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_D2B194B012F7BDswallowciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR for the subject draft other than that which = was disclosed in IPR statement 2546.

George

From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Tuesday, January 5, 2016 at 2= :13 PM
To: "Andrew G. Malis" <= ;agmalis@gmail.com>
Cc: Loa Andersson <loa@pi.nu>, "m= pls@ietf.org" <mpls@ietf.org>, "= draft-ietf-mpls-entropy-lsp-ping@ietf.org" <draft-iet= f-mpls-entropy-lsp-ping@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: Re: IPR poll on draft-ietf= -mpls-entropy-lsp-ping

I am not aware of any IPR related to this draft.

-sam

On Tue, Jan 5, 2016 at 8:44 AM, Andrew G. Malis = <agmalis@gmail.co= m> wrote:
Loa,

I am not aware of any IPR that applies to this draft.

Thanks,
Andy


On Tue, Jan 5, 2016 at 2:56 AM, Loa Andersson <loa@pi.nu>= wrote:
Working Group,

The authors of draft-ietf-mpls-entropy-lsp-ping has told us that
the document is ready to be considered for working last call.

We will start an IPR poll prior to the start of the wglc.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-entropy-
lsp-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There are three IPR disclosures filed directly against this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair
--


Loa Andersson                 =       email: loa@mail01.huawei.com
Senior MPLS Expert                &= nbsp;         loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


 --_000_D2B194B012F7BDswallowciscocom_-- From nobody Tue Jan 5 13:01:05 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6891A911B; Tue, 5 Jan 2016 13:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMwEEGMbAiTf; Tue, 5 Jan 2016 13:01:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6531A9114; Tue, 5 Jan 2016 13:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2955; q=dns/txt; s=iport; t=1452027662; x=1453237262; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MdFc6/fElLlGsUGMovcZMEMJnc6/CZqvky7vH7HNrQA=; b=bJc+CJ7WUCbUZ7PzxQmwuv+cSHRhS3HjMGfWGavlULJYgTdO5VHcTS1k 8E8jXo+mn4OofSwkhFal29AVWB6L0MdcZsiKM5dc4AsLNJMtPATE+F1zF rVjKONX3kqkU39eSb8FYw2XsxwKSs0uS61I569Kmy1cojHS3SOoi+LYuT Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgCjLYxW/xbLJq1ehHkGiFOzaQ6BZ?= =?us-ascii?q?IYPAoFXFAEBAQEBAQGBCoQ0AQEBAwEjSAMGBQUJAgIBCBgqAgIbFyUCBA4FDog?= =?us-ascii?q?ZCLFVkGsBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQSGUoIPgnCEJhACAYM6LoEbB?= =?us-ascii?q?ZcIAYJygWWIe4FchEeIWo5AASABQ4QKcoRZgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,526,1444694400"; d="asc'?scan'208";a="631398103" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2016 21:01:00 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u05L0wS3011209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 21:01:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 16:00:57 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 16:00:57 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: IPR poll on draft-ietf-mpls-entropy-lsp-ping Thread-Index: AQHRR46WppSo2dHH/kOu2s/GQ06pDJ7tvQyA Date: Tue, 5 Jan 2016 21:00:57 +0000 Message-ID: <04FD8C63-13AF-4B49-BDDE-F5F19A4DCF0D@cisco.com> References: <568B7723.3000705@pi.nu> In-Reply-To: <568B7723.3000705@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.81.8.176] Content-Type: multipart/signed; boundary="Apple-Mail=_2FB83F1F-59B0-4FCD-9039-960BE605466F"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-lsp-ping@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 21:01:04 -0000 --Apple-Mail=_2FB83F1F-59B0-4FCD-9039-960BE605466F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Loa, I am not aware of any relevant IPR for the subject draft, other that = what=E2=80=99s already been disclosed. Thanks, =E2=80=94 Carlos. > On Jan 5, 2016, at 2:56 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > The authors of draft-ietf-mpls-entropy-lsp-ping has told us that > the document is ready to be considered for working last call. >=20 > We will start an IPR poll prior to the start of the wglc. >=20 > This mail starts the IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-entropy- > lsp-ping? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > There are three IPR disclosures filed directly against this document. >=20 > If you are listed as a document author or contributor please respond = to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > /Loa > mpls wg co-chair > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 --Apple-Mail=_2FB83F1F-59B0-4FCD-9039-960BE605466F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWjC8JAAoJEIXgpQGOZny9wxsQAKS1ONidB6+6psW5zH6txK9h N6A/pucB5cGLLhengmj+z7CNITqI2C+/5rbqTjowgWG4BPbMWuJ4T0+0pCLLNPcA Dq5ex1j9Pd/HFfiI7Bw/R9JGc4Vzr3PzUvIv23Jd0b4zKiBXL7vObe5i93+6S6cz HQt7EdfaaF9tIN28v6nUbqa2Agn0YyzDeRiyZpSDWZnxV3AWUIH69uf8YAq+kK3U jijRmAd3xZdEB4HYV69QuogfpdXnt6obyODRTPUxmPMrATc9Zn0G1EUcQBJYLMKZ KPl4Of9VgqzqiqIRC7nbf7HUrtF3cto/fCn5XBhDlKWCXI1YoLK26K/GIrcka273 l9K8VJgwTxjMk2/hOFeAc9mY08OXb+jMmt5Qh/xEe7bQSQsDQsc0Ygu5VHxCXy8+ DhMLLney6Y7sTKrdem432wj+hkboRlBBWy9y5dqvvPXptNzRrPMRzVVNXkcPJoRA 6MV1y0Z/PrTxL7kQoIQ7qOVoUobkQkxZTm1FvFlD9QR5B9V4BU5xnpwFZMfbHL5f CSSRu59oE/tTwJdyfFdrv9IM3VIc2e8JeIdbh+od5BwFaQBVxtvwmvIyentk9+9c bT4UJsiX/UHk2yLGR1eucwnS9S8bdo+toeVg/Lg/ivXN2JQF5uGTTnbDI45ldUPC 1Bm4CzO2uGE1PX1zhSjW =8iv+ -----END PGP SIGNATURE----- --Apple-Mail=_2FB83F1F-59B0-4FCD-9039-960BE605466F-- From nobody Tue Jan 5 13:47:08 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2E31A92F4; Tue, 5 Jan 2016 13:47:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 13:47:06 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 21:47:06 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am in favour of publishing this document, but I have two major points that are not addressed in the document by now: 1) It is not clear for anybody what the expected size and sending frequency of such MPLS-PLDM over IP/UDP responses are. This will influence any measures an operator has to take in order to assure that there is no congestion caused by these messages. I can understand that this cannot be foreseen, but a few words considering this fact are excellent to have in the document. 2) This leads to my second point: the lack of any reference to RFC 5405 "Unicast UDP Usage Guidelines for Application Designers" and the content out of this RFC that is applicable for this draft. There is no discussion about this at all. Please note well that this is BCP 145. With regard to point 2): I can try to find some help from the transport area, in case you need help. From nobody Tue Jan 5 23:02:54 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 039C21ACD39; Tue, 5 Jan 2016 23:02:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106070253.11743.55096.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 23:02:53 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Barry Leiba's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 07:02:54 -0000 Barry Leiba has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 3 -- Multiple UROs MAY be present in a MPLS-PLDM Query indicating that an identical responses SHOULD be sent to each address-port pair. A small point: I think this is not meant to be instructions to the entity issuing the query, but to the entity responding. Is that correct? If so, the "MAY" is a statement of fact, not a normative requirement, so it should be "may" (or "might"). Also, the word "an" should be removed. -- Sections 4.x -- Should the subsection titles of 4.1, 4.2, 4.3, and 4.4 say "MPLS-PLDM" instead of "MPLS-PM"? From nobody Wed Jan 6 03:06:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6352B1ACEA5 for ; Wed, 6 Jan 2016 03:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goa3itxywh8M for ; Wed, 6 Jan 2016 03:06:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24B1ACE72 for ; Wed, 6 Jan 2016 03:06:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1848F180011; Wed, 6 Jan 2016 03:05:54 -0800 (PST) To: yakov@juniper.net, erosen@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160106110554.1848F180011@rfc-editor.org> Date: Wed, 6 Jan 2016 03:05:54 -0800 (PST) Archived-At: Cc: equinox@opensourcerouting.org, rfc-editor@rfc-editor.org, mpls@ietf.org Subject: [mpls] [Technical Errata Reported] RFC3107 (4582) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 11:06:51 -0000 The following errata report has been submitted for RFC3107, "Carrying Label Information in BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3107&eid=4582 -------------------------------------- Type: Technical Reported by: David Lamparter Section: GLOBAL Original Text ------------- [... section 3: ...] A BGP speaker can withdraw a previously advertised route (as well as the binding between this route and a label) by either (a) advertising a new route (and a label) with the same NLRI as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field should be set to 0x800000. (Of course, terminating the BGP session also withdraws all the previously advertised routes.) 4. Advertising Multiple Routes to a Destination A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination, as long as each such route has its own label(s). The encoding described above allows a single BGP Update message to carry multiple routes, each with its own label(s). In the case where a BGP speaker advertises multiple routes to a destination, if a route is withdrawn, and a label(s) is specified at the time of withdrawal, only the corresponding route with the corresponding label is withdrawn. If a route is withdrawn, and no label is specified at the time of withdrawal, then only the corresponding unlabeled route is withdrawn; the labeled routes are left in place. [...] Corrected Text -------------- -- ALTERNATE 1: require label value -- A BGP speaker can withdraw a previously advertised route by either (a) advertising a new route with the same NLRI (including label) as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field MUST be set to the value previously announced. (Of course, terminating the BGP session also withdraws all the previously advertised routes.) The binding between route and label cannot be updated to change the label without withdrawing the old label and sending an update with the new label. [keep section 4 unchanged] -- ALTERNATE 2: drop multiple label support -- A BGP speaker can withdraw a previously advertised route (as well as the binding between this route and a label) by either (a) advertising a new route (and a label) with the same prefix as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field should be set to 0x800000. (Of course, terminating the BGP session also withdraws all the previously advertised routes.) [remove section 4, remove capability "4" in section 5] -- ALTERNATE 3: clarify implications of capability "4" -- [optionally, change section 3:] The label information carried (as part of NLRI) in the Withdrawn Routes field SHOULD be set to the value previously announced. [insert section 5.1:] 5.1. Implications of Multiple Routes Capability Implementing the "multiple routes" capability introduced above slightly changes the processing of update and withdraw messages to requiring an exact match on the label, i.e. including it in NLRI comparisons. To ensure interoperability, an implementation that has this capability SHOULD NOT send updates with different label values on a session whose peer does not advertise the capability. The peer would in this case only hold the latest update, possibly introducing label oscillations. Further, the implementation MUST process incoming updates and withdraws on such sessions as if their labels were wildcards, removing any previous routes with the same prefix. It MUST NOT hold the same prefix with any but the last seen label value on these sessions. Notes ----- This issue was previously discussed in https://osdir.com/ml/ietf.idr/2004-06/msg00010.html https://osdir.com/ml/ietf.idr/2004-06/msg00018.html Sections 3 and 4 are inherently conflicting. The conflict is: Section 3 states a withdraw "should" be sent with a null label/BoS=1. This means it's not possible to withdraw a specific labeled route, instead all routes with the given prefix would need to be withdrawn. However, section 4 specifies exact-match behavior for processing updates and withdraws. Also, the Section 3 text is semantically/editorially wrong in itself, saying (shortened) "withdraw [...] binding [... by] new route (and a label) with the same NLRI". However, the label is part of the NLRI; an update with the same NLRI could thus not withdraw the binding, only possibly cause it to not be selected as best path anymore by updating attributes. I have not checked what other implementations do; Quagga (which only implements this as route reflector): - does not implement SAFI 4, but applies the behavior on SAFI 128 (VPN) - does not advertise capability 4 - excludes the label value from all comparisons - will only keep the last label value received - will set the label on withdraws to all zeroes (ignoring the recommended value) Note that, as with Quagga, this also affects BGP-VPN implementations since these essentially inherit the behavior. Also note that the "Multiple Routes Capability" is global over all AFI/SAFI pairs. P.S.: Out of curiosity / for IDR mailing list: for anyone implementing 3107 or 4364: does your implementation include/advertise the "multiple routes" capability? Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3107 (draft-ietf-mpls-bgp4-mpls-04) -------------------------------------- Title : Carrying Label Information in BGP-4 Publication Date : May 2001 Author(s) : Y. Rekhter, E. Rosen Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Jan 6 12:02:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE671A01AA; Wed, 6 Jan 2016 12:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh-QDuyFFOeO; Wed, 6 Jan 2016 12:02:20 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7B81A01D7; Wed, 6 Jan 2016 12:02:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id u188so73097373wmu.1; Wed, 06 Jan 2016 12:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:references:in-reply-to :mime-version:message-id:cc:from:subject:date:to; bh=F4tWwZIwlu6/RwNlSHE6pe8TzvCqdEOzaExVhev4Esk=; b=c0rlcSFYmdE2cfG9HcZ9HcxEJjOujmJ01JNfh4ZE2jKxlL7wRxYJDV9bXEuzSZRMX6 ZKkkwTHxlykbp8dG5BbYqnezMw1d+lKQa6kdTISPYTunbMU6JjAojdulwYkWOQN28sC4 ybM1jvg3XfurWA8bAo/HtarxOuP6HI+cUcGRVlC9ScCDxSHK+Dd3AXTRcghw/QHTH7/U xpKqZrBHsqiaqWLXNAQXPZO6F4BG9ifcjrWmWAXErgzwqd8Wr47BNZHYYKOCDltSBgck z48Wa60A50uLdiWJmWullOL9dBlVPhZslYoNoOsK/YjuaPqwRjDumvCvTunQP0Hs4R7s sPBA== X-Received: by 10.28.134.147 with SMTP id i141mr12800318wmd.87.1452110522589; Wed, 06 Jan 2016 12:02:02 -0800 (PST) Received: from [192.168.2.101] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l194sm10263547wmb.14.2016.01.06.12.02.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 12:02:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> In-Reply-To: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) Message-Id: From: Gmail Date: Wed, 6 Jan 2016 17:10:40 +0000 To: Martin Stiemerling X-Mailer: iPad Mail (13C75) Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, The IESG , mpls-chairs@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:02:21 -0000 Martin It is a fundamental tenet of MPLS is that the network is well managed with t= he operators paying significant attention to traffic planning, I therefore t= hink that it is reasonable to assume that they would also pay adequate atten= tion to their UDP management traffic. Loss is so light in these networks that the interval between loss measuremen= ts needs to be long to see any loss at all, thus I would normally expect us t= o be talking packets per minute or packets per hour rather than packets per s= econd, and this would be on links with GB+ capacity. Similarly it makes litt= le sense to make delay measurements very frequently. In both cases the amount of traffic will be minuscule compared to the IPFIX o= ver UDP traffic that that many operators will already will running. I thus fear that you raise the congestion daemon without proper regard to th= e practicalities of this type of application. Stewart.=20 Sent from my iPad > On 5 Jan 2016, at 21:47, Martin Stiemerling wrote: >=20 > Martin Stiemerling has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I am in favour of publishing this document, but I have two major points > that are not addressed in the document by now: >=20 > 1) It is not clear for anybody what the expected size and sending > frequency of such MPLS-PLDM over IP/UDP responses are. This will > influence any measures an operator has to take in order to assure that > there is no congestion caused by these messages. I can understand that > this cannot be foreseen, but a few words considering this fact are > excellent to have in the document.=20 >=20 > 2) This leads to my second point: the lack of any reference to RFC 5405 > "Unicast UDP Usage Guidelines for Application Designers" and the content > out of this RFC that is applicable for this draft. There is no discussion > about this at all. Please note well that this is BCP 145.=20 >=20 > With regard to point 2): I can try to find some help from the transport > area, in case you need help. >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jan 6 12:32:40 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 079001A0377; Wed, 6 Jan 2016 12:32:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106203238.32338.922.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 12:32:38 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:32:38 -0000 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 : Use Cases and Requirements for MPLS-TP multi-failure protection Authors : Zhenlong Cui Rolf Winter Himanshu Shah Sam Aldrin Masahiro Daikoku Filename : draft-cui-mpls-tp-mfp-use-case-and-requirements-06.txt Pages : 8 Date : 2016-01-06 Abstract: For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-cui-mpls-tp-mfp-use-case-and-requirements-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-cui-mpls-tp-mfp-use-case-and-requirements-06 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 6 12:42:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B81A03A1 for ; Wed, 6 Jan 2016 12:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eMBCnHPphrz for ; Wed, 6 Jan 2016 12:42:12 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FDB1A012F for ; Wed, 6 Jan 2016 12:42:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 69B1210BB49 for ; Wed, 6 Jan 2016 21:42:11 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0NJiE86zWBR for ; Wed, 6 Jan 2016 21:42:11 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 481C110BB48 for ; Wed, 6 Jan 2016 21:42:09 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.84]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Wed, 6 Jan 2016 21:41:47 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-06.txt Thread-Index: AQHRSMF59aZuJL6NaUK+7sBDYI6Sr57u8uEQ Date: Wed, 6 Jan 2016 20:41:47 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DA9CE32B2@PALLENE.office.hd> References: <20160106203238.32338.922.idtracker@ietfa.amsl.com> In-Reply-To: <20160106203238.32338.922.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:42:14 -0000 Hi, we just submitted a new version of this document which addresses the MPLS-R= T comments made some time ago (sorry for the delay). What we are really interested in is to gauge whether there is interest in w= orking on a solution to the problem described in this document and if the W= G agrees to the requirements on such a solution. Best, Rolf NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Mittwoch, 6. Januar 2016 21:33 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and- > requirements-06.txt >=20 >=20 > 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. >=20 > Title : Use Cases and Requirements for MPLS-TP multi- > failure protection > Authors : Zhenlong Cui > Rolf Winter > Himanshu Shah > Sam Aldrin > Masahiro Daikoku > Filename : draft-cui-mpls-tp-mfp-use-case-and- > requirements-06.txt > Pages : 8 > Date : 2016-01-06 >=20 > Abstract: > For the Multiprotocol Label Switching Transport Profile (MPLS-TP) > linear protection capable of 1+1 and 1:1 protection has already been > defined. That linear protection mechanism has not been designed for > handling multiple, simultaneously occuring failures, i.e. multiple > failures that affect the working and the protection entity during > the > same time period. In these situations currently defined protection > mechanisms would fail. >=20 > This document introduces use cases and requirements for mechanisms > that are capable of protecting against such failures. It does not > specify a multi-failure protection mechanism itself. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and- > requirements/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-cui-mpls-tp-mfp-use-case-and- > requirements-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-cui-mpls-tp-mfp-use-case-and- > requirements-06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jan 6 14:53:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1CD1A1B5E for ; Wed, 6 Jan 2016 14:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qgFW1vN9IGX for ; Wed, 6 Jan 2016 14:53:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0161D1A1B5A for ; Wed, 6 Jan 2016 14:53:19 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.28.32.102] (66.129.241.14) by SN1PR0501MB2157.namprd05.prod.outlook.com (10.163.229.151) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 22:53:01 +0000 To: RFC Errata System , , , , , , References: <20160106110554.1848F180011@rfc-editor.org> From: Eric C Rosen Message-ID: <568D9AC7.2010303@juniper.net> Date: Wed, 6 Jan 2016 17:52:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160106110554.1848F180011@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR08CA050.namprd08.prod.outlook.com (10.141.248.168) To SN1PR0501MB2157.namprd05.prod.outlook.com (25.163.229.151) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 2:7dfr3RY4DWNYScH8QR9MmT+93lM7uQ3DVUZJVmZMzsz/6S2JYsEfpaowgV9sq/vo7b5HJ2LjW+XO2SNZ+3inC0Z/Hh/rZ961JU4y3/FOtCuVhE8kp3qApK//gHT3znPZDZSyR/SVocAV+JGYCsDn9g==; 3:PX8NLpTjbAZENxLnEkEr/2478X7ODBp4H5wylZDmo7646GEvk1t3+g0fVjU+d66O/vm723IEo7cHhekZEr6FrFALh3z0hO+2WTq+nvx2yBbnadhyKhOBVZ4vwQzHvu22; 25:vxzNB6CBs8zOMuvsAGUKssBJjOzJ/p4XOc4QVepyBdw3srHnakm5JSrm0d4B9b38kwvabGGtdVLoOjenXIL2JLhngQS1vJr+Uj+dGGBHhGHk7t2SX+7Wc+XaVpVB6IHTqFGhP0elMJBF96FQ6wc7q8ld2vjAps4QdiIjrILJtDB5OMrhziLrFq3wxfj3T894JgCQTHUJyjbmfm1z0CTRUA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2157; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 20:fACQi+TCPcuYOKS/CmacRtELzQAQpAdA2prQMdl4EJjLAzX3gU6KsW90g6IQamta/axEoTH9h0i2CG9rIEbAQfGDTEKXCNvq8NDXOgjwxfeTNntqHD0Vr9fCkXisCYovA2K5j4zhNjFSB6bSRIb4jRVNXRQoGHBpV/7/oaD9B11uyEZlCfs/qJZuSntZxPg9ISKvFTwY77KaCfRgaf3N8TydSob7QKCg7VaLugmJEgo8UmCm42DJAQrwoo53rxk1wpjXQtJzDv/2tfFQD/uC3sSlFEUYZJfWAi+yHfu7DsOFPhuKZxMAzTBClXHCVsdVZz+VFX+ULNJTThISekv//GvVHLm6cPJj3LnYXbTEFwciamCpwRvkyVaqj35pCmLCAI8HBqpSFiGyQRbFUrKDUVIU0t7LohycM+zR5M9AW/eyBPgZ+QGa1J9M+MOJ7f0XiILUS/Oq6ugl2TjGE0YegcMt8uJdP4MyIolJEGAWmluTm2X1pxBiylXNmg0aolVw; 4:ee3XU2O9f+GybnhjpK8BsW20vwDCmX7a1jQXNfsScAYFIgxby+VdW3MoqaA5fPAaX8sUXeqZUNhyjoa+pGBDLgR4FxryhAwQ3I7B2cxFY46lEOAG1nTdzd12uP2F5m35fHK/C4GFS7KdxbWZdZgzvCSyPoKtBhKQumdHhe19wvA/sexbx++v97JNbOLeT9aEI0mlaaH6p3vB12suJ2J4Ul2ViSd5N0+/AxNxuyUl1gugG5BPKDGwXPdeYRnTgWSEi6uyLqJ6m9EeKlvR/IX60Mjr29BVznWDP3l0a2bfIV5AH4o9I98dVdAaWvW3Oe8qjVms+rNWyuo6bhI4I/2s/rpUsSTVARJ7Hux9mG45wODz4Y7thRuPOV69S36il9Bp X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:SN1PR0501MB2157; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2157; X-Forefront-PRVS: 0813C68E65 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(65956001)(92566002)(65806001)(87976001)(65816999)(83506001)(97736004)(1941001)(105586002)(2201001)(2906002)(50466002)(4001450100002)(106356001)(4001350100001)(1096002)(2950100001)(86362001)(101416001)(36756003)(5004730100002)(77096005)(5008740100001)(66066001)(189998001)(80316001)(3846002)(42186005)(47776003)(40100003)(64126003)(122386002)(59896002)(23746002)(6116002)(81156007)(87266999)(33656002)(5001770100001)(5001960100002)(54356999)(230700001)(4326007)(76176999)(50986999)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2157; H:[172.28.32.102]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR0501MB2157; 23:QTo09kM4cUfCVlLf03LJ5LkcApKlhW9mKnU?= =?Windows-1252?Q?iOA4ZBs7g/3xnf2AsgWqJgDQevCPKb30JSgJ2chyN7Pi7XtMJv6jkm6C?= =?Windows-1252?Q?vZUlIucbjKSLZxKEGBy2/EdhfZeL5+m2CO8gNVy/hvzcKjUQEfSk8vGA?= =?Windows-1252?Q?O1EN12Eupm0tXscBotmA0EusEbaqrvhi9kSD8NAnKc/ofEKB2XzT/DNr?= =?Windows-1252?Q?UXWQUcgHj6hZT4irf2wDk9mjClia/MS1zPGRRh2u045wm4jG/9P+x0XK?= =?Windows-1252?Q?KUyhAi7vi0ZTTSL/iaC2o47JdSa5fHvo08/9yg6KNoUiYvAtAWRO0cS5?= =?Windows-1252?Q?X8fgEUiLci7cGZdtbl7r/HFXAjQCFcXymSTie774SamggdMk82o88EVq?= =?Windows-1252?Q?u7h+14jJoVo0YvMh9BCFAmj4Yfev16VPkSqxQeeAdMUFsiloWfiqwNTM?= =?Windows-1252?Q?rz2FGxAnTpYKjfloSV9CmdbB2GOKN0rU//JZaKn2YqMXsi8RVoHIAD5e?= =?Windows-1252?Q?fvWOi4lTSe5OB7Q7IffZvgB3RSq1X2/WWq7y9Adi6QlAeJXHk4j3OpuS?= =?Windows-1252?Q?2gmYWSoqp129XfNe+iQBK23NLUx2PV+h8N29ezvkgZit9X4VNY9ZkgcE?= =?Windows-1252?Q?PVWIkO6VEdsFw4kLbtD3P1oYtyY2yADzMLqi08ujRD9sDiW3VPT6ltUl?= =?Windows-1252?Q?dQX7SIHD2ovlLKa3kzAWLzx9c+PgWYF8hKMuR2KwTPxyHtbwwBQOmSsH?= =?Windows-1252?Q?FZH0OrBi1UsGS3va4lHtM16P1+JGmTPEja2KcfZ+MaEkeIzPwN8MdNdb?= =?Windows-1252?Q?DlQOX/hvHVhUz5iDxujWVONMbAOsRPLJi0xtClg11D8txnQtvP1eA202?= =?Windows-1252?Q?lwHN8xb+Z+mNiMzG51gVzi9POP7l/b4yDO8VzGRFVWEsqblzdaoVYNmf?= =?Windows-1252?Q?dmvxx/HE0eoi0Bnme8XFNZsuSFYZj/3VqdU9ngoKWKkvTi4I+L3zCwnG?= =?Windows-1252?Q?7dgWWi2nCWRn/CwQftFofZi3gqR/XXEKueFzZsV4vwtlN+UL7bxy8+yn?= =?Windows-1252?Q?EeAqHy5i+wcaBKDgBw9vSqZG1SuAxoaB5IWwUGvYQnGH15p0OJsvwcM6?= =?Windows-1252?Q?Z4vzkW/VfYcir4jln+T8kWlLqE5gdDYv6vju1sjUx0h/r4MiTgGYEGCW?= =?Windows-1252?Q?7aCDAFjheFsxH14y8mETs1b/MW+Eomh9v54rwkNFAyFbS9O3WIYtqQcV?= =?Windows-1252?Q?EewwIzt/PQMIAY6nIUpAYqoRGeDrhH6es/S0T9fiVzxFlydSppUlItVm?= =?Windows-1252?Q?8RVgcauwHX2E16vX6h7zaK56mP2Flcb8B+IqOrDesIO2QQCONbDlMeM+?= =?Windows-1252?Q?aNuFOg+QzymKY?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 5:Sf5Pqcz0TDkOmQZRtJrlUMRHEVBvGarwWNBP3SzgSDY5v+obrRYrXgWTXnjSymq5t2rOctBb4DXtijBBkE5xYx4VJjrPux5lEiXKrVfgIRWUIfTiGS+xwmvEpTRXMOzjj6oLZLR16+UUtoWhzp+NUA==; 24:eLd3bWVy1C8JITJE+kp+uQ5rvY4t3Ja7yfTAySS8htdQXM5k8f0HenbvIigtjrQEY4EuORQcnW965dqIALaEgDPXEW+mhtCReNoC4S4PK+Q= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 22:53:01.5927 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2157 Archived-At: Cc: equinox@opensourcerouting.org, mpls@ietf.org Subject: Re: [mpls] [Technical Errata Reported] RFC3107 (4582) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:53:26 -0000 A proposed 3107bis draft will be available shortly. The draft will deal with the issues you've raised, as well as other issues with RFC3107. Meanwhile ... As far as I know, no one has ever implemented Capability 4, and I believe 3107bis should propose to deprecate it. Section 4 of RFC3107 is intended to apply only when Capability 4 has been used. So you can just ignore that section. However, I think it is perfectly valid to use add-paths to advertise two routes whose respective NLRIs have different labels but the same prefix. This is like having two different paths to the same prefix, and each path may have a different label. Bestpath selection should choose the best path to a given prefix, without considering the labels. Section 3 is, as you observe, very sloppy in its use of the terms "NLRI" and "Prefix". > I have not checked what other implementations do; You're very brave ;-) > Quagga (which only implements this as route reflector): > - does not implement SAFI 4, but applies the behavior on SAFI 128 (VPN) I can't comment on whether your implementation needs SAFI-4 support, but the 3107bis draft will make it clear that most of the draft applies to SAFI-128 as well. > - does not advertise capability 4 Good. > - excludes the label value from all comparisons Right. > - will only keep the last label value received I assume you mean this to be in the context of a given prefix, as advertised on a given BGP session. But remember that if add-paths is being used to advertise two paths to a given prefix, each path may have a different label. > - will set the label on withdraws to all zeroes (ignoring the recommended value) When you receive a withdraw, the best strategy might be to ignore the value of the label field. When sending a withdraw, setting the label field to all zeroes is risking an interoperability problem. It might be safer to set the value to 0x800000, as RFC3107 says. From nobody Wed Jan 6 20:33:23 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1851A1A02; Wed, 6 Jan 2016 20:33:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107043320.4920.88068.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 20:33:20 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 04:33:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would be fine keeping the to-be-deleted text explaining alternatives that were not selected, especially if it was moved to an appendix. If anyone ever wonders about the alternatives, that would mean they didn't have to dig through e-mail archives to see what was considered and why the alternatives were rejected. I'm not understanding why When the MPLS-PLDM Response is requested out-of-band by setting the Control Code of the MPLS-PLDM query to "Out-of-band Response Requested", and the URO is present, the responder SHOULD send the response back to querier on the specified destination UDP port at the specified destination IP address contained in the URO. is a SHOULD. Could you help me with that? From nobody Thu Jan 7 01:48:37 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAC81A8851; Thu, 7 Jan 2016 01:48:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107094835.20273.74075.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 01:48:35 -0800 Archived-At: Cc: mpls@ietf.org, evyncke@cisco.com, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:48:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad that there is no alignment. At the very minimum, in the terminology and concepts. >From RFC 5357 +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ Something I already mentioned to the RFC 6374 authors in the past when doing my OPS-DIR review. Sigh... Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR review: This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT: as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem of course. Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation. What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)? Small nits: in introduction, I guess you meant "internally be forwarded" rather than "internally forwarded" Section 4.3, when selecting the source address, you may want to refer to RFC 6724 From nobody Thu Jan 7 05:27:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9A91A898C for ; Thu, 7 Jan 2016 05:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J480jwuXV0P5 for ; Thu, 7 Jan 2016 05:27:15 -0800 (PST) Received: from smtp02.msg.oleane.net (smtp02.msg.oleane.net [62.161.4.2]) by ietfa.amsl.com (Postfix) with ESMTP id ED2281A899C for ; Thu, 7 Jan 2016 05:27:13 -0800 (PST) Received: from MGosseDellM6800 (AClermont-Ferrand-551-1-197-85.w86-207.abo.wanadoo.fr [86.207.64.85]) (authenticated) by smtp02.msg.oleane.net (MSA) with ESMTP id u07DRAY7013891 for ; Thu, 7 Jan 2016 14:27:11 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 7 Jan 2016 14:25:33 +0100 Message-ID: <002901d1494e$e34435b0$a9cca110$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01D14957.4509D630" X-Mailer: Microsoft Outlook 15.0 Content-Language: fr Thread-Index: AdFIjSUukZcSeoJNREunc1A6E1L1Fw== X-Backend: vm-smtp-sophos07v3 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.1.7.132116 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: Subject: [mpls] MPLS+SDN+NFV World 2016: Two months left X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:27:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002A_01D14957.4509D630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit After the Marketing Rush, What is Left of SDN/NFV? * Software defined WAN: Next generation CPE, security * NFV & Open Source track: Service insurance, open ecosystem, use cases * MPLS & SDN track: Segment routing progress, SDN for core networks, analytics & multicast Full agenda & more info: http://www.uppersideconferences.com/mpls-sdn-nfv/ MPLS + SDN + NFV World Paris. 08/11 March 2016 ------=_NextPart_000_002A_01D14957.4509D630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After the Marketing Rush, What is Left of = SDN/NFV?

 

·         = Software defined WAN: Next generation CPE, = security

·         = NFV & Open Source track: Service insurance, open ecosystem, = use cases

·         = MPLS & SDN track: Segment routing progress, SDN for core = networks, analytics & multicast

 

Full agenda & more info: http://www.upp= ersideconferences.com/mpls-sdn-nfv/

 

MPLS + SDN + NFV World Paris. 08/11 March = 2016

 

------=_NextPart_000_002A_01D14957.4509D630-- From nobody Thu Jan 7 17:07:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F90E1A90A9; Thu, 7 Jan 2016 17:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3ChaEWbMPel; Thu, 7 Jan 2016 17:07:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D76001A21AE; Thu, 7 Jan 2016 17:07:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9479F180011; Thu, 7 Jan 2016 17:06:24 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160108010624.9479F180011@rfc-editor.org> Date: Thu, 7 Jan 2016 17:06:24 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7697 on MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 01:07:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7697 Title: MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) Author: P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros Status: Standards Track Stream: IETF Date: January 2016 Mailbox: aldrin.ietf@gmail.com, venkat.mahalingams@gmail.com, kannankvs@gmail.com, tnadeau@lucidvision.com, sboutros@vmware.com Pages: 36 Characters: 66337 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-oam-id-mib-11.txt URL: https://www.rfc-editor.org/info/rfc7697 DOI: http://dx.doi.org/10.17487/RFC7697 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jan 7 21:25:33 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29FF1ACDB7; Thu, 7 Jan 2016 21:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCJ9x0GDnDAo; Thu, 7 Jan 2016 21:25:29 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1331ACDB8; Thu, 7 Jan 2016 21:25:29 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.205.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 00C28180137F; Fri, 8 Jan 2016 06:25:25 +0100 (CET) To: "mpls@ietf.org" References: <5674E8EF.80807@pi.nu> From: Loa Andersson Message-ID: <568F4840.5090507@pi.nu> Date: Fri, 8 Jan 2016 13:25:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5674E8EF.80807@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-smack-mpls-rfc4379bis@ietf.org" Subject: [mpls] Closed - new wg document - Re: Poll to see if we have consensus to adopt draft-smack-mpls-rfc4379bis as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 05:25:31 -0000 Working Group, This poll is closed and we have a new working group document. Can the authors please post the draft as draft-ietf-mpls-rfc4379bis-00, without any other changes than file name, version and dates. /Loa On 2015-12-19 13:19, Loa Andersson wrote: > Working Group, > > This is to start a three week (because of the holiday season) poll > to see if we have consensus to adopt draft-smack-mpls-rfc4379bis > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR disclosures directly against > draft-smack-mpls-rfc4379bis document. However, there are IPR disclosures > against > RFC 4379. > > We have started an IPR poll in parallel to the adoption poll. > > The document shepherd and working group chairs are frequently asked > about the working group discussions related to any IPR disclosures. > > We like to remind the working group that discussion on the content > and validity of an IPR disclosure should not take place on the > MPLS wg list or any IETF mailing lists. > > However we are looking for simple statements whether you think the > working group should continue progress the document, regardless of > an existing IPR disclosure. Please include this information in your > 'support/do not support' when responding to working group adoption > calls and last calls. > > This working group adoptiom poll ends January 8, 2016. > > /Loa From nobody Fri Jan 8 07:19:38 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 912A41A8A61; Fri, 8 Jan 2016 07:19:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108151936.15569.95894.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 07:19:36 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:19:36 -0000 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 : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Authors : Kireeti Kompella Carlos Pignataro Nagendra Kumar Sam Aldrin Mach(Guoyi) Chen Filename : draft-ietf-mpls-rfc4379bis-00.txt Pages : 52 Date : 2016-01-08 Abstract: This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (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. This document obsoletes RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-00 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 8 11:03:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39211B2ADF; Fri, 8 Jan 2016 11:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCAnkmAgVjK0; Fri, 8 Jan 2016 11:03:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0471C1ABC75; Fri, 8 Jan 2016 11:03:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6E5B0180092; Fri, 8 Jan 2016 11:02:21 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160108190221.6E5B0180092@rfc-editor.org> Date: Fri, 8 Jan 2016 11:02:21 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7715 on Multipoint LDP (mLDP) Node Protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:03:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7715 Title: Multipoint LDP (mLDP) Node Protection Author: IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao Status: Standards Track Stream: IETF Date: January 2016 Mailbox: ice@cisco.com, skraza@cisco.com, akatlas@juniper.net, jeff.tantsura@ericsson.com, quintin.zhao@huawei.com Pages: 19 Characters: 39353 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-mldp-node-protection-08.txt URL: https://www.rfc-editor.org/info/rfc7715 DOI: http://dx.doi.org/10.17487/RFC7715 This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) 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 (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jan 8 15:12:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5EF1B2C8E for ; Fri, 8 Jan 2016 15:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoFscEnP-gO5 for ; Fri, 8 Jan 2016 15:12:04 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305941B2C89 for ; Fri, 8 Jan 2016 15:12:04 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id m198so36874102lfm.0 for ; Fri, 08 Jan 2016 15:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=qxtxbwef+FC7XFHnKpYQ962ENdm8tc/Q3jOAhXVO/BU=; b=gPOzHdbOkTkxegsWlv+TOTytD5HU0TkAhO7iECdApmYc3eHjLUQ4uxcSd6w2JKx3r7 OEbuq2EuKYe5bEq+/mQl/KJHLtu3LGpB6NmnNOpFbd+JdkJQno3QjTw3UwpatLKJZW+L HIX194HNd+fgj8VlyYEg5uHZ41c6h2bsnDeu9m7dVQ5T4vizF0+RjvAHbeAyFl6/0Rnr jos06Z5IDUSg3zKDl+bFG2xWyNm7eQUa6hxwRXN/i0Gk+5FEkbVHPkGPAnnEww19NZdV FQaAaALqR8/hrzhKl1fko4fGQNLi8tJ0ghoNlLcWTGpZlreNOOCPFscni6pnheCjhWmy gonw== X-Received: by 10.112.199.105 with SMTP id jj9mr40181676lbc.131.1452294722466; Fri, 08 Jan 2016 15:12:02 -0800 (PST) Received: from [10.0.1.5] (85-114-21-254.obit.ru. [85.114.21.254]) by smtp.googlemail.com with ESMTPSA id k64sm13657923lfi.23.2016.01.08.15.12.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 15:12:01 -0800 (PST) From: Alexander Okonnikov To: erosen@juniper.net, rfc-editor@rfc-editor.org, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net Message-ID: <56904241.7070006@gmail.com> Date: Sat, 9 Jan 2016 02:12:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, equinox@opensourcerouting.org Subject: Re: [mpls] [Technical Errata Reported] RFC3107 (4582) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:12:06 -0000 Using terms "NLRI" and "Prefix" interchangeably is a root of confusion. I saw good example of how clarification could be done to distinguish them. Follow example is from RFC 7432, section 7.1: "... For the purpose of BGP route key processing, only the Ethernet Segment Identifier and the Ethernet Tag ID are considered to be part of the prefix in the NLRI. The MPLS Label field is to be treated as a route attribute as opposed to being part of the route. ..." Indeed, in SAFI 4 NLRI label is attribute of prefix rather than part of prefix itself. This was implicitly assumed in RFC 3107, but was not stated explicitly. Agree with deprecation of capability type 4, because a) we have add-paths mechanism now and b) this capability could pose some problems and thus is unreliable, for example, when two routes have the same label value. Using 0x800000 though is not in line with rule of label stack encoding, but perhaps only solution for backward compatibility. May be it makes sense to deprecate encoding BoS (due to deprecation of multiple routes). Thank you. From nobody Fri Jan 8 18:37:43 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A36251A00ED; Fri, 8 Jan 2016 18:37:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160109023740.22715.13885.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 18:37:40 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 02:37:40 -0000 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 : Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Authors : Kishore Tiruveedhula Uwe Joorde Arvind Venkateswaran Filename : draft-ietf-mpls-mldp-mib-00.txt Pages : 37 Date : 2016-01-08 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing multicast LDP point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB module defined in this document is extension of LDP MIB defined in RFC3815 which supports only for LDP point-to-point LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-mldp-mib-00 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 8 23:18:36 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E01A1B13 for ; Fri, 8 Jan 2016 23:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz3WNSwtcdtN for ; Fri, 8 Jan 2016 23:18:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id CD9271A1B12 for ; Fri, 8 Jan 2016 23:18:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A4DC0180206; Fri, 8 Jan 2016 23:17:29 -0800 (PST) To: none@rfc-editor.org, aldrin.ietf@gmail.com, venkat.mahalingams@gmail.com, kannankvs@gmail.com, tnadeau@lucidvision.com, sboutros@vmware.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160109071729.A4DC0180206@rfc-editor.org> Date: Fri, 8 Jan 2016 23:17:29 -0800 (PST) Archived-At: Cc: venkat.mahalingams@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC7697 (4586) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 07:18:35 -0000 The following errata report has been submitted for RFC7697, "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7697&eid=4586 -------------------------------------- Type: Editorial Reported by: Venkatesan Mahalingam Section: 9.1 Original Text ------------- 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB IANA has to assign the OID { mplsStdMIB 21 } to the MPLS-OAM-ID-STD-MIB module specified in this document. Corrected Text -------------- 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB IANA has assigned the OID { mplsStdMIB 21 } to the MPLS-OAM-ID-STD-MIB module specified in this document. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7697 (draft-ietf-mpls-tp-oam-id-mib-11) -------------------------------------- Title : MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) Publication Date : January 2016 Author(s) : P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Jan 8 23:26:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE43A1A1B1B for ; Fri, 8 Jan 2016 23:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltOXwa9S6Wpl for ; Fri, 8 Jan 2016 23:26:49 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF0C1A1B18 for ; Fri, 8 Jan 2016 23:26:49 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.205.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C88F018013CB; Sat, 9 Jan 2016 08:26:40 +0100 (CET) To: RFC Errata System , none@rfc-editor.org, aldrin.ietf@gmail.com, venkat.mahalingams@gmail.com, kannankvs@gmail.com, tnadeau@lucidvision.com, sboutros@vmware.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, swallow@cisco.com, rcallon@juniper.net References: <20160109071729.A4DC0180206@rfc-editor.org> From: Loa Andersson Message-ID: <5690B629.7030306@pi.nu> Date: Sat, 9 Jan 2016 15:26:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160109071729.A4DC0180206@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC7697 (4586) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 07:26:51 -0000 Deborah, The nature of this is such that I don't we need to much process to approve it. As the wg chair I support this. If you are OK with it just go ahead and approve. /Loa On 2016-01-09 15:17, RFC Errata System wrote: > The following errata report has been submitted for RFC7697, > "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7697&eid=4586 > > -------------------------------------- > Type: Editorial > Reported by: Venkatesan Mahalingam > > Section: 9.1 > > Original Text > ------------- > 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB > > IANA has to assign the OID { mplsStdMIB 21 } to the > MPLS-OAM-ID-STD-MIB module specified in this document. > > > Corrected Text > -------------- > 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB > > IANA has assigned the OID { mplsStdMIB 21 } to the > MPLS-OAM-ID-STD-MIB module specified in this document. > > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7697 (draft-ietf-mpls-tp-oam-id-mib-11) > -------------------------------------- > Title : MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) > Publication Date : January 2016 > Author(s) : P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > From nobody Sat Jan 9 13:07:11 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519AC1A8F4F for ; Sat, 9 Jan 2016 13:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiyDXOfraply for ; Sat, 9 Jan 2016 13:07:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDAB1A8ACB for ; Sat, 9 Jan 2016 13:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2646; q=dns/txt; s=iport; t=1452373621; x=1453583221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PM+n1euvKeSmaf5QfSttgkkCKE0y4Mv+QVYKU0lKrWU=; b=YbuUEfmNopiuBlkM5+vaFdsSVzv3H27QfWF13TICy9eMcYJXX89XOMrS R2mHr2XTpOZeI3nF2/rUMSICoICMpuHwStP9ZAvpxsb2/q0XwRu2cC8MH q+UIp+5WUs3uCSR8K2pJD4YTpQ2/GspOK54J+e9VehQClQWaHEEWjgdIM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgC4dZFW/51dJa1EGoM6Um2IWaFNk?= =?us-ascii?q?gIBDYFmGAqFbQKBFzgUAQEBAQEBAYEKhDQBAQEDAQEBATc0CwULAgEIGB4QIQY?= =?us-ascii?q?LJQIEDgWIGQMKCA47vEoNgn8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaCDwiCa?= =?us-ascii?q?IE8gROCBoNMgRsFh2QKhwWIIAGLYIF4gV6EQ4hchWSBDodeASABAUKCEQ0PgV1?= =?us-ascii?q?yAROFTQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,545,1444694400"; d="scan'208";a="64844781" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2016 21:07:00 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u09L70Ph006743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 21:07:00 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 9 Jan 2016 15:06:59 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Sat, 9 Jan 2016 15:06:59 -0600 From: "Stewart Bryant (stbryant)" To: Loa Andersson Thread-Topic: [mpls] [Editorial Errata Reported] RFC7697 (4586) Thread-Index: AQHRSq39JhYdtcNMOESTaqoS+vI7Yp7zLVqAgACApoM= Date: Sat, 9 Jan 2016 21:06:59 +0000 Message-ID: <61ECDC31-1A8D-4257-83AF-87A45ED37744@cisco.com> References: <20160109071729.A4DC0180206@rfc-editor.org>, <5690B629.7030306@pi.nu> In-Reply-To: <5690B629.7030306@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sboutros@vmware.com" , "mpls@ietf.org" , "kannankvs@gmail.com" , "rcallon@juniper.net" , "none@rfc-editor.org" , "venkat.mahalingams@gmail.com" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7697 (4586) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 21:07:09 -0000 Loa Surely this is of marginal value and should not be other than fixed in next= update. After all it will be obvious to the reader what the value is. Stewart Sent from my iPad > On 9 Jan 2016, at 07:27, Loa Andersson wrote: >=20 > Deborah, >=20 > The nature of this is such that I don't we need to much process to > approve it. As the wg chair I support this. If you are OK with it > just go ahead and approve. >=20 > /Loa >=20 >> On 2016-01-09 15:17, RFC Errata System wrote: >> The following errata report has been submitted for RFC7697, >> "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Mainte= nance (OAM) Identifiers Management Information Base (MIB)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7697&eid=3D4586 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Venkatesan Mahalingam >>=20 >> Section: 9.1 >>=20 >> Original Text >> ------------- >> 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB >>=20 >> IANA has to assign the OID { mplsStdMIB 21 } to the >> MPLS-OAM-ID-STD-MIB module specified in this document. >>=20 >>=20 >> Corrected Text >> -------------- >> 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB >>=20 >> IANA has assigned the OID { mplsStdMIB 21 } to the >> MPLS-OAM-ID-STD-MIB module specified in this document. >>=20 >>=20 >> Notes >> ----- >>=20 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC7697 (draft-ietf-mpls-tp-oam-id-mib-11) >> -------------------------------------- >> Title : MPLS Transport Profile (MPLS-TP) Operations, Admin= istration, and Maintenance (OAM) Identifiers Management Information Base (M= IB) >> Publication Date : January 2016 >> Author(s) : P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. N= adeau, S. Boutros >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jan 10 04:33:29 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F871ACCE8 for ; Sun, 10 Jan 2016 04:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K53-P-qBBrtb for ; Sun, 10 Jan 2016 04:33:25 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C51ACCE6 for ; Sun, 10 Jan 2016 04:33:24 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.205.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 31DB01801569; Sun, 10 Jan 2016 13:33:12 +0100 (CET) To: "Stewart Bryant (stbryant)" References: <20160109071729.A4DC0180206@rfc-editor.org> <5690B629.7030306@pi.nu> <61ECDC31-1A8D-4257-83AF-87A45ED37744@cisco.com> From: Loa Andersson Message-ID: <56924F80.3020709@pi.nu> Date: Sun, 10 Jan 2016 20:33:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <61ECDC31-1A8D-4257-83AF-87A45ED37744@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sboutros@vmware.com" , "mpls@ietf.org" , "kannankvs@gmail.com" , "rcallon@juniper.net" , "none@rfc-editor.org" , "venkat.mahalingams@gmail.com" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7697 (4586) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 12:33:27 -0000 Stewart, Yes - exactly! However Errata is there to capture both technical and editorial errors. This is an editorial errata, if we neglect it, i.e. not add a note in the errata system, that it is know and will be taken care of if we ever do an update. The effect would be that we will see the same errata reported over again; and a number mails that authors/chairs/ADs have to respond to. Today this is piece of a cake, we are all up to speed, but in the future what happen will fade into the background (new chairs/ADs) and someone will have to dig into this to understand it. Far better to respond to the errata "Approved - hold for potential update." /Loa On 2016-01-10 05:06, Stewart Bryant (stbryant) wrote: > Loa > > Surely this is of marginal value and should not be other than fixed in next update. After all it will be obvious to the reader what the value is. > > Stewart > > Sent from my iPad > >> On 9 Jan 2016, at 07:27, Loa Andersson wrote: >> >> Deborah, >> >> The nature of this is such that I don't we need to much process to >> approve it. As the wg chair I support this. If you are OK with it >> just go ahead and approve. >> >> /Loa >> >>> On 2016-01-09 15:17, RFC Errata System wrote: >>> The following errata report has been submitted for RFC7697, >>> "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=7697&eid=4586 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Venkatesan Mahalingam >>> >>> Section: 9.1 >>> >>> Original Text >>> ------------- >>> 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB >>> >>> IANA has to assign the OID { mplsStdMIB 21 } to the >>> MPLS-OAM-ID-STD-MIB module specified in this document. >>> >>> >>> Corrected Text >>> -------------- >>> 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB >>> >>> IANA has assigned the OID { mplsStdMIB 21 } to the >>> MPLS-OAM-ID-STD-MIB module specified in this document. >>> >>> >>> Notes >>> ----- >>> >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC7697 (draft-ietf-mpls-tp-oam-id-mib-11) >>> -------------------------------------- >>> Title : MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) >>> Publication Date : January 2016 >>> Author(s) : P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jan 10 08:02:13 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6B11ACDF9; Sun, 10 Jan 2016 08:02:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160110160210.31758.28405.idtracker@ietfa.amsl.com> Date: Sun, 10 Jan 2016 08:02:10 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 16:02:10 -0000 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 : Use Cases and Requirements for MPLS-TP multi-failure protection Authors : Zhenlong Cui Rolf Winter Himanshu Shah Sam Aldrin Masahiro Daikoku Filename : draft-cui-mpls-tp-mfp-use-case-and-requirements-07.txt Pages : 8 Date : 2016-01-10 Abstract: For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-cui-mpls-tp-mfp-use-case-and-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-cui-mpls-tp-mfp-use-case-and-requirements-07 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 10 22:14:25 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48301A006F; Sun, 10 Jan 2016 22:14:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111061423.23145.24467.idtracker@ietfa.amsl.com> Date: Sun, 10 Jan 2016 22:14:23 -0800 Archived-At: Cc: mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] mpls - New Meeting Session Request for IETF 95 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 06:14:24 -0000 A new meeting session request has just been submitted by Tarek Saad, a Secretary of the mpls working group. --------------------------------------------------------- Working Group Name: Multiprotocol Label Switching Area Name: Routing Area Session Requester: Tarek Saad Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas ccamp pce bess bfd idr pals bier Second Priority: nvo3 sfc spring i2rs rtgarea rtgwg Third Priority: ospf isis sidr Special Requests: --------------------------------------------------------- From nobody Mon Jan 11 04:48:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AE51A89FF; Mon, 11 Jan 2016 04:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGSRChiP1Gr9; Mon, 11 Jan 2016 04:48:01 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0975B1A89FD; Mon, 11 Jan 2016 04:48:01 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.205.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BD3F8180137F; Mon, 11 Jan 2016 13:47:56 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Message-ID: <5693A478.7010701@pi.nu> Date: Mon, 11 Jan 2016 20:47:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 12:48:02 -0000 Working Group, draft-cui-mpls-tp-mfp-use-case-and-requirements are being prepared for working group adoption poll. There are still some minor lose ends that needs to be tied up. We will start an IPR poll before the wg adoption poll is started. Are you aware of any IPR that applies to draft-cui-mpls-tp-mfp-use- case-and-requirements? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosures filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jan 11 05:12:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844A01A8A27; Mon, 11 Jan 2016 05:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJLuBna-XpOl; Mon, 11 Jan 2016 05:12:01 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A2B1A8A1E; Mon, 11 Jan 2016 05:12:00 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id u0BDBuYk027303; Mon, 11 Jan 2016 22:11:56 +0900 (JST) Received: from mailsv3.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id u0BDBu427141; Mon, 11 Jan 2016 22:11:56 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id u0BDBtFT006847; Mon, 11 Jan 2016 22:11:55 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.141] [10.38.151.141]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-4682402; Mon, 11 Jan 2016 22:11:28 +0900 Received: from BPXM18GP.gisp.nec.co.jp ([10.38.151.210]) by BPXC13GP.gisp.nec.co.jp ([10.38.151.141]) with mapi id 14.03.0224.002; Mon, 11 Jan 2016 22:11:27 +0900 From: Zhenlong Cui To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHRTG5elS/vanikdUK89cw2kYM+RZ72ScUw Date: Mon, 11 Jan 2016 13:11:27 +0000 Message-ID: References: <5693A478.7010701@pi.nu> In-Reply-To: <5693A478.7010701@pi.nu> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.38.126.83] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:12:02 -0000 Hi, I am not aware of any IPR related to this document. Regards, zhenlong > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Monday, January 11, 2016 9:48 PM > To: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-cui-mpls-tp-mfp-use-case-and-requirements= @ietf.org > Subject: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requiremen= ts >=20 > Working Group, >=20 > draft-cui-mpls-tp-mfp-use-case-and-requirements are being prepared for wo= rking group adoption poll. There are still some > minor lose ends that needs to be tied up. >=20 > We will start an IPR poll before the wg adoption poll is started. >=20 > Are you aware of any IPR that applies to draft-cui-mpls-tp-mfp-use- case-= and-requirements? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > There are no IPR disclosures filed directly against this document. >=20 > If you are listed as a document author or contributor please respond to t= his email regardless of whether or not you are > aware of any relevant IPR. *The response needs to be sent to the MPLS wg = mailing list.* The document will not advance > to the next stage until a response has been received from each author and= contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or c= ontributor, then please explicitly respond only > if you are aware of any IPR that has not yet been disclosed in conformanc= e with IETF rules. >=20 >=20 > /Loa > mpls wg co-chair > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jan 11 08:42:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4A1A8A90; Mon, 11 Jan 2016 08:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzUWXL1sdZ8O; Mon, 11 Jan 2016 08:42:18 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA261A8A87; Mon, 11 Jan 2016 08:42:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 72CEC10BCE4; Mon, 11 Jan 2016 17:42:16 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6rY7LpASghO; Mon, 11 Jan 2016 17:42:16 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 4CD0810BCE2; Mon, 11 Jan 2016 17:42:06 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.84]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Mon, 11 Jan 2016 17:42:05 +0100 From: Rolf Winter To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHRTG5S4dzZTMJIU0y/y7HEtMB2NJ72hQXg Date: Mon, 11 Jan 2016 16:42:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DA9CE5C57@PALLENE.office.hd> References: <5693A478.7010701@pi.nu> In-Reply-To: <5693A478.7010701@pi.nu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:42:21 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUi4NCg0KTkVDIEV1cm9wZSBMdGQgfCBSZWdpc3RlcmVk IE9mZmljZTogQXRoZW5lLCBPZHlzc2V5IEJ1c2luZXNzIFBhcmssIFdlc3QgRW5kICBSb2FkLCBM b25kb24sIEhBNCA2UUUsIEdCIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86 bG9hQHBpLm51XQ0KPiBTZW50OiBNb250YWcsIDExLiBKYW51YXIgMjAxNiAxMzo0OA0KPiBUbzog bXBsc0BpZXRmLm9yZw0KPiBDYzogZHJhZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1y ZXF1aXJlbWVudHNAaWV0Zi5vcmc7IG1wbHMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgQlJVTkdBUkQs IERFQk9SQUggQQ0KPiBTdWJqZWN0OiBJUFIgcG9sbCBvbiBkcmFmdC1jdWktbXBscy10cC1tZnAt dXNlLWNhc2UtYW5kLXJlcXVpcmVtZW50cw0KPiANCj4gV29ya2luZyBHcm91cCwNCj4gDQo+IGRy YWZ0LWN1aS1tcGxzLXRwLW1mcC11c2UtY2FzZS1hbmQtcmVxdWlyZW1lbnRzIGFyZSBiZWluZyBw cmVwYXJlZCBmb3INCj4gd29ya2luZyBncm91cCBhZG9wdGlvbiBwb2xsLiBUaGVyZSBhcmUgc3Rp bGwgc29tZSBtaW5vciBsb3NlIGVuZHMgdGhhdA0KPiBuZWVkcyB0byBiZSB0aWVkIHVwLg0KPiAN Cj4gV2Ugd2lsbCBzdGFydCBhbiBJUFIgcG9sbCBiZWZvcmUgdGhlIHdnIGFkb3B0aW9uIHBvbGwg aXMgc3RhcnRlZC4NCj4gDQo+IEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gZHJhZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS0NCj4gY2FzZS1hbmQtcmVxdWlyZW1lbnRzPw0K PiANCj4gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMNCj4gKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzgg Zm9yIG1vcmUgZGV0YWlscykuDQo+IA0KPiBUaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGZp bGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCj4gDQo+IElmIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRv DQo+IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJl IG9mIGFueSByZWxldmFudA0KPiBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0 byB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuKiBUaGUNCj4gZG9jdW1lbnQgd2lsbCBub3QgYWR2 YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuDQo+IHJlY2Vp dmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KPiANCj4gSWYgeW91IGFyZSBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig b3INCj4gY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlm IHlvdSBhcmUgYXdhcmUgb2YNCj4gYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xv c2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCj4gDQo+IA0KPiAvTG9hDQo+IG1w bHMgd2cgY28tY2hhaXINCj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAg ICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBF eHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5v bG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Tue Jan 12 01:22:38 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B71161A6F57; Tue, 12 Jan 2016 01:22:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112092232.30654.88643.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 01:22:32 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 09:22:32 -0000 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 : Use Cases and Requirements for MPLS-TP multi-failure protection Authors : Zhenlong Cui Rolf Winter Himanshu Shah Sam Aldrin Masahiro Daikoku Filename : draft-cui-mpls-tp-mfp-use-case-and-requirements-08.txt Pages : 8 Date : 2016-01-12 Abstract: For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-cui-mpls-tp-mfp-use-case-and-requirements-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-cui-mpls-tp-mfp-use-case-and-requirements-08 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 01:55:18 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A291A6FDB for ; Tue, 12 Jan 2016 01:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6uRARPO_hXI for ; Tue, 12 Jan 2016 01:55:16 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EA11A6FD9 for ; Tue, 12 Jan 2016 01:55:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2659610BD2E for ; Tue, 12 Jan 2016 10:55:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OxTYMxERRA9 for ; Tue, 12 Jan 2016 10:55:14 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 0476310BD25 for ; Tue, 12 Jan 2016 10:55:12 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.84]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 12 Jan 2016 10:55:11 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-08.txt Thread-Index: AQHRTRrg6qCvu4CNL0Cu8bRacVnIk573onxA Date: Tue, 12 Jan 2016 09:55:10 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DA9CE5E59@PALLENE.office.hd> References: <20160112092232.30654.88643.idtracker@ietfa.amsl.com> In-Reply-To: <20160112092232.30654.88643.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 09:55:17 -0000 This version addresses a fix to a comment that was made from the MPLS revie= w team which should now be all addressed in this version. Big thanks to the= review team. NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Dienstag, 12. Januar 2016 10:23 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-cui-mpls-tp-mfp-use-case-and- > requirements-08.txt >=20 >=20 > 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. >=20 > Title : Use Cases and Requirements for MPLS-TP multi- > failure protection > Authors : Zhenlong Cui > Rolf Winter > Himanshu Shah > Sam Aldrin > Masahiro Daikoku > Filename : draft-cui-mpls-tp-mfp-use-case-and- > requirements-08.txt > Pages : 8 > Date : 2016-01-12 >=20 > Abstract: > For the Multiprotocol Label Switching Transport Profile (MPLS-TP) > linear protection capable of 1+1 and 1:1 protection has already been > defined. That linear protection mechanism has not been designed for > handling multiple, simultaneously occuring failures, i.e. multiple > failures that affect the working and the protection entity during > the > same time period. In these situations currently defined protection > mechanisms would fail. >=20 > This document introduces use cases and requirements for mechanisms > that are capable of protecting against such failures. It does not > specify a multi-failure protection mechanism itself. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and- > requirements/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-cui-mpls-tp-mfp-use-case-and- > requirements-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-cui-mpls-tp-mfp-use-case-and- > requirements-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 12 02:36:37 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27CE1A86F6; Tue, 12 Jan 2016 02:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFLa5zyU1DYR; Tue, 12 Jan 2016 02:36:34 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ACB1A86F2; Tue, 12 Jan 2016 02:36:34 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.213.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 752CC18013CB; Tue, 12 Jan 2016 11:36:31 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Message-ID: <5694D729.5000505@pi.nu> Date: Tue, 12 Jan 2016 18:36:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: [mpls] Poll to see if we have consensus to adopt draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:36:36 -0000 Working Group, This is to start a two week poll on adopting draft-cui-mpls-tp-mfp- use-case-and-requirements as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There are no IPR disclosures against this document. We have an IPR poll running in parallel, his poll ends January 27, 2016; or when the IPR poll has concluded if that is later than January 27. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 12 03:36:17 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EDD1ACF1C; Tue, 12 Jan 2016 03:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YuMWtgi9O7X; Tue, 12 Jan 2016 03:36:14 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F2D1ACF18; Tue, 12 Jan 2016 03:36:13 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id ba1so433630458obb.3; Tue, 12 Jan 2016 03:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0fjUjmHlQsxAgkyAQsJHTTFqUAYyjnc24N2l8qJ/yHc=; b=lFT3N/beEhjtXHJ8f5XZEuRCB3tjCtUrRpuntlEMvoA3W6l5HlJpMi0c61NplNgMeV 4Am4g3aX0mDvPCmqQngmv2Z47kXJBMrZ7zNUmWXCD7w3n4kouIYMCn2McVDUwlhZb46A M8UWfS1+2gtNXS4lquRMdtywuoJGr3+poRV3KY+p2WIQkmB4m3eMmpOyDyDDOcUvpiOX kD7QTHUDIirUyWWb04zI50HAzumncW52FgPNi0GQpf2fdQsWsyqQdLq7QI8yhTWvIzmE XYnyTx9q82ihqHYkflNPbwn9x7UYFaPRsWH8g2YOVcSITMtxjbC3v7gElTC9BkZnEzx1 lEOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0fjUjmHlQsxAgkyAQsJHTTFqUAYyjnc24N2l8qJ/yHc=; b=b4RHOjxZq6PoVbh8wDyKqZkVcl7K7shgKtQKtx053KmMWn1AlKeFWAJ7T+K2FHl/9K PxK2zG1NMZBFUPtiBTv59oXJHRqvdiJxawse1GNEyh4rQB306j49iegL1SyzOI451jyr IIsV6wG3kiBet79Xy9lcwxQPoxugvEtSixi6Z1m86kBH0djuV0gtVAz4uxeasw3LokNg yUAC2Rm73qR1Xr6d1DZ/I3+Ey1QZ8Nl6XBg2wgrhj9iS7ShY+Rx/457eCXUvQ5Spx2CZ cnPT8CDzJn95/Q+wNSSY1VZiD8IVht9I5m0j/sdE3u4KF7yXG6I7aX8bDDybO401KFi9 1aUA== X-Gm-Message-State: ALoCoQkEOpNaGXTAE9Rg6cusAyh25mOf0SxwEuo2JIERsXIAQbUNPOYTd0QCBSidpINxCZBgI21zh5Bkrla9577lJ2pKl3yBVQ== X-Received: by 10.60.137.137 with SMTP id qi9mr101103300oeb.56.1452598573325; Tue, 12 Jan 2016 03:36:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Tue, 12 Jan 2016 03:35:53 -0800 (PST) In-Reply-To: <5694D729.5000505@pi.nu> References: <5694D729.5000505@pi.nu> From: "Andrew G. Malis" Date: Tue, 12 Jan 2016 06:35:53 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b4141aaf6e62305292175ca Archived-At: Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 11:36:16 -0000 --047d7b4141aaf6e62305292175ca Content-Type: text/plain; charset=UTF-8 Loa, This looks like a very useful draft, and I support its adoption. Cheers, Andy On Tue, Jan 12, 2016 at 5:36 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting draft-cui-mpls-tp-mfp- > use-case-and-requirements as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR disclosures against this document. > > We have an IPR poll running in parallel, his poll ends January 27, 2016; > or when the IPR poll has concluded if that is later than January 27. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b4141aaf6e62305292175ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

This looks like a very useful draf= t, and I support its adoption.

Cheers,
A= ndy

On= Tue, Jan 12, 2016 at 5:36 AM, Loa Andersson <loa@pi.nu> wrote:
=
Working Group,

This is to start a two week poll on adopting draft-cui-mpls-tp-mfp-
use-case-and-requirements as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There are no IPR disclosures against this document.

We have an IPR poll running in parallel, his poll ends January 27, 2016; or when the IPR poll has concluded if that is later than January 27.

/Loa
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--047d7b4141aaf6e62305292175ca-- From nobody Tue Jan 12 10:09:08 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044971A026A; Tue, 12 Jan 2016 10:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcIOXEwPzO0V; Tue, 12 Jan 2016 10:09:05 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74841A0235; Tue, 12 Jan 2016 10:09:05 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id n128so66484211pfn.3; Tue, 12 Jan 2016 10:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=by4XII/Gdc53r1Gi2/AOoGEtlfxUTcthkyf+HnCvLA8=; b=foVqyglpOXEzm7vCrCdfVx5sq2Q7OdQ1s48aaGVPHKHCVNdCdd5TLx1OFq+YYCpo3q hKUr+YtmI4hcDvousajdP3WAeJouS78HAQ508l+zCrTapxo8cp/xQjartwiBl6dGKOio +Y5pJ3WfngnKxHzWlmR2r8UxIadj3v7uTlqY9oB4hBe5lvKwdXkvy7+Zsg+z46QUp3rD vjVKebmI7MukOgIGqOdjmdJWUB8CujCHMSh6boJdYmlnZa+4rD+gk8YeO7uQyE0wjhhH QbYMUuw5+Ai/3cv63eWetdvxwdse3zUoR+ks5p1RbKLdl5RtJKdwm1rh2T0usGH0c/5j 1+GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=by4XII/Gdc53r1Gi2/AOoGEtlfxUTcthkyf+HnCvLA8=; b=P7lzsHYgeCgJleu057/Zk5pB0LcekPqqXDUpzi3lrQEY8gQ3d2EIAbbgLMwt5rCGGv /QhM0t2Vc5P8+H60Inf5kUUrG8j83VgypTlxykNhSMT4v0lxmPWfU+B0Q79KseJONuQ6 FR0YyoX/yNLNK+7ceiY/VdaTFEJb8flI0Lh89VhDXQYNCqRmoA+d528QlS9L0xJ699Y+ J24EpE8UDRBSKsMoniGliNf50xfdCKpKPZTT9PIAu2HZi9YVHRY894Z/AFgELPWQw3Xz QipQDN6lp3BALMmQ8iCBQF/xK0X7dXOQPZpNViC1hwGVSFGGt6TclxhwciXs5VR6/FRi SOmQ== X-Gm-Message-State: ALoCoQl+k6rkwmEwrpNG8Aqzl+Pk+cGAdPQTIqkCr5PONJnGZDMwOmTZA84EV79R8mZCgKwCtDEtYzPsxGNgdvZQw1N9fUfCbw== X-Received: by 10.98.71.197 with SMTP id p66mr36643707pfi.166.1452622145277; Tue, 12 Jan 2016 10:09:05 -0800 (PST) Received: from ?IPv6:2620::1000:fd35:6917:755:87fa:4bae? ([2620:0:1000:fd35:6917:755:87fa:4bae]) by smtp.gmail.com with ESMTPSA id l73sm31910439pfi.37.2016.01.12.10.09.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 10:09:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sam Aldrin X-Mailer: iPhone Mail (13C75) In-Reply-To: <791AD3077F94194BB2BDD13565B6295DA9CE5C57@PALLENE.office.hd> Date: Tue, 12 Jan 2016 10:09:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5693A478.7010701@pi.nu> <791AD3077F94194BB2BDD13565B6295DA9CE5C57@PALLENE.office.hd> To: Rolf Winter Archived-At: Cc: "mpls@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 18:09:08 -0000 I am not aware of any IPR related to this draft Sent from my iPhone > On Jan 11, 2016, at 8:42 AM, Rolf Winter wrote: >=20 > I am not aware of any IPR. >=20 > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West En= d Road, London, HA4 6QE, GB | Registered in England 2832014 >=20 >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Montag, 11. Januar 2016 13:48 >> To: mpls@ietf.org >> Cc: draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org; mpls- >> chairs@ietf.org; BRUNGARD, DEBORAH A >> Subject: IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements >>=20 >> Working Group, >>=20 >> draft-cui-mpls-tp-mfp-use-case-and-requirements are being prepared for >> working group adoption poll. There are still some minor lose ends that >> needs to be tied up. >>=20 >> We will start an IPR poll before the wg adoption poll is started. >>=20 >> Are you aware of any IPR that applies to draft-cui-mpls-tp-mfp-use- >> case-and-requirements? >>=20 >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>=20 >> There are no IPR disclosures filed directly against this document. >>=20 >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >>=20 >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of >> any IPR that has not yet been disclosed in conformance with IETF rules. >>=20 >>=20 >> /Loa >> mpls wg co-chair >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 12 16:53:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE68B1AC3E8; Tue, 12 Jan 2016 16:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJLvnZnKc8xg; Tue, 12 Jan 2016 16:53:32 -0800 (PST) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBBF1AC3E0; Tue, 12 Jan 2016 16:53:32 -0800 (PST) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 91C14E0082; Wed, 13 Jan 2016 09:53:31 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Wed, 13 Jan 2016 09:53:31 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 6B45D3A0065; Wed, 13 Jan 2016 09:53:31 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id 5FCED3A005F; Wed, 13 Jan 2016 09:53:31 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u0D0rUjE013909; Wed, 13 Jan 2016 09:53:31 +0900 Received: from LTMC2152.kddi.com.mid_29425304 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id u0D0qYvR012500; Wed, 13 Jan 2016 09:52:34 +0900 X-SA-MID: 29425304 Received: from KDDI1310PC0003 ([10.211.189.59] [10.211.189.59]) by post-smtp2.kddi.com with ESMTPA; Wed, 13 Jan 2016 09:52:34 +0900 From: "Masahiro DAIKOKU" To: "'Zhenlong Cui'" , "'Loa Andersson'" , References: <5693A478.7010701@pi.nu> In-Reply-To: Date: Wed, 13 Jan 2016 09:52:34 +0900 Message-ID: <006901d14d9c$b0a33d20$11e9b760$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLDO+BYv5XMiA0yzgDCUrJP3LPz5QILSnranQRnAXA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Cc: mpls-chairs@ietf.org, draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org Subject: Re: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 00:53:34 -0000 Not aware of any IPR related to this draft. Best regards, Masahiro Daikoku > > Working Group, > > > > draft-cui-mpls-tp-mfp-use-case-and-requirements are being prepared for > > working group adoption poll. There are still some minor lose ends that needs to be tied up. > > > > We will start an IPR poll before the wg adoption poll is started. > > > > Are you aware of any IPR that applies to draft-cui-mpls-tp-mfp-use- case-and-requirements? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > > > > There are no IPR disclosures filed directly against this document. > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the > next stage until a response has been received from each author and contributor. > > > > If you are on the MPLS WG email list but are not listed as an author > > or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed > in conformance with IETF rules. > > > > > > /Loa > > mpls wg co-chair > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jan 13 01:40:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E41A21BC; Wed, 13 Jan 2016 01:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcLeLQnzcbZA; Wed, 13 Jan 2016 01:39:58 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA641A21B3; Wed, 13 Jan 2016 01:39:58 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f206so286130031wmf.0; Wed, 13 Jan 2016 01:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=CWP6Uua0V4+eE9tflkdlnzR1ScJbA1ci5Z6kRyIxD8s=; b=U1EAGuiBEGRf/v2EfTvvrzhNqlu7e0OSvzqLiOPiein+bSnkkoMfQySiWtQhDkhU0q H79QsPm96iN/JWqpwk8E8gSw8/PbFsnzZrP+nBCuTTCOy5x27tT182kgyHN9XTRuyWxq sIBfiUs8vrMmbXWhhd1uBE7L7Opy48fflm6Zggoq+8p37RQ3Y3yqWvoU8TcOH7ENxRX4 q3YS20PykzMa5+ajOwu/i+tLcb7QHu+2PQ7JKpnsklv7+dwqQbyhcEOBtuAcsQjAZ+61 VOAh633LteHHaJGz4LRXzQXsJ3lOgeLvaWkm+C8L/WLNc0HQTQIO1okqniCu+xsqy+A8 0z3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=CWP6Uua0V4+eE9tflkdlnzR1ScJbA1ci5Z6kRyIxD8s=; b=MkYFFZ6Wjo3kBU5dfdcOLwdPt2E4eD/jLJMPJpDxG5UkmfFQ9QtOym5xiDFtgDvriD Ppd9i+45gDvW1RgjGynHTcCL5zd9M2mt46kLm5VcHO7LRpm3XF03SoxQoqRPYoezxhmx vScCv/BN/1ibaQi2hose1nHP4cN0fpL9l6IlJQpCZ7uj//6P9PQ3AbUeEHWBD91rtpQi mM0lHD4Ihy4rQdkHful2FbrmkvCZpKFX+9p1BiR9TxxAYEE0Xj7XFL0gSSePn0G5Ewz4 +eDHd7/cu9WunJ7EJup7f51plj3AtUI/pARItnWaC0xbaJ+oeg+TtWmFYVwyrpZ6vS8j j+VA== X-Gm-Message-State: ALoCoQnuD5q1Iz1gbJU4t9CUdtUgC4EFt6nNiduSneTco3cjxYL9W/CMi/c/f8Jef7lF9ZgN6pFAtBPDwsBjQlVocMXEHA8NbQ== X-Received: by 10.194.115.164 with SMTP id jp4mr108620154wjb.26.1452677996710; Wed, 13 Jan 2016 01:39:56 -0800 (PST) Received: from fbipool-clients-45-53.fbi.h-da.de (fbipool-clients-45-53.fbi.h-da.de. [141.100.45.53]) by smtp.googlemail.com with ESMTPSA id w80sm21412944wme.17.2016.01.13.01.39.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 01:39:56 -0800 (PST) To: Gmail References: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> From: Martin Stiemerling Message-ID: <56961B6C.3040705@gmail.com> Date: Wed, 13 Jan 2016 10:39:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, The IESG , mpls-chairs@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:40:00 -0000 Hi Steward, Am 06.01.16 um 18:10 schrieb Gmail: > Martin > > It is a fundamental tenet of MPLS is that the network is well > managed with the operators paying significant attention to traffic > planning, I therefore think that it is reasonable to assume that they > would also pay adequate attention to their UDP management traffic. > > Loss is so light in these networks that the interval between loss > measurements needs to be long to see any loss at all, thus I would > normally expect us to be talking packets per minute or packets per > hour rather than packets per second, and this would be on links with > GB+ capacity. Similarly it makes little sense to make delay > measurements very frequently. > > In both cases the amount of traffic will be minuscule compared to the > IPFIX over UDP traffic that that many operators will already will > running. > > I thus fear that you raise the congestion daemon without proper > regard to the practicalities of this type of application. I fully understand that this type of protocol is used usually in a fully managed network. But congestion can also happen there, and congestion is by the way not a daemon, but a natural consequence of a best effort network even if it is managed And even in fully managed networks traffic can accumulate at one point causing congestion. I do not see the need to work through all details of RFC 5405, but I want to see text that reflects about using an not congestion controlled protocol and possible consequences and guidances for operators using this. One way to handle this, to make operators aware of the need to monitor the rate of UDP traffic and that any excess of this rate is worth noting to the network operator. By the way, your argument above about the managed environment would also make Section 5 superfluous, isn't it? Thanks, Martin > > Stewart. > > Sent from my iPad > >> On 5 Jan 2016, at 21:47, Martin Stiemerling >> wrote: >> >> Martin Stiemerling has entered the following ballot position for >> draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss >> >> 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.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ >> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> I am in favour of publishing this document, but I have two major points >> that are not addressed in the document by now: >> >> 1) It is not clear for anybody what the expected size and sending >> frequency of such MPLS-PLDM over IP/UDP responses are. This will >> influence any measures an operator has to take in order to assure >> that there is no congestion caused by these messages. I can >> understand that this cannot be foreseen, but a few words >> considering this fact are excellent to have in the document. >> >> 2) This leads to my second point: the lack of any reference to RFC >> 5405 "Unicast UDP Usage Guidelines for Application Designers" and >> the content out of this RFC that is applicable for this draft. >> There is no discussion about this at all. Please note well that >> this is BCP 145. >> >> With regard to point 2): I can try to find some help from the >> transport area, in case you need help. >> >> >> >> >> _______________________________________________ mpls mailing list >> mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jan 13 10:11:43 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2051A00D4; Wed, 13 Jan 2016 10:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8e9vlBNAMwl; Wed, 13 Jan 2016 10:11:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FB1B304A; Wed, 13 Jan 2016 10:11:38 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.81] (66.129.241.12) by SN1PR0501MB2158.namprd05.prod.outlook.com (10.163.229.152) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 13 Jan 2016 18:11:14 +0000 To: , BESS , From: Eric C Rosen Message-ID: <5696933E.1080802@juniper.net> Date: Wed, 13 Jan 2016 13:11:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CO1PR06CA055.namprd06.prod.outlook.com (10.242.160.45) To SN1PR0501MB2158.namprd05.prod.outlook.com (25.163.229.152) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 2:6eBOpkqm+/nvNfRF+VLk4KLu+Wn+oO7krTpp3casaGE3GxmIaffsiCPGIhQMOXIQ3tCWUFjf8GqW8SffAi3xlA4f50JwnOD3grPn71k7EuFUHJubcl9zYx+9ae42bKiNgT0O8K+VLAgcnG7/RqdmQw==; 3:bz5azzoBVIUc+VQW3JUz3r8FkzWHY2Wqrb7pjoD+p9g0pkbra8MNsPCf4l+7gpADv+0iQd5qZDJhEgEWcnhXwTF4y0gtsbf32+nt2JOa/mnYq6RzuJlEpV+IOln2fbPz; 25:fjZsqujxso2GTCd0AU+D6sF+IBNeBABfRPl0Tj8z71bi5l9hdCj+DhsCSFrH9MYpWorLUe0aOLw9RnIbrRxeEQn4h0RuW8F+LQVVqlVI7/MF6HzN/xvHRrq/iBssEtVB3Lg/QWbNg+exziZWP8WtvvwPsrMHmHIcdNmupo6UM1Raq8qxqMQA2ZEIAJmha3DyGzHcQoCy65apeNON2uKXwae6gx4JU05p7h3flWM43680csKrvNgmGtq0Blr3UjK1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2158; X-MS-Office365-Filtering-Correlation-Id: bed98c45-7f61-417c-1837-08d31c44ed88 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 20:jZ5o8sPTpWWkTiySBxRPn5uCLoZgQwuajTVVYWG4c1koHIFRV+SA4Z7Ue+6nDoalVZ5dzZ/iJiuhUQ6fmS+D3OYrH8kR7YK4BZ4VQb8cTD8G2mXcgmBSx28mlfSQGUPYcypiflE0bWo+/6yK/fPQ4HxkTt/WyjYlN4C+H37yFid7Ojby/bwuos8ewkg3zriXIsy3CMo68ifbWuSb1PRnvCXXU5O8cGfRvX0OlD9Z4s6PGIOmj/EGUAKQA2yZs/s90/TD7OI6mTx1ktibfADO7WiUrcsALqIr4p7EOdefUMQXA3m6SSUoALOKz3JLL/cHVqJ0DZ3zFR1cJ7pyo71MqiBHpyAKdMar/ersFbWbHTqiVxpzrhEaw1IrgG8K5MZHc1PmYrlUzeXke7A6sBMnddxkI4kMkJjDDuJYCOSWV4WBWWHRLn/xhRutLYrES43j83xMQrktdNQzm68/Nc2Wcio8K8ygviN0J3EIk1FvcbWteCTnF7rCSl3zOROJR+c4; 4:fWSJnEEs5u6dkW325/eKMAsTPymCGF6FMX5pY8ihnpNU9AFUXNMbg767WG+tNM9IDETHqdAIr3lGCqCX8AI1rVVJvg0EW9NhS9SJFXh57AElVxLyGn1gTxOlHL9UPeseLMibwm92Dwj9mcBmpC+6AWG8AZHCv5WyXugm4TC+nV1D1mgj9uuSkfnK1Vaiu0Y/VaDmQa61u2WxCk76VuuqM7y/y5vk1t/OC4WY+AVkAZBamKDs9jKkKYkU0i8EM4y08536XRu9/ADI7EDpCV6ARrFBvfevEqmoVlVBPI+RfNatzZ9NYsHmm+F/TDKzWrC+femzqvvBY7YFw9cp8o8K6MiEfDCwsMr67NR7UwqLrSL2YcPco/MEikKc/h+otQDT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:SN1PR0501MB2158; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2158; X-Forefront-PRVS: 08200063E9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(164054003)(189002)(50466002)(23676002)(229853001)(77096005)(230783001)(83506001)(86362001)(97736004)(80316001)(4001350100001)(81156007)(59896002)(87976001)(65816999)(5001960100002)(42186005)(101416001)(107886002)(230700001)(40100003)(5001770100001)(122386002)(87266999)(106356001)(50986999)(105586002)(54356999)(64126003)(2906002)(36756003)(99136001)(33656002)(92566002)(189998001)(6116002)(450100001)(3846002)(1096002)(586003)(5008740100001)(47776003)(5004730100002)(65806001)(65956001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2158; H:[172.29.35.81]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1MDFNQjIxNTg7MjM6V2VqVlpNNW9CVHZuK0lYcjZRVXlYNE9E?= =?utf-8?B?MFNtWTFqbHV4VUhqLzRTaTNvZm9SQUUzdW5ObkdveVdQdjhmYkdOdzZ5dEsv?= =?utf-8?B?VEZxb0FUeTJhOHg5QnNHK2diZGdwOFhoK3F5c1VLeTdlR2RTZVZXQlNuTlcx?= =?utf-8?B?TWNKM3pyRGMySWhFRGg1MUxWNzlCT05TOHgxZlN6VjFweldqU0FrL1FpVjZ3?= =?utf-8?B?cVpTR3FXekdCVHh6SDBCV2tpVGg3TmlmSHZFcDZNQ1pjVythNnVoTlBCeTFH?= =?utf-8?B?YXBpRnd4RW1ualN1dmhDWG9qNWVRZ2lUTWFZbCtOL2JsNjJpWXJZejBZdHIy?= =?utf-8?B?S2ZNSGVrYkpDcGRRRHE0Sm81SWozZ2lTa2creFVhdDd0T2ZUUDdQOXBVaTBS?= =?utf-8?B?eHJqQmF6Y3VjWEVqcWh1NVRSWXRIR0F0WkJiS2xFbGZYMlpFMTUyODBscGlK?= =?utf-8?B?N3BObnBEZFJkZG5JVDMyVHA3TUZKaXVlRlZQMWlFVyszQkxGOVBoQURnZ2VS?= =?utf-8?B?WURiM1l6K1B3eVZwSW0reVl4Z25YWSs4aW11TkJaTmVyc1pUbXpPcnZVa1A2?= =?utf-8?B?RWFTS3owbjZjMUtvVjZBeEEzWnRxeUNBcUNOMmRFV0x3S0tuQWRvajhickNm?= =?utf-8?B?WWJPS20xZjUycTYzYnNjWFh2N1Q2czlCZjBOOFMxTENodld1YnNPcXNicldK?= =?utf-8?B?WFpjZkZhM3h4bS9yeXdOK09PVVI1VGJXaVV5QXpVTVRzVkcwd3hCRk16VTkw?= =?utf-8?B?MWNHd3ltcDBDZmVvYmpzVS9VMTJMUmtDTnZVT0NMdjdQSG8zeVU4ZEVUaEd2?= =?utf-8?B?bXVkN3BNZkFCT2hGaC80b0lscEEwckRqMDBnQXJGdzR5aFZ4VXU4SWltMTdX?= =?utf-8?B?UllFeGJmTndlcmZWTUtreDZBQjV4bUlBLzE4MDZIMDl6ZUhRWTlRNGc0Q0Q5?= =?utf-8?B?Z0R2UU9rcEdKTGxuNXpHSENhVXluTEtLdVo3dThUWWRNS0dUcGtnMkhBRXp1?= =?utf-8?B?RWw1YWFVSmlUWTZ6VU9BSVNvbXRMY3JxdVc2SGg4aW40NGIyejdjVWtaaTlS?= =?utf-8?B?bkwzVmxZd0tmcHJaaUVxemNRdzFzKzdWQWxJZ0JKQzZuVWp2NzliNVg4V0Z1?= =?utf-8?B?TnBjb2JsTCtDVG5oT1Y2L0VDanZjYXU4NkxuV2JZbnRZVzZSQlk2REgxMlhG?= =?utf-8?B?K3g4V2ZtMzdpek85WG0wRTZNYnVkUk1HRE0vaVNkbzZWRmdzdVlEbWszMHgv?= =?utf-8?B?akxmdit4MERjUHgxTHo1Z3pZdjQzOUZnZmlZRVpNalhSM2NKYUFpY2VQY2dG?= =?utf-8?B?UzZQMEx6TkNLbHZoekw4d05JY3JHR0FaNmlzR2ZKRS9Ldm13Wm5YUkRoQkRY?= =?utf-8?B?NnJVUWNwME5kSnQyVFh0eEx2NXJpZUlQSGROZkl4SlF6R25NcTVIZ3JjZzlB?= =?utf-8?B?N0RXMzVBSHl3aUp4dm1BNlZFemhTa3F6a0UvNUR4QVFldlk0UTRybmwycUx6?= =?utf-8?B?Qmk2emc2NzgyMXBkK1dmL3VDTDFZa25LdGFSajIrM0lScEhsK21KVVUyYnVv?= =?utf-8?B?Q2ZZNEk2MFRZVUk4NjJ0eXNuS1RzSE96OWNRSGxxRHZZaFRaU3hSSXl1NllJ?= =?utf-8?B?NkRyYXNyUXdadDluTXZnTjBKUjg2RzByUFFWa3crNnVZc2FqS0NLeVp0NDkw?= =?utf-8?Q?l9NPAijcn/FNvrjuIXvHBl9nOQ8Zo45A7+cEwBaSF?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 5:LVDsseTPAGOWs9d9oYG9CKsP087XoSE5yt8u/GX1zS91TxjZ3N8AtvGRBlVA8+4Ko2KGnyXl5ejuCf2c7M212jnc905PKrsxGJkA5zbfx54la9xHGsiUik+ZFC6wZHJ4DSrnAWSx0MqOGuRoq6xpcA==; 24:dAtz/XlEGncAeTjrirdHD1paT+/Js8T78rZ0DgsOsSof+B2bbm4mit+2WRxUZ7uy59pbUZLLtBOkZT5TR4s44/CZtJJS0SHRg1Neh30Hu/8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2016 18:11:14.8469 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2158 Archived-At: Subject: [mpls] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 18:11:41 -0000 Folks, Pardon the cross-post, but I think this may be of interest to all three of the IDR, MPLS, and BESS WGs. I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels to Address Prefixes"), which is intended of course to obsolete RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in the name of the draft, it's not completely obvious which WG should own this draft (assuming it progresses)). The purpose of this draft is the following: - It fixes a number of errors in RFC3107. It attempts to do so in a way that is compatible with existing implementations. - It removes the material about "Advertising Multiple Routes to a Destination". This is a feature that was never implemented as specified, and the text about it just causes confusion. The functionality that this feature was intended to provide can now be better provided by using add-paths; this is discussed in the draft. - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. - It clarifies the procedures for withdrawing and replacing label bindings. - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, which is very unclear in RFC3107. Different implementations have treated the SAFI-1/SAFI-4 interactions differently, and the draft discusses these differences. However, as the draft is not intended to favor any one implementation over another, it can't do much more than point out some of the differences among implementations. - RFC 3107 provides an encoding that allows BGP to assign multiple labels (i.e., a label stack) to a given prefix. However, it provides no semantics for this, and this feature has been only rarely implemented. In fact, it is believed that some implementations will not parse the Updates correctly if they encode multiple labels in the NLRI. Therefore the draft only allows a label stack to be assigned to a given prefix if a new Capability has been exchanged. It also discusses the semantics of assigning a label stack, and gives some examples of how this might be used. I hope that those of you who are interested in this topic will provide your comments. I've tried to make the draft compatible with existing implementations and deployments, so if anyone sees anything that negatively impacts an existing implementation, please comment on that. I also removed most of the text that explains why it is a good idea to use BGP to distribute label bindings. That text was important in the '90s, but now seems rather out of date. However, I would welcome comments on whether an updated "motivation/positioning" section should be added. Thanks, Eric From nobody Thu Jan 14 07:18:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FA11B356B; Thu, 14 Jan 2016 07:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1_xgDGCiWUN; Thu, 14 Jan 2016 07:18:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408BB1B3570; Thu, 14 Jan 2016 07:18:36 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B6F4C2642F5; Thu, 14 Jan 2016 16:18:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 914E14C074; Thu, 14 Jan 2016 16:18:34 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0279.002; Thu, 14 Jan 2016 16:18:34 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3fSdezVI1uUky3rzngjkewoJ76y2xw Date: Thu, 14 Jan 2016 15:18:33 +0000 Message-ID: <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.1.14.150317 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:18:41 -0000 Hi Eric, Thanks for the draft. I read it and it looks good and useful to me. I have mostly 1 comment: > - RFC 3107 provides an encoding that allows BGP to assign multiple labels Upfront, the current issue is that implementations, which claim compliance = with RFC 3107, are just non-compliant. So the draft is proposing to change = the specification to make such implementations compliant, while another opt= ion would be to fix implementation (to be compliant with the RFC they claim= to support). I don't really expect that we'll agree on it, but I had to make the comment= nonetheless. ;-) That being said, The proposed capability is a good idea to improve interoperability. Thanks. The main issue I have, is that this draft is not backward compatible with R= FC 3107 (as a RFC 3107 speaker will never notice that its peer has not send= the new capability, and may still send multiple labels). Plus in case of e= rror due to this incompatibility, the error handling behavior is likely to = be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which = is disruptive. Plus the implementation A not supporting multiple labels, wi= ll claim that the implementation B supporting multiple labels is "not compl= iant" with rfc3107bis, while I would rather argue that this is implementati= on A which is not compliant with RFC 3107. I'd propose one change: - Capability means: I don't support receiving multiple labels, hence you SH= OULD not send that to me. - Even if the capability is not advertised by both peers, and hence a singl= e label is expected, all implementations MUST check that the "S" bit (in th= is first label) is set to 1. If the bit is cleared, the Prefix MUST be iden= tified as per RFC 3107/this document and treated as withdraw as defined in = RFC 7606. This means more work for rfc3107bis speakers, but we can't ask existing spe= akers to do the job. Especially since they were compliant with RFC 3107. Alternatively, the capability could be extended to carry two meanings: I su= pport rfc3107bis, I support multiple labels. This would allow a rfc3107bis = speaker to refuse the BGP connection with RFC 3107 speakers. But this is mu= ch less convenient. Plus very minor comments - From an editorial standpoint, I'd personally favor removing =A72.2 and sa= ying in 2.3(or elsewhere) that if the capability is not exchanged, a single= label may be encoded. (IMHO duplicating the text is less easy to read and = more error prone. And I believe this would be enough to address your point). - In Figure 2 (=A72.3), 2 labels are indicated. Do you think there is a nee= d to indicate which one is the first (Label 1) and which one is the k th (L= abel k). Indeed, the order of the labels is significant when the router wil= l need to push them in the dataplane. Or a sentence could be added to make = this explicit. - In =A74, there is a possible case which is not described: S1 receives L11, L12,... L1k S1 sends L21, L12,... L1k S1 programs in the data plane: L21 swap L11 Compared to sending a single label (L21), S1 avoids having to push k labels= in its dataplane, which it may be incapable of. - In =A74 "While this may be useful in certain scenarios, it may provide unintended r= esults in other scenarios." I fail to see when this can be useful as N1 or = downstream LSR will receive packets with labels there are not aware of (L22= ...L2k). Out of curiosity, I'm be curious to know the useful scenario that = you have in mind. - in =A75 " It is possible that a BGP speaker will receive both a SAFI-1 ro= ute for prefix P and a SAFI-4 route for prefix P. The significance of this is a matter of local policy." For 6PE (rfc4798), may be this should not be a local policy but be specifie= d as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc479= 8 could have specified this but I haven't check if it's done. Alternatively= =A75 could reference this case. (Same point for propagation between SAFI-1 and SAFI-4) Thanks again for the draft, Regards, -- Bruno > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen > Subject: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Folks, >=20 > Pardon the cross-post, but I think this may be of interest to all three > of the IDR, MPLS, and BESS WGs. >=20 > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS > Labels to Address Prefixes"), which is intended of course to obsolete > RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in > the name of the draft, it's not completely obvious which WG should own > this draft (assuming it progresses)). >=20 > The purpose of this draft is the following: >=20 > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. >=20 > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as > specified, and the text about it just causes confusion. The > functionality that this feature was intended to provide can now be > better provided by using add-paths; this is discussed in the draft. >=20 > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. >=20 > - It clarifies the procedures for withdrawing and replacing label binding= s. >=20 > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft > discusses these differences. However, as the draft is not intended to > favor any one implementation over another, it can't do much more than > point out some of the differences among implementations. >=20 > - RFC 3107 provides an encoding that allows BGP to assign multiple > labels (i.e., a label stack) to a given prefix. However, it provides no > semantics for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if > a new Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be use= d. >=20 > I hope that those of you who are interested in this topic will provide > your comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. >=20 > I also removed most of the text that explains why it is a good idea to > use BGP to distribute label bindings. That text was important in the > '90s, but now seems rather out of date. However, I would welcome > comments on whether an updated "motivation/positioning" section should > be added. >=20 > Thanks, >=20 > Eric >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 14 22:50:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478491B29FF; Thu, 14 Jan 2016 22:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUpsbX48mwBz; Thu, 14 Jan 2016 22:49:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FFA1B2A29; Thu, 14 Jan 2016 22:49:55 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.213.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2F77E18013CB; Fri, 15 Jan 2016 07:49:51 +0100 (CET) To: Eric C Rosen , idr@ietf.org, BESS , mpls@ietf.org References: <5696933E.1080802@juniper.net> From: Loa Andersson Message-ID: <56989686.2000100@pi.nu> Date: Fri, 15 Jan 2016 14:49:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5696933E.1080802@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] [Idr] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 06:49:59 -0000 Eric, In this particular case I think "cross-posting" is necessary. One small reflection for what it is worth. If there is no strong reason to put this in one working group or another, there is probably no strong reason to change the home of a draft either. /Loa On 2016-01-14 02:11, Eric C Rosen wrote: > Folks, > > Pardon the cross-post, but I think this may be of interest to all three > of the IDR, MPLS, and BESS WGs. > > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS > Labels to Address Prefixes"), which is intended of course to obsolete > RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in > the name of the draft, it's not completely obvious which WG should own > this draft (assuming it progresses)). > > The purpose of this draft is the following: > > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. > > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as > specified, and the text about it just causes confusion. The > functionality that this feature was intended to provide can now be > better provided by using add-paths; this is discussed in the draft. > > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. > > - It clarifies the procedures for withdrawing and replacing label bindings. > > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft > discusses these differences. However, as the draft is not intended to > favor any one implementation over another, it can't do much more than > point out some of the differences among implementations. > > - RFC 3107 provides an encoding that allows BGP to assign multiple > labels (i.e., a label stack) to a given prefix. However, it provides no > semantics for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if > a new Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be used. > > I hope that those of you who are interested in this topic will provide > your comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. > > I also removed most of the text that explains why it is a good idea to > use BGP to distribute label bindings. That text was important in the > '90s, but now seems rather out of date. However, I would welcome > comments on whether an updated "motivation/positioning" section should > be added. > > Thanks, > > Eric > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jan 15 05:41:20 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9C1B2D02 for ; Fri, 15 Jan 2016 05:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eyuPQBqFLJB for ; Fri, 15 Jan 2016 05:41:15 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0CB1B2D00 for ; Fri, 15 Jan 2016 05:41:15 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u0FDf9Fv000698; Fri, 15 Jan 2016 13:41:09 GMT Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u0FDf6HL000644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Jan 2016 13:41:07 GMT From: "Adrian Farrel" To: , Date: Fri, 15 Jan 2016 13:41:05 -0000 Message-ID: <06f301d14f9a$63011bf0$290353d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFPmbjIaEL3wN4lQbyDhznKiLgSnw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22066.007 X-TM-AS-Result: No--10.045-10.0-31-10 X-imss-scan-details: No--10.045-10.0-31-10 X-TMASE-MatchedRID: 3Oda+C3NjoHmdcm+4RXJ7cK7fT3t6J55StGAgmKqWuUPVb41Wr4BJ6ZE Tt/s5jFSDk/BWghZZhOO0HEoL+4qNsLk3xw1Sf9eU+OjsPhIWDjvuxUBBenYrbBOE9APtGEpK4y 9tZbFc857TtRd+Rdj8wnxfqppvFLB9dBT/rXQR8q4jAucHcCqnX4rryovYbmmqPm/sjj9KBhC2N m8Kw//Y0T5eteBYbZagbO6ndAwwWWJr1DakyMzT5WOaq+3+nxyg3XZcphu4kteNs5tWYvjCQk9h gFqz4UG4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjOwBXM346/+x3Aku17uUlvssi493p0AqTT28v VFibnfuTvwRDBflABIcKt/WUynNs Archived-At: Cc: mpls@ietf.org Subject: [mpls] Question about RFC 7439 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:41:18 -0000 Hi Wes and Carlos, Embarrassingly I was the AD for this document, but I still have a question. Section 3.5 comments about MplsLsrIdentifier. It says that RFC 3811 "lack[s] support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier." It also says that "[MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete." Note that the second quote refers to just one TC. Looking at 3811, 5036, and (most importantly) 7552, it seems to me that the LSR Identifier is *always* a 32 bit quantity regardless of whether the LDP system is v4-only, v4/v6, or v6-only. Furthermore, draft-manral-mpls-rfc3811bis (i.e., [MPLS-TC]) clearly shows no change to MplsLsrIdentifier while marking MplsExtendedTunnelId as obsolete. Notwithstanding that draft-manral-mpls-rfc3811bis appears to have been abandoned in state "candidate for WG adoption", it looks to me that RFC 7439 has an error we could call a typo. I propose the following Errata Report... OLD 3.5. MIB Modules RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete. NEW 3.5. MIB Modules RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId. This textual conventions is used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802], and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete. END Am I wrong? Thanks, Adrian -- Celebrate the New Year by buying someone you love a book. Tales from the Wood - Eighteen new fairy tales http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. From nobody Fri Jan 15 06:52:30 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BE91ACE6A; Fri, 15 Jan 2016 06:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVK9HNfj5AqS; Fri, 15 Jan 2016 06:52:28 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94A91ACE6B; Fri, 15 Jan 2016 06:52:27 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so23395636wmf.0; Fri, 15 Jan 2016 06:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=C0EAQ+x5BMm0HxEJYLRSP5tBHqct/VEggDJnBXWtzlE=; b=ziTUIKaujvXkuQid1sI0STzw11yP/f+ToIYFq53YaqCgFyiHl+m/V/l61UWPm4nMX2 Cm55IEeZWapRwAcaLjU3hbKrVkx5Qax5DuAinvFurXigoYAIfawlKxsVTNcIUd6qkN0G P/rc5ZKXJHxMVMDcM4AgAoW+gFeoAWzS/0epw7AUlcl3VM0nsLmD1hvNwPtabcafx+c2 VZaB4ooOMcA2ZRNJv//wkW4gAc2y7+wgYIwn/UoKyjjyq+gBIyE1aQDDeNWW8Z4h/kem yhbdxzcZeKjT67jaT3McINIFGDe+kNC2ud6CV312Vr2Xy6wR7TDwxEdm19kElxdMANFL wDRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=C0EAQ+x5BMm0HxEJYLRSP5tBHqct/VEggDJnBXWtzlE=; b=AIF/sNGV5amGUTEvWd1iynBDxAlyHxxwW3nQrlz81XTKekTYDyW1dkCJJ1cPvI/NDA Lkd1Vac3J7qx73MGEQ7wZ+FJBrbM+1Ahu6jG6RrIl4+oIlj7I6BYVSJTyCQ4VaYksZUq I16yyg6cN4Bcl8LVqm9+vGNh7AGGk/CKV/eqlYip+HBgzem+SK5aEJAJeIn8hNN7GUlX QlCj6n/OIcSRDSn5p4nl46ugiyRGQ1d+JBzmiouQ04kzX3VFttelL/Z4ZRXg3SyDMm4I CdQOULK4WdU+/7kH/CvhAUJ22+2u+6KDKGVdQNTlnekbNwUeXmDr+9HBezOR4n14pXRT lo2A== X-Gm-Message-State: ALoCoQnUpTi5o64rY7MNMM8GVqyZhti7d2m7iy4EJ4khZuKs8eJStimjldQi5AReTTN+H9saQ/Bu42SIPgKk1UnhE4Dt3Kd1lQ== X-Received: by 10.194.158.135 with SMTP id wu7mr10525994wjb.142.1452869546245; Fri, 15 Jan 2016 06:52:26 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id cv10sm10876099wjb.17.2016.01.15.06.52.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 06:52:25 -0800 (PST) Message-ID: <569907A8.1050909@gmail.com> Date: Fri, 15 Jan 2016 15:52:24 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" References: <5694D729.5000505@pi.nu> In-Reply-To: <5694D729.5000505@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:52:29 -0000 All, I think this is a useful document. I support adoption as WG draft. Best regards, Huub. > Working Group, > > This is to start a two week poll on adopting draft-cui-mpls-tp-mfp- > use-case-and-requirements as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR disclosures against this document. > > We have an IPR poll running in parallel, his poll ends January 27, 2016; > or when the IPR poll has concluded if that is later than January 27. > > /Loa -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Fri Jan 15 10:01:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4BD1B308A; Fri, 15 Jan 2016 10:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw3UEikbY3Ek; Fri, 15 Jan 2016 10:01:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70281B3085; Fri, 15 Jan 2016 10:01:12 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.81] (66.129.241.12) by SN1PR0501MB2158.namprd05.prod.outlook.com (10.163.229.152) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 18:01:09 +0000 To: References: <5696933E.1080802@juniper.net> <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <569933E1.7000104@juniper.net> Date: Fri, 15 Jan 2016 13:01:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20421_1452784714_5697BC4A_20421_2179_1_53C29892C857584299CBF5D05346208A0F791AE7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY2PR08CA0007.namprd08.prod.outlook.com (25.163.62.145) To SN1PR0501MB2158.namprd05.prod.outlook.com (25.163.229.152) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 2:YLAtsVufOQ0RW20UEP4vSPrsXMZz5AWJCQxk6XJ7TQ07iihu/QMFkzN3PUzrAY/lLsDYBXyawuQUbMB6ywHqQ5hHYOMNmh0tyek3FgacaqFdo3GqBIKcasRH3jvFziPqUaswuvjY5kLiCLKKYytFbQ==; 3:ZFuAmh7G9M5sqKxP4hPk5AaHfbh7wogtdSIRyp9IvYdRMGtoNfySnWpg+4b6sHjopsVTJZp0NrD/RRFmrnevsZwfxikn22yh+V5suCYnD2oFuy+NgUetFGN/Jp50ZchV; 25:bG31oiigTmFIyz/k72L8BcKMfO/4Itq4xSr2x9OW2udWNGCMqFBApquDEpgz7g68KJ9+hZE3Sc+Pe9rqVk1XF66o7C493ElPg0+/YtXLBzwCWThTIieu5YFppC/4+PMmu0SsonThI+mI4bppQ+zwDKPyXORw/4VuhFilWvBpiptdC4qiXuD0YjSfapOhP5k419VaX0R2c2XDBSKDK742upF2p9nMVBlfR7GZExE5mAtTIWWADJ4BFTuS5nCzHAUC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2158; X-MS-Office365-Filtering-Correlation-Id: 2842bd9f-8cc4-4dd7-e371-08d31dd5d9f1 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 20:gudvSEvPSP5E6hS4j4QMHzRaGfEP+ScD9pdLOcJf1Sv72uzfKa7QzA97PNVdvgFRb36EaG2H6LHDZ9mURJ7r6FDSl/PZhdf99IamFujEph5spfVOgJpu6LVpQFpQh7RA3QG46rZlDPWT3AdZQ75Y4QGZ/ISf4DSZzSleyRbYEWvobVrAuWlaiyOV5/MVy7jProZOVSgHGnLGJjvGa+wbM4a2yRrbbdVa/v1MdF5tzjWrudGW0fyj2qZxMIvQZb5p65GvDglFZbpsXZGQEAwP6KI3Qoy/0bDbWBsyBoMqdRxAlKfpJDnqxqD0LBQDarcjk42YmdI8B8b5Pa+NC8DOgpt5G8ywZ7lnMy52rxb8AcweMjZj0bfKCSAh32XD1dkOJXqyfa3UjZ+WVdJonNPdDQEl16z02kgiGtFRQrsFH0louSYY1TvArwXLIY9h4VL3os8YMD8oHnbvgEk1X9Qlh4ZCQJpv32Sl5Dhbks8uePvySS9m5tPHcAOe975iRMDZ; 4:aKPXGIxecab0PpXGCrhY/pEk0t2MPCv7GIQxHrRyZpxPeO2iTL6gv7ubzsQH6kzhVN99Ti0MAwM8rj5WmByTmXr3bMTtNeNPZNUBl3UQsMYmNQL78j8lWPEzysbvCyI7Yofuh1iZM+NnEbLnQHxs1cLglfO1vWDCGlGZTn7EIkbdnhuSsGt+5FkD+qg3q8tkfg0FACfn9E1E2P2wmKROf9Td5gGXbvYIpWDYEAmf4fRGDXdJnWdOgM0PW4VDbr23MqVUOFINvuR9ygx9grW/BqPoSGR+US2wDmJ0hEh3wur6U3ApB4BRG8cI6UDjkDyB2k7JZEaudYS9OKDtUH+RL8004KY3A3sLfBCz1qRDls+hvwUWB/0BJ/+ZSkl8r+qC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:SN1PR0501MB2158; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2158; X-Forefront-PRVS: 08220FA8D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(31014005)(199003)(52604005)(2950100001)(77096005)(101416001)(5008740100001)(86362001)(92566002)(2906002)(33656002)(3846002)(40100003)(122386002)(4326007)(5004730100002)(50466002)(1096002)(6116002)(586003)(42186005)(5001960100002)(189998001)(59896002)(36756003)(54356999)(110136002)(87266999)(4001350100001)(65816999)(81156007)(97736004)(47776003)(87976001)(50986999)(230783001)(83506001)(23746002)(2351001)(80316001)(64126003)(65956001)(66066001)(65806001)(106356001)(99136001)(76176999)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2158; H:[172.29.35.81]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR0501MB2158; 23:pI7dfvafUg2rC7o0M/Y7J9C1pqnWlG1YU5j?= =?Windows-1252?Q?RF9pfsKP/ZItqTbU25uvj14cCfWPSP04OXSDa94CttAoAXAYHeCjXn1g?= =?Windows-1252?Q?jwZO+70UrQAtCshzcDFuDTu8nigll5P3oWuvr9HPAdvd9yiUmLK9XlzK?= =?Windows-1252?Q?9AU/SJbn0oMfCEWBEkLlrzgHxMHaLVihnqjup84hBzvbCz2hY1+AE5ir?= =?Windows-1252?Q?npLZxHPFu2dETfpYSgKoqtjJKJ2w+DQuEkdbpISgVpb/NkmlqpnZoXVV?= =?Windows-1252?Q?WC3s5S3i3V8v03KdIn4n7Fo7dm6fhktXGouOtFVUe/YP160Wdm8pVFfh?= =?Windows-1252?Q?3RigiLYT7nbrL44vrqx/CAKTMTO7uQ5RlFFjlcSoHcoaYTlPZv3CaalT?= =?Windows-1252?Q?D88hGapX8stIUCWfuYZ9T3ahVXZPMYPlDRU0zi/E9Et7o1g9SkhqVJmL?= =?Windows-1252?Q?aMTItFTJ9XqdlLGLZU9oqtLorfFTVEtGqBFAGCFRrmq5q64PBjyRazeQ?= =?Windows-1252?Q?Kto0JBGQRnvIDyq+3l0+RaEZmSmQ5B1WxIJ1m5xWwXt4Ckzs/t6UA10X?= =?Windows-1252?Q?0+R+0fCzXM2YYpW7hiv6lLRk/LXRQ096UY+QdeM/WxQrCwOSdSLd8lw/?= =?Windows-1252?Q?ILY8wkFQ1XGM4WEad51IBej4Yewa3V8ScCt5x/jQVxf4x2pN8U4Wj0Jh?= =?Windows-1252?Q?KcexhVgV9FGlan95zhBPTwM+H0dfktGW8duOrDi+5BNmgWOPs+2aN8N5?= =?Windows-1252?Q?BtPXYVvB5fPzX1lxzSytZMiQFvo802el/pLxeikjDOv01//q/D9RQXx+?= =?Windows-1252?Q?jcCFdJSquXT8veA/7rwWwcSaRw7npY/Oh5IdcOEsBAhTX41m4CGyJA4G?= =?Windows-1252?Q?6YQ7wuz89qEqvE5kCpYiUWoP5h3SyEzPUesioBK5a7F0U8TqBVlenbeN?= =?Windows-1252?Q?TSzMflrAb8WeS1hHxwDTC++5viW7aQy9dvbx/4WvttZj65SQvRivj5N+?= =?Windows-1252?Q?9mD9v/6rJ30mAZMPq5G2PBpESvpWZWvbeWp4VVInZtOcp1cX/okKKyWs?= =?Windows-1252?Q?rgw1dH01fmiMMfF0ygzSSOo2YllIRSlMXYGMsfril+6Cja+5+lkipDVp?= =?Windows-1252?Q?hl35Up/tx7uOndGo1gAcDSf5pv42iWj//kwSpC1ng9qrWAphYs3zrLOM?= =?Windows-1252?Q?1ZHNIhhUMYhMk4GnQWeW4xB/4YIqmiyrsT0SYFrkJGnAKOB4SVn2pvK4?= =?Windows-1252?Q?iu0dayKlVCVcXns5q0PW6Exjj7T4zHuxjm3zDvc7ICBaoWmTSDaII60H?= =?Windows-1252?Q?Ias7+T5EBRaZqnMg9K/w/VvKcanEla8VzLhfSOzy8P5r1s+31Cm/kSY0?= =?Windows-1252?Q?UyXt8zR+lTFvB/59FdLYJ5ltUnSKGJKOU+Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2158; 5:MdsfsRHYS+gT5KWL7Bo9sGJ0VTZBLCKpfB0/uM1BZrgy8lLkOVJevWbZvxLTJ3t4NImpqgSTLrztPas+XjV3aYjhlXqRnUx19ikNXUl3y/pbn4x2iKHTTCsBFWak2JofgLIikw+sir7ImwoEvFmviA==; 24:bux7oR+246sTnVRkK597UAWZMuGJrs+7a0WMD/PtpOJ80Zdyo2NbYG8WkoTxBb/lbGzoy5/3KIahFw/TmeVsmvOfnjSbskTiNoFyBI9S3fM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2016 18:01:09.8619 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2158 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 18:01:15 -0000 Bruno, Thanks for reviewing the draft! >> - RFC 3107 provides an encoding that allows BGP to assign multiple labels > Upfront, the current issue is that implementations, which claim compliance with RFC 3107, are just non-compliant. So the draft is proposing to change the specification to make such implementations compliant, while another option would be to fix implementation (to be compliant with the RFC they claim to support). I think the best approach is to try to write 3107bis in such a way that the existing deployed implementations are compliant to it. > The main issue I have, is that this draft is not backward compatible with RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not send the new capability, and may still send multiple labels). Plus in case of error due to this incompatibility, the error handling behavior is likely to be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which is disruptive. Plus the implementation A not supporting multiple labels, will claim that the implementation B supporting multiple labels is "not compliant" with rfc3107bis, while I would rather argue that this is implementation A which is not compliant with RFC 3107. Luckily, the existing deployed implementations, as far as I know, do not support multiple labels. If a new implementation were to send multiple labels to an old implementation, we would likely experience the disruptive behavior you describe. 3107bis tries to prevent this disruption. > > I'd propose one change: > - Capability means: I don't support receiving multiple labels, hence you SHOULD not send that to me. > - Even if the capability is not advertised by both peers, and hence a single label is expected, all implementations MUST check that the "S" bit (in this first label) is set to 1. If the bit is cleared, the Prefix MUST be identified as per RFC 3107/this document and treated as withdraw as defined in RFC 7606. > > This means more work for rfc3107bis speakers, but we can't ask existing speakers to do the job. Especially since they were compliant with RFC 3107. If only a single label is expected, there is no real reason to check the S bit. I'm not sure that all existing implementations actually set the S bit, so requiring new implementations to check for it would just introduce a possible backwards compatibility problem. > Plus very minor comments > - From an editorial standpoint, I'd personally favor removing 2.2 and saying in 2.3(or elsewhere) that if the capability is not exchanged, a single label may be encoded. (IMHO duplicating the text is less easy to read and more error prone. And I believe this would be enough to address your point). I went back and forth on this issue, and I'd welcome more opinions on this from the WG. You are right that it is generally a bad practice to have so much duplicated text in a specification, but I thought the intention would be clearer if the encoding for multiple labels were described separately from the encoding for single labels. > - In Figure 2 (2.3), 2 labels are indicated. Do you think there is a need to indicate which one is the first (Label 1) and which one is the k th (Label k). Indeed, the order of the labels is significant when the router will need to push them in the dataplane. Or a sentence could be added to make this explicit. This is mentioned in the "Data Plane" section, but I think you're right, it should be mentioned in section 2.3 as well. > - In 4, there is a possible case which is not described: > S1 receives L11, L12,... L1k > S1 sends L21, L12,... L1k > S1 programs in the data plane: L21 swap L11 > Compared to sending a single label (L21), S1 avoids having to push k labels in its dataplane, which it may be incapable of. > - In 4 > "While this may be useful in certain scenarios, it may provide unintended results in other scenarios." I fail to see when this can be useful as N1 or downstream LSR will receive packets with labels there are not aware of (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario that you have in mind. Actually, I was thinking of the case you just described above, but I wanted to formulate it in a more general way. For all we know, may be domain-wide unique labels ;-), or S1 may have some other way of knowing L21 will get the packet to a node that will be able to understand . > - in 5 " It is possible that a BGP speaker will receive both a SAFI-1 route > for prefix P and a SAFI-4 route for prefix P. The significance of > this is a matter of local policy." > For 6PE (rfc4798), may be this should not be a local policy but be specified as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 could have specified this but I haven't check if it's done. Alternatively 5 could reference this case. > (Same point for propagation between SAFI-1 and SAFI-4) In 3107bis, I just tried to capture the fact that different implementations handle this differently. If a particular application needs to mandate a particular behavior, that should be part of the spec for that application. Eric From nobody Fri Jan 15 10:15:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961311B2FA8 for ; Fri, 15 Jan 2016 10:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4JCSoRorXTg for ; Fri, 15 Jan 2016 10:15:01 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD041B2D30 for ; Fri, 15 Jan 2016 10:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1452881700; x=1454091300; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xux1oBeqF9ykccF5cYCq/9c7acTva4kgmEKlmp/F6zE=; b=FPIND3SsKSxq9zHrz+iLU7RAvLxZxPyVCn/7Q5dLYzjC0hdHU2yTye4h fYH4x9ymVq7EMye8kcC1sV2DAA2BuK3cJtWSI3KPZZ51NfD0EpgD3aeiX o2Z+6dM+o7ngu+p6h5secsqunrnFehkdA/rUe+8SuQSsN0xntu3UKqeLy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgALNplW/4wNJK1egzpSbQaIULMsA?= =?us-ascii?q?Q2BYyKFbQKBODgUAQEBAQEBAYEKhDQBAQEEeQwEAgEIEQMBAi8yFAkIAQEEAQ0?= =?us-ascii?q?FiBsOwSwBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlWEf4E8iAEFg3mTIAGFRogXj?= =?us-ascii?q?wGOXAEgAQFCgh6BbHIBhSeBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,300,1449532800"; d="scan'208";a="227879809" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jan 2016 18:15:00 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0FIExVI022088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 18:15:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Jan 2016 13:14:59 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 15 Jan 2016 13:14:58 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel , "wesley.george@twcable.com" Thread-Topic: Question about RFC 7439 Thread-Index: AdFPmbjIaEL3wN4lQbyDhznKiLgSnwAJur2A Date: Fri, 15 Jan 2016 18:14:58 +0000 Message-ID: References: <06f301d14f9a$63011bf0$290353d0$@olddog.co.uk> In-Reply-To: <06f301d14f9a$63011bf0$290353d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.55] Content-Type: text/plain; charset="Windows-1252" Content-ID: <34F9B2FFE8F0B144829144068AA1AE5E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about RFC 7439 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 18:15:05 -0000 Hi, Adrian, I believe you are right, in removing =B3MplsLsrIdentifier" from that sentence. As you imply, the answer seems to be in S4 of RFC 7552, at https://tools.ietf.org/html/rfc7552#section-4. Thanks, =8B Carlos. -----Original Message----- From: Adrian Farrel Reply-To: Adrian Farrel Date: Friday, January 15, 2016 at 8:41 AM To: Wes George , Carlos Pignataro Cc: "mpls@ietf.org" Subject: Question about RFC 7439 >Hi Wes and Carlos, > >Embarrassingly I was the AD for this document, but I still have a >question. > >Section 3.5 comments about MplsLsrIdentifier. >It says that RFC 3811 "lack[s] support for IPv6 in defining >MplsExtendedTunnelId >and MplsLsrIdentifier." >It also says that "[MPLS-TC] tries to resolve this gap by marking this >textual >convention as obsolete." > >Note that the second quote refers to just one TC. > >Looking at 3811, 5036, and (most importantly) 7552, it seems to me that >the LSR >Identifier is *always* a 32 bit quantity regardless of whether the LDP >system is >v4-only, v4/v6, or v6-only. > >Furthermore, draft-manral-mpls-rfc3811bis (i.e., [MPLS-TC]) clearly shows >no >change to MplsLsrIdentifier while marking MplsExtendedTunnelId as >obsolete. > >Notwithstanding that draft-manral-mpls-rfc3811bis appears to have been >abandoned >in state "candidate for WG adoption", it looks to me that RFC 7439 has an >error >we could call a typo. > >I propose the following Errata Report... > >OLD >3.5. MIB Modules > > RFC 3811 [RFC3811] defines the textual conventions for MPLS. These > lack support for IPv6 in defining MplsExtendedTunnelId and > MplsLsrIdentifier. These textual conventions are used in the MPLS-TE > MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] > and the FRR extension [RFC6445]. "Definitions of Textual Conventions > (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] > tries to resolve this gap by marking this textual convention as > obsolete. >NEW >3.5. MIB Modules > > RFC 3811 [RFC3811] defines the textual conventions for MPLS. These > lack support for IPv6 in defining MplsExtendedTunnelId. This textual > conventions is used in the MPLS-TE MIB specification [RFC3812], the > GMPLS-TE MIB specification [RFC4802], and the FRR extension > [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol > Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this > gap by marking this textual convention as obsolete. >END > >Am I wrong? > >Thanks, >Adrian >-- >Celebrate the New Year by buying someone you love a book. >Tales from the Wood - Eighteen new fairy tales >http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx >http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 >Or buy from me direct. > > > > From nobody Fri Jan 15 12:09:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95E1B3207 for ; Fri, 15 Jan 2016 12:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CAHwsQhP7tX for ; Fri, 15 Jan 2016 12:09:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE71B320A for ; Fri, 15 Jan 2016 12:09:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C298C180206; Fri, 15 Jan 2016 12:08:45 -0800 (PST) To: wesley.george@twcable.com, cpignata@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160115200845.C298C180206@rfc-editor.org> Date: Fri, 15 Jan 2016 12:08:45 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, mpls@ietf.org Subject: [mpls] [Editorial Errata Reported] RFC7439 (4595) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 20:09:45 -0000 The following errata report has been submitted for RFC7439, "Gap Analysis for Operating IPv6-Only MPLS Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7439&eid=4595 -------------------------------------- Type: Editorial Reported by: Adrian Farrel Section: 3.5 Original Text ------------- RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete. Corrected Text -------------- RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId. This textual conventions is used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802], and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete. Notes ----- Section 3.5 comments about MplsLsrIdentifier. It says that RFC 3811 "lack[s] support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier." It also says that "[MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete." Note that the second quote refers to just one TC. Looking at 3811, 5036, and (most importantly) 7552, it seems to me that the LSR Identifier is *always* a 32 bit quantity regardless of whether the LDP system is v4-only, v4/v6, or v6-only. Furthermore, draft-manral-mpls-rfc3811bis (i.e., [MPLS-TC]) clearly shows no change to MplsLsrIdentifier while marking MplsExtendedTunnelId as obsolete. Notwithstanding that draft-manral-mpls-rfc3811bis appears to have been abandoned in state "candidate for WG adoption", it looks to me that RFC 7439 has an error we could call a typo. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7439 (draft-ietf-mpls-ipv6-only-gap-04) -------------------------------------- Title : Gap Analysis for Operating IPv6-Only MPLS Networks Publication Date : January 2015 Author(s) : W. George, Ed., C. Pignataro, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Jan 15 19:35:47 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008831B36AB; Fri, 15 Jan 2016 19:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeI6hBjLtJAe; Fri, 15 Jan 2016 19:35:44 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB7E1B36AA; Fri, 15 Jan 2016 19:35:44 -0800 (PST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0G3M93s011717; Fri, 15 Jan 2016 22:35:41 -0500 Received: from mdwexght02.ciena.com (lin1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 20ayaj6qwd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jan 2016 22:35:41 -0500 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 15 Jan 2016 22:35:41 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Fri, 15 Jan 2016 22:35:40 -0500 From: "Shah, Himanshu" To: Rolf Winter , Loa Andersson , "mpls@ietf.org" Date: Fri, 15 Jan 2016 22:35:37 -0500 Thread-Topic: IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHRTG5S4dzZTMJIU0y/y7HEtMB2NJ72hQXggAb/+MA= Message-ID: <40746B2300A8FC4AB04EE722A593182BA213C73D@ONWVEXCHMB04.ciena.com> References: <5693A478.7010701@pi.nu> <791AD3077F94194BB2BDD13565B6295DA9CE5C57@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295DA9CE5C57@PALLENE.office.hd> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22068.004 X-TM-AS-Result: No--14.915500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-16_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601160059 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] IPR poll on draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 03:35:46 -0000 Tm90IGF3YXJlIG9mIGFueSBJUFIgYXMgd2VsbC4uDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2xmIFdpbnRlciBbbWFpbHRvOlJvbGYu V2ludGVyQG5lY2xhYi5ldV0gDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTEsIDIwMTYgMTE6NDIg QU0NClRvOiBMb2EgQW5kZXJzc29uOyBtcGxzQGlldGYub3JnDQpDYzogZHJhZnQtY3VpLW1wbHMt dHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJlbWVudHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGll dGYub3JnOyBCUlVOR0FSRCwgREVCT1JBSCBBDQpTdWJqZWN0OiBSRTogSVBSIHBvbGwgb24gZHJh ZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJlbWVudHMNCg0KSSBhbSBub3Qg YXdhcmUgb2YgYW55IElQUi4NCg0KTkVDIEV1cm9wZSBMdGQgfCBSZWdpc3RlcmVkIE9mZmljZTog QXRoZW5lLCBPZHlzc2V5IEJ1c2luZXNzIFBhcmssIFdlc3QgRW5kICBSb2FkLCBMb25kb24sIEhB NCA2UUUsIEdCIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51 XQ0KPiBTZW50OiBNb250YWcsIDExLiBKYW51YXIgMjAxNiAxMzo0OA0KPiBUbzogbXBsc0BpZXRm Lm9yZw0KPiBDYzogZHJhZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJlbWVu dHNAaWV0Zi5vcmc7IG1wbHMtIA0KPiBjaGFpcnNAaWV0Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFI IEENCj4gU3ViamVjdDogSVBSIHBvbGwgb24gZHJhZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNl LWFuZC1yZXF1aXJlbWVudHMNCj4gDQo+IFdvcmtpbmcgR3JvdXAsDQo+IA0KPiBkcmFmdC1jdWkt bXBscy10cC1tZnAtdXNlLWNhc2UtYW5kLXJlcXVpcmVtZW50cyBhcmUgYmVpbmcgcHJlcGFyZWQg Zm9yIA0KPiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwuIFRoZXJlIGFyZSBzdGlsbCBzb21l IG1pbm9yIGxvc2UgZW5kcyB0aGF0IA0KPiBuZWVkcyB0byBiZSB0aWVkIHVwLg0KPiANCj4gV2Ug d2lsbCBzdGFydCBhbiBJUFIgcG9sbCBiZWZvcmUgdGhlIHdnIGFkb3B0aW9uIHBvbGwgaXMgc3Rh cnRlZC4NCj4gDQo+IEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS0gDQo+IGNhc2UtYW5kLXJlcXVpcmVtZW50cz8NCj4gDQo+ IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzIA0KPiAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3Ig bW9yZSBkZXRhaWxzKS4NCj4gDQo+IFRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgZmlsZWQg ZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPiANCj4gSWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgDQo+IHRv IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSANCj4gcmVsZXZhbnQgSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8g dGhlIE1QTFMgd2cgbWFpbGluZyANCj4gbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZh bmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgDQo+IHJlc3BvbnNlIGhhcyBiZWVuIHJlY2Vp dmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KPiANCj4gSWYgeW91IGFyZSBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig DQo+IG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp ZiB5b3UgYXJlIGF3YXJlIA0KPiBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNj bG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPiANCj4gDQo+IC9Mb2ENCj4g bXBscyB3ZyBjby1jaGFpcg0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAg ICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExT IEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNo bm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From mustapha.aissaoui@nokia.com Fri Jan 15 20:30:24 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740651B3747; Fri, 15 Jan 2016 20:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOFxwJ8cQTgr; Fri, 15 Jan 2016 20:30:14 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B8B1B3743; Fri, 15 Jan 2016 20:30:13 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 511A020D9C60D; Sat, 16 Jan 2016 04:30:12 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u0G4UCf1021462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jan 2016 04:30:12 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u0G4UB4U025247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Jan 2016 04:30:11 GMT Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 15 Jan 2016 23:30:11 -0500 From: "AISSAOUI, Mustapha (Mustapha)" To: Chandrasekar Ramachandran , Sriganesh Kini , Loa Andersson , Lucy yong Thread-Topic: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr Thread-Index: AQHRDMPhsONZcO/ZDU6JSnAr5/i5wJ55MxXAgC7BdQCAAj56AIAB1u4AgAwwBlCAGFak8IAbhGgQ Date: Sat, 16 Jan 2016 04:30:10 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340DD47F8527@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <5628D430.4070602@pi.nu> <4A79394211F1AF4EB57D998426C9340DD479A17D@US70UWXCHMBA01.zam.alcatel-lucent.com> <56514290.60200@pi.nu> <95453A37E413464E93B5ABC0F8164C4D14C9BB4D@eusaamb101.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47C1317@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Guijuan Wang 3 , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-chandra-mpls-ri-rsvp-frr@ietf.org" , Lizhong Jin Subject: Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 04:35:38 -0000 Hi Chandra, Sorry for the late reply. See inline for some follow-up. Regards, Mustapha. > -----Original Message----- > From: Chandrasekar Ramachandran [mailto:csekar@juniper.net] > Sent: Friday, December 18, 2015 12:41 AM > To: Chandrasekar Ramachandran; Aissaoui, Mustapha (Mustapha); Sriganesh K= ini; > Loa Andersson; Lucy yong > Cc: mpls-chairs@ietf.org; mpls@ietf.org; draft-chandra-mpls-ri-rsvp-frr@i= etf.org; > Guijuan Wang 3; Lizhong Jin > Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr >=20 > Mustapha, > Did my response address your concerns? If I have understood you correctly= , the > concerns fall in two categories and I have tried to address these concern= s. > (A) The need for introducing refresh-interval independent behavior into R= SVP-TE > (B) Why some kind of local implementation based timers will not be suffic= ient to > support long refresh intervals >=20 > Do you have any specific comment on my responses? Specifically, do you st= ill > think the responses did not address (A), or (B) or both? >=20 > Regards, > Chandra. >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Chandrasekar > > Ramachandran > > Sent: Thursday, December 03, 2015 12:58 AM > > To: Aissaoui, Mustapha (Mustapha) > > ; > > Sriganesh Kini ; Loa Andersson > > ; Lucy yong > > Cc: mpls-chairs@ietf.org; mpls@ietf.org; draft-chandra-mpls-ri-rsvp- > > frr@ietf.org; Guijuan Wang 3 ; Lizhong Jin > > > > Subject: Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr > > > > Mustapha, > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > > > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Thursday, November 26, 2015 8:48 AM > > > To: Sriganesh Kini ; Loa Andersson > > > ; Lucy yong > > > Cc: Lizhong Jin ; Guijuan Wang 3 > > > ; > > > draft-chandra-mpls-ri-rsvp-frr@ietf.org; > > > mpls-chairs@ietf.org; Aissaoui, Mustapha (Mustapha) > > > ; mpls@ietf.org > > > Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr > > > > > > Dear authors, > > > I read this draft and I believe the intent is to provide a tighter > > > control plane synchronization of the PLR and MP roles on a per RSVP > > > session basis such that a LSR will know if it is a MP for a given > > > RSVP session which requested protection. This is done such that the > > > decision to retain or delete the state by the LSR detecting the > > > failure of the link to the previous hop (or the failure of the > > > previous hop itself) is made with the prior knowledge that the LSR is= a MP or > not on a per RSVP session basis. > > > > [Chandra] The primary motivation of the draft is to enable LSRs to > > support FRR when the LSP scale on the LSR is of the order of hundreds > > of thousands. The analysis of the bottlenecks as a consequence of LSP > > scale, that can cause disruption of the LSR has already been > > documented in RFC 5439. As analyzed in RFC 5439, while there is a > > correlation between the percentage increase in refresh time and the > > improvement in LSR performance, there is a degree of functionality > > that is lost owing to the soft-state nature of the protocol. TE- > > SCALE-REC > > (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00) > > outlines the motivation for refresh independent RSVP (RI-RSVP) for all > > types of LSPs (packet or non-packet), and makes recommendations to > > enable RSVP implementations eliminate the reliance on short refresh > > time. This draft addresses the refresh-interval dependent behavior of > > RFC 4090 in order to support RI-RSVP, as facility backup FRR is a > > widely deployed feature in production networ ks. MA> It seems to me the main issue with bypass protection is to deal with th= e generation (PLR) and processing (MP) of a large number of *triggered* Pat= h messages for the individual protected LSPs at the time the PLR activates = the bypass LSP.=20 I do not see anything new in this draft to address the bottleneck of the st= ate refresh mechanism itself. In fact, the draft suggests that after the by= pass LSP is activated, the state refresh continues with summary refreshes w= hich is the solution already existent as per RFC 2961. Based on that, it is= misleading to call this a Refresh-Independent RSVP FRR and this draft is n= ot changing the fact that a PLR can generate and the MP may have to process= a Srefresh message with potentially a large number of message IDs once the= bypass is activated. What this mechanism is providing is a bulk notification of bypass activatio= n from the PLR to the MP. This can speed up the creation in the control pla= ne of the new remote neighbor (PLR) at the MP and associate the existing PS= B/RSBs of the protected LSPs with this new neighbor. The savings in the cre= ation of the new remote neighbor is due to not relying on the receipt from = the PLR and the processing of a triggered refresh message for each protecte= d LSP. Note here there are no issue with the data plane and packets from al= l LSPs will be forwarded properly at the MP since the ILM for the protected= LSP is the same whether the packet is received from the primary interface = or from the bypass LSP interface.=20 Based on the above, I am having trouble reconciling the limited benefits an= d the complexity of the proposed mechanism. I am not opposed for this part of the draft to move forward as an optional = mechanism but I propose that it gets merged with draft-mtaillon-mpls-summar= y-frr-rsvpte and that the reference to "Refresh-Independent RSVP FRR" be re= moved. Also, the objective of the mechanism to more clearly explained as a = bulk notification mechanism when bypass is activated. > > > However, the procedures presented in this document are fairly > > > complex and go at odds with the original intent of making state > > > synchronization based on a soft-state mechanism. > > > > [Chandra] The tradeoffs between using short or long refresh intervals > > has been well understood. Short refresh intervals aid fast > > synchronization of states along the path of the LSP, but is > > problematic because of the control message traffic that a router has > > to handle at high LSP scale. Routers not only must synchronize new > > states as promptly as possible, but also must maintain the rate of > > periodic Srefresh messages to a level sufficient to refresh all > > existing states without being timed out. When the number of LSPs that r= outers > carry approach half a million, there will be two problems with the contro= l message > rate. > > (1) As analyzed in RFC 5439, even with RFC 2961 refresh reduction the > > size of Srefresh message may become very large, and the processing > > required may cause disruption of the LSR. > > (2) Apart from the problem of RSVP message processing overhead, there > > is also the problem of RSVP-TE becoming a bottleneck preventing the > > router to scale other protocols or services. MA> This draft does not solve the issue of large Srefresh message. After th= e bulk triggering of the bypass, Srefresh message will still be large becau= se implementations will need to make efficient use of the message by sendin= g as many Message IDs as possible. > > > In fact, what I fail to find is a compelling argument or data from > > > the field which shows the issue is not resolved via much simpler > > > methods which are used in production networks today. I describe this > > > in the detailed comments below. > > > > [Chandra] Some of the mechanisms already deployed in multi-vendor > > production networks involve configuring implementation specific timers = or > delays on LSRs. > > Multiple vendors support various timers or delays on Ingress and Transi= t LSRs. > > However, in practice the values configured for these timers or delays > > are very scale specific, and the values that work at one LSP scale > > usually do not work at higher LSP scale. In practice, the "scale" that > > impacts the behavior at specific timer or delay value is not only the > > number of LSPs carried on the router, but also the number of other > > protocol states that reside on the router. It should be noted that the > > reliance on such implementation specific timers or delays has been a > > major contributor of operational complexity in running RSVP-TE FRR. > > Any solution based on such timers or delays while being operationally > > simple at one scale ceases to be so at higher scale. It has been > > practically found (with existing implementations from multiple > > vendors) tha t it is operationally hard to find out the new better > > value as a running production network grows over time. In short, the us= e of such > timers or delays has been found to involve guess work that seldom remain = simple > in the long run. MA> The timer is for a different issue than the main objective of the draft= . Let us discuss it in the points below > > > Regards, > > > Mustapha. > > > --------------------- > > > 1. Section 3.1 - Problem Description " > > > - If the protected LSP on C times out before D receives signaling > > > for the backup LSP, then D would receive PathTear from C prior to > > > receiving signaling for the backup LSP, thus resulting in deleting > > > the LSP state. This would be possible at scale even with default > > > refresh time. > > > " > > > MA> Since each LSR in the path of a RSVP session which requested > > > MA> protection > > > has to assume it can be a MP without prior knowledge, a simpler > > > method is to reset the refresh timeout for each session as soon as > > > the link to the previous hop failed. In fact, a user configurable MP > > > timeout upon failure, independent of the refresh timeout, can be > > > provided to tune it to the desired value to give enough time to the > > > Path message to be received via the bypass LSP. > > > > [Chandra] The option of resetting the refresh timeout may not be > > viable if long refresh interval (of the order of tens of minutes) is > > applied on the LSPs. That leaves the other option of providing a "wait > > timer" (independent of refresh time) that is configurable on the MP. Ho= wever, it is > fairly clear that the "wait timer" > > that the operator should configure on MP will be problematic for two re= asons. > > The operator should carefully analyze the performance impact of an > > existing timer/delay value if and when (a) the LSP scale on the same > > router increases, and (2) the LSP scale increases on other routers > > around it (that may potentially become upstream PLRs)! MA> The use of a refresh-timeout independent timer has been shown to work i= n production networks. Most of the time, the value is conservative enough t= o cover a large scale network. =20 > > > 2. Section 3.1 - Problem Description: > > > " > > > - If upon the link failure C is to keep state until its timeout, > > > then with long refresh interval this may result in a large amount of > > > stale state on C. Alternatively, if upon the link failure C is to > > > delete the state and send PathTear to D, this would result in > > > deleting the state on D, thus deleting the LSP. D needs a reliable > > > mechanism to determine whether it is MP or not to overcome this > > > problem. > > > " > > > MA> What is exactly the issue with state timeout being retained > > > MA> until the > > > refresh timeout? You refer to this as "stale" state but in fact it > > > is desirable to keep the state until node D created the backup PSB. > > > Also, remember that head-end node will perform global revertive MBB > > > and may tear down the LSP before the state timeout. > > > > [Chandra] As described in the first response in this mail, the > > motivation driving the draft is to eliminate RSVP-TE's reliance of > > short refresh intervals. If router C were to retain the LSP state > > until time out, without any additional procedures that provide an > > explicit indication to router C on when the LSP state is no longer > > required, then router C would retain the LSP state potentially for > > hours if the refresh interval is long. So, router C will not only > > store the state of the LSP but also periodically send the Path message > > (in Srefresh) downstream - thereby unnecessarily consuming resources th= at > could potentially be utilized for other LSPs. > > It should also be noted that the transit router cannot assume that > > Ingress LSR will be able to complete global repair within a particular > > time frame. The transit LSR procedures should be able to handle cases > > when global repair does not complete for some valid reason for an exten= ded > period of time. MA> Clearly, you are not taking away the reliance on refresh messages. Any = ad-hoc mechanism which is not reliable such as a PathTear may still keep th= e state until it times out. Furthermore, relying exclusively on Message ID = ACk as proposed in draft-ietf-teas-rsvp-te-scaling-rec in a scaled network = is not good. Data from deployment networks I am familiar with has shown tha= t the retransmission of messages which are not acknowledged when the contro= l plane churn is happening is causing much more churn. Our advice for our c= ustomers was to disable the requirement to receive a Message ID Ack. > > > 3. Section 3.1 - Problem Statement: > > > " > > > - If head-end A attempts to tear down LSP after step 1 but before > > > step 2 of the above sequence, then B may receive the tear down > > > message before step 2 and delete the LSP state from its state > > > database. If B deletes its state without informing D, with long > > > refresh interval this could cause (large) buildup of stale state on > > > D. > > > " > > > MA> I am not sure I understand the issue here. If B acting as a PLR > > > MA> receives a > > > PathTear from A, all it needs to do is to check that the primary > > > path neighbor (C in this case) is in down or in cleanup state and > > > send the PathTear over the bypass before deleting its own local state= . > > > Note here a key assumption is that PLR node B must send triggered > > > Path refresh messages to the MP over the bypass. If node B has to > > > wait to the next refresh interval to send the Path refresh over the > > > bypass, then you can run into the issue described here. > > > > [Chandra] The problem described is different. Router B detects the > > failure and undertakes local actions for re-routing traffic for all > > protected LSPs traversing the failed link. In parallel, router B also > > initiates backup LSP signaling for all those protected LSPs. At scale > > (i.e. if the number of protected LSPs thus undergoing repair is of the > > order of hundreds of thousands), the initiation of backup LSP > > signaling for all those protected LSPs is not expected to happen > > within short time period. If the Ingress LSR initiates LSP tear down > > during this interim time duration, the existing procedures do not > > offer any mechanism for router B to indicate to MP that it need not > > hold on to that state any longer. The new procedure described in the > > document does not introduce any major extension but simply use PathTear > message from PLR to MP even though the PLR had not reliably refreshed bac= kup > LSP Path. > > > > Here again, one may suggest the use of some "wait timer" on MP > > independent of refresh time out - say if the MP does not receive > > backup LSP Path message within the "wait timer", the MP can delete the > > LSP state. But depending on a timer or delay suffers from the same > > drawbacks pointed out in the response to comment #1. MA> A timer at the MP node D will not work in this case because the MP does= not see any incoming interface failure. For me this is a non issue as head= -end trying to delete an LSP during a churn in the network is not a common = event.=20 > > > 4. Section 3.1 - Problem Statement: > > > " > > > - If B fails to perform local repair in step 1, then B will delete > > > the LSP state from its state database without informing D. As B > > > deletes its state without informing D, with long refresh interval > > > this could cause (large) buildup of stale state on D. > > > " > > > MA> Well this is the normal RSVP soft-state behavior and in fact > > > MA> this > > > behavior can occur for defects of link B-C which are not detected > > > and which will not trigger the activation of the bypass LSP. There > > > is nothing abnormal about this and this behavior is not specific to > > > the case when the bypass could not be activated. > > > > [Chandra] The problem is not about the activation of bypass LSP but > > that there is no indication to the MP router that it does not have to > > hold on to the LSP state any more. The problem has been explained in > > the response to comment #3 and #4. On the soft-state behavior, the > > responses to the first three paragraphs to your mail contain the > > reasoning for removing the limitations of soft-state nature of the prot= ocol. MA> Again, it is not clear what would cause B to not be able to perform loc= al repair. Seems like another non issue. By the way, this is not different = from the case when the LSP does not have the "local protection desired" fla= g and the PathTear cannot be sent downstream because of the failure of the = outgoing interface for the LSP. Nothing unusual here. RSVP protocol was des= igned this way. > > > 5. Section 4.5.2 - Procedures for backward compatibility: > > > MA> What is the need to set the refresh interval to the default > > > MA> value when a > > > LSR detects that a downstream or upstream neighbour does not support > > > the refresh independent procedures? I assume you meant to change it > > > back to the configured value which may not be the default value of 30 > seconds. > > > > [Chandra] If refresh time is not explicitly configured on the LSR > > supporting RI- RSVP-FRR, then the refresh interval should be reduced > > to RFC 2205 default value of 30 seconds for messages sent to a > > neighboring router that is not RI-RSVP capable. TE-SCALE-REC draft > > recommends default refresh interval of 20 minutes be used in Path and > > Resv messages if RI-RSVP is supported by the LSR. The statement in the > > draft referred here is not applicable if the operator has overridden th= e RI-RSVP > default value. > > > > I think the text in Section 4.5.2 could have state explicitly that if > > downstream or upstream neighbor does not advertise RI-RSVP capability, > > then the router should reduce the refresh interval to 30 seconds if > > the refresh interval has not been configured on the router. We will > > update this section accordingly to clarify the proposed behavior. > > > > Regards, > > Chandra. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jan 20 19:59:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77B91B2E26; Wed, 20 Jan 2016 19:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmKb0L5rY8iH; Wed, 20 Jan 2016 19:59:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id F389B1B2E34; Wed, 20 Jan 2016 19:59:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9BB6F18000D; Wed, 20 Jan 2016 19:58:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160121035805.9BB6F18000D@rfc-editor.org> Date: Wed, 20 Jan 2016 19:58:05 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7743 on Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 03:59:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7743 Title: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping Author: J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed. Status: Standards Track Stream: IETF Date: January 2016 Mailbox: luo.jian@zte.com.cn, lizho.jin@gmail.com, tnadeau@lucidvision.com, swallow@cisco.com Pages: 18 Characters: 39321 Updates: RFC 4379 I-D Tag: draft-ietf-mpls-lsp-ping-relay-reply-11.txt URL: https://www.rfc-editor.org/info/rfc7743 DOI: http://dx.doi.org/10.17487/RFC7743 In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jan 21 03:49:43 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7D61A912C; Thu, 21 Jan 2016 03:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UjFRW5_xz6F; Thu, 21 Jan 2016 03:49:40 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268ED1A910A; Thu, 21 Jan 2016 03:49:40 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id b14so76393109wmb.1; Thu, 21 Jan 2016 03:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Zzmr9XlJwhpLBq5Vl3iGCwutOTKpDHIRV/ARa8Zxdxo=; b=L5vkNiD/OK92gB6GpZPNcDv1a7qHWOFuERxEano6jspi/5edlbVgZg+yOE+fy1AVol d8bCRWAnSzgiijHjbcw2b7iyKhyN5nzXglEI8zOLvVzmU0R3LhC1fW8OYpXiLOcXEgPD t0/kfys1/wdSNlqbFBL7X7sIMZF2zWmWS3+anqGmkdWClBAQdVoFQQJyRxnrCKG5KSWq +OvsN0PJhbJuZaP4CBhRLBHZFagbh30AkMaJBZzG67tONhQozr13Ll3+2p7zw1DXnaGz 9Jm4ELU+f2vyFdmLmvdoGhXwkG8QYjEM6qNEbqYnc67okBjOx6Rh/OONRS8w7E7h/yd5 ZlQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Zzmr9XlJwhpLBq5Vl3iGCwutOTKpDHIRV/ARa8Zxdxo=; b=b46I+tz+asLDU6VpAZoPuqYFjp0J7xZicw0JzbDew4kGpFmCSQ/0qIr/Ds6K6WcvCp om3hh4PahxG4lULD3ejL5xP/nsDTgqrdnnGsKlfIHCRJjmFplhuspy8MbJE6QgjjzewT aQLf6l+7QF0ySkPm+S3i0Roq+0gf0OUDRmQSFZs9NN9MZgmfLOQMOqgofiEseN1V9O+c YSARrlXqfRBMO3+D1yGpFMwlNb5Xd8F7Z0tAjP+1mbhffhObp7ibGRb/8XCh6DZ38dRk 7VesoY+sJH8gj7W3uNprY3xGWRNlDNoHSK99LBrToDXCSZPNgLQX56lqcw4Ic5hvSAHo RulQ== X-Gm-Message-State: ALoCoQnYyfgorNS+5dTGTtQ1IHYziLTOl8RO5tzgBU0WO58D+oUOWMsVfgvR8Uow/jAFzJTNuMpUv9arBHDcgyNPWzuT9cTmQQ== X-Received: by 10.194.78.175 with SMTP id c15mr42392160wjx.16.1453376978794; Thu, 21 Jan 2016 03:49:38 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c185sm29522287wma.5.2016.01.21.03.49.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 03:49:37 -0800 (PST) To: Martin Stiemerling References: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> <56961B6C.3040705@gmail.com> From: Stewart Bryant Message-ID: <56A0C5D4.3080802@gmail.com> Date: Thu, 21 Jan 2016 11:49:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56961B6C.3040705@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, The IESG , mpls-chairs@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 11:49:42 -0000 On 13/01/2016 09:39, Martin Stiemerling wrote: > Hi Steward, > > Am 06.01.16 um 18:10 schrieb Gmail: >> Martin >> >> It is a fundamental tenet of MPLS is that the network is well >> managed with the operators paying significant attention to traffic >> planning, I therefore think that it is reasonable to assume that they >> would also pay adequate attention to their UDP management traffic. >> >> Loss is so light in these networks that the interval between loss >> measurements needs to be long to see any loss at all, thus I would >> normally expect us to be talking packets per minute or packets per >> hour rather than packets per second, and this would be on links with >> GB+ capacity. Similarly it makes little sense to make delay >> measurements very frequently. >> >> In both cases the amount of traffic will be minuscule compared to the >> IPFIX over UDP traffic that that many operators will already will >> running. >> >> I thus fear that you raise the congestion daemon without proper >> regard to the practicalities of this type of application. > > I fully understand that this type of protocol is used usually in a > fully managed network. But congestion can also happen there, and > congestion is by the way not a daemon, but a natural consequence of a > best effort network even if it is managed Martin If a basic monitoring protocol such as this, drives a network over the edge through congestion, then there is so much else wrong with that the network that it would be unable perform it primary mission. My concern is that by always highlighting congestion concerns, even when the risk is minor, you dilute the importance of the message when there is a real need for caution. > > And even in fully managed networks traffic can accumulate at one point > causing congestion. Again, if this type of protocol pushes it over the edge, I would be concerned that there were much more significant issues with that network. > > I do not see the need to work through all details of RFC 5405, but I > want to see text that reflects about using an not congestion > controlled protocol and possible consequences and guidances for > operators using this. > One way to handle this, to make operators aware of the need to monitor > the rate of UDP traffic and that any excess of this rate is worth > noting to the network operator. > > By the way, your argument above about the managed environment would > also make Section 5 superfluous, isn't it? I will willingly delete section 5 if that is the consensus of the IESG. The following text inserted as a new section between section 4 and 5 will hopefully address your congestion concerns. 5. Congestion Considerations This protocol MUST be run in accordance the guidance provided in [RFC5405]. As advised in section 3.2.1 of RFC5405, operators that wish to run this protocol at rates in excess of one packet per three seconds need to ensure that the MPLS path being monitored and any IP path that may be used to carry the response are provisioned such that there is a negligible chance of this protocol causing congestion. Additionally, if a significant number of response packets are lost, the querier MUST reduce the sending rate to a point where there is a negligible chance that this protocol is contributing to network congestion. The operator should also take precautions that response packets do not leak out of the network domain being used and cause congestion elsewhere. If a default IP address is configured by the equipment vendor, this MUST be an address known to contain the response packet within the responder, such as the IPv4 localhost address [RFC5735] or the IPv6 loopback address [RFC4291]. A responder receiving a query specifying this as a return address, and not being configured to expect such a return address*, SHOULD notify the operator in a suitably rate limited manner. Add refs to RFC5405 (normative), RFC 5735 (informational) and RFC 4291 (informational) *Not part of RFC text - this might occur if the operator wanted a data collector co-located on the responder, so it's better to specifically allow it than have confusion as to whether it is allowed or not. - StewarT >> >> Sent from my iPad >> >>> On 5 Jan 2016, at 21:47, Martin Stiemerling >>> wrote: >>> >>> Martin Stiemerling has entered the following ballot position for >>> draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss >>> >>> 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.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>> information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found >>> here: >>> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ >>> >>> >>> >>> >>> >>> > ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> > I am in favour of publishing this document, but I have two major points >>> that are not addressed in the document by now: >>> >>> 1) It is not clear for anybody what the expected size and sending >>> frequency of such MPLS-PLDM over IP/UDP responses are. This will >>> influence any measures an operator has to take in order to assure >>> that there is no congestion caused by these messages. I can >>> understand that this cannot be foreseen, but a few words >>> considering this fact are excellent to have in the document. >>> >>> 2) This leads to my second point: the lack of any reference to RFC >>> 5405 "Unicast UDP Usage Guidelines for Application Designers" and >>> the content out of this RFC that is applicable for this draft. >>> There is no discussion about this at all. Please note well that >>> this is BCP 145. >>> >>> With regard to point 2): I can try to find some help from the >>> transport area, in case you need help. >>> >>> >>> >>> >>> _______________________________________________ mpls mailing list >>> mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jan 22 16:28:26 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61A1B2DCC; Fri, 22 Jan 2016 16:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIgNzjn6zzfb; Fri, 22 Jan 2016 16:28:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 768CA1B2DFF; Fri, 22 Jan 2016 16:27:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6300818046A; Fri, 22 Jan 2016 16:26:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160123002637.6300818046A@rfc-editor.org> Date: Fri, 22 Jan 2016 16:26:37 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7737 on Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 00:28:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7737 Title: Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification Author: N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen Status: Standards Track Stream: IETF Date: January 2016 Mailbox: nobo.akiya.dev@gmail.com, swallow@cisco.com, cpignata@cisco.com, loa@mail01.huawei.com, mach.chen@huawei.com Pages: 17 Characters: 35253 Updates: RFC 7110 I-D Tag: draft-ietf-mpls-lsp-ping-reply-mode-simple-05.txt URL: https://www.rfc-editor.org/info/rfc7737 DOI: http://dx.doi.org/10.17487/RFC7737 The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jan 25 23:47:30 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084E1A6F9A; Mon, 25 Jan 2016 23:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP7B1S0su4NI; Mon, 25 Jan 2016 23:47:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EA61A6F98; Mon, 25 Jan 2016 23:47:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDL56945; Tue, 26 Jan 2016 07:47:17 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 07:47:15 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 15:47:12 +0800 From: "Dongjie (Jimmy)" To: Eric C Rosen , "idr@ietf.org" , BESS , "mpls@ietf.org" Thread-Topic: [bess] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3nNGAWkbeTK0mnYPsI1D9BXJ8NbouA Date: Tue, 26 Jan 2016 07:47:11 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A72486.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 48b7346b462526dc7cd533c204f3535e Archived-At: Subject: Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 07:47:24 -0000 Hi Eric,=20 Thanks for writing this draft, it provides useful clarifications and update= s for RFC 3107.=20 After reading the draft, I have some comments: 1. For NLRI encoding with single label, this draft says that "the S bit MUS= T be set to one on transmission". IMO RFC 3107 does not mandate this, and a= s you said some existing implementations may not set the S bit. To ensure b= ackward compatibility, maybe the requirement on setting the S bit can be re= laxed. 2. For NLRI encoding with multiple labels, I guess the beginning of the pre= fix field is identified based on the S bit of the last label. If a malforme= d NLRI is received, in which the S bit of the last label is not set, then t= he prefix cannot be recognized, and the treat-as-withdraw error handling is= not applicable. This may be worth mentioned in the draft.=20 3. Section 2.5 describes implicit withdrawn and load balancing in detail. O= ne possible issue here is it seems that the same next hop is required for t= he routes in Update U1 and U2. While section 9 of RFC 4271 specifies: "...if the NLRI of the new route is identical to the one the route curre= ntly has stored in the Adj-RIB-In, then the new route SHALL replace the old= er route in the Adj-RIB-In, thus implicitly withdrawing the older route fro= m service." Thus same next hop is not required for implicit withdrawn. This also applie= s to the load balancing case with Add_Path, in which the 2 paths used for l= oad balancing may have different next hops. Best regards, Jie > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Thursday, January 14, 2016 2:11 AM > To: idr@ietf.org; BESS ; mpls@ietf.org > Subject: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Folks, >=20 > Pardon the cross-post, but I think this may be of interest to all three o= f > the IDR, MPLS, and BESS WGs. >=20 > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels > to Address Prefixes"), which is intended of course to obsolete RFC 3107 > ("Carrying Label Information in BGP"). (While I put "idr" in the name of > the draft, it's not completely obvious which WG should own this draft > (assuming it progresses)). >=20 > The purpose of this draft is the following: >=20 > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. >=20 > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as specified, > and the text about it just causes confusion. The functionality that this > feature was intended to provide can now be better provided by using > add-paths; this is discussed in the draft. >=20 > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4= . >=20 > - It clarifies the procedures for withdrawing and replacing label binding= s. >=20 > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft discuss= es > these differences. However, as the draft is not intended to favor any on= e > implementation over another, it can't do much more than point out some > of the differences among implementations. >=20 > - RFC 3107 provides an encoding that allows BGP to assign multiple labels > (i.e., a label stack) to a given prefix. However, it provides no semanti= cs > for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if a= new > Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be > used. >=20 > I hope that those of you who are interested in this topic will provide yo= ur > comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. >=20 > I also removed most of the text that explains why it is a good idea to us= e > BGP to distribute label bindings. That text was important in the '90s, b= ut > now seems rather out of date. However, I would welcome comments on > whether an updated "motivation/positioning" section should be added. >=20 > Thanks, >=20 > Eric >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From swallow.ietf@gmail.com Tue Jan 26 14:03:40 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF721B320A for ; Tue, 26 Jan 2016 14:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cttiXSPfemzd for ; Tue, 26 Jan 2016 14:03:39 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9263C1B3209 for ; Tue, 26 Jan 2016 14:03:39 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id 123so19815841wmz.2 for ; Tue, 26 Jan 2016 14:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oWz40VVNS7mLdan0tZ1IjSzjQdUP0VYpgaj7QYglUJQ=; b=AXyaFRCyDljRcJMu2Yb9+nM40xR5Me5Y77wbiOpvMxO9DizxwH2vHJCy8fPbYTMfJm Kf24kgSYC7rD9otAglNMiI70PRniabfidFz8OnkUweV5venEGsPDpglHWAZHAVjnNu/R H+NjMqVyADJ55HvvLKN/VS3fTVd9s65pmSTyP3TAI59OSzkG3JZfvh0+C+uqmY+ge5JU ns5wrym6aIA9jmcr27GS2vZbnzMEix35rOH+cgKzLKMKZRpbf1411ar7CBvBKUOVmIlw WTKBOm+RbVmGgeut4BEImgIWp+OOJIGw3QDNIHt4x0qqtaAdXJpOQEjkXlZQDzpB6Qd9 hvcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oWz40VVNS7mLdan0tZ1IjSzjQdUP0VYpgaj7QYglUJQ=; b=X4JFfKvAybyPPAji7wE63FvutzDrfcdyBBvvXoe9D750ucMDB6NZx2J/2ndyn54J9R XcWEC93hDdBK100TVxwarOLgQBXpDDi+8e6ZVUYTfB+yQXQQCOSQddVVapPr9MECiWpR EmDfDnrHSE0qncu+spe2T9jYLwaZxrfFxh1Vp8oA9fCYhjS+0Fhm6MXeNwJrF0s08GeH WoEpu49GXnv7oxNspxgbvAtY/xcQzlqF49yjTeXh6TlhWuRr3eJb7yeZsB1eArbaCyut KuctdLt9EaSi5HVtct/YroITZ8+oU/wnvC0+syFM7SiZuPSGrQY63CK1P+fGMDosO+Qb uZZQ== X-Gm-Message-State: AG10YOTmJ3T7oFupzs96apO77GeCDyURdkLhY68IwECl98FDj0nJVmUGPeLeoTh4ocaXGZNp6bxXAsJexvDFRw== MIME-Version: 1.0 X-Received: by 10.194.242.2 with SMTP id wm2mr20103254wjc.155.1453845817977; Tue, 26 Jan 2016 14:03:37 -0800 (PST) Received: by 10.194.30.65 with HTTP; Tue, 26 Jan 2016 14:03:37 -0800 (PST) Date: Tue, 26 Jan 2016 17:03:37 -0500 Message-ID: From: George Swallow To: mpls@ietf.org Content-Type: multipart/alternative; boundary=089e013d145289f26d052a43db43 Archived-At: X-Mailman-Approved-At: Tue, 26 Jan 2016 14:26:09 -0800 Subject: [mpls] Subscribe X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:08:17 -0000 --089e013d145289f26d052a43db43 Content-Type: text/plain; charset=UTF-8 subscribe --089e013d145289f26d052a43db43 Content-Type: text/html; charset=UTF-8
subscribe
--089e013d145289f26d052a43db43-- From nobody Wed Jan 27 02:04:14 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E991B37E8; Wed, 27 Jan 2016 02:04:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127100412.527.57410.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 02:04:12 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-spring-entropy-label-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:04:13 -0000 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 : Entropy labels for source routed tunnels with label stacks Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Xiaohu Xu Wim Hendrickx Jeff Tantsura Filename : draft-ietf-mpls-spring-entropy-label-02.txt Pages : 11 Date : 2016-01-27 Abstract: Source routed tunnels with label stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed tunnels with label stacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-spring-entropy-label-02 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 16:54:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425C21B301F for ; Thu, 28 Jan 2016 16:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grYGV8nJ3NI5 for ; Thu, 28 Jan 2016 16:54:45 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279921B301C for ; Thu, 28 Jan 2016 16:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2748; q=dns/txt; s=iport; t=1454028885; x=1455238485; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=u4zOePBhJWIMRYIY8gDi5smkrniv6in8uhbgI8tA7rs=; b=kxOVO3qdIeuIYugshpgTQou1YCkTS3lKiuUQ7GHxKUTETdP9QOrroJKz ryrhyviOJM+NWXHkzVlCU9AUeiQ0rcqSF7n6xtVyP7SeWuIH2gmZgvqSX 3B44I1DeS/37Qcnfk44l6jWdTSzRVXFxa6YUKKu+8uuDV/I/dbgj7F0p/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQB9iqpW/xbLJq1ehAxtBohRsUQBD?= =?us-ascii?q?YFiGAqFbQIcgWQUAQEBAQEBAYEKhEEBAQEEAQEBIBE6CwwGAQgRBAEBAQICIwM?= =?us-ascii?q?CBCULFAEICgQOBYgbDrEHjxgBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuJSYQwG?= =?us-ascii?q?IJqgToFlm4BjUqBW4dnhS+OPAEeAQFCggIZgU9qiAF8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,360,1449532800"; d="scan'208";a="648876079" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2016 00:54:42 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0T0sfRb024715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 00:54:42 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 19:54:40 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 19:54:40 -0500 From: "Acee Lindem (acee)" To: Loa Andersson Thread-Topic: [mpls] Progressing Resdience Time Measurement draft Thread-Index: AQHRWi+i4aCoaj+USzqP2deJ9ymVRA== Date: Fri, 29 Jan 2016 00:54:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.205] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 00:54:47 -0000 SeKAmXZlIHJlYWQgdGhlIHN1YmplY3QgZHJhZnQgYW5kIHRoaW5rIGl0IG9mZmVycyBhIHVzZWZ1 bCBmdW5jdGlvbiB0bw0KZmFjaWxpdGF0ZSBtb3JlIGFjY3VyYXRlIHRpbWUgc3luY2hyb25pemF0 aW9uIGluIE5UUC9QVFAgZGVwbG95bWVudHMuIE9uZQ0KcXVlc3Rpb24gSSBoYXZlIGlzIHdoeSB0 aGUgY2FwYWJpbGl0eSBpcyBzaWduYWxlZCBpbiB0aGUgZ2VuZXJpYyBJR1AgVExWDQpMU0FzIGFu ZCBMU1BzIHJhdGhlciB0aGFuIHRoZSBURSBhZHZlcnRpc2VtZW50cyB3aGVuIHRoZSBkb2N1bWVu dCBpcw0Kc2NvcGVkIHRvIFJTVlAtVEUgW1JGQzMyMDldIExTUHM/IE9uZSByZWFzb24gSSBhc2sg aXMgdGhhdCB3ZSBhcmUgd2FpdGluZw0Kb24gaW1wbGVtZW50YXRpb25zIG9mIHRoZSBPU1BGdjMg RXh0ZW5kZWQgTFNBcyBkcmFmdC4gSGF2aW5nIHNhaWQgdGhhdCwNCk9TUEZ2MiBhbmQgT1NQRnYz IGhhdmUgc2VwYXJhdGUgcmVnaXN0cnkgZm9yIHRoZSBUTFYgTFNBcyBhbmQgc2VjdGlvbiA4DQpz aG91bGQgcmVmbGVjdCB0aGlzLiBBbHNvLCBPU1BGIFByZWZpeC9MaW5rIEF0dHJpYnV0ZXMgaXMg bm93IFJGQyA3Njg0Lg0KDQpUaGFua3MsDQpBY2VlDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPlNlbnQ6IE1vbmRh eSwgRGVjZW1iZXIgMTQsIDIwMTUgNzoyMyBQTQ0KPlRvOiBHcmVnb3J5IE1pcnNreTsgbXBscy1j aGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj5DYzogZHJhZnQtaWV0Zi1tcGxzLXJlc2lk ZW5jZS10aW1lQHRvb2xzLmlldGYub3JnDQo+U3ViamVjdDogUmU6IFttcGxzXSBQcm9ncmVzc2lu ZyBSZXNkaWVuY2UgVGltZSBNZWFzdXJlbWVudCBkcmFmdA0KPldvcmtpbmcgR3JvdXAgYW5kIGF1 dGhvcnMsDQo+PGNoYWlyIGhhdCBvZmY+DQo+QXMgYSBtYXR0ZXIgb2YgZmFjdCBJIGJlbGlldmUg dGhpcyBkb2N1bWVudCBzaG91bGQgYmUgcHJvZ3Jlc3NlZC4NCj48Y2hhaXIgaGF0IG9uPg0KPlRo aXMgZHJhZnQgaGFzIGJlZW4gYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHNpbmNlIGVhcmx5IEF1 Z3VzdCwgYnV0DQo+dGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lvbiBvbiB0aGUgZG9jdW1lbnQg b24gdGhlIHdnIG1haWxpbmcgbGlzdC4NCj5UaGVyZSBhcmUgb2YgY291cnNlIHR3byB3YXlzIGlm IGludGVycHJldGluZyB0aGlzLg0KPi0gdGhlcmUgaXMgdG90YWwgYWdyZWVtZW50IG9uIHRoZSBk cmFmdA0KPi0gdGhlcmUgaXMgbm8gaW50cmVzdCBpbiB0aGUgZHJhZnQNCj5JIGhhdmUgbm8gYmFz aXMgdG8gZGVjaWRlIHdoaWNoIGlzIHRoZSBjYXNlLg0KPkNhbiB3ZSBwbGVzZSBoYXZlIGF0IGxl YXN0IGEgZmV3IChub24tYXV0aG9yKSBjb21tZW50cyBvbiB0aGUgbWFpbGluZw0KPmxpc3QgaWYg aXQgaXMgdGltZSB0byBzdGFydCB0aGUgd2dsYy4NCj4vTG9hDQo+bXBscyB3ZyBjby1jaGFpcg0K Pk9uIDIwMTUtMTItMTUgMDc6MjEsIEdyZWdvcnkgTWlyc2t5IHdyb3RlOg0KPkRlYXIgQ2hhaXJz IG9mIHRoZSBNUExTIFdHLA0KPj5hdXRob3JzIG9mIHRoZSBSZXNpZGVuY2UgVGltZSBNZWFzdXJl bWVudCBpbiBNUExTIE5ldHdvcmsgZHJhZnQNCj4+YmVsaWV2ZSB0aGF0IGFsbCBjb21tZW50cyBy ZWNlaXZlZCBkdXJpbmcgdGhlIFdHIGFkb3B0aW9uIGNhbGwgYmVlbg0KPj5hZGRyZXNzZWQuDQo+ PlRodXMsIGF1dGhvcnMgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIENoYWlycyB0byBjb25zaWRl ciBXRyBMQyBhcyB0aGUNCj4+bmV4dCBzdGVwLg0KPj4gICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+bXBscyBtYWlsaW5nIGxpc3QN Cj4+bXBsc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCg0KDQo= From nobody Thu Jan 28 18:05:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624F51B36BF; Thu, 28 Jan 2016 18:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDR49wNSUUwZ; Thu, 28 Jan 2016 18:05:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1181B36BE; Thu, 28 Jan 2016 18:05:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B361618000D; Thu, 28 Jan 2016 18:04:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160129020406.B361618000D@rfc-editor.org> Date: Thu, 28 Jan 2016 18:04:06 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7746 on Label Switched Path (LSP) Self-Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:05:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7746 Title: Label Switched Path (LSP) Self-Ping Author: R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki Status: Standards Track Stream: IETF Date: January 2016 Mailbox: rbonica@juniper.net, inaminei@google.com, meconn26@gmail.com, dante.j.pacella@verizon.com, luis.tomotaki@verizon.com Pages: 12 Characters: 25146 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-self-ping-06.txt URL: https://www.rfc-editor.org/info/rfc7746 DOI: http://dx.doi.org/10.17487/RFC7746 When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures. LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jan 29 02:01:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F741AD0CD; Fri, 29 Jan 2016 02:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kbOc63vxCmV; Fri, 29 Jan 2016 02:00:59 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF831AD068; Fri, 29 Jan 2016 02:00:59 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-2f-56ab3846f84f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id E4.B6.32102.6483BA65; Fri, 29 Jan 2016 11:00:39 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 05:00:57 -0500 From: Jeff Tantsura To: Loa Andersson , Gregory Mirsky , "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] Progressing Resdience Time Measurement draft Thread-Index: AdE2xLcE4aCoaj+USzqP2deJ9ymVRAATRseACOccSYA= Date: Fri, 29 Jan 2016 10:00:57 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221965953@eusaamb103.ericsson.se> <566F8799.1070305@pi.nu> In-Reply-To: <566F8799.1070305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <4D30D2ED333B0E44881AAB17C380A459@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyuXRPgq67xeowg4d7+Czufb7NaPFv7hxm i3WXT7FZ3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr49P2T8wFPwQq Oq6dYWxgPCDQxcjJISFgItHzdC8bhC0mceHeeiCbi0NI4AijxI7rH1ggnOWMEn2f3rKAVLEJ GEj8/3YcLCEiMJ9RomnHbnaQBLNAqsTCC0/AbGEBB4mNHasZuxg5gIocJX6cSQUJiwhYSbSs mcQKYrMIqEpMfnwXbCavgL3EyglXwGwhgQyJxzfmM4HYnEA1q1YcAruOEei676fWMEGsEpe4 9QSiRkJAQGLJnvPMELaoxMvH/8DmiwroSny8vo8dIq4kMef1NWaQc5gFNCXW79KHGGMt8XBl LyuErSgxpfshO8Q5ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjBylxQU5uelGhpsY gZF4TILNcQfj3l7PQ4wCHIxKPLwFc1eFCbEmlhVX5h5ilOBgVhLhrdNaHSbEm5JYWZValB9f VJqTWnyIUZqDRUmcdwv/ojAhgfTEktTs1NSC1CKYLBMHp1QDI3tQ957JbJ3V1XnW87r5tEUu MnjYVvvXVYd9ub/g30fRsty3VnJeaxXONL9qbBZvlHrW6nAwbeW+ddtOP1KUd3iv4rzOdNbj udF3z6QpmWm3BZ2eE3ZZu3imX+EfU4tzjidCY1ony0byOGptCuJbl9bPZfz30byfG1d9lC5s ux17jutM18VVSizFGYmGWsxFxYkAzGg3i8ACAAA= Archived-At: Cc: "draft-ietf-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 10:01:01 -0000 SGkgTG9hLA0KDQpJIHN1cHBvcnQgcHJvZ3Jlc3Npb24gb2YgdGhlIGRyYWZ0LCBpdCBpcyBuZWVk ZWQgZm9yIHRpbWUgc3luY2hyb25pemF0aW9uIHByb3RvY29scyB3aGVuIHRyYW5zcG9ydGVkIG92 ZXIgTVBMUyBuZXR3b3JrLg0KVGhhbmtzISAgDQoNCkNoZWVycywNCkplZmYNCg0KDQoNCg0KT24g MTIvMTUvMTUsIDA0OjIzLCAibXBscyBvbiBiZWhhbGYgb2YgTG9hIEFuZGVyc3NvbiIgPG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbG9hQHBpLm51PiB3cm90ZToNCg0KPg0KPldv cmtpbmcgR3JvdXAgYW5kIGF1dGhvcnMsDQo+DQo+PGNoYWlyIGhhdCBvZmY+DQo+QXMgYSBtYXR0 ZXIgb2YgZmFjdCBJIGJlbGlldmUgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgcHJvZ3Jlc3NlZC4N Cj48Y2hhaXIgaGF0IG9uPg0KPlRoaXMgZHJhZnQgaGFzIGJlZW4gYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50IHNpbmNlIGVhcmx5IEF1Z3VzdCwgYnV0DQo+dGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vz c2lvbiBvbiB0aGUgZG9jdW1lbnQgb24gdGhlIHdnIG1haWxpbmcgbGlzdC4NCj4NCj5UaGVyZSBh cmUgb2YgY291cnNlIHR3byB3YXlzIGlmIGludGVycHJldGluZyB0aGlzLg0KPi0gdGhlcmUgaXMg dG90YWwgYWdyZWVtZW50IG9uIHRoZSBkcmFmdA0KPi0gdGhlcmUgaXMgbm8gaW50cmVzdCBpbiB0 aGUgZHJhZnQNCj4NCj5JIGhhdmUgbm8gYmFzaXMgdG8gZGVjaWRlIHdoaWNoIGlzIHRoZSBjYXNl Lg0KPg0KPkNhbiB3ZSBwbGVzZSBoYXZlIGF0IGxlYXN0IGEgZmV3IChub24tYXV0aG9yKSBjb21t ZW50cyBvbiB0aGUgbWFpbGluZw0KPmxpc3QgaWYgaXQgaXMgdGltZSB0byBzdGFydCB0aGUgd2ds Yy4NCj4NCj4vTG9hDQo+bXBscyB3ZyBjby1jaGFpcg0KPg0KPk9uIDIwMTUtMTItMTUgMDc6MjEs IEdyZWdvcnkgTWlyc2t5IHdyb3RlOg0KPj4gRGVhciBDaGFpcnMgb2YgdGhlIE1QTFMgV0csDQo+ Pg0KPj4gYXV0aG9ycyBvZiB0aGUgUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQgaW4gTVBMUyBO ZXR3b3JrIGRyYWZ0IGJlbGlldmUNCj4+IHRoYXQgYWxsIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmlu ZyB0aGUgV0cgYWRvcHRpb24gY2FsbCBiZWVuIGFkZHJlc3NlZC4NCj4+IFRodXMsIGF1dGhvcnMg d291bGQgbGlrZSB0byBhc2sgdGhlIFdHIENoYWlycyB0byBjb25zaWRlciBXRyBMQyBhcyB0aGUN Cj4+IG5leHQgc3RlcC4NCj4+DQo+PiAgICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+Pg0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KPj4NCj4+DQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1wbHMgbWFp bGluZyBsaXN0DQo+PiBtcGxzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5tcGxzIG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Fri Jan 29 03:23:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0761B2DC7; Fri, 29 Jan 2016 03:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w55X3Q-bkZHS; Fri, 29 Jan 2016 03:23:54 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA87E1B2E67; Fri, 29 Jan 2016 03:23:53 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-7a-56ab4bc7039d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.36.05041.7CB4BA65; Fri, 29 Jan 2016 12:23:51 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.140]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 12:23:09 +0100 From: Daniele Ceccarelli To: "loa@pi.nu" Thread-Topic: [mpls] Progressing Resdience Time Measurement draft Thread-Index: AdE2xLcE4aCoaj+USzqP2deJ9ymVRAATRseACI17tjAALjbOQAAhmjHg Date: Fri, 29 Jan 2016 11:23:09 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4816190B67@ESESSMB301.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221965953@eusaamb103.ericsson.se> <566F8799.1070305@pi.nu> <7347100B5761DC41A166AC17F22DF11221995A71@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdSfe49+owgy0LLC3+zZ3DbLHu8ik2 i1tLV7I6MHssWfKTyWPW9Da2AKYoLpuU1JzMstQifbsErox/N6axFyzhrbi26j9zA+MEri5G Tg4JAROJ85+fMELYYhIX7q1n62Lk4hASOMwo8fLFNEYIZwmjxIf2p0AZDg42ASuJJ4d8QEwR AWmJhefjQUqYBZoYJR4f3Ak2SFjAQWJt30IWiBpHiR9nUkHCIgJuEtteT2EGsVkEVCWWrH0G Vs4r4Ctx4fJyVohVzUwS6x6fYwNJcAokSuztv8oEYjMKyEpM2L0IrIFZQFzi1pP5TBBHC0gs 2XOeGcIWlXj5+B8rhK0k8WPDJRaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIykg1t+W+1gPPjc8RCjAAej Eg9vwdxVYUKsiWXFlbmHGCU4mJVEeOu0VocJ8aYkVlalFuXHF5XmpBYfYpTmYFES5z3IvyhM SCA9sSQ1OzW1ILUIJsvEwSnVwFjpERn936XU8/xSKRml3GQ3obtxEQoTLa6LHSy61DapUsfg zbqpVz/f/pp/4pHrza1zK5evN75ZWnLZxHK1oJN15Lu11UusZTKEhF+3flx4SPnGyt2JzPoV lU/8+yRcf373YZNe57X747u6254zI33nbGqJz05zPHNq/sHHj2+InfRX4xZWylZiKc5INNRi LipOBADMNRfpoAIAAA== Archived-At: Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 11:23:55 -0000 Hi Loa, Totally agree with you, I agree on the fact that this draft should be progr= essed.=20 I believe the feature is a really important one. BR Daniele > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, December 14, 2015 7:23 PM > To: Gregory Mirsky; mpls-chairs@ietf.org; mpls@ietf.org > Cc: draft-ietf-mpls-residence-time@tools.ietf.org > Subject: Re: [mpls] Progressing Resdience Time Measurement draft >=20 >=20 > Working Group and authors, >=20 > > As a matter of fact I believe this document should be progressed. > > This draft has been a working group document since early August, but ther= e > has been no discussion on the document on the wg mailing list. >=20 > There are of course two ways if interpreting this. > - there is total agreement on the draft > - there is no intrest in the draft >=20 > I have no basis to decide which is the case. >=20 > Can we plese have at least a few (non-author) comments on the mailing lis= t if > it is time to start the wglc. >=20 > /Loa > mpls wg co-chair >=20 > On 2015-12-15 07:21, Gregory Mirsky wrote: > > Dear Chairs of the MPLS WG, > > > > authors of the Residence Time Measurement in MPLS Network draft > > believe that all comments received during the WG adoption call been > addressed. > > Thus, authors would like to ask the WG Chairs to consider WG LC as the > > next step. > > > > Regards, > > > > Greg > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From nobody Fri Jan 29 07:22:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490811A882C; Fri, 29 Jan 2016 07:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN6FEv3ie_Gi; Fri, 29 Jan 2016 07:22:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEBD1A701D; Fri, 29 Jan 2016 07:22:31 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.112] (66.129.241.14) by BLUPR0501MB2147.namprd05.prod.outlook.com (10.164.23.153) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 29 Jan 2016 15:22:28 +0000 To: "Dongjie (Jimmy)" , "idr@ietf.org" , BESS , "mpls@ietf.org" References: <5696933E.1080802@juniper.net> <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> From: Eric C Rosen Message-ID: <56AB83AF.7000200@juniper.net> Date: Fri, 29 Jan 2016 10:22:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR13CA0041.namprd13.prod.outlook.com (25.162.223.51) To BLUPR0501MB2147.namprd05.prod.outlook.com (25.164.23.153) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 2:hjc/2NyHGjgcQMSOfgMkkWbYQAD7mWMfgjKk1fFnbtZNPni3ZZd+BW3ar2JxXe60q1Vl2uPCjgbJMlgg4+xcaZwNFLeVcKRGSpk6Sx/sEwLWWhyTAW+PHwRLJnoYESsAEEyD6iE418pOqPcjB+Z4mw==; 3:B17GEu4VF5FogC8vW9wjU9NB+ACOI/MdSFdk/2cRlPNwmEhEWV+/4ELAvo3eHJ7BtvTiK01PQqnHS7RVSE7hCNTF17XZ4Vt6G6xZaORuH1aeMdnbLApV33ae8UUCVIym; 25:1iGhMZCl4gDY3uIPJnv1CDRwfoKGGMpENF/shpx31IQCPfJdGW0mIkd4XT5BfWPRbHOhwrEHgfIbOytmiyCWL1AYpNm9b9xoAU3fS4k5eietfeRcPMjDY9szKtCPH5UmYhEhr5ng8TVHhnj3jGAE6kPcu5jJtdx4HnP6dXLIQn1ujrDln3F9McxE+YHDipNpCkMhc4f2FO/WuycKA+GCivX6WFaEYQNtEWIsJoUO3SP0WsdwEmfHAw9bVMYVXEyb X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2147; X-MS-Office365-Filtering-Correlation-Id: 7b33fbe7-5348-4816-d7fa-08d328c000d0 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 20:+lcXPtkZkrPUnMKazJrgCvgDdxSJi6brrz9pC9EASK8FZIT7w3aRicgEwjWMQfg75n4449I4TQt0mHAL66ZwAr3ZSD/cm60x9Yiv7TsAql77fMqk4la+iQhoXVCSnsI8MXookONjtbieuL6LyIHuAXyJQjMG8bi+l+LuaD7QHQMWFXnVV/LTWShdK0Ri5IgBfePhtdBTSsJWGYAjohkIN7lRfZbbaVpeuWTDO6OkGFyXegTeJs/CXXyiNlpCyRXJd66LB3ndinci3V51bUgunq0eW8Iqw6PWIrPsE1H88xNU28P1iNHHpW/Gg2NFtnDvgE9/dPML5BQd141Pn8zRSAcFiWQTLyQn7ok1cxebHWhPDz/6sNJa8r4UgL0uFFimbWy7RzNtKxWov4ZvbckWeBMfxkMceG5lC5//rBhjGLOMedWQC5uc/xUstgMJA68ulUNEtUO7+VXpytYlUsOzJjOsOxZd09fKrPqa5nKu5vAjKMS6Fx11M/jnef4PvAP3; 4:bO3O+mitknuLPSktMCUcMXAgAVSz1oP2vEI1j4wxicZUE0J+bNyCaLz5Pntej8xoUZn0kN/rsoPMFhSQgMVx41ZppPB0Vl0P9IiBFgD8J58NP6SFpIBKSH7RJeMK4pSOketCimySG4cas2yJ2Q5kcSglol4+HkGUMD8LRyIxTzUsJH7imbgIU1Xcuei+4e8NoVchJqLs3k3nIMZy2HO+OwLifY4dTcg1qHi5H2h/nRXEuIqSpBnSYZCVAY9ARZ0vehBiz8kVqtPUTu/z9ogkGqxMI+fQOgsi5qKyeC4lAOd7OUgcYcxEIZSE17cyonphr5P2/RoSzrCdmSmPiGlrt8lVwrH/pIMYyz8X7Uv+vvR2axWdCGMED47VImq6dt43 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR0501MB2147; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2147; X-Forefront-PRVS: 083691450C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(52604005)(377454003)(24454002)(479174004)(65816999)(65806001)(50986999)(5008740100001)(42186005)(76176999)(54356999)(4001350100001)(77096005)(86362001)(87266999)(5004730100002)(2501003)(33656002)(23746002)(36756003)(122386002)(40100003)(66066001)(65956001)(50466002)(47776003)(6116002)(64126003)(59896002)(5001960100002)(5001770100001)(92566002)(80316001)(2906002)(83506001)(107886002)(586003)(230700001)(3846002)(2950100001)(230783001)(189998001)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2147; H:[172.29.36.112]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR0501MB2147; 23:/fptYAlktrZ8rnY133ZOLK71h4gufKK+FQK?= =?Windows-1252?Q?9LDZIgV+N2I28dFxTgGWJh75TEQeNbrOf+zUNKrJQ34vTCEiF9fLJlBN?= =?Windows-1252?Q?u3FW13Kxhdff7ukGCTH23a3fLmbwimVEyPtzwFaXad1j7r8L45gNWHlO?= =?Windows-1252?Q?zx7TyQ8tTiQk9KLkBFdN7x+5I0Rfsnwyz8l1i+yVzTCaxLkuHkVKLAlb?= =?Windows-1252?Q?s0yKjDMIXjzEbshUPZUQeAJjAw5wDDJEv6eLxaPBsRzriNyKIkpXYGqK?= =?Windows-1252?Q?FmuGVJ7ObACmmHOmPX03PzT79163jxLlF5cm/PIsvv43uXF3DxJJayTj?= =?Windows-1252?Q?Krs0PxylJEx9iNHgL5YYsaVrd0QKxMIwyCvuZDAEGK5T6m4Uhaj4XCs6?= =?Windows-1252?Q?5qh0jJTN2DqBBftTkI/6lQXgV9USupHnGrV/OSktTSxp8V+VfoWdNtC8?= =?Windows-1252?Q?MSD/UmnhPcHCLcV1amp2bCvyovGEP/32oUMDjRupaWHiyXb72Hh+7Ag1?= =?Windows-1252?Q?Uuzx04XO3+vZiTVZHtjKzDsegNegt9Rq+HomYwB5zDmI5HtoDn3GMXw2?= =?Windows-1252?Q?05qBnX99/In5hDtdHoflcAQMYg8hM3RPlDVfFKq0N1ePsMqIVSPlPwD6?= =?Windows-1252?Q?6XWif+pB0Z1dLad0J/sBO401h5fVb/W2dvkhpdxGDN8rSEXbmWW+ckeN?= =?Windows-1252?Q?0xsja/tH4QaUtrcv+OK0oAxBWBAhU5xCIbxk+riOpNeuEt90lw2cXBZT?= =?Windows-1252?Q?txsrPvjIkq+Dxff1eub14P4weAsKqRiPQIfTW3q+45+OLbwSlf2KZo6G?= =?Windows-1252?Q?hbOHlEjUAdkrjcRjeUKugED4dmsGqbK2cbEp4AuWg0VTC+/R5yt3tEyX?= =?Windows-1252?Q?GlscGQPmT1cgYWMzNF2I+ni+lBOsgDcqBbQZJ8zZkXE5Jol8rxSF7Mo4?= =?Windows-1252?Q?8kcjVyo/PNdR72+VIDYYbnRpzeSy2JJrsvwsGV1/JraLBlWTkxcb/tUn?= =?Windows-1252?Q?mNVluOzVPGvGQf4T1O/TFxTIK20B6yT0UtFXyOYtt/WAtBdFWOcivltd?= =?Windows-1252?Q?WYnuZOAbjHTH9e4n+NpsZOs6R7a49UB+VoxYidmtSCzuoDZqLyvJ7ZME?= =?Windows-1252?Q?olcc4meCZlzMVxM7l0Lul9PQebAhHjTomhyKJUv3Qz4XRNUaZPLI2N/u?= =?Windows-1252?Q?yqwWYekNeMZ0q6+oAVf/3j8xEI8+MPQ0NL/9jw6cBpNMNHnTQq2otEHR?= =?Windows-1252?Q?ETuPwk0+1AHt2EfCVmaPJITouijGE6Jxb+aBBEBc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2147; 5:hiRwp9HgXyqCUKevIe1ZoTCkUec6QOtYMkPlAw2CLhNVlA0B9S8wk0vblhUzoFqfuMLTQ1w2LLo+P5+TwW8AwjVStkHhD0WVAM7GeqqY9zoBH+O6GNmqgPLKUN/o14aigOH3+ClbEf3v/8gZmmy0CA==; 24:34yujGoL9r9OyxHZGZ+uYM/qvgkrlYkiKaArWcoQ1p55DfVZrv7jmAKGk6U8NjBcfb+cLRjhBLzaBboPSAbPqr6DIrZExxXTq2J1gMjL6TA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2016 15:22:28.9546 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2147 Archived-At: Subject: Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:22:34 -0000 Thanks for reviewing the draft! On 1/26/2016 2:47 AM, Dongjie (Jimmy) wrote: > 1. For NLRI encoding with single label, this draft says that "the S bit MUST be set to one on transmission". IMO RFC 3107 does not mandate this, and as you said some existing implementations may not set the S bit. To ensure backward compatibility, maybe the requirement on setting the S bit can be relaxed. RFC3107 does allow the NLRI to contain multiple labels, but the only way you can tell how many labels there are is by looking for the S bit. So I think the setting of the S bit really is required by RFC 3107, even though the RFC doesn't make that very clear. I believe that some implementations check for the S bit and some do not. I also believe that most implementations set the S bit, but I'm not sure if all do. Thus I think the strategy of "set the S bit on transmission but ignore it on reception" is most likely to result in multi-vendor interoperability. This does mean that an old implementation that doesn't set the S bit would be non-compliant with 3107bis. However, it would interoperate with compliant implementations, and that's what really matters. I didn't want to say "SHOULD set the S bit", because that leaves it open for new implementations to leave the S bit unset, and that might result in interoperability problems with older implementations that do check for the S bit. > > 2. For NLRI encoding with multiple labels, I guess the beginning of the prefix field is identified based on the S bit of the last label. If a malformed NLRI is received, in which the S bit of the last label is not set, then the prefix cannot be recognized, and the treat-as-withdraw error handling is not applicable. This may be worth mentioned in the draft. Excellent point. I'll add something about this, with a reference to section 3j of RFC 7606. > > 3. Section 2.5 describes implicit withdrawn and load balancing in detail. One possible issue here is it seems that the same next hop is required for the routes in Update U1 and U2. While section 9 of RFC 4271 specifies: > > "...if the NLRI of the new route is identical to the one the route currently has stored in the Adj-RIB-In, then the new route SHALL replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service." > > Thus same next hop is not required for implicit withdrawn. This also applies to the load balancing case with Add_Path, in which the 2 paths used for load balancing may have different next hops. Section 2.5 is intended to address only the case where the next hop doesn't change. When the next hop does change, the procedures from RFC 4271 apply as usual. I'll try to make this clear. From nobody Fri Jan 29 07:30:17 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858251ACED6 for ; Fri, 29 Jan 2016 07:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NszybnkD1UnT for ; Fri, 29 Jan 2016 07:30:12 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067491ACEB1 for ; Fri, 29 Jan 2016 07:30:12 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id wb13so32728204obb.1 for ; Fri, 29 Jan 2016 07:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JK/c2xr1Ao2CJaxccCHsyB6nj0lOcJeGafvdlimYQxs=; b=jW0HqLVhy992jVzwSV/mb+WJbzbl6P38CfA8kOhm9EvXx0wbF4EjdS5HE/cwXvhkPd 08VlZbYzZooZbYrU1/QgKwZN0cNPB0BE5qBtIcZHDDyw/xMnsVTwVyAerjosGFbrnJe5 jGtw6s1lybCxbnsBqWUEuBcExuPWrP0J+x92VP/K2cyEzQdmY+XdmPaMsPy9LJhIodCx 39OtJ1NgnLOkDAIJNs7t1GRQgZInLV2s9FrVuGroBvPefQb+jLsfoG2CyZbeCSUFY5OW VXmbaTVwLjlmNOkmT5enrmKlFJHaQoGo0nDFKIDvbm/jPxTVbRPpJkU30bixFPIdJdbF wyaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JK/c2xr1Ao2CJaxccCHsyB6nj0lOcJeGafvdlimYQxs=; b=YG1nZif/EQ26su/9Yf63CSE1omRXNOzrXDI7YU/eIv/wq/nTvYOQXBsZ6EAnDBR3OZ cVNS+GsWhNKAIC+c9XnckN3WVxf2E5UGbIPp0yCFcb0D28GmozN+zJ7u6W3nen96AgZz L0gKbrHYu/kMotBsCo1OVc3dL+bko5jyXiZ3whmeS+xG+SSQ/mTm7o+C2NLsE9IRjwbA eRbkT4ZGdD3esIXTm59QijhKB6yaaWO+K9R/CE1RztyWSnep5i+llsdYsGouzUWs89/v Po+V6hw5yHC2kq8+9k+zs/6mEdzSpfanV0cu03IX7URlVpOILAFnKQdL5dogSiuDDjmX /q8Q== X-Gm-Message-State: AG10YOTbU1bNaWvhRuFUx5kqhi3HzDMTeT6ZPkOhkHz05xcrSgzmrKgKCNNHF3tBrNHrXh/xdC/8Vrmt5LGY/A== X-Received: by 10.182.130.234 with SMTP id oh10mr7218438obb.58.1454081411369; Fri, 29 Jan 2016 07:30:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Fri, 29 Jan 2016 07:29:51 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 29 Jan 2016 10:29:51 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=089e013a0112ffd39f052a7ab5df Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:30:14 -0000 --089e013a0112ffd39f052a7ab5df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Loa, IMHO, this is a useful draft and shouldn=E2=80=99t be abandoned. However, I= =E2=80=99m not expert enough with timing protocols to have an informed opinion of its readiness for WG LC, I=E2=80=99ll defer that to the authors or implementors= . I would also like to see Acee=E2=80=99s comments addressed. Cheers, Andy On Thu, Jan 28, 2016 at 7:54 PM, Acee Lindem (acee) wrote: > I=E2=80=99ve read the subject draft and think it offers a useful function= to > facilitate more accurate time synchronization in NTP/PTP deployments. One > question I have is why the capability is signaled in the generic IGP TLV > LSAs and LSPs rather than the TE advertisements when the document is > scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is that we are waiting > on implementations of the OSPFv3 Extended LSAs draft. Having said that, > OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and section 8 > should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684. > > Thanks, > Acee > >-----Original Message----- > >From: Loa Andersson [mailto:loa@pi.nu] > >Sent: Monday, December 14, 2015 7:23 PM > >To: Gregory Mirsky; mpls-chairs@ietf.org; mpls@ietf.org > >Cc: draft-ietf-mpls-residence-time@tools.ietf.org > >Subject: Re: [mpls] Progressing Resdience Time Measurement draft > >Working Group and authors, > > > >As a matter of fact I believe this document should be progressed. > > > >This draft has been a working group document since early August, but > >there has been no discussion on the document on the wg mailing list. > >There are of course two ways if interpreting this. > >- there is total agreement on the draft > >- there is no intrest in the draft > >I have no basis to decide which is the case. > >Can we plese have at least a few (non-author) comments on the mailing > >list if it is time to start the wglc. > >/Loa > >mpls wg co-chair > >On 2015-12-15 07:21, Gregory Mirsky wrote: > >Dear Chairs of the MPLS WG, > >>authors of the Residence Time Measurement in MPLS Network draft > >>believe that all comments received during the WG adoption call been > >>addressed. > >>Thus, authors would like to ask the WG Chairs to consider WG LC as the > >>next step. > >> Regards, > >> Greg > >>_______________________________________________ > >>mpls mailing list > >>mpls@ietf.org > >>https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --089e013a0112ffd39f052a7ab5df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

IMHO, this is a useful draft and s= houldn=E2=80=99t be abandoned. However, I=E2=80=99m not expert enough with = timing protocols to have an informed opinion of its readiness for WG LC, I= =E2=80=99ll defer that to the authors or implementors. I would also like to= see Acee=E2=80=99s comments addressed.

Cheers,
Andy

On Thu, Jan 28, 2016 at 7:54 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
I=E2=80=99ve read the= subject draft and think it offers a useful function to
facilitate more accurate time synchronization in NTP/PTP deployments. One question I have is why the capability is signaled in the generic IGP TLV LSAs and LSPs rather than the TE advertisements when the document is
scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is that we are waiting on implementations of the OSPFv3 Extended LSAs draft. Having said that,
OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and section 8
should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684.

Thanks,
Acee
>-----Original Message-----
>From: Loa Andersson [mailto:loa@pi.nu]=
>Sent: Monday, December 14, 2015 7:23 PM
>To: Gregory Mirsky; mpls-chairs= @ietf.org; mpls@ietf.org
>Cc: dr= aft-ietf-mpls-residence-time@tools.ietf.org
>Subject: Re: [mpls] Progressing Resdience Time Measurement draft
>Working Group and authors,
><chair hat off>
>As a matter of fact I believe this document should be progressed.
><chair hat on>
>This draft has been a working group document since early August, but >there has been no discussion on the document on the wg mailing list. >There are of course two ways if interpreting this.
>- there is total agreement on the draft
>- there is no intrest in the draft
>I have no basis to decide which is the case.
>Can we plese have at least a few (non-author) comments on the mailing >list if it is time to start the wglc.
>/Loa
>mpls wg co-chair
>On 2015-12-15 07:21, Gregory Mirsky wrote:
>Dear Chairs of the MPLS WG,
>>authors of the Residence Time Measurement in MPLS Network draft
>>believe that all comments received during the WG adoption call been=
>>addressed.
>>Thus, authors would like to ask the WG Chairs to consider WG LC as = the
>>next step.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regar= ds,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>>_______________________________________________
>>mpls mailing list
>>mpls@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--089e013a0112ffd39f052a7ab5df-- From nobody Fri Jan 29 07:43:44 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E208E1B2B81; Fri, 29 Jan 2016 07:43:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129154340.31938.46662.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 07:43:40 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:43:41 -0000 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 : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-01.txt Pages : 24 Date : 2016-01-29 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-01 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 29 07:47:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C231B2C51; Fri, 29 Jan 2016 07:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SOTrTWWbQA1; Fri, 29 Jan 2016 07:47:20 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE121B2C19; Fri, 29 Jan 2016 07:47:20 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-1b-56ab869ce36a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 2B.E5.06940.C968BA65; Fri, 29 Jan 2016 16:34:53 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 10:47:18 -0500 From: Gregory Mirsky To: "mpls@ietf.org" , "tictoc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-mpls-residence-time-01.txt Thread-Index: AQHRWqvXwUiv0tpHEkCLN5TFxTHEJp8SopkQ Date: Fri, 29 Jan 2016 15:47:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112219976D9@eusaamb103.ericsson.se> References: <20160129154341.31938.98685.idtracker@ietfa.amsl.com> In-Reply-To: <20160129154341.31938.98685.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPlO7cttVhBk2T2SxuLV3JavG3uYfd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZN6+cYim4IlJx78pZlgbGCSJdjJwcEgImEn8n3GaE sMUkLtxbz9bFyMUhJHCEUeL1kj4mCGc5o0RP3yMmkCo2ASOJFxt72LsYOThEBDwk+nemgYSF BQIlVl9+wAJiiwgESSyc9ZYVwjaSeLPvEhtIOYuAqsS5Bg6QMK+Ar8SaNx/YQGwhAUeJGzcO gJVzCjhJ7Hg8E2wMI9A930+tAdvKLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWkpjz+hoz yCpmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjFylBYX5OSm GxlsYgQG/zEJNt0djPenex5iFOBgVOLhNUhdFSbEmlhWXJl7iFGCg1lJhLdOa3WYEG9KYmVV alF+fFFpTmrxIUZpDhYlcV4b3kVhQgLpiSWp2ampBalFMFkmDk6pBkatqL2Gh7mDk/5zba5g nj/l5wMWzees95/ufvxhq9Hq48VnHZbMef3ld1pJG7/d0t5r03UtK0LdrWecXjxZYPrx8z4b 7IuPs27IurWKh4Hx0ovoHRapO9rWvLM6nVmjMnFt8vrLUrWLZNWzPMVTb3zwLK/+X5nuvvzl g86WoH3lF24/EHz0LtpYiaU4I9FQi7moOBEAlECqr3oCAAA= Archived-At: Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-residence-time-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:47:22 -0000 RGVhciBBbGwsDQp0aGUgbmV3IHZlcnNpb24gb2YgUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQg ZHJhZnQgYWRkcmVzc2VzIGNvbW1lbnRzIHJlY2VpdmVkIGVhcmxpZXIgZnJvbSBZYWFrb3YgU3Rl aW4uDQoNCkF1dGhvcnMgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zLg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgSmFudWFyeSAyOSwgMjAxNiA3OjQ0IEFNDQpUbzog QWxleGFuZGVyIFZhaW5zaHRlaW47IEdyZWdvcnkgTWlyc2t5OyBTdGVmYW5vIFJ1ZmZpbmk7IEpv aG4gRHJha2U7IFNhc2hhIFZhaW5zaHRlaW47IEVyaWMgR3JheTsgU3Rld2FydCBCcnlhbnQ7IEVy aWMgR3JheQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LW1wbHMtcmVzaWRlbmNlLXRpbWUtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lDQpSZXZpc2lvbjoJ MDENClRpdGxlOgkJUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQgaW4gTVBMUyBuZXR3b3JrDQpE b2N1bWVudCBkYXRlOgkyMDE2LTAxLTI4DQpHcm91cDoJCW1wbHMNClBhZ2VzOgkJMjQNClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1tcGxzLXJlc2lkZW5jZS10aW1lLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS8NCkh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxz LXJlc2lkZW5jZS10aW1lLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMQ0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIEctQUNoIGJhc2VkIFJlc2lkZW5jZSBUaW1l IE1lYXN1cmVtZW50IGFuZA0KICAgaG93IGl0IGNhbiBiZSB1c2VkIGJ5IHRpbWUgc3luY2hyb25p emF0aW9uIHByb3RvY29scyBiZWluZw0KICAgdHJhbnNwb3J0ZWQgb3ZlciBNUExTIGRvbWFpbi4N Cg0KICAgUmVzaWRlbmNlIHRpbWUgaXMgdGhlIHZhcmlhYmxlIHBhcnQgb2YgcHJvcGFnYXRpb24g ZGVsYXkgb2YgdGltaW5nDQogICBhbmQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzIGFuZCBrbm93 aW5nIHdoYXQgdGhpcyBkZWxheSBpcyBmb3IgZWFjaA0KICAgbWVzc2FnZSBhbGxvd3MgZm9yIGEg bW9yZSBhY2N1cmF0ZSBkZXRlcm1pbmF0aW9uIG9mIHRoZSBkZWxheSB0byBiZQ0KICAgdGFrZW4g aW50byBhY2NvdW50IGluIGFwcGx5aW5nIHRoZSB2YWx1ZSBpbmNsdWRlZCBpbiBhIFBUUCBldmVu dA0KICAgbWVzc2FnZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jan 29 08:28:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED291A00B7 for ; Fri, 29 Jan 2016 08:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldzGRv0DkRVu for ; Fri, 29 Jan 2016 08:28:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892041A036F for ; Fri, 29 Jan 2016 08:28:51 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 426963BC5D492 for ; Fri, 29 Jan 2016 16:28:46 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u0TGSmI3015588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 29 Jan 2016 16:28:48 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u0TGSlHd022918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Jan 2016 17:28:48 +0100 Received: from [135.224.219.106] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 29 Jan 2016 17:28:47 +0100 Message-ID: <56AB933E.7000700@alcatel-lucent.com> Date: Fri, 29 Jan 2016 17:28:46 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <7347100B5761DC41A166AC17F22DF11221965953@eusaamb103.ericsson.se> <566F8799.1070305@pi.nu> In-Reply-To: <566F8799.1070305@pi.nu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 16:28:53 -0000 Loa, although it is a fairly recent WG Document, it has gone through several revisions as an individual document and has been subject to external reviews. I believe you can start the WG LC, which is anyway a time during which reviews and comments are welcome/expected. -m Le 15/12/2015 04:23, Loa Andersson a crit : > > Working Group and authors, > > > As a matter of fact I believe this document should be progressed. > > This draft has been a working group document since early August, but > there has been no discussion on the document on the wg mailing list. > > There are of course two ways if interpreting this. > - there is total agreement on the draft > - there is no intrest in the draft > > I have no basis to decide which is the case. > > Can we plese have at least a few (non-author) comments on the mailing > list if it is time to start the wglc. > > /Loa > mpls wg co-chair > > On 2015-12-15 07:21, Gregory Mirsky wrote: >> Dear Chairs of the MPLS WG, >> >> authors of the Residence Time Measurement in MPLS Network draft believe >> that all comments received during the WG adoption call been addressed. >> Thus, authors would like to ask the WG Chairs to consider WG LC as the >> next step. >> >> Regards, >> >> Greg >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From nobody Sat Jan 30 00:55:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBBC1B36E6; Sat, 30 Jan 2016 00:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqjyRn9JDsi0; Sat, 30 Jan 2016 00:55:55 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928A01B36DD; Sat, 30 Jan 2016 00:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sFr6z6rZ6L6h00RlanVWT+ESs2wF8zZOK6AibiXqF5U=; b=g96TlA4nT17WFBok+4pALgrf8IZmPyBBJr51LXyzs8eZr6F3e8FgY0YtZThKE/Sxcoq2wAXHGHiXZlgISh3c7bUCdo1jh8qZW/GHTPbMIvhABm2R8mhidRbdemeaX7e0n9YwBQoFu0lW3RrjxVrUWgEohpw6Po2vkc1ro7xVPGQ= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.396.15; Sat, 30 Jan 2016 08:55:35 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0396.017; Sat, 30 Jan 2016 08:55:35 +0000 From: Alexander Vainshtein To: Gregory Mirsky , "mpls@ietf.org" , "tictoc@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-ietf-mpls-residence-time-01.txt Thread-Index: AQHRWzv73op+33pf8kyd40WyQTwK5g== Date: Sat, 30 Jan 2016 08:55:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Infraware POLARIS Mobile Mailer v2.5 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [176.13.7.203] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:YMGzkJQWcqs3ORZbqDIBNy/7YBZRjwzmpm8mvRMhWZZC5g57qZ9DqzaKgIQacc2wo/yICecldEDlU0sBgISJ12bqYz0Ti9DIqlipoJm7sCBeJj4470xZZhyUBy+dpnfOs7fczauSCf5UpYBe2wU8bQ==; 24:ipehcK/ohM/BSYmsnfkBF76Wl+4WSgSsoTOnKJQSFXqxpFUEYekM4FhzGSOxAnO/J0kmO8DC0uXRhUlfon4r3KaYPNgWCdqiT2Gt+J3X+KA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-ms-office365-filtering-correlation-id: 86f9d1bc-60dd-42b6-a51f-08d329531e66 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(13464003)(377424004)(377454003)(479174004)(74316001)(86362001)(5003600100002)(19580395003)(50226001)(19580405001)(76576001)(5004730100002)(87936001)(92566002)(3846002)(4326007)(19625215002)(3470700001)(2906002)(50986999)(15975445007)(3660700001)(77096005)(122556002)(5001960100002)(5002640100001)(40100003)(3280700002)(33656002)(10400500002)(2501003)(16236675004)(1096002)(2900100001)(66066001)(102836003)(6116002)(5001770100001)(11100500001)(2201001)(586003)(230783001)(1220700001)(189998001)(106116001)(5008740100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780E07922FDC970313575CE9DDC0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2016 08:55:35.7502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-ietf-mpls-residence-time-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 08:55:58 -0000 --_000_DB3PR03MB0780E07922FDC970313575CE9DDC0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KTG90cyBvZiB0aGFua3MgZm9yIHRoZSBncmF0IGpvYiBkb25lIQ0KDQoNCg0KVGh1 bWIgdHlwZWQgb24gbXkgTEcsDQpTYXNoYQ0KDQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0NCkZyb206IEdyZWdvcnkgTWlyc2t5DQpEYXRlOiAyOS8wMS8yMDE2IDE3OjQ3DQpUbzogbXBs c0BpZXRmLm9yZzt0aWN0b2NAaWV0Zi5vcmc7DQpTdWJqZWN0OlttcGxzXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMDEudHh0 DQoNCkRlYXIgQWxsLA0KdGhlIG5ldyB2ZXJzaW9uIG9mIFJlc2lkZW5jZSBUaW1lIE1lYXN1cmVt ZW50IGRyYWZ0IGFkZHJlc3NlcyBjb21tZW50cyByZWNlaXZlZCBlYXJsaWVyIGZyb20gWWFha292 IFN0ZWluLg0KDQpBdXRob3JzIGdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucy4NCg0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgIEdyZWcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6IEZyaWRheSwgSmFudWFy eSAyOSwgMjAxNiA3OjQ0IEFNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEdyZWdvcnkgTWly c2t5OyBTdGVmYW5vIFJ1ZmZpbmk7IEpvaG4gRHJha2U7IFNhc2hhIFZhaW5zaHRlaW47IEVyaWMg R3JheTsgU3Rld2FydCBCcnlhbnQ7IEVyaWMgR3JheQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMDEudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMS50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0 Zi1tcGxzLXJlc2lkZW5jZS10aW1lDQpSZXZpc2lvbjogICAgICAgMDENClRpdGxlOiAgICAgICAg ICBSZXNpZGVuY2UgVGltZSBNZWFzdXJlbWVudCBpbiBNUExTIG5ldHdvcmsNCkRvY3VtZW50IGRh dGU6ICAyMDE2LTAxLTI4DQpHcm91cDogICAgICAgICAgbXBscw0KUGFnZXM6ICAgICAgICAgIDI0 DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMS50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRp bWUvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMDENCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBHLUFDaCBiYXNlZCBSZXNpZGVu Y2UgVGltZSBNZWFzdXJlbWVudCBhbmQNCiAgIGhvdyBpdCBjYW4gYmUgdXNlZCBieSB0aW1lIHN5 bmNocm9uaXphdGlvbiBwcm90b2NvbHMgYmVpbmcNCiAgIHRyYW5zcG9ydGVkIG92ZXIgTVBMUyBk b21haW4uDQoNCiAgIFJlc2lkZW5jZSB0aW1lIGlzIHRoZSB2YXJpYWJsZSBwYXJ0IG9mIHByb3Bh Z2F0aW9uIGRlbGF5IG9mIHRpbWluZw0KICAgYW5kIHN5bmNocm9uaXphdGlvbiBtZXNzYWdlcyBh bmQga25vd2luZyB3aGF0IHRoaXMgZGVsYXkgaXMgZm9yIGVhY2gNCiAgIG1lc3NhZ2UgYWxsb3dz IGZvciBhIG1vcmUgYWNjdXJhdGUgZGV0ZXJtaW5hdGlvbiBvZiB0aGUgZGVsYXkgdG8gYmUNCiAg IHRha2VuIGludG8gYWNjb3VudCBpbiBhcHBseWluZyB0aGUgdmFsdWUgaW5jbHVkZWQgaW4gYSBQ VFAgZXZlbnQNCiAgIG1lc3NhZ2UuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_DB3PR03MB0780E07922FDC970313575CE9DDC0DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-ID: <09C62DB28BF72544B6C8CCA84596A9B8@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7 IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAw MCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPkdyZWcsPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij5M b3RzIG9mIHRoYW5rcyBmb3IgdGhlIGdyYXQgam9iIGRvbmUhPC9wPg0KPHAgc3R5bGU9Im1hcmdp bi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij4mbmJzcDs8L3A+DQo8ZGV2M19qank+VGh1bWIgdHlw ZWQgb24gbXkgTEcsPGJyPg0KU2FzaGE8L2RldjNfamp5Pjxicj4NCjxicj4NCi0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPkdyZWdvcnkgTWlyc2t5 PGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT48YnI+DQo8Yj5EYXRlOiZuYnNwOzwvYj4yOS8w MS8yMDE2IDE3OjQ3PGJyPg0KPGI+VG86Jm5ic3A7PC9iPm1wbHNAaWV0Zi5vcmc7dGljdG9jQGll dGYub3JnOzxicj4NCjxiPlN1YmplY3Q6PC9iPlttcGxzXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMDEudHh0PGJyPg0KPGJy Pg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSB0ZXh0IC0tPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5EZWFyIEFsbCw8YnI+ DQp0aGUgbmV3IHZlcnNpb24gb2YgUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJhZnQgYWRk cmVzc2VzIGNvbW1lbnRzIHJlY2VpdmVkIGVhcmxpZXIgZnJvbSBZYWFrb3YgU3RlaW4uPGJyPg0K PGJyPg0KQXV0aG9ycyBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7UmVnYXJkcyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtHcmVnPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgWzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciPm1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XQ0KPGJyPg0K U2VudDogRnJpZGF5LCBKYW51YXJ5IDI5LCAyMDE2IDc6NDQgQU08YnI+DQpUbzogQWxleGFuZGVy IFZhaW5zaHRlaW47IEdyZWdvcnkgTWlyc2t5OyBTdGVmYW5vIFJ1ZmZpbmk7IEpvaG4gRHJha2U7 IFNhc2hhIFZhaW5zaHRlaW47IEVyaWMgR3JheTsgU3Rld2FydCBCcnlhbnQ7IEVyaWMgR3JheTxi cj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tcGxz LXJlc2lkZW5jZS10aW1lLTAxLnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMDEudHh0PGJyPg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHcmVnIE1pcnNreSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZHJhZnQtaWV0Zi1tcGxzLXJlc2lk ZW5jZS10aW1lPGJyPg0KUmV2aXNpb246ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzAxPGJyPg0KVGl0bGU6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1Jlc2lkZW5jZSBUaW1lIE1lYXN1cmVtZW50IGluIE1QTFMgbmV0d29y azxicj4NCkRvY3VtZW50IGRhdGU6ICZuYnNwOzIwMTYtMDEtMjg8YnI+DQpHcm91cDogJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bXBsczxicj4N ClBhZ2VzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsyNDxicj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0wMS50eHQiIHRh cmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lLTAxLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS8i IHRhcmdldD0iX0JMQU5LIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lLTAxIiB0YXJnZXQ9Il9CTEFOSyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZS0w MTwvYT48YnI+DQpEaWZmOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lLTAxIiB0YXJnZXQ9Il9CTEFOSyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1yZXNpZGVu Y2UtdGltZS0wMTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBHLUFDaCBiYXNlZCBSZXNpZGVuY2UgVGltZSBNZWFz dXJlbWVudCBhbmQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtob3cgaXQgY2FuIGJlIHVzZWQgYnkg dGltZSBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2xzIGJlaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7dHJhbnNwb3J0ZWQgb3ZlciBNUExTIGRvbWFpbi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDtSZXNpZGVuY2UgdGltZSBpcyB0aGUgdmFyaWFibGUgcGFydCBvZiBwcm9wYWdhdGlvbiBk ZWxheSBvZiB0aW1pbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDthbmQgc3luY2hyb25pemF0aW9u IG1lc3NhZ2VzIGFuZCBrbm93aW5nIHdoYXQgdGhpcyBkZWxheSBpcyBmb3IgZWFjaDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwO21lc3NhZ2UgYWxsb3dzIGZvciBhIG1vcmUgYWNjdXJhdGUgZGV0ZXJt aW5hdGlvbiBvZiB0aGUgZGVsYXkgdG8gYmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDt0YWtlbiBp bnRvIGFjY291bnQgaW4gYXBwbHlpbmcgdGhlIHZhbHVlIGluY2x1ZGVkIGluIGEgUFRQIGV2ZW50 PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7bWVzc2FnZS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBt YWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCjwvZGl2Pg0KPC9zcGFu PjwvZm9udD48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB3PR03MB0780E07922FDC970313575CE9DDC0DB3PR03MB0780eurp_-- From nobody Sat Jan 30 01:29:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163741B3746 for ; Sat, 30 Jan 2016 01:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQAvDkPq53Yt for ; Sat, 30 Jan 2016 01:29:12 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7421B3744 for ; Sat, 30 Jan 2016 01:29:11 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.162.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 62FE718013CB; Sat, 30 Jan 2016 10:29:08 +0100 (CET) To: mpls@ietf.org, Martin Vigoureux References: <7347100B5761DC41A166AC17F22DF11221965953@eusaamb103.ericsson.se> <566F8799.1070305@pi.nu> <56AB933E.7000700@alcatel-lucent.com> From: Loa Andersson Message-ID: <56AC8259.9060907@pi.nu> Date: Sat, 30 Jan 2016 17:28:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AB933E.7000700@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 09:29:14 -0000 Martin, We do not disagree, the situation just now is (as different from when I wrote the mail you responded to) that we have both discussion and support on the mailing list. In discussion with the authors we have converged on that they will address the comments from Acee, and then I see the resolution of these comments I will stat the wglc procedures. This does not mean that anyone that have opinions or comments need to wait for the wglc. /Loa On 2016-01-30 00:28, Martin Vigoureux wrote: > Loa, > > although it is a fairly recent WG Document, it has gone through several > revisions as an individual document and has been subject to external > reviews. > > I believe you can start the WG LC, which is anyway a time during which > reviews and comments are welcome/expected. > > -m > > Le 15/12/2015 04:23, Loa Andersson a crit : >> >> Working Group and authors, >> >> >> As a matter of fact I believe this document should be progressed. >> >> This draft has been a working group document since early August, but >> there has been no discussion on the document on the wg mailing list. >> >> There are of course two ways if interpreting this. >> - there is total agreement on the draft >> - there is no intrest in the draft >> >> I have no basis to decide which is the case. >> >> Can we plese have at least a few (non-author) comments on the mailing >> list if it is time to start the wglc. >> >> /Loa >> mpls wg co-chair >> >> On 2015-12-15 07:21, Gregory Mirsky wrote: >>> Dear Chairs of the MPLS WG, >>> >>> authors of the Residence Time Measurement in MPLS Network draft believe >>> that all comments received during the WG adoption call been addressed. >>> Thus, authors would like to ask the WG Chairs to consider WG LC as the >>> next step. >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Jan 30 04:19:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F61A1A5A for ; Sat, 30 Jan 2016 04:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcPv1pmKlPvT for ; Sat, 30 Jan 2016 04:18:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFCE1A1A58 for ; Sat, 30 Jan 2016 04:18:58 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.162.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 114D418013CB for ; Sat, 30 Jan 2016 13:18:55 +0100 (CET) References: <56AB96E6.8030503@labn.net> To: "mpls@ietf.org" From: Loa Andersson X-Forwarded-Message-Id: <56AB96E6.8030503@labn.net> Message-ID: <56ACAA24.4090300@pi.nu> Date: Sat, 30 Jan 2016 20:18:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AB96E6.8030503@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Fwd: [Teas] status of draft-ietf-teas-rsvp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 12:19:01 -0000 Working Group, draft-ietf-teas-rsvp-ingress-protection was one of the documents that was moved to the teas working from mpls, when teas wg was created. teas had an interim on Thursday (Jan 28) to discuss how to progress the draft. The mail from the teas chairs below is the teas chairs summary after that meeting. Take discussion, comments and questions, both on the draft itself and the approach Lou and Pavan outline to the teas working group list. /Loa -------- Forwarded Message -------- Subject: [Teas] status of draft-ietf-teas-rsvp-ingress-protection Date: Fri, 29 Jan 2016 11:44:22 -0500 From: Lou Berger To: TEAS WG CC: TEAS WG Chairs , BRUNGARD, DEBORAH A (ATTLABS) All, Based on yesterday's interim as well as input we have received, both on and off list, we have concluded that there is interest in ensuring that a particular problem is documented and that there may be multiple possible solutions to this problem. We also conclude that there is not support for new Standards Track mechanisms *at this time*. We'd like to propose the following: 1) The -03 rev of the draft serve as the foundation for the next rev, as the -04 version doesn't represent any WG consensus. And that this rev have 'Experimental' listed as its intended status. For those who really want a PS, we'd like to remind you that the WG can revisit this at a later time, even after publication. See rfc5467 as an example of work that went through a similar evolution and then was eventually replaced by a PS in rfc6387. 2) That the WG* agree on a brief (say 1-2 page) description of the problem to be solved. This should be discussed on list and eventually captured in a draft of the Author's choosing - which may or may not be an existing one. Adding information on any real-world experience would be very useful. * - WG includes authors+anyone else who wishes to contribute, e.g., Adrian has volunteered to help. 3) That draft-ietf-teas-rsvp-ingress-protection be updated with a brief summary of why existing RFC documented mechanisms don't address the problem. Authors should lead this update, but all WG participants should feel free to contribute. 4) That draft-ietf-teas-rsvp-ingress-protection be updated with a brief summary of what other non-standard mechanisms have been considered as possible solutions and why they were rejected. Authors should lead this update, but all WG participants should feel free to contribute. We believe these steps move us beyond the state represented by the -04 rev of this document and balances the various views that have been expressed. These steps should not be viewed as representing any departure from future normal WG processing of this draft, including anticipated refinement, review and, when ready, LC. Please feel free to discuss as you may see appropriate. If your comment relates to this document's process, please respond to this message. If your comment is technical, please start a new thread. Thank you, Pavan and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 30 17:36:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CE1B3D78 for ; Sat, 30 Jan 2016 17:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQCfQZg7K_o2 for ; Sat, 30 Jan 2016 17:36:45 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C32B1B3D77 for ; Sat, 30 Jan 2016 17:36:45 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-ff-56ad6519bac2 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.7B.32102.9156DA65; Sun, 31 Jan 2016 02:36:25 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sat, 30 Jan 2016 20:36:44 -0500 From: Gregory Mirsky To: "Acee Lindem (acee)" , Loa Andersson Thread-Topic: [mpls] Progressing Resdience Time Measurement draft Thread-Index: AQHRWi+i4aCoaj+USzqP2deJ9ymVRJ8U2EGw Date: Sun, 31 Jan 2016 01:36:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112219B81A7@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHW1cydW2Ywc514haT385jtrj3+Taj xb+5c5gtbi1dyerA4jHl90ZWjyVLfjJ5zJrexubx5fJntgCWKC6blNSczLLUIn27BK6M55/+ MxfMkK84N/MHewPjBrkuRk4OCQETibddU5ghbDGJC/fWs3UxcnEICRxhlLjYt58ZwlnOKPFp xi4WkCo2ASOJFxt72EFsEQEXiemXNrCCFDELdDBKNN06xQqSEBZwkFjbtxCogQOoyFHix5lU iHojiUM3l4H1sgioStydcAJsJq+Ar8SUfzPByoUEtCV2rBUFCXMK6EismfaLEcRmBDru+6k1 TCA2s4C4xK0n85kgjhaQWLLnPNQDohIvH/9jhbCVJD7+ns8OMpJZQFNi/S59iFZFiSndD9kh tgpKnJz5hGUCo9gsJFNnIXTMQtIxC0nHAkaWVYwcpcUFObnpRoabGIGRdEyCzXEH495ez0OM AhyMSjy8BQ5rw4RYE8uKK3MPMUpwMCuJ8C4NBwrxpiRWVqUW5ccXleakFh9ilOZgURLn3cK/ KExIID2xJDU7NbUgtQgmy8TBKdXAKG4VPcnpX4GZ2udJ5Uo53JxLT26okGVday+7OXGL1Mof vQfVHsWvMjn91qTqvngD54roD5ve1Jof9yrx62tT0Fpql8yWaq+yY+X/vTwBt3KT3r7gWNM3 e/3jlQUb2k76XZ2x7LKNqOCvk/v8nsr/OBJrJpgUWV265+nEX2dNXho+ncO3fZP5UyWW4oxE Qy3mouJEAGDqUdigAgAA Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 01:36:47 -0000 SGkgQWNlZSwNCnRoYW5rIHlvdSBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcgYW5kIE9TUEYgaW5z aWdodHMuDQpJJ3ZlIHVwZGF0ZWQgcmVmZXJlbmNlIHRvIFJGQyA3Njg0IGluIHRoZSBuZXcgLTAx IHZlcnNpb24uDQpXaGVuIHdlIHdlcmUgc3RhcnRpbmcgd29yayBvbiBSVE0gd2UgaW50ZW5kZWQg dG8gYWRkcmVzcyBMRFAgc2lnbmFsZWQgSVAvTVBMUyBuZXR3b3JrcyBhcyB3ZWxsIGFuZCB0aGF0 LCBhcyBJIHJlY2FsbCwgd2FzIHRoZSByZWFzb24gdG8gdXNlIG1vcmUgZ2VuZXJpYyBJR1AgVExW cyByYXRoZXIgdGhhbiBURS1zcGVjaWZpYy4gU2luY2UgTERQIGRyaWZ0ZWQgb3V0IG9mIHNjb3Bl LCBJIGFncmVlLCB1c2Ugb2YgVEUgYWR2ZXJ0aXNlbWVudHMgaXMgbW9yZSBzdWl0YWJsZS4gV2Un bGwgd29yayBvbiB0aGF0IGFuZCBzaGFyZSBuZXcgdXBkYXRlIHdpdGggeW91IGFuZCB0aGUgSUdQ IFdHcy4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB Y2VlIExpbmRlbSAoYWNlZSkNClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDQ6NTUg UE0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxz LXJlc2lkZW5jZS10aW1lQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFByb2dy ZXNzaW5nIFJlc2RpZW5jZSBUaW1lIE1lYXN1cmVtZW50IGRyYWZ0DQoNCknigJl2ZSByZWFkIHRo ZSBzdWJqZWN0IGRyYWZ0IGFuZCB0aGluayBpdCBvZmZlcnMgYSB1c2VmdWwgZnVuY3Rpb24gdG8g ZmFjaWxpdGF0ZSBtb3JlIGFjY3VyYXRlIHRpbWUgc3luY2hyb25pemF0aW9uIGluIE5UUC9QVFAg ZGVwbG95bWVudHMuIE9uZSBxdWVzdGlvbiBJIGhhdmUgaXMgd2h5IHRoZSBjYXBhYmlsaXR5IGlz IHNpZ25hbGVkIGluIHRoZSBnZW5lcmljIElHUCBUTFYgTFNBcyBhbmQgTFNQcyByYXRoZXIgdGhh biB0aGUgVEUgYWR2ZXJ0aXNlbWVudHMgd2hlbiB0aGUgZG9jdW1lbnQgaXMgc2NvcGVkIHRvIFJT VlAtVEUgW1JGQzMyMDldIExTUHM/IE9uZSByZWFzb24gSSBhc2sgaXMgdGhhdCB3ZSBhcmUgd2Fp dGluZyBvbiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE9TUEZ2MyBFeHRlbmRlZCBMU0FzIGRyYWZ0 LiBIYXZpbmcgc2FpZCB0aGF0LA0KT1NQRnYyIGFuZCBPU1BGdjMgaGF2ZSBzZXBhcmF0ZSByZWdp c3RyeSBmb3IgdGhlIFRMViBMU0FzIGFuZCBzZWN0aW9uIDggc2hvdWxkIHJlZmxlY3QgdGhpcy4g QWxzbywgT1NQRiBQcmVmaXgvTGluayBBdHRyaWJ1dGVzIGlzIG5vdyBSRkMgNzY4NC4NCg0KVGhh bmtzLA0KQWNlZQ0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTG9hIEFuZGVy c3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj5TZW50OiBNb25kYXksIERlY2VtYmVyIDE0LCAyMDE1 IDc6MjMgUE0NCj5UbzogR3JlZ29yeSBNaXJza3k7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxz QGlldGYub3JnDQo+Q2M6IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUB0b29scy5pZXRm Lm9yZw0KPlN1YmplY3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGllbmNlIFRpbWUgTWVh c3VyZW1lbnQgZHJhZnQgDQo+V29ya2luZyBHcm91cCBhbmQgYXV0aG9ycywgPGNoYWlyIGhhdCBv ZmY+IEFzIGEgbWF0dGVyIG9mIGZhY3QgSSANCj5iZWxpZXZlIHRoaXMgZG9jdW1lbnQgc2hvdWxk IGJlIHByb2dyZXNzZWQuDQo+PGNoYWlyIGhhdCBvbj4NCj5UaGlzIGRyYWZ0IGhhcyBiZWVuIGEg d29ya2luZyBncm91cCBkb2N1bWVudCBzaW5jZSBlYXJseSBBdWd1c3QsIGJ1dCANCj50aGVyZSBo YXMgYmVlbiBubyBkaXNjdXNzaW9uIG9uIHRoZSBkb2N1bWVudCBvbiB0aGUgd2cgbWFpbGluZyBs aXN0Lg0KPlRoZXJlIGFyZSBvZiBjb3Vyc2UgdHdvIHdheXMgaWYgaW50ZXJwcmV0aW5nIHRoaXMu DQo+LSB0aGVyZSBpcyB0b3RhbCBhZ3JlZW1lbnQgb24gdGhlIGRyYWZ0DQo+LSB0aGVyZSBpcyBu byBpbnRyZXN0IGluIHRoZSBkcmFmdA0KPkkgaGF2ZSBubyBiYXNpcyB0byBkZWNpZGUgd2hpY2gg aXMgdGhlIGNhc2UuDQo+Q2FuIHdlIHBsZXNlIGhhdmUgYXQgbGVhc3QgYSBmZXcgKG5vbi1hdXRo b3IpIGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5nIA0KPmxpc3QgaWYgaXQgaXMgdGltZSB0byBzdGFy dCB0aGUgd2dsYy4NCj4vTG9hDQo+bXBscyB3ZyBjby1jaGFpcg0KPk9uIDIwMTUtMTItMTUgMDc6 MjEsIEdyZWdvcnkgTWlyc2t5IHdyb3RlOg0KPkRlYXIgQ2hhaXJzIG9mIHRoZSBNUExTIFdHLA0K Pj5hdXRob3JzIG9mIHRoZSBSZXNpZGVuY2UgVGltZSBNZWFzdXJlbWVudCBpbiBNUExTIE5ldHdv cmsgZHJhZnQgDQo+PmJlbGlldmUgdGhhdCBhbGwgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRo ZSBXRyBhZG9wdGlvbiBjYWxsIGJlZW4gDQo+PmFkZHJlc3NlZC4NCj4+VGh1cywgYXV0aG9ycyB3 b3VsZCBsaWtlIHRvIGFzayB0aGUgV0cgQ2hhaXJzIHRvIGNvbnNpZGVyIFdHIExDIGFzIHRoZSAN Cj4+bmV4dCBzdGVwLg0KPj4gICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+bXBscyBtYWlsaW5nIGxpc3QNCj4+bXBsc0BpZXRmLm9y Zw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5n IGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0K From nobody Sun Jan 31 04:50:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193E81A8AB9 for ; Sun, 31 Jan 2016 04:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-ohw_1M68ou for ; Sun, 31 Jan 2016 04:50:54 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F561A88FC for ; Sun, 31 Jan 2016 04:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4278; q=dns/txt; s=iport; t=1454244654; x=1455454254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sc4ojcuTEoB4VTHF8txQRGaLcgVkBVy84nMJAhH+nwI=; b=QzkR7Hn1y7a7tZ2rSjllTQeAXn/9rG94E3RFJemFx55jc2QSItdHaMyb bfGWxL4u3DbulqLHd0kx+jKlHD/U3ACojMNLgN50yP2vh7EX9dxEPKq6e kkmJ9sEaNqwgGfLqLY0GXdoV1q4VtDaNoN8gS3N4NzeEbGab65CxxctUh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBADcAa5W/xbLJq1dhAxtBohSsygYC?= =?us-ascii?q?oVtAhyBUgEBAQEBAYELhEEBAQEEAQEBIBE6CwwEAgEIEQQBAQECAiMDAgICJQs?= =?us-ascii?q?UAQgIAgQBDQWIGw6vGo44AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR7iUuESIJqg?= =?us-ascii?q?ToFlm8BjUqBW4dnhS6FboR+g1EBYoICGYFRaogBfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,375,1449532800"; d="scan'208";a="623921716" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2016 12:50:51 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0VCoo5Z015854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Jan 2016 12:50:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 31 Jan 2016 07:50:49 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 31 Jan 2016 07:50:49 -0500 From: "Acee Lindem (acee)" To: Gregory Mirsky , Loa Andersson Thread-Topic: [mpls] Progressing Resdience Time Measurement draft Thread-Index: AQHRWi+i4aCoaj+USzqP2deJ9ymVRJ8U2EGwgAC/YoA= Date: Sun, 31 Jan 2016 12:50:49 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF112219B81A7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF112219B81A7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.205] Content-Type: text/plain; charset="utf-8" Content-ID: <19053E83A65D6A4C83C16C0B403220FA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 12:50:56 -0000 SGkgR3JlZywgDQpUaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCBwbGFuLg0KVGhhbmtzLA0KQWNlZQ0K DQpPbiAxLzMwLzE2LCA4OjM2IFBNLCAiR3JlZ29yeSBNaXJza3kiIDxncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj50aGFuayB5b3UgZm9yIHlvdXIgdGhv cm91Z2ggcmV2aWV3IGFuZCBPU1BGIGluc2lnaHRzLg0KPkkndmUgdXBkYXRlZCByZWZlcmVuY2Ug dG8gUkZDIDc2ODQgaW4gdGhlIG5ldyAtMDEgdmVyc2lvbi4NCj5XaGVuIHdlIHdlcmUgc3RhcnRp bmcgd29yayBvbiBSVE0gd2UgaW50ZW5kZWQgdG8gYWRkcmVzcyBMRFAgc2lnbmFsZWQNCj5JUC9N UExTIG5ldHdvcmtzIGFzIHdlbGwgYW5kIHRoYXQsIGFzIEkgcmVjYWxsLCB3YXMgdGhlIHJlYXNv biB0byB1c2UNCj5tb3JlIGdlbmVyaWMgSUdQIFRMVnMgcmF0aGVyIHRoYW4gVEUtc3BlY2lmaWMu IFNpbmNlIExEUCBkcmlmdGVkIG91dCBvZg0KPnNjb3BlLCBJIGFncmVlLCB1c2Ugb2YgVEUgYWR2 ZXJ0aXNlbWVudHMgaXMgbW9yZSBzdWl0YWJsZS4gV2UnbGwgd29yayBvbg0KPnRoYXQgYW5kIHNo YXJlIG5ldyB1cGRhdGUgd2l0aCB5b3UgYW5kIHRoZSBJR1AgV0dzLg0KPg0KPglSZWdhcmRzLA0K PgkJR3JlZw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbXBscyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGluZGVtIChhY2Vl KQ0KPlNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDQ6NTUgUE0NCj5UbzogTG9hIEFu ZGVyc3Nvbg0KPkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRp bWVAdG9vbHMuaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW21wbHNdIFByb2dyZXNzaW5nIFJlc2Rp ZW5jZSBUaW1lIE1lYXN1cmVtZW50IGRyYWZ0DQo+DQo+SeKAmXZlIHJlYWQgdGhlIHN1YmplY3Qg ZHJhZnQgYW5kIHRoaW5rIGl0IG9mZmVycyBhIHVzZWZ1bCBmdW5jdGlvbiB0bw0KPmZhY2lsaXRh dGUgbW9yZSBhY2N1cmF0ZSB0aW1lIHN5bmNocm9uaXphdGlvbiBpbiBOVFAvUFRQIGRlcGxveW1l bnRzLiBPbmUNCj5xdWVzdGlvbiBJIGhhdmUgaXMgd2h5IHRoZSBjYXBhYmlsaXR5IGlzIHNpZ25h bGVkIGluIHRoZSBnZW5lcmljIElHUCBUTFYNCj5MU0FzIGFuZCBMU1BzIHJhdGhlciB0aGFuIHRo ZSBURSBhZHZlcnRpc2VtZW50cyB3aGVuIHRoZSBkb2N1bWVudCBpcw0KPnNjb3BlZCB0byBSU1ZQ LVRFIFtSRkMzMjA5XSBMU1BzPyBPbmUgcmVhc29uIEkgYXNrIGlzIHRoYXQgd2UgYXJlIHdhaXRp bmcNCj5vbiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE9TUEZ2MyBFeHRlbmRlZCBMU0FzIGRyYWZ0 LiBIYXZpbmcgc2FpZCB0aGF0LA0KPk9TUEZ2MiBhbmQgT1NQRnYzIGhhdmUgc2VwYXJhdGUgcmVn aXN0cnkgZm9yIHRoZSBUTFYgTFNBcyBhbmQgc2VjdGlvbiA4DQo+c2hvdWxkIHJlZmxlY3QgdGhp cy4gQWxzbywgT1NQRiBQcmVmaXgvTGluayBBdHRyaWJ1dGVzIGlzIG5vdyBSRkMgNzY4NC4NCj4N Cj5UaGFua3MsDQo+QWNlZQ0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBM b2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPj5TZW50OiBNb25kYXksIERlY2VtYmVy IDE0LCAyMDE1IDc6MjMgUE0NCj4+VG86IEdyZWdvcnkgTWlyc2t5OyBtcGxzLWNoYWlyc0BpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZw0KPj5DYzogZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1l QHRvb2xzLmlldGYub3JnDQo+PlN1YmplY3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGll bmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJhZnQNCj4+V29ya2luZyBHcm91cCBhbmQgYXV0aG9ycywg PGNoYWlyIGhhdCBvZmY+IEFzIGEgbWF0dGVyIG9mIGZhY3QgSQ0KPj5iZWxpZXZlIHRoaXMgZG9j dW1lbnQgc2hvdWxkIGJlIHByb2dyZXNzZWQuDQo+PjxjaGFpciBoYXQgb24+DQo+PlRoaXMgZHJh ZnQgaGFzIGJlZW4gYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHNpbmNlIGVhcmx5IEF1Z3VzdCwg YnV0DQo+PnRoZXJlIGhhcyBiZWVuIG5vIGRpc2N1c3Npb24gb24gdGhlIGRvY3VtZW50IG9uIHRo ZSB3ZyBtYWlsaW5nIGxpc3QuDQo+PlRoZXJlIGFyZSBvZiBjb3Vyc2UgdHdvIHdheXMgaWYgaW50 ZXJwcmV0aW5nIHRoaXMuDQo+Pi0gdGhlcmUgaXMgdG90YWwgYWdyZWVtZW50IG9uIHRoZSBkcmFm dA0KPj4tIHRoZXJlIGlzIG5vIGludHJlc3QgaW4gdGhlIGRyYWZ0DQo+PkkgaGF2ZSBubyBiYXNp cyB0byBkZWNpZGUgd2hpY2ggaXMgdGhlIGNhc2UuDQo+PkNhbiB3ZSBwbGVzZSBoYXZlIGF0IGxl YXN0IGEgZmV3IChub24tYXV0aG9yKSBjb21tZW50cyBvbiB0aGUgbWFpbGluZw0KPj5saXN0IGlm IGl0IGlzIHRpbWUgdG8gc3RhcnQgdGhlIHdnbGMuDQo+Pi9Mb2ENCj4+bXBscyB3ZyBjby1jaGFp cg0KPj5PbiAyMDE1LTEyLTE1IDA3OjIxLCBHcmVnb3J5IE1pcnNreSB3cm90ZToNCj4+RGVhciBD aGFpcnMgb2YgdGhlIE1QTFMgV0csDQo+Pj5hdXRob3JzIG9mIHRoZSBSZXNpZGVuY2UgVGltZSBN ZWFzdXJlbWVudCBpbiBNUExTIE5ldHdvcmsgZHJhZnQNCj4+PmJlbGlldmUgdGhhdCBhbGwgY29t bWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBXRyBhZG9wdGlvbiBjYWxsIGJlZW4NCj4+PmFkZHJl c3NlZC4NCj4+PlRodXMsIGF1dGhvcnMgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIENoYWlycyB0 byBjb25zaWRlciBXRyBMQyBhcyB0aGUNCj4+Pm5leHQgc3RlcC4NCj4+PiAgICAgICAgICAgICAg ICAgUmVnYXJkcywNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5tcGxz IG1haWxpbmcgbGlzdA0KPj4+bXBsc0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5tcGxzIG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K From nobody Sun Jan 31 06:02:23 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7E1A1B19; Sun, 31 Jan 2016 06:02:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160131140221.18002.45463.idtracker@ietfa.amsl.com> Date: Sun, 31 Jan 2016 06:02:21 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kumarkini-mpls-spring-lsp-ping-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 14:02:22 -0000 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 : Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane Authors : Nagendra Kumar George Swallow Carlos Pignataro Nobo Akiya Sriganesh Kini Hannes Gredler Mach(Guoyi) Chen Filename : draft-kumarkini-mpls-spring-lsp-ping-05.txt Pages : 16 Date : 2016-01-31 Abstract: Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to MPLS data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with a Segment Routing header. The segment assignment and forwarding semantic nature of Segment Routing raises additional consideration for connectivity verification and fault isolation in LSP with Segment Routing architecture. This document illustrates the problem and describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kumarkini-mpls-spring-lsp-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-kumarkini-mpls-spring-lsp-ping-05 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: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 31 06:27:33 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E021AD33F for ; Sun, 31 Jan 2016 06:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbYQvQKuhkm8 for ; Sun, 31 Jan 2016 06:27:31 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 448411AD338 for ; Sun, 31 Jan 2016 06:27:31 -0800 (PST) Received: (qmail 13272 invoked by uid 0); 31 Jan 2016 14:27:26 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 31 Jan 2016 14:27:26 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id CeTH1s00M2SSUrH01eTLXX; Sun, 31 Jan 2016 07:27:25 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7aQ_Q-yQQ-AA:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=VYftjG--RY8hbhC1RNsA:9 a=Hwm-rIzr9CuGOSFS:21 a=3RmREeOJRhj8Ri5d:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=lbn/YEaOH/EqQGd2Qyqnq49AUNnY4x/Yvb1zKtAzkkw=; b=yT1re1RXwYKa5BX7YGGJv5aHyWel1JKQAX2tG2pgwXds3ztWaeoEXcP/Zb2TFmRzUyzY4vpXP6v011dH4pHEMIU6+9WsUeyNkbHD4nuFqFy6SoTNuKa2M4rrC4Nb0QYg; Received: from box313.bluehost.com ([69.89.31.113]:44586 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aPsyE-00024E-Gy; Sun, 31 Jan 2016 07:27:18 -0700 To: "Acee Lindem (acee)" , Gregory Mirsky , Loa Andersson , draft-ietf-mpls-residence-time@ietf.org References: <7347100B5761DC41A166AC17F22DF112219B81A7@eusaamb103.ericsson.se> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56AE19BB.4000006@labn.net> Date: Sun, 31 Jan 2016 09:27:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Progressing Resdience Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 14:27:33 -0000 So this thread triggered me to reread the draft. I don't really have any time sync experience, so won't be commenting on those aspects of the draft - but I did just send a message off to the DetNet WG as they be interested in using this at some point and are likely to have some folks with 1588 knowledge. The following comment is independent of which LSA types are used, as discussed below, but others may feel it impacts the choice. Should the solution really scoped to just RSVP controlled TE LSPs? It seems to me it should work for any TE LSP, and any TE LSP setup mechanism that can provide the participating nodes with the required information. Does this make sense? I think the following changes are one way to make this change: OLD The scope of this document is on LSPs instantiated using RSVP-TE [RFC3209 ] because the LSP's path can be determined. NEW The scope of this document is on TE LSPs, e.g., those instantiated using RSVP-TE [RFC3209 ], because the LSP's path can be determined. And add text that describes the following in a new section, perhaps at 4.6 or 4.8 "Non-RSVP controlled LSPs" When the TE LSP is controlled via mechanisms other than RSVP-TE, the following information needs to be provided to the RTM capable nodes along the LSP path: - RTM role (ingress, transit, egress) - RTM neighbors - RTM hop counts (as needed) - Anything else I'm sure I missed! The method used to convey this information is out of scope of this document. I have an RSVP specific comment that I'll send separately. Thanks, Lou PS I think this is important work and hope to see it completed soon. On 1/31/2016 7:50 AM, Acee Lindem (acee) wrote: > Hi Greg, > That sounds like a good plan. > Thanks, > Acee > > On 1/30/16, 8:36 PM, "Gregory Mirsky" wrote: > >> Hi Acee, >> thank you for your thorough review and OSPF insights. >> I've updated reference to RFC 7684 in the new -01 version. >> When we were starting work on RTM we intended to address LDP signaled >> IP/MPLS networks as well and that, as I recall, was the reason to use >> more generic IGP TLVs rather than TE-specific. Since LDP drifted out of >> scope, I agree, use of TE advertisements is more suitable. We'll work on >> that and share new update with you and the IGP WGs. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Acee Lindem (acee) >> Sent: Thursday, January 28, 2016 4:55 PM >> To: Loa Andersson >> Cc: mpls@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org >> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >> >> I’ve read the subject draft and think it offers a useful function to >> facilitate more accurate time synchronization in NTP/PTP deployments. One >> question I have is why the capability is signaled in the generic IGP TLV >> LSAs and LSPs rather than the TE advertisements when the document is >> scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is that we are waiting >> on implementations of the OSPFv3 Extended LSAs draft. Having said that, >> OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and section 8 >> should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684. >> >> Thanks, >> Acee >>> -----Original Message----- >>> From: Loa Andersson [mailto:loa@pi.nu] >>> Sent: Monday, December 14, 2015 7:23 PM >>> To: Gregory Mirsky; mpls-chairs@ietf.org; mpls@ietf.org >>> Cc: draft-ietf-mpls-residence-time@tools.ietf.org >>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >>> Working Group and authors, As a matter of fact I >>> believe this document should be progressed. >>> >>> This draft has been a working group document since early August, but >>> there has been no discussion on the document on the wg mailing list. >>> There are of course two ways if interpreting this. >>> - there is total agreement on the draft >>> - there is no intrest in the draft >>> I have no basis to decide which is the case. >>> Can we plese have at least a few (non-author) comments on the mailing >>> list if it is time to start the wglc. >>> /Loa >>> mpls wg co-chair >>> On 2015-12-15 07:21, Gregory Mirsky wrote: >>> Dear Chairs of the MPLS WG, >>>> authors of the Residence Time Measurement in MPLS Network draft >>>> believe that all comments received during the WG adoption call been >>>> addressed. >>>> Thus, authors would like to ask the WG Chairs to consider WG LC as the >>>> next step. >>>> Regards, >>>> Greg >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jan 31 06:37:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7CE1AD36F for ; Sun, 31 Jan 2016 06:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27J73KIkz6a7 for ; Sun, 31 Jan 2016 06:37:50 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 53FBC1AD367 for ; Sun, 31 Jan 2016 06:37:50 -0800 (PST) Received: (qmail 1531 invoked by uid 0); 31 Jan 2016 14:37:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 31 Jan 2016 14:37:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Cedj1s00y2SSUrH01edmse; Sun, 31 Jan 2016 07:37:47 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7aQ_Q-yQQ-AA:10 a=ywnwY2WruEfJrcUo7gcA:9 a=xPNAt_YxZ3yXBEZu:21 a=S9fUUbhmGIO5KX0I:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=tYdFXad41zQ7auW7iJDXfb7PY/uPOTQ750fLdcA70XE=; b=fd4uGDopFQuGqAeC4QPRCCwfZP2oe7W4v1m8I0CGzLyT8GRdiZ1rKXYhuc9QRS2uSCYfcCY7szmGH694HXB/03ztQcrsQr5pk7JjBneQmYel+tKwVpHJGKZKBQSP26Mv; Received: from box313.bluehost.com ([69.89.31.113]:46483 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aPt8L-0004H8-IW; Sun, 31 Jan 2016 07:37:45 -0700 To: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <56AE1C2E.4040109@labn.net> Date: Sun, 31 Jan 2016 09:37:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [mpls] comment on draft-ietf-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 14:37:51 -0000 Hi, I see you propose defining a new RSVP object class that has application specific scope. As I'm sure you know the RSVP class-number space is really small so it's best to avoid allocating new object classes whenever possible. I believe there is an existing object class that you can use for your purposes -- the LSP_ATTRIBUTES object. Have you considered carrying RTM Hops in 1 (or three, depending on if you want sub-tlvs or not) new RTM Attribute TLV (or TLVs)? If not, I think it is worth exploring the viability of this approach or any other approach that doesn't require the allocation of a new class-num. Lou (As contributor and TEAS co-chair) From nobody Sun Jan 31 06:50:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B4B1B29DA; Sun, 31 Jan 2016 06:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvj1AMpwsYVM; Sun, 31 Jan 2016 06:50:51 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967A41B29D9; Sun, 31 Jan 2016 06:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LydCe0iDS+ZBamnvSx8k969QmfYA+KXt2dqCSPWNsDw=; b=jx4dXQeHO7LLSMgS+udor3TzKzPQMLs+LXGfefBbojE7bZ6lpOvRiSx0bRdL7B73aIexRxEDaNT1qgvxHzVBAIlO6KbpT451gxUxyrngbuCXqrV9GGwYOjscHvVLsd91bgFkdpQgyQgo7xh25qy/kIL2H0sHj8DeRAQl3xe2YEk= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.396.15; Sun, 31 Jan 2016 14:50:31 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0396.017; Sun, 31 Jan 2016 14:50:31 +0000 From: Alexander Vainshtein To: Lou Berger Thread-Topic: [mpls] Progressing Residence Time Measurement draft Thread-Index: AdFcNrbbWd1Pf8ipTpKMdzi5VKrLgw== Date: Sun, 31 Jan 2016 14:50:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:UJhNkw1S4aus+MEpv2P7+cAOeKRh5OXYHiOOaoVnxHe4saq55T4ksajPSF3lsxBNDUwxD219K3SY43JuTTLAojkLNSTAoXCJHKj2iWM/EHLIMfIsbKyf/I5Xv/R54uFocxYxBIZt7FqZb6ENSGaVYA==; 24:vbfSu14xlAdCwsz8zFUM3dlMqcztyqFd9P84FBWVN6K773vxxFIL0Wkt1DA2Op0np7I+00hf3SMOmTWS1OjmIz42h0+PwKbhkjzEBYTTdxw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-ms-office365-filtering-correlation-id: 51956d9c-4802-4d92-e430-08d32a4dde12 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 08381C729B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(164054003)(24454002)(51914003)(252514010)(377424004)(37854004)(110136002)(6116002)(3280700002)(66066001)(33656002)(10400500002)(2900100001)(102836003)(5002640100001)(5001960100002)(40100003)(1096002)(1220700001)(4001150100001)(5008740100001)(586003)(189998001)(3470700001)(87936001)(74316001)(92566002)(3846002)(86362001)(19580405001)(76576001)(11100500001)(5004730100002)(15975445007)(3660700001)(50986999)(54356999)(77096005)(4326007)(2906002)(122556002)(19580395003)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2016 14:50:30.8812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@ietf.org" Subject: Re: [mpls] Progressing Residence Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 14:50:54 -0000 TG91LA0KRmlyc3Qgb2YgYWxsLCBsb3RzIG9mIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIC0gYm90 aCBmb3Igb25lcyB5b3UgaGF2ZSBzZW50IGFuZCAtIGluIGFkdmFuY2UgLSBmb3Igb25lIGRlYWxp bmcgd2l0aCBSU1ZQLVRFIHRoYXQgeW91J3ZlIHByb21pc2VkIHRvIHNlbmQuDQoNClNlY29uZCwg SSB3b25kZXIgd2hpY2ggVEUgTFNQcyBiZXlvbmQgb25lcyBzZXQgdXAgYnkgUlNWUC1URSBvbmVz IHlvdSBoYXZlIGluIG1pbmQuDQoNCklmICB5b3UgYXJlIHNwZWFraW5nIGFib3V0IHN0YXRpY2Fs bHkgY29uZmlndXJlZCBMU1BzIChhbmQgdGhlc2UsIGluIGEgd2F5LCBhcmUgYWx3YXlzIFRFIExT UHMpLCBJIGRvIG5vdCBmb3Jlc2VlIGFueSBwcm9ibGVtIHdpdGggZXh0ZW5kaW5nIFJUTSB0byB0 aGVtLg0KDQpJZiwgaG93ZXZlciwgeW91IGFyZSBzcGVha2luZyBhYm91dCBMU1BzIHRoYXQgaGF2 ZSBiZWVuIHNldCB1cCB1c2luZyBTZWdtZW50IFJvdXRpbmcgKFNSKSwgSSBkb3VidCBSVE0gY2Fu IHdvcmsgd2l0aCB0aGVzZSBiZWNhdXNlIHRoZXNlIExTUHMgY291bGQgKGFuZCwgbW9zdCBwcm9i YWJseSwgcHJvYmFibHkgd291bGQpIGluY2x1ZGUgbXVsdGlwbGUgRUNNUCBzdWItcGF0aHMgYmV0 d2VlbiBzcGVjaWZpYyAicGlubmVkIiBub2Rlcy4NCg0KU28gSSBhbSBub3Qgc3VyZSBleHRlbmRp bmcgKGV2ZW4gYXQgdGhlIGxldmVsIG9mIGEgZGVjbGFyYXRpb24gd2l0aG91dCBwcm92aWRpbmcg YW55IGRldGFpbHMpIGFwcGxpY2FiaWxpdHkgb2YgUlRQIHRvIGFsbCBURSBMU1BzIGlzIHRoZSBy aWdodCB3YXkgdG8gZ28uDQoNClJlZ2FyZHMsDQpTYXNoYQ0KDQpPZmZpY2U6ICs5NzItMzkyNjYz MDINCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBTdW5kYXksIEphbnVhcnkg MzEsIDIwMTYgNDoyNyBQTQ0KVG86IEFjZWUgTGluZGVtIChhY2VlKTsgR3JlZ29yeSBNaXJza3k7 IExvYSBBbmRlcnNzb247IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUBpZXRmLm9yZw0K Q2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGll bmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJhZnQNCg0KU28gdGhpcyB0aHJlYWQgdHJpZ2dlcmVkIG1l IHRvIHJlcmVhZCB0aGUgZHJhZnQuICBJIGRvbid0IHJlYWxseSBoYXZlIGFueSB0aW1lIHN5bmMg ZXhwZXJpZW5jZSwgc28gd29uJ3QgYmUgY29tbWVudGluZyBvbiB0aG9zZSBhc3BlY3RzIG9mIHRo ZSBkcmFmdCAtIGJ1dCBJIGRpZCBqdXN0IHNlbmQgYSBtZXNzYWdlIG9mZiB0byB0aGUgRGV0TmV0 IFdHIGFzIHRoZXkgYmUgaW50ZXJlc3RlZCBpbiB1c2luZyB0aGlzIGF0IHNvbWUgcG9pbnQgYW5k IGFyZSBsaWtlbHkgdG8gaGF2ZSBzb21lIGZvbGtzIHdpdGggMTU4OCBrbm93bGVkZ2UuIA0KDQpU aGUgZm9sbG93aW5nIGNvbW1lbnQgaXMgaW5kZXBlbmRlbnQgb2Ygd2hpY2ggTFNBIHR5cGVzIGFy ZSB1c2VkLCBhcyBkaXNjdXNzZWQgYmVsb3csIGJ1dCBvdGhlcnMgbWF5IGZlZWwgaXQgaW1wYWN0 cyB0aGUgY2hvaWNlLg0KDQpTaG91bGQgdGhlIHNvbHV0aW9uIHJlYWxseSBzY29wZWQgdG8ganVz dCBSU1ZQIGNvbnRyb2xsZWQgVEUgTFNQcz8gIEl0IHNlZW1zIHRvIG1lIGl0IHNob3VsZCB3b3Jr IGZvciBhbnkgVEUgTFNQLCBhbmQgYW55IFRFIExTUCBzZXR1cCBtZWNoYW5pc20gdGhhdCBjYW4g cHJvdmlkZSB0aGUgcGFydGljaXBhdGluZyBub2RlcyB3aXRoIHRoZSByZXF1aXJlZCBpbmZvcm1h dGlvbi4gIERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQpJIHRoaW5rIHRoZSBmb2xsb3dpbmcgY2hh bmdlcyBhcmUgb25lIHdheSB0byBtYWtlIHRoaXMgY2hhbmdlOg0KT0xEDQoNCiAgICBUaGUgc2Nv cGUgb2YNCiAgIHRoaXMgZG9jdW1lbnQgaXMgb24gTFNQcyBpbnN0YW50aWF0ZWQgdXNpbmcgUlNW UC1URSBbUkZDMzIwOSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyMDk+XSBiZWNh dXNlDQogICB0aGUgTFNQJ3MgcGF0aCBjYW4gYmUgZGV0ZXJtaW5lZC4NCk5FVw0KDQogICAgVGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgaXMgb24gVEUgTFNQcywgZS5nLiwgdGhvc2UgIGluc3Rh bnRpYXRlZCB1c2luZw0KICAgICBSU1ZQLVRFIFtSRkMzMjA5IDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzIwOT5dLCBiZWNhdXNlIHRoZSBMU1AncyBwYXRoIGNhbiBiZSBkZXRlcm1p bmVkLg0KDQpBbmQgYWRkIHRleHQgdGhhdCBkZXNjcmliZXMgdGhlIGZvbGxvd2luZyBpbiBhIG5l dyBzZWN0aW9uLCBwZXJoYXBzIGF0DQo0LjYgb3IgNC44ICJOb24tUlNWUCBjb250cm9sbGVkIExT UHMiDQogIFdoZW4gdGhlIFRFIExTUCBpcyBjb250cm9sbGVkIHZpYSBtZWNoYW5pc21zIG90aGVy IHRoYW4gUlNWUC1URSwgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm92 aWRlZCB0byB0aGUgUlRNIGNhcGFibGUgbm9kZXMgYWxvbmcgdGhlIExTUCBwYXRoOg0KICAgLSBS VE0gcm9sZSAoaW5ncmVzcywgdHJhbnNpdCwgZWdyZXNzKQ0KICAgLSBSVE0gbmVpZ2hib3JzDQog ICAtIFJUTSBob3AgY291bnRzIChhcyBuZWVkZWQpDQogIC0gQW55dGhpbmcgZWxzZSBJJ20gc3Vy ZSBJIG1pc3NlZCENCiAgVGhlIG1ldGhvZCB1c2VkIHRvIGNvbnZleSB0aGlzIGluZm9ybWF0aW9u IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJIGhhdmUgYW4gUlNWUCBzcGVj aWZpYyBjb21tZW50IHRoYXQgSSdsbCBzZW5kIHNlcGFyYXRlbHkuDQoNClRoYW5rcywNCkxvdQ0K DQpQUyBJIHRoaW5rIHRoaXMgaXMgaW1wb3J0YW50IHdvcmsgYW5kIGhvcGUgdG8gc2VlIGl0IGNv bXBsZXRlZCBzb29uLg0KDQpPbiAxLzMxLzIwMTYgNzo1MCBBTSwgQWNlZSBMaW5kZW0gKGFjZWUp IHdyb3RlOg0KPiBIaSBHcmVnLA0KPiBUaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCBwbGFuLg0KPiBU aGFua3MsDQo+IEFjZWUNCj4NCj4gT24gMS8zMC8xNiwgODozNiBQTSwgIkdyZWdvcnkgTWlyc2t5 IiA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4NCj4+IEhpIEFjZWUsDQo+ PiB0aGFuayB5b3UgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3IGFuZCBPU1BGIGluc2lnaHRzLg0K Pj4gSSd2ZSB1cGRhdGVkIHJlZmVyZW5jZSB0byBSRkMgNzY4NCBpbiB0aGUgbmV3IC0wMSB2ZXJz aW9uLg0KPj4gV2hlbiB3ZSB3ZXJlIHN0YXJ0aW5nIHdvcmsgb24gUlRNIHdlIGludGVuZGVkIHRv IGFkZHJlc3MgTERQIHNpZ25hbGVkIA0KPj4gSVAvTVBMUyBuZXR3b3JrcyBhcyB3ZWxsIGFuZCB0 aGF0LCBhcyBJIHJlY2FsbCwgd2FzIHRoZSByZWFzb24gdG8gdXNlIA0KPj4gbW9yZSBnZW5lcmlj IElHUCBUTFZzIHJhdGhlciB0aGFuIFRFLXNwZWNpZmljLiBTaW5jZSBMRFAgZHJpZnRlZCBvdXQg DQo+PiBvZiBzY29wZSwgSSBhZ3JlZSwgdXNlIG9mIFRFIGFkdmVydGlzZW1lbnRzIGlzIG1vcmUg c3VpdGFibGUuIFdlJ2xsIA0KPj4gd29yayBvbiB0aGF0IGFuZCBzaGFyZSBuZXcgdXBkYXRlIHdp dGggeW91IGFuZCB0aGUgSUdQIFdHcy4NCj4+DQo+PiAJUmVnYXJkcywNCj4+IAkJR3JlZw0KPj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBtcGxzIFttYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gDQo+PiAoYWNlZSkN Cj4+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDQ6NTUgUE0NCj4+IFRvOiBMb2Eg QW5kZXJzc29uDQo+PiBDYzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5j ZS10aW1lQHRvb2xzLmlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFByb2dyZXNzaW5n IFJlc2RpZW5jZSBUaW1lIE1lYXN1cmVtZW50IGRyYWZ0DQo+Pg0KPj4gSeKAmXZlIHJlYWQgdGhl IHN1YmplY3QgZHJhZnQgYW5kIHRoaW5rIGl0IG9mZmVycyBhIHVzZWZ1bCBmdW5jdGlvbiB0byAN Cj4+IGZhY2lsaXRhdGUgbW9yZSBhY2N1cmF0ZSB0aW1lIHN5bmNocm9uaXphdGlvbiBpbiBOVFAv UFRQIGRlcGxveW1lbnRzLiANCj4+IE9uZSBxdWVzdGlvbiBJIGhhdmUgaXMgd2h5IHRoZSBjYXBh YmlsaXR5IGlzIHNpZ25hbGVkIGluIHRoZSBnZW5lcmljIA0KPj4gSUdQIFRMViBMU0FzIGFuZCBM U1BzIHJhdGhlciB0aGFuIHRoZSBURSBhZHZlcnRpc2VtZW50cyB3aGVuIHRoZSANCj4+IGRvY3Vt ZW50IGlzIHNjb3BlZCB0byBSU1ZQLVRFIFtSRkMzMjA5XSBMU1BzPyBPbmUgcmVhc29uIEkgYXNr IGlzIA0KPj4gdGhhdCB3ZSBhcmUgd2FpdGluZyBvbiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE9T UEZ2MyBFeHRlbmRlZCBMU0FzIA0KPj4gZHJhZnQuIEhhdmluZyBzYWlkIHRoYXQsDQo+PiBPU1BG djIgYW5kIE9TUEZ2MyBoYXZlIHNlcGFyYXRlIHJlZ2lzdHJ5IGZvciB0aGUgVExWIExTQXMgYW5k IHNlY3Rpb24gDQo+PiA4IHNob3VsZCByZWZsZWN0IHRoaXMuIEFsc28sIE9TUEYgUHJlZml4L0xp bmsgQXR0cmlidXRlcyBpcyBub3cgUkZDIDc2ODQuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNlZQ0K Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogTG9hIEFuZGVyc3NvbiBb bWFpbHRvOmxvYUBwaS5udV0NCj4+PiBTZW50OiBNb25kYXksIERlY2VtYmVyIDE0LCAyMDE1IDc6 MjMgUE0NCj4+PiBUbzogR3JlZ29yeSBNaXJza3k7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxz QGlldGYub3JnDQo+Pj4gQ2M6IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUB0b29scy5p ZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGllbmNlIFRp bWUgTWVhc3VyZW1lbnQgZHJhZnQgDQo+Pj4gV29ya2luZyBHcm91cCBhbmQgYXV0aG9ycywgPGNo YWlyIGhhdCBvZmY+IEFzIGEgbWF0dGVyIG9mIGZhY3QgSSANCj4+PiBiZWxpZXZlIHRoaXMgZG9j dW1lbnQgc2hvdWxkIGJlIHByb2dyZXNzZWQuDQo+Pj4gPGNoYWlyIGhhdCBvbj4NCj4+PiBUaGlz IGRyYWZ0IGhhcyBiZWVuIGEgd29ya2luZyBncm91cCBkb2N1bWVudCBzaW5jZSBlYXJseSBBdWd1 c3QsIGJ1dCANCj4+PiB0aGVyZSBoYXMgYmVlbiBubyBkaXNjdXNzaW9uIG9uIHRoZSBkb2N1bWVu dCBvbiB0aGUgd2cgbWFpbGluZyBsaXN0Lg0KPj4+IFRoZXJlIGFyZSBvZiBjb3Vyc2UgdHdvIHdh eXMgaWYgaW50ZXJwcmV0aW5nIHRoaXMuDQo+Pj4gLSB0aGVyZSBpcyB0b3RhbCBhZ3JlZW1lbnQg b24gdGhlIGRyYWZ0DQo+Pj4gLSB0aGVyZSBpcyBubyBpbnRyZXN0IGluIHRoZSBkcmFmdA0KPj4+ IEkgaGF2ZSBubyBiYXNpcyB0byBkZWNpZGUgd2hpY2ggaXMgdGhlIGNhc2UuDQo+Pj4gQ2FuIHdl IHBsZXNlIGhhdmUgYXQgbGVhc3QgYSBmZXcgKG5vbi1hdXRob3IpIGNvbW1lbnRzIG9uIHRoZSAN Cj4+PiBtYWlsaW5nIGxpc3QgaWYgaXQgaXMgdGltZSB0byBzdGFydCB0aGUgd2dsYy4NCj4+PiAv TG9hDQo+Pj4gbXBscyB3ZyBjby1jaGFpcg0KPj4+IE9uIDIwMTUtMTItMTUgMDc6MjEsIEdyZWdv cnkgTWlyc2t5IHdyb3RlOg0KPj4+IERlYXIgQ2hhaXJzIG9mIHRoZSBNUExTIFdHLA0KPj4+PiBh dXRob3JzIG9mIHRoZSBSZXNpZGVuY2UgVGltZSBNZWFzdXJlbWVudCBpbiBNUExTIE5ldHdvcmsg ZHJhZnQgDQo+Pj4+IGJlbGlldmUgdGhhdCBhbGwgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRo ZSBXRyBhZG9wdGlvbiBjYWxsIGJlZW4gDQo+Pj4+IGFkZHJlc3NlZC4NCj4+Pj4gVGh1cywgYXV0 aG9ycyB3b3VsZCBsaWtlIHRvIGFzayB0aGUgV0cgQ2hhaXJzIHRvIGNvbnNpZGVyIFdHIExDIGFz IA0KPj4+PiB0aGUgbmV4dCBzdGVwLg0KPj4+PiAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIA0KPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBtcGxzIG1haWxpbmcg bGlzdA0KPj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBs aXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQoNCg0K From nobody Sun Jan 31 07:08:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6194E1B2A3E for ; Sun, 31 Jan 2016 07:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EScKXUlQRl32 for ; Sun, 31 Jan 2016 07:08:46 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 659071B2A3D for ; Sun, 31 Jan 2016 07:08:46 -0800 (PST) Received: (qmail 25857 invoked by uid 0); 31 Jan 2016 15:08:44 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 31 Jan 2016 15:08:44 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Cf8f1s0082SSUrH01f8i8k; Sun, 31 Jan 2016 08:08:43 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7aQ_Q-yQQ-AA:10 a=IRDgFnn-AAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=hUxWGHdmqRaY2WBoc5kA:9 a=fyAjd1GmZGdofVgW:21 a=TX0N_uI5QG7XqOre:21 a=QEXdDO2ut3YA:10 a=ZgsxABZQttoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=Jb+XxrvyavW36EVx1YCiRHpAxsyiSXBt/q2dj+heDM4=; b=UGZgRgjPykvCHx+WtFTvNbRcUwErvEGqtj5JHaAAhNGbrU6m5G+lk+8LKnuIZuyqRhbCGLE0e07A9r9lFoS373rs9t1UP7qMDTk0fEx0TsdeqbFszQ4cCRgIZ7yKR4DA; Received: from box313.bluehost.com ([69.89.31.113]:53072 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aPtcG-0002NK-58; Sun, 31 Jan 2016 08:08:40 -0700 To: Alexander Vainshtein References: From: Lou Berger Message-ID: <56AE236C.8010005@labn.net> Date: Sun, 31 Jan 2016 10:08:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@ietf.org" Subject: Re: [mpls] Progressing Residence Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 15:08:48 -0000 Sasha, See below. On 1/31/2016 9:50 AM, Alexander Vainshtein wrote: > Lou, > First of all, lots of thanks for the comments - both for ones you have sent and - in advance - for one dealing with RSVP-TE that you've promised to send. > > Second, I wonder which TE LSPs beyond ones set up by RSVP-TE ones you have in mind. > > If you are speaking about statically configured LSPs (and these, in a way, are always TE LSPs), I do not foresee any problem with extending RTM to them. Yes. Or controller based. > If, however, you are speaking about LSPs that have been set up using Segment Routing (SR), I doubt RTM can work with these because these LSPs could (and, most probably, probably would) include multiple ECMP sub-paths between specific "pinned" nodes. Haven't really dug in enough on SR to have an opinion... > So I am not sure extending (even at the level of a declaration without providing any details) applicability of RTP to all TE LSPs is the right way to go. I think the fully pinned/ER case should be covered -- and that's what I was really trying to refer to. Thanks, Lou > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Sunday, January 31, 2016 4:27 PM > To: Acee Lindem (acee); Gregory Mirsky; Loa Andersson; draft-ietf-mpls-residence-time@ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Progressing Resdience Time Measurement draft > > So this thread triggered me to reread the draft. I don't really have any time sync experience, so won't be commenting on those aspects of the draft - but I did just send a message off to the DetNet WG as they be interested in using this at some point and are likely to have some folks with 1588 knowledge. > > The following comment is independent of which LSA types are used, as discussed below, but others may feel it impacts the choice. > > Should the solution really scoped to just RSVP controlled TE LSPs? It seems to me it should work for any TE LSP, and any TE LSP setup mechanism that can provide the participating nodes with the required information. Does this make sense? > > I think the following changes are one way to make this change: > OLD > > The scope of > this document is on LSPs instantiated using RSVP-TE [RFC3209 ] because > the LSP's path can be determined. > NEW > > The scope of this document is on TE LSPs, e.g., those instantiated using > RSVP-TE [RFC3209 ], because the LSP's path can be determined. > > And add text that describes the following in a new section, perhaps at > 4.6 or 4.8 "Non-RSVP controlled LSPs" > When the TE LSP is controlled via mechanisms other than RSVP-TE, the following information needs to be provided to the RTM capable nodes along the LSP path: > - RTM role (ingress, transit, egress) > - RTM neighbors > - RTM hop counts (as needed) > - Anything else I'm sure I missed! > The method used to convey this information is out of scope of this document. > > I have an RSVP specific comment that I'll send separately. > > Thanks, > Lou > > PS I think this is important work and hope to see it completed soon. > > On 1/31/2016 7:50 AM, Acee Lindem (acee) wrote: >> Hi Greg, >> That sounds like a good plan. >> Thanks, >> Acee >> >> On 1/30/16, 8:36 PM, "Gregory Mirsky" wrote: >> >>> Hi Acee, >>> thank you for your thorough review and OSPF insights. >>> I've updated reference to RFC 7684 in the new -01 version. >>> When we were starting work on RTM we intended to address LDP signaled >>> IP/MPLS networks as well and that, as I recall, was the reason to use >>> more generic IGP TLVs rather than TE-specific. Since LDP drifted out >>> of scope, I agree, use of TE advertisements is more suitable. We'll >>> work on that and share new update with you and the IGP WGs. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Acee Lindem >>> (acee) >>> Sent: Thursday, January 28, 2016 4:55 PM >>> To: Loa Andersson >>> Cc: mpls@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org >>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >>> >>> I’ve read the subject draft and think it offers a useful function to >>> facilitate more accurate time synchronization in NTP/PTP deployments. >>> One question I have is why the capability is signaled in the generic >>> IGP TLV LSAs and LSPs rather than the TE advertisements when the >>> document is scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is >>> that we are waiting on implementations of the OSPFv3 Extended LSAs >>> draft. Having said that, >>> OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and section >>> 8 should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684. >>> >>> Thanks, >>> Acee >>>> -----Original Message----- >>>> From: Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Monday, December 14, 2015 7:23 PM >>>> To: Gregory Mirsky; mpls-chairs@ietf.org; mpls@ietf.org >>>> Cc: draft-ietf-mpls-residence-time@tools.ietf.org >>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >>>> Working Group and authors, As a matter of fact I >>>> believe this document should be progressed. >>>> >>>> This draft has been a working group document since early August, but >>>> there has been no discussion on the document on the wg mailing list. >>>> There are of course two ways if interpreting this. >>>> - there is total agreement on the draft >>>> - there is no intrest in the draft >>>> I have no basis to decide which is the case. >>>> Can we plese have at least a few (non-author) comments on the >>>> mailing list if it is time to start the wglc. >>>> /Loa >>>> mpls wg co-chair >>>> On 2015-12-15 07:21, Gregory Mirsky wrote: >>>> Dear Chairs of the MPLS WG, >>>>> authors of the Residence Time Measurement in MPLS Network draft >>>>> believe that all comments received during the WG adoption call been >>>>> addressed. >>>>> Thus, authors would like to ask the WG Chairs to consider WG LC as >>>>> the next step. >>>>> Regards, >>>>> Greg >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From nobody Sun Jan 31 07:13:24 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3431B2A5E; Sun, 31 Jan 2016 07:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfxHWRzlTCyj; Sun, 31 Jan 2016 07:13:21 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FF91B2A5D; Sun, 31 Jan 2016 07:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WHQ2E24XiiSI8ykth0gULtAgfLoEM+gSeE47G8rSH4A=; b=OPOxPjRl0T4FMGM/fYlATIKeVq7+5TsPU+X8VabCaHW6lDkzumsHoH/rffRNXvw0sntwr6jFtUNFqIgBO06gRZFmMM+teYB8POpugtx7pmNjUT9GenlO37qVsw61qJtTKpUFpu4kISqcm3RHfDDxUwdagvv4AtWbpc+BZ8yyLBE= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.396.15; Sun, 31 Jan 2016 15:12:57 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0396.017; Sun, 31 Jan 2016 15:12:57 +0000 From: Alexander Vainshtein To: Lou Berger Thread-Topic: [mpls] Progressing Residence Time Measurement draft Thread-Index: AdFcNrbbWd1Pf8ipTpKMdzi5VKrLgwAAoZUAAAAW7eA= Date: Sun, 31 Jan 2016 15:12:57 +0000 Message-ID: References: <56AE236C.8010005@labn.net> In-Reply-To: <56AE236C.8010005@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:HrNJVtqj5K+wbZQ0ON2lJ5p25EsOqQd9HoPjcsknQV3jjoVVUCFNy4bmieehv1W7GM5FRLPXGhntJUOyBhVQ89jfhSM2m10AAqA6w+n7jSpy6hGoJ8LRq30pz82a4p5moy5e4b77ebzBtb81aa9PvA==; 24:2jQ/KI1cktH1oCly8eOgFV0VukbNJUoAPSe1RFP8lkip1dm02bFpkND5f8dlBZB09pb+gM4TlmbmdjC3R3eQ5qKPk/6NyOxbrsUaQpSMakw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-ms-office365-filtering-correlation-id: 37997b18-a152-4659-022d-08d32a510067 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 08381C729B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(37854004)(377424004)(252514010)(479174004)(24454002)(51914003)(77096005)(122556002)(2900100001)(15975445007)(2950100001)(74316001)(86362001)(50986999)(66066001)(586003)(87936001)(54356999)(5008740100001)(11100500001)(5004730100002)(102836003)(1220700001)(6116002)(3846002)(76176999)(1096002)(33656002)(3470700001)(3660700001)(4001150100001)(10400500002)(4326007)(5001960100002)(19580395003)(40100003)(92566002)(3280700002)(110136002)(189998001)(76576001)(5002640100001)(5003600100002)(2906002)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2016 15:12:57.4027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@ietf.org" Subject: Re: [mpls] Progressing Residence Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 15:13:23 -0000 TG91LA0KTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLg0KDQpTcGVha2luZyBq dXN0IGZvciBteXNlbGYsIEkgYWdyZWUgdGhhdCBSVE0gY291bGQgd29yayAoaW4gcHJpbmNpcGxl KSB3aXRoIGZ1bGx5IHBpbm5lZC9FUiBURSBMU1BzLiANCg0KUmVnYXJkcywNClNhc2hhDQoNCk9m ZmljZTogKzk3Mi0zOTI2NjMwMg0KQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KRW1haWw6ICAg QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2Vu dDogU3VuZGF5LCBKYW51YXJ5IDMxLCAyMDE2IDU6MDggUE0NClRvOiBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IEFjZWUgTGluZGVtIChhY2VlKTsgR3JlZ29yeSBNaXJz a3k7IExvYSBBbmRlcnNzb247IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFttcGxzXSBQcm9ncmVzc2luZyBSZXNpZGVuY2UgVGltZSBNZWFzdXJl bWVudCBkcmFmdA0KDQpTYXNoYSwNCiAgICBTZWUgYmVsb3cuDQoNCk9uIDEvMzEvMjAxNiA5OjUw IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gTG91LA0KPiBGaXJzdCBvZiBhbGws IGxvdHMgb2YgdGhhbmtzIGZvciB0aGUgY29tbWVudHMgLSBib3RoIGZvciBvbmVzIHlvdSBoYXZl IHNlbnQgYW5kIC0gaW4gYWR2YW5jZSAtIGZvciBvbmUgZGVhbGluZyB3aXRoIFJTVlAtVEUgdGhh dCB5b3UndmUgcHJvbWlzZWQgdG8gc2VuZC4NCj4NCj4gU2Vjb25kLCBJIHdvbmRlciB3aGljaCBU RSBMU1BzIGJleW9uZCBvbmVzIHNldCB1cCBieSBSU1ZQLVRFIG9uZXMgeW91IGhhdmUgaW4gbWlu ZC4NCj4NCj4gSWYgIHlvdSBhcmUgc3BlYWtpbmcgYWJvdXQgc3RhdGljYWxseSBjb25maWd1cmVk IExTUHMgKGFuZCB0aGVzZSwgaW4gYSB3YXksIGFyZSBhbHdheXMgVEUgTFNQcyksIEkgZG8gbm90 IGZvcmVzZWUgYW55IHByb2JsZW0gd2l0aCBleHRlbmRpbmcgUlRNIHRvIHRoZW0uDQpZZXMuICBP ciBjb250cm9sbGVyIGJhc2VkLg0KDQo+IElmLCBob3dldmVyLCB5b3UgYXJlIHNwZWFraW5nIGFi b3V0IExTUHMgdGhhdCBoYXZlIGJlZW4gc2V0IHVwIHVzaW5nIFNlZ21lbnQgUm91dGluZyAoU1Ip LCBJIGRvdWJ0IFJUTSBjYW4gd29yayB3aXRoIHRoZXNlIGJlY2F1c2UgdGhlc2UgTFNQcyBjb3Vs ZCAoYW5kLCBtb3N0IHByb2JhYmx5LCBwcm9iYWJseSB3b3VsZCkgaW5jbHVkZSBtdWx0aXBsZSBF Q01QIHN1Yi1wYXRocyBiZXR3ZWVuIHNwZWNpZmljICJwaW5uZWQiIG5vZGVzLg0KSGF2ZW4ndCBy ZWFsbHkgZHVnIGluIGVub3VnaCBvbiBTUiB0byBoYXZlIGFuIG9waW5pb24uLi4NCg0KPiBTbyBJ IGFtIG5vdCBzdXJlIGV4dGVuZGluZyAoZXZlbiBhdCB0aGUgbGV2ZWwgb2YgYSBkZWNsYXJhdGlv biB3aXRob3V0IHByb3ZpZGluZyBhbnkgZGV0YWlscykgYXBwbGljYWJpbGl0eSBvZiBSVFAgdG8g YWxsIFRFIExTUHMgaXMgdGhlIHJpZ2h0IHdheSB0byBnby4NCg0KSSB0aGluayB0aGUgZnVsbHkg cGlubmVkL0VSIGNhc2Ugc2hvdWxkIGJlIGNvdmVyZWQgLS0gYW5kIHRoYXQncyB3aGF0IEkgd2Fz IHJlYWxseSB0cnlpbmcgdG8gcmVmZXIgdG8uIA0KDQpUaGFua3MsDQpMb3UNCg0KPiBSZWdhcmRz LA0KPiBTYXNoYQ0KPg0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gQ2VsbDogICAgICArOTcy LTU0OTI2NjMwMg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWls dG86bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDMxLCAyMDE2IDQ6 MjcgUE0NCj4gVG86IEFjZWUgTGluZGVtIChhY2VlKTsgR3JlZ29yeSBNaXJza3k7IExvYSBBbmRl cnNzb247IA0KPiBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWVAaWV0Zi5vcmcNCj4gQ2M6 IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBQcm9ncmVzc2luZyBSZXNkaWVu Y2UgVGltZSBNZWFzdXJlbWVudCBkcmFmdA0KPg0KPiBTbyB0aGlzIHRocmVhZCB0cmlnZ2VyZWQg bWUgdG8gcmVyZWFkIHRoZSBkcmFmdC4gIEkgZG9uJ3QgcmVhbGx5IGhhdmUgYW55IHRpbWUgc3lu YyBleHBlcmllbmNlLCBzbyB3b24ndCBiZSBjb21tZW50aW5nIG9uIHRob3NlIGFzcGVjdHMgb2Yg dGhlIGRyYWZ0IC0gYnV0IEkgZGlkIGp1c3Qgc2VuZCBhIG1lc3NhZ2Ugb2ZmIHRvIHRoZSBEZXRO ZXQgV0cgYXMgdGhleSBiZSBpbnRlcmVzdGVkIGluIHVzaW5nIHRoaXMgYXQgc29tZSBwb2ludCBh bmQgYXJlIGxpa2VseSB0byBoYXZlIHNvbWUgZm9sa3Mgd2l0aCAxNTg4IGtub3dsZWRnZS4gDQo+ DQo+IFRoZSBmb2xsb3dpbmcgY29tbWVudCBpcyBpbmRlcGVuZGVudCBvZiB3aGljaCBMU0EgdHlw ZXMgYXJlIHVzZWQsIGFzIGRpc2N1c3NlZCBiZWxvdywgYnV0IG90aGVycyBtYXkgZmVlbCBpdCBp bXBhY3RzIHRoZSBjaG9pY2UuDQo+DQo+IFNob3VsZCB0aGUgc29sdXRpb24gcmVhbGx5IHNjb3Bl ZCB0byBqdXN0IFJTVlAgY29udHJvbGxlZCBURSBMU1BzPyAgSXQgc2VlbXMgdG8gbWUgaXQgc2hv dWxkIHdvcmsgZm9yIGFueSBURSBMU1AsIGFuZCBhbnkgVEUgTFNQIHNldHVwIG1lY2hhbmlzbSB0 aGF0IGNhbiBwcm92aWRlIHRoZSBwYXJ0aWNpcGF0aW5nIG5vZGVzIHdpdGggdGhlIHJlcXVpcmVk IGluZm9ybWF0aW9uLiAgRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+DQo+IEkgdGhpbmsgdGhlIGZv bGxvd2luZyBjaGFuZ2VzIGFyZSBvbmUgd2F5IHRvIG1ha2UgdGhpcyBjaGFuZ2U6DQo+IE9MRA0K Pg0KPiAgICAgVGhlIHNjb3BlIG9mDQo+ICAgIHRoaXMgZG9jdW1lbnQgaXMgb24gTFNQcyBpbnN0 YW50aWF0ZWQgdXNpbmcgUlNWUC1URSBbUkZDMzIwOSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzMyMDk+XSBiZWNhdXNlDQo+ICAgIHRoZSBMU1AncyBwYXRoIGNhbiBiZSBkZXRlcm1p bmVkLg0KPiBORVcNCj4NCj4gICAgIFRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGlzIG9uIFRF IExTUHMsIGUuZy4sIHRob3NlICBpbnN0YW50aWF0ZWQgdXNpbmcNCj4gICAgICBSU1ZQLVRFIFtS RkMzMjA5IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwOT5dLCBiZWNhdXNlIHRo ZSBMU1AncyBwYXRoIGNhbiBiZSBkZXRlcm1pbmVkLg0KPg0KPiBBbmQgYWRkIHRleHQgdGhhdCBk ZXNjcmliZXMgdGhlIGZvbGxvd2luZyBpbiBhIG5ldyBzZWN0aW9uLCBwZXJoYXBzIGF0DQo+IDQu NiBvciA0LjggIk5vbi1SU1ZQIGNvbnRyb2xsZWQgTFNQcyINCj4gICBXaGVuIHRoZSBURSBMU1Ag aXMgY29udHJvbGxlZCB2aWEgbWVjaGFuaXNtcyBvdGhlciB0aGFuIFJTVlAtVEUsIHRoZSBmb2xs b3dpbmcgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gdGhlIFJUTSBjYXBhYmxl IG5vZGVzIGFsb25nIHRoZSBMU1AgcGF0aDoNCj4gICAgLSBSVE0gcm9sZSAoaW5ncmVzcywgdHJh bnNpdCwgZWdyZXNzKQ0KPiAgICAtIFJUTSBuZWlnaGJvcnMNCj4gICAgLSBSVE0gaG9wIGNvdW50 cyAoYXMgbmVlZGVkKQ0KPiAgIC0gQW55dGhpbmcgZWxzZSBJJ20gc3VyZSBJIG1pc3NlZCENCj4g ICBUaGUgbWV0aG9kIHVzZWQgdG8gY29udmV5IHRoaXMgaW5mb3JtYXRpb24gaXMgb3V0IG9mIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+DQo+IEkgaGF2ZSBhbiBSU1ZQIHNwZWNpZmljIGNvbW1l bnQgdGhhdCBJJ2xsIHNlbmQgc2VwYXJhdGVseS4NCj4NCj4gVGhhbmtzLA0KPiBMb3UNCj4NCj4g UFMgSSB0aGluayB0aGlzIGlzIGltcG9ydGFudCB3b3JrIGFuZCBob3BlIHRvIHNlZSBpdCBjb21w bGV0ZWQgc29vbi4NCj4NCj4gT24gMS8zMS8yMDE2IDc6NTAgQU0sIEFjZWUgTGluZGVtIChhY2Vl KSB3cm90ZToNCj4+IEhpIEdyZWcsDQo+PiBUaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCBwbGFuLg0K Pj4gVGhhbmtzLA0KPj4gQWNlZQ0KPj4NCj4+IE9uIDEvMzAvMTYsIDg6MzYgUE0sICJHcmVnb3J5 IE1pcnNreSIgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IEhp IEFjZWUsDQo+Pj4gdGhhbmsgeW91IGZvciB5b3VyIHRob3JvdWdoIHJldmlldyBhbmQgT1NQRiBp bnNpZ2h0cy4NCj4+PiBJJ3ZlIHVwZGF0ZWQgcmVmZXJlbmNlIHRvIFJGQyA3Njg0IGluIHRoZSBu ZXcgLTAxIHZlcnNpb24uDQo+Pj4gV2hlbiB3ZSB3ZXJlIHN0YXJ0aW5nIHdvcmsgb24gUlRNIHdl IGludGVuZGVkIHRvIGFkZHJlc3MgTERQIA0KPj4+IHNpZ25hbGVkIElQL01QTFMgbmV0d29ya3Mg YXMgd2VsbCBhbmQgdGhhdCwgYXMgSSByZWNhbGwsIHdhcyB0aGUgDQo+Pj4gcmVhc29uIHRvIHVz ZSBtb3JlIGdlbmVyaWMgSUdQIFRMVnMgcmF0aGVyIHRoYW4gVEUtc3BlY2lmaWMuIFNpbmNlIA0K Pj4+IExEUCBkcmlmdGVkIG91dCBvZiBzY29wZSwgSSBhZ3JlZSwgdXNlIG9mIFRFIGFkdmVydGlz ZW1lbnRzIGlzIG1vcmUgDQo+Pj4gc3VpdGFibGUuIFdlJ2xsIHdvcmsgb24gdGhhdCBhbmQgc2hh cmUgbmV3IHVwZGF0ZSB3aXRoIHlvdSBhbmQgdGhlIElHUCBXR3MuDQo+Pj4NCj4+PiAJUmVnYXJk cywNCj4+PiAJCUdyZWcNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4g RnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFj ZWUgTGluZGVtDQo+Pj4gKGFjZWUpDQo+Pj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjgsIDIw MTYgNDo1NSBQTQ0KPj4+IFRvOiBMb2EgQW5kZXJzc29uDQo+Pj4gQ2M6IG1wbHNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUB0b29scy5pZXRmLm9yZw0KPj4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGllbmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJh ZnQNCj4+Pg0KPj4+IEnigJl2ZSByZWFkIHRoZSBzdWJqZWN0IGRyYWZ0IGFuZCB0aGluayBpdCBv ZmZlcnMgYSB1c2VmdWwgZnVuY3Rpb24gdG8gDQo+Pj4gZmFjaWxpdGF0ZSBtb3JlIGFjY3VyYXRl IHRpbWUgc3luY2hyb25pemF0aW9uIGluIE5UUC9QVFAgZGVwbG95bWVudHMuDQo+Pj4gT25lIHF1 ZXN0aW9uIEkgaGF2ZSBpcyB3aHkgdGhlIGNhcGFiaWxpdHkgaXMgc2lnbmFsZWQgaW4gdGhlIGdl bmVyaWMgDQo+Pj4gSUdQIFRMViBMU0FzIGFuZCBMU1BzIHJhdGhlciB0aGFuIHRoZSBURSBhZHZl cnRpc2VtZW50cyB3aGVuIHRoZSANCj4+PiBkb2N1bWVudCBpcyBzY29wZWQgdG8gUlNWUC1URSBb UkZDMzIwOV0gTFNQcz8gT25lIHJlYXNvbiBJIGFzayBpcyANCj4+PiB0aGF0IHdlIGFyZSB3YWl0 aW5nIG9uIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgT1NQRnYzIEV4dGVuZGVkIExTQXMgDQo+Pj4g ZHJhZnQuIEhhdmluZyBzYWlkIHRoYXQsDQo+Pj4gT1NQRnYyIGFuZCBPU1BGdjMgaGF2ZSBzZXBh cmF0ZSByZWdpc3RyeSBmb3IgdGhlIFRMViBMU0FzIGFuZCANCj4+PiBzZWN0aW9uDQo+Pj4gOCBz aG91bGQgcmVmbGVjdCB0aGlzLiBBbHNvLCBPU1BGIFByZWZpeC9MaW5rIEF0dHJpYnV0ZXMgaXMg bm93IFJGQyA3Njg0Lg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IEFjZWUNCj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBw aS5udV0NCj4+Pj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNCwgMjAxNSA3OjIzIFBNDQo+Pj4+ IFRvOiBHcmVnb3J5IE1pcnNreTsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcN Cj4+Pj4gQ2M6IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUB0b29scy5pZXRmLm9yZw0K Pj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIFByb2dyZXNzaW5nIFJlc2RpZW5jZSBUaW1lIE1lYXN1 cmVtZW50IGRyYWZ0IA0KPj4+PiBXb3JraW5nIEdyb3VwIGFuZCBhdXRob3JzLCA8Y2hhaXIgaGF0 IG9mZj4gQXMgYSBtYXR0ZXIgb2YgZmFjdCBJIA0KPj4+PiBiZWxpZXZlIHRoaXMgZG9jdW1lbnQg c2hvdWxkIGJlIHByb2dyZXNzZWQuDQo+Pj4+IDxjaGFpciBoYXQgb24+DQo+Pj4+IFRoaXMgZHJh ZnQgaGFzIGJlZW4gYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHNpbmNlIGVhcmx5IEF1Z3VzdCwg DQo+Pj4+IGJ1dCB0aGVyZSBoYXMgYmVlbiBubyBkaXNjdXNzaW9uIG9uIHRoZSBkb2N1bWVudCBv biB0aGUgd2cgbWFpbGluZyBsaXN0Lg0KPj4+PiBUaGVyZSBhcmUgb2YgY291cnNlIHR3byB3YXlz IGlmIGludGVycHJldGluZyB0aGlzLg0KPj4+PiAtIHRoZXJlIGlzIHRvdGFsIGFncmVlbWVudCBv biB0aGUgZHJhZnQNCj4+Pj4gLSB0aGVyZSBpcyBubyBpbnRyZXN0IGluIHRoZSBkcmFmdA0KPj4+ PiBJIGhhdmUgbm8gYmFzaXMgdG8gZGVjaWRlIHdoaWNoIGlzIHRoZSBjYXNlLg0KPj4+PiBDYW4g d2UgcGxlc2UgaGF2ZSBhdCBsZWFzdCBhIGZldyAobm9uLWF1dGhvcikgY29tbWVudHMgb24gdGhl IA0KPj4+PiBtYWlsaW5nIGxpc3QgaWYgaXQgaXMgdGltZSB0byBzdGFydCB0aGUgd2dsYy4NCj4+ Pj4gL0xvYQ0KPj4+PiBtcGxzIHdnIGNvLWNoYWlyDQo+Pj4+IE9uIDIwMTUtMTItMTUgMDc6MjEs IEdyZWdvcnkgTWlyc2t5IHdyb3RlOg0KPj4+PiBEZWFyIENoYWlycyBvZiB0aGUgTVBMUyBXRywN Cj4+Pj4+IGF1dGhvcnMgb2YgdGhlIFJlc2lkZW5jZSBUaW1lIE1lYXN1cmVtZW50IGluIE1QTFMg TmV0d29yayBkcmFmdCANCj4+Pj4+IGJlbGlldmUgdGhhdCBhbGwgY29tbWVudHMgcmVjZWl2ZWQg ZHVyaW5nIHRoZSBXRyBhZG9wdGlvbiBjYWxsIA0KPj4+Pj4gYmVlbiBhZGRyZXNzZWQuDQo+Pj4+ PiBUaHVzLCBhdXRob3JzIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBXRyBDaGFpcnMgdG8gY29uc2lk ZXIgV0cgTEMgYXMgDQo+Pj4+PiB0aGUgbmV4dCBzdGVwLg0KPj4+Pj4gICAgICAgICAgICAgICAg IFJlZ2FyZHMsDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcgDQo+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+ PiBtcGxzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KDQoNCg== From nobody Sun Jan 31 13:37:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61671B2D96; Sun, 31 Jan 2016 13:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wNC7iKY6kFl; Sun, 31 Jan 2016 13:37:44 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ACE1B2D94; Sun, 31 Jan 2016 13:37:43 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id 128so46245058wmz.1; Sun, 31 Jan 2016 13:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=oDoEWs2dg3FUc1VAcuX/o2ZBDpNyKiyA3G81Um1rva8=; b=fIALzQ0mu9j3pl32W3SodRKN8XJelmIqT+JD3lnG3bcFaczbUFlliw9yT1jk+4If4/ FugDSI43cpvTID+VqAWwDb6YhHHYr+OJNLe4KTmDYk6lLtT7Rdox/C2vqP/4jHbuToKb 5Yj6jGEy9q56a15g+tELeKKjd/rJ/7pydlDowstaAur4ZnbYpH9zA9bGM24XC+HJu+3I 2/BrBQyBNrIGtNod8rTkCIdlzrzKhaeNmm06pCvYZY36rhka7ijrGbEH6wYbZGEn6tOi 0a9uPyJs1d8aAqSvEUbaIPuvQqRW1ju9NOYP/Ab7NULApfcp08q6C0oluBOkVRM+4kdi EOjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=oDoEWs2dg3FUc1VAcuX/o2ZBDpNyKiyA3G81Um1rva8=; b=IvbZyJV07CfIgURWwWtw8oUN0d7tPouSPkApCxgVnoXI43TrhY0K4K7gdTumzvx8nC gB1pCPS2TCTSMO3S9cwQq/sFxZEaqsuBosYazEjV8uSvGZHYa7O/2FlFrPh7WDDxjAdZ fVDvVVXhW/L6aBJOh5ZC0oFJHnJNLscLGqM88f/pcJm6LVrjQ2e6lM2qSjQYCL4+Ecot VZMSrm4nJf9GnDgam3CJsHyKK928VjhDgKjKF3lmgC+/QO943+CO+UAqQQZoSikXj1+n oReHTIGRL2tbOPkilX4R9kBHEoeV7G3E1Zh13TCiP2vI3ov1XGydSudND+Q4MgDiD+92 2iPA== X-Gm-Message-State: AG10YOQboZdGjGhC4e9YnHVtg/+Tb1CDojixJJ/8MTovXFeqsuW/spAobpAgvsJGSL0MXg== X-Received: by 10.194.234.41 with SMTP id ub9mr19078113wjc.9.1454276262371; Sun, 31 Jan 2016 13:37:42 -0800 (PST) Received: from Martins-MBP-2.fritz.box ([2001:1a80:280c:a800:8d42:9464:bf21:603e]) by smtp.googlemail.com with ESMTPSA id ha9sm25972090wjc.3.2016.01.31.13.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jan 2016 13:37:41 -0800 (PST) To: Stewart Bryant References: <20160105214706.11111.8218.idtracker@ietfa.amsl.com> <56961B6C.3040705@gmail.com> <56A0C5D4.3080802@gmail.com> From: Martin Stiemerling Message-ID: <56AE7E9C.3060304@gmail.com> Date: Sun, 31 Jan 2016 22:37:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A0C5D4.3080802@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, The IESG , mpls-chairs@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 21:37:45 -0000 Hi Steward, Am 21.01.16 um 12:49 schrieb Stewart Bryant: > > The following text inserted as a new section between section 4 and 5 > will hopefully address your congestion concerns. > > 5. Congestion Considerations > > This protocol MUST be run in accordance the guidance provided in > [RFC5405]. As advised in section 3.2.1 of RFC5405, operators that wish > to run this protocol at rates in excess of one packet per three seconds > need to ensure that the MPLS path being monitored and any IP path that > may be used to carry the response are provisioned such that there is a > negligible chance of this protocol causing congestion. Additionally, if > a significant number of response packets are lost, the querier MUST > reduce the sending rate to a point where there is a negligible chance > that this protocol is contributing to network congestion. The operator > should also take precautions that response packets do not leak out of > the network domain being used and cause congestion elsewhere. If a > default IP address is configured by the equipment vendor, this MUST be > an address known to contain the response packet within the responder, > such as the IPv4 localhost address [RFC5735] or the IPv6 loopback > address [RFC4291]. A responder receiving a query specifying this as a > return address, and not being configured to expect such a return > address*, SHOULD notify the operator in a suitably rate limited manner. > > Add refs to RFC5405 (normative), RFC 5735 (informational) and RFC 4291 > (informational) > > > *Not part of RFC text - this might occur if the operator wanted a data > collector co-located on the responder, so it's better to specifically > allow it than have confusion as to whether it is allowed or not. Perfectly! I will clear once there is the updated draft. Thank you, Martin From nobody Sun Jan 31 17:28:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378BF1A87A1; Sun, 31 Jan 2016 17:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er2CvPaH8Ubg; Sun, 31 Jan 2016 17:28:04 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8CD1A879F; Sun, 31 Jan 2016 17:28:04 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-90-56aeb19b7263 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id DB.87.06940.B91BEA65; Mon, 1 Feb 2016 02:15:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Sun, 31 Jan 2016 20:28:02 -0500 From: Gregory Mirsky To: Lou Berger , Alexander Vainshtein Thread-Topic: [mpls] Progressing Residence Time Measurement draft Thread-Index: AdFcNrbbWd1Pf8ipTpKMdzi5VKrLgwALG8sAAAqnhAA= Date: Mon, 1 Feb 2016 01:28:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112219B9665@eusaamb103.ericsson.se> References: <56AE236C.8010005@labn.net> In-Reply-To: <56AE236C.8010005@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPoO7sjevCDF6ckrKY/HYes8XUrR+Y LQ5fOMVu0dH8lsXi39w5zBa3lq5kdWDzmPJ7I6vHpn/HGT2WLPnJ5PFhUzObx6zpbWwBrFFc NimpOZllqUX6dglcGTPuPGIseBVW0XT4O3sD45mQLkZODgkBE4mF3zvYIGwxiQv31gPZXBxC AkcYJd5+mMkK4SxnlDjZ/BGsik3ASOLFxh52EFtEIEbixYtVYEXMAvsYJQ41vWcBSQgLOEgs +9vNBFHkKHHzxEXmLkYOINtK4tjdTJAwi4CKxLKOu2DlvAK+Eg+2vwWbKSRQJbH3VBNYK6eA hsSBGZ/A9jICXff91BqwOLOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1YIW0ni4+/57CBrmQU0 Jdbv0odoVZSY0v2QHWKtoMTJmU9YJjCKzUIydRZCxywkHbOQdCxgZFnFyFFaXJCTm25ksIkR GGnHJNh0dzDen+55iFGAg1GJh3dD5LowIdbEsuLK3EOMEhzMSiK8T02AQrwpiZVVqUX58UWl OanFhxilOViUxHlteBeFCQmkJ5akZqemFqQWwWSZODilGhjV15ZIrY97unFy68/G1fO/lP+5 PyM3YHPXjEOHt/+7dOOuXwLH39iSpYsexV0t1E9umXbluNet231Flo39aRJHJ77x3XfLZh7X o7vSihXXk2O+7+KNzNQMSDq+/Emn5f285sxfBaf0tFcnFwhruaTK7pGS6T9hq7giYrFXy1Mx keNsnzmKu02VWIozEg21mIuKEwFTo+IKsAIAAA== Archived-At: Cc: "draft-ietf-mpls-residence-time@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Progressing Residence Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 01:28:07 -0000 SGkgTG91LA0KdGhhbmsgeW91IGZvciB5b3VyIHRob3JvdWdoIHJldmlldyBvZiBSVE0gYW5kIHRo b3VnaHRmdWwgY29tbWVudHMgb24gcHJvcG9zZWQgUlNWUC1URSBleHRlbnNpb24uIEdyZWF0bHkg YXBwcmVjaWF0ZSBoZWxwaW5nIHVzIHRvIHJlYWNoIHRvIERldE5ldCBjb21tdW5pdHkgZm9yIGNv bnNpZGVyYXRpb24gb2YgUlRNIGFuZCBoZWxwZnVsIGlucHV0cy4gUGxlYXNlIGZpbmQgbXkgbm90 ZXMgaW4tbGluZWQgYW5kIHRhZ2dlZCBHSU0+Pi4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2Vy QGxhYm4ubmV0XSANClNlbnQ6IFN1bmRheSwgSmFudWFyeSAzMSwgMjAxNiA3OjA4IEFNDQpUbzog QWxleGFuZGVyIFZhaW5zaHRlaW4NCkNjOiBtcGxzQGlldGYub3JnOyBBY2VlIExpbmRlbSAoYWNl ZSk7IEdyZWdvcnkgTWlyc2t5OyBMb2EgQW5kZXJzc29uOyBkcmFmdC1pZXRmLW1wbHMtcmVzaWRl bmNlLXRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzaWRl bmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJhZnQNCg0KU2FzaGEsDQogICAgU2VlIGJlbG93Lg0KDQpP biAxLzMxLzIwMTYgOTo1MCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IExvdSwN Cj4gRmlyc3Qgb2YgYWxsLCBsb3RzIG9mIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIC0gYm90aCBm b3Igb25lcyB5b3UgaGF2ZSBzZW50IGFuZCAtIGluIGFkdmFuY2UgLSBmb3Igb25lIGRlYWxpbmcg d2l0aCBSU1ZQLVRFIHRoYXQgeW91J3ZlIHByb21pc2VkIHRvIHNlbmQuDQo+DQo+IFNlY29uZCwg SSB3b25kZXIgd2hpY2ggVEUgTFNQcyBiZXlvbmQgb25lcyBzZXQgdXAgYnkgUlNWUC1URSBvbmVz IHlvdSBoYXZlIGluIG1pbmQuDQo+DQo+IElmICB5b3UgYXJlIHNwZWFraW5nIGFib3V0IHN0YXRp Y2FsbHkgY29uZmlndXJlZCBMU1BzIChhbmQgdGhlc2UsIGluIGEgd2F5LCBhcmUgYWx3YXlzIFRF IExTUHMpLCBJIGRvIG5vdCBmb3Jlc2VlIGFueSBwcm9ibGVtIHdpdGggZXh0ZW5kaW5nIFJUTSB0 byB0aGVtLg0KWWVzLiAgT3IgY29udHJvbGxlciBiYXNlZC4NCkdJTT4+IFdvdWxkIHlvdSBzdWdn ZXN0IHRvIGNvbnNpZGVyIGV4dGVuc2lvbiB0byBQQ0VQIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhh dCBjb3VsZCBiZSBpbiB0aGUgbmV3IGRvY3VtZW50Pw0KDQo+IElmLCBob3dldmVyLCB5b3UgYXJl IHNwZWFraW5nIGFib3V0IExTUHMgdGhhdCBoYXZlIGJlZW4gc2V0IHVwIHVzaW5nIFNlZ21lbnQg Um91dGluZyAoU1IpLCBJIGRvdWJ0IFJUTSBjYW4gd29yayB3aXRoIHRoZXNlIGJlY2F1c2UgdGhl c2UgTFNQcyBjb3VsZCAoYW5kLCBtb3N0IHByb2JhYmx5LCBwcm9iYWJseSB3b3VsZCkgaW5jbHVk ZSBtdWx0aXBsZSBFQ01QIHN1Yi1wYXRocyBiZXR3ZWVuIHNwZWNpZmljICJwaW5uZWQiIG5vZGVz Lg0KSGF2ZW4ndCByZWFsbHkgZHVnIGluIGVub3VnaCBvbiBTUiB0byBoYXZlIGFuIG9waW5pb24u Li4NCkdJTT4+IFNSIGlzIHZlcnkgaW50ZXJlc3Rpbmcgc2NlbmFyaW8gYW5kIG1heSBiZSB0aGUg anVzdGlmaWNhdGlvbiB0byB1c2UgZ2VuZXJpYyBJR1AgVExWIHRvIGFkdmVydGlzZSBSVE0gY2Fw YWJpbGl0eS4gQnV0IFJUTSBoYW5kbGluZyBpbiBTUiBkYXRhIHBsYW5lLCBhcyBJIHRoaW5rIG9m IGl0LCByZXF1aXJlcyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb24uIENvdWxkIHRoYXQgYmUgaW4g dGhlIG5ldyBkb2N1bWVudD8NCg0KPiBTbyBJIGFtIG5vdCBzdXJlIGV4dGVuZGluZyAoZXZlbiBh dCB0aGUgbGV2ZWwgb2YgYSBkZWNsYXJhdGlvbiB3aXRob3V0IHByb3ZpZGluZyBhbnkgZGV0YWls cykgYXBwbGljYWJpbGl0eSBvZiBSVFAgdG8gYWxsIFRFIExTUHMgaXMgdGhlIHJpZ2h0IHdheSB0 byBnby4NCg0KSSB0aGluayB0aGUgZnVsbHkgcGlubmVkL0VSIGNhc2Ugc2hvdWxkIGJlIGNvdmVy ZWQgLS0gYW5kIHRoYXQncyB3aGF0IEkgd2FzIHJlYWxseSB0cnlpbmcgdG8gcmVmZXIgdG8uIA0K R0lNPj4gSSB0aGluayB0aGF0IGZ1bGx5IEVSIHBhdGggd291bGQgcHJvdmlkZSB0aGUgYmVzdCBy ZXN1bHQgZm9yIFBUUCBhbmQgdGh1cyBSVE0gYnV0IHBpbm5pbmcgUlRNLWNhcGFibGUgbm9kZXMg d2l0aCBsb29zZWx5LXJvdXRlZCBzZWdtZW50cyBpbiBiZXR3ZWVuIG1heSBzdGlsbCBiZSB1c2Vm dWwgc2NlbmFyaW8uIEknbGwgYXNrIFN0ZWZhbm8gdG8gY29tbWVudCBvbiB0aGF0IGZyb20gUFRQ IHBvaW50IG9mIHZpZXcuDQoNClRoYW5rcywNCkxvdQ0KDQo+IFJlZ2FyZHMsDQo+IFNhc2hhDQo+ DQo+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPiBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQo+ IEVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+DQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxh Ym4ubmV0XQ0KPiBTZW50OiBTdW5kYXksIEphbnVhcnkgMzEsIDIwMTYgNDoyNyBQTQ0KPiBUbzog QWNlZSBMaW5kZW0gKGFjZWUpOyBHcmVnb3J5IE1pcnNreTsgTG9hIEFuZGVyc3NvbjsgDQo+IGRy YWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUBpZXRmLm9yZw0KPiBDYzogbXBsc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIFByb2dyZXNzaW5nIFJlc2RpZW5jZSBUaW1lIE1lYXN1 cmVtZW50IGRyYWZ0DQo+DQo+IFNvIHRoaXMgdGhyZWFkIHRyaWdnZXJlZCBtZSB0byByZXJlYWQg dGhlIGRyYWZ0LiAgSSBkb24ndCByZWFsbHkgaGF2ZSBhbnkgdGltZSBzeW5jIGV4cGVyaWVuY2Us IHNvIHdvbid0IGJlIGNvbW1lbnRpbmcgb24gdGhvc2UgYXNwZWN0cyBvZiB0aGUgZHJhZnQgLSBi dXQgSSBkaWQganVzdCBzZW5kIGEgbWVzc2FnZSBvZmYgdG8gdGhlIERldE5ldCBXRyBhcyB0aGV5 IGJlIGludGVyZXN0ZWQgaW4gdXNpbmcgdGhpcyBhdCBzb21lIHBvaW50IGFuZCBhcmUgbGlrZWx5 IHRvIGhhdmUgc29tZSBmb2xrcyB3aXRoIDE1ODgga25vd2xlZGdlLiANCj4NCj4gVGhlIGZvbGxv d2luZyBjb21tZW50IGlzIGluZGVwZW5kZW50IG9mIHdoaWNoIExTQSB0eXBlcyBhcmUgdXNlZCwg YXMgZGlzY3Vzc2VkIGJlbG93LCBidXQgb3RoZXJzIG1heSBmZWVsIGl0IGltcGFjdHMgdGhlIGNo b2ljZS4NCj4NCj4gU2hvdWxkIHRoZSBzb2x1dGlvbiByZWFsbHkgc2NvcGVkIHRvIGp1c3QgUlNW UCBjb250cm9sbGVkIFRFIExTUHM/ICBJdCBzZWVtcyB0byBtZSBpdCBzaG91bGQgd29yayBmb3Ig YW55IFRFIExTUCwgYW5kIGFueSBURSBMU1Agc2V0dXAgbWVjaGFuaXNtIHRoYXQgY2FuIHByb3Zp ZGUgdGhlIHBhcnRpY2lwYXRpbmcgbm9kZXMgd2l0aCB0aGUgcmVxdWlyZWQgaW5mb3JtYXRpb24u ICBEb2VzIHRoaXMgbWFrZSBzZW5zZT8NCj4NCj4gSSB0aGluayB0aGUgZm9sbG93aW5nIGNoYW5n ZXMgYXJlIG9uZSB3YXkgdG8gbWFrZSB0aGlzIGNoYW5nZToNCj4gT0xEDQo+DQo+ICAgICBUaGUg c2NvcGUgb2YNCj4gICAgdGhpcyBkb2N1bWVudCBpcyBvbiBMU1BzIGluc3RhbnRpYXRlZCB1c2lu ZyBSU1ZQLVRFIFtSRkMzMjA5IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwOT5d IGJlY2F1c2UNCj4gICAgdGhlIExTUCdzIHBhdGggY2FuIGJlIGRldGVybWluZWQuDQo+IE5FVw0K Pg0KPiAgICAgVGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgaXMgb24gVEUgTFNQcywgZS5nLiwg dGhvc2UgIGluc3RhbnRpYXRlZCB1c2luZw0KPiAgICAgIFJTVlAtVEUgW1JGQzMyMDkgPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjA5Pl0sIGJlY2F1c2UgdGhlIExTUCdzIHBhdGgg Y2FuIGJlIGRldGVybWluZWQuDQo+DQo+IEFuZCBhZGQgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUg Zm9sbG93aW5nIGluIGEgbmV3IHNlY3Rpb24sIHBlcmhhcHMgYXQNCj4gNC42IG9yIDQuOCAiTm9u LVJTVlAgY29udHJvbGxlZCBMU1BzIg0KPiAgIFdoZW4gdGhlIFRFIExTUCBpcyBjb250cm9sbGVk IHZpYSBtZWNoYW5pc21zIG90aGVyIHRoYW4gUlNWUC1URSwgdGhlIGZvbGxvd2luZyBpbmZvcm1h dGlvbiBuZWVkcyB0byBiZSBwcm92aWRlZCB0byB0aGUgUlRNIGNhcGFibGUgbm9kZXMgYWxvbmcg dGhlIExTUCBwYXRoOg0KPiAgICAtIFJUTSByb2xlIChpbmdyZXNzLCB0cmFuc2l0LCBlZ3Jlc3Mp DQo+ICAgIC0gUlRNIG5laWdoYm9ycw0KPiAgICAtIFJUTSBob3AgY291bnRzIChhcyBuZWVkZWQp DQo+ICAgLSBBbnl0aGluZyBlbHNlIEknbSBzdXJlIEkgbWlzc2VkIQ0KPiAgIFRoZSBtZXRob2Qg dXNlZCB0byBjb252ZXkgdGhpcyBpbmZvcm1hdGlvbiBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBk b2N1bWVudC4NCj4NCj4gSSBoYXZlIGFuIFJTVlAgc3BlY2lmaWMgY29tbWVudCB0aGF0IEknbGwg c2VuZCBzZXBhcmF0ZWx5Lg0KPg0KPiBUaGFua3MsDQo+IExvdQ0KPg0KPiBQUyBJIHRoaW5rIHRo aXMgaXMgaW1wb3J0YW50IHdvcmsgYW5kIGhvcGUgdG8gc2VlIGl0IGNvbXBsZXRlZCBzb29uLg0K Pg0KPiBPbiAxLzMxLzIwMTYgNzo1MCBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4g SGkgR3JlZywNCj4+IFRoYXQgc291bmRzIGxpa2UgYSBnb29kIHBsYW4uDQo+PiBUaGFua3MsDQo+ PiBBY2VlDQo+Pg0KPj4gT24gMS8zMC8xNiwgODozNiBQTSwgIkdyZWdvcnkgTWlyc2t5IiA8Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+Pj4gSGkgQWNlZSwNCj4+PiB0 aGFuayB5b3UgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3IGFuZCBPU1BGIGluc2lnaHRzLg0KPj4+ IEkndmUgdXBkYXRlZCByZWZlcmVuY2UgdG8gUkZDIDc2ODQgaW4gdGhlIG5ldyAtMDEgdmVyc2lv bi4NCj4+PiBXaGVuIHdlIHdlcmUgc3RhcnRpbmcgd29yayBvbiBSVE0gd2UgaW50ZW5kZWQgdG8g YWRkcmVzcyBMRFAgDQo+Pj4gc2lnbmFsZWQgSVAvTVBMUyBuZXR3b3JrcyBhcyB3ZWxsIGFuZCB0 aGF0LCBhcyBJIHJlY2FsbCwgd2FzIHRoZSANCj4+PiByZWFzb24gdG8gdXNlIG1vcmUgZ2VuZXJp YyBJR1AgVExWcyByYXRoZXIgdGhhbiBURS1zcGVjaWZpYy4gU2luY2UgDQo+Pj4gTERQIGRyaWZ0 ZWQgb3V0IG9mIHNjb3BlLCBJIGFncmVlLCB1c2Ugb2YgVEUgYWR2ZXJ0aXNlbWVudHMgaXMgbW9y ZSANCj4+PiBzdWl0YWJsZS4gV2UnbGwgd29yayBvbiB0aGF0IGFuZCBzaGFyZSBuZXcgdXBkYXRl IHdpdGggeW91IGFuZCB0aGUgSUdQIFdHcy4NCj4+Pg0KPj4+IAlSZWdhcmRzLA0KPj4+IAkJR3Jl Zw0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBtcGxzIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0NCj4+ PiAoYWNlZSkNCj4+PiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOCwgMjAxNiA0OjU1IFBNDQo+ Pj4gVG86IExvYSBBbmRlcnNzb24NCj4+PiBDYzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1t cGxzLXJlc2lkZW5jZS10aW1lQHRvb2xzLmlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFttcGxz XSBQcm9ncmVzc2luZyBSZXNkaWVuY2UgVGltZSBNZWFzdXJlbWVudCBkcmFmdA0KPj4+DQo+Pj4g SeKAmXZlIHJlYWQgdGhlIHN1YmplY3QgZHJhZnQgYW5kIHRoaW5rIGl0IG9mZmVycyBhIHVzZWZ1 bCBmdW5jdGlvbiB0byANCj4+PiBmYWNpbGl0YXRlIG1vcmUgYWNjdXJhdGUgdGltZSBzeW5jaHJv bml6YXRpb24gaW4gTlRQL1BUUCBkZXBsb3ltZW50cy4NCj4+PiBPbmUgcXVlc3Rpb24gSSBoYXZl IGlzIHdoeSB0aGUgY2FwYWJpbGl0eSBpcyBzaWduYWxlZCBpbiB0aGUgZ2VuZXJpYyANCj4+PiBJ R1AgVExWIExTQXMgYW5kIExTUHMgcmF0aGVyIHRoYW4gdGhlIFRFIGFkdmVydGlzZW1lbnRzIHdo ZW4gdGhlIA0KPj4+IGRvY3VtZW50IGlzIHNjb3BlZCB0byBSU1ZQLVRFIFtSRkMzMjA5XSBMU1Bz PyBPbmUgcmVhc29uIEkgYXNrIGlzIA0KPj4+IHRoYXQgd2UgYXJlIHdhaXRpbmcgb24gaW1wbGVt ZW50YXRpb25zIG9mIHRoZSBPU1BGdjMgRXh0ZW5kZWQgTFNBcyANCj4+PiBkcmFmdC4gSGF2aW5n IHNhaWQgdGhhdCwNCj4+PiBPU1BGdjIgYW5kIE9TUEZ2MyBoYXZlIHNlcGFyYXRlIHJlZ2lzdHJ5 IGZvciB0aGUgVExWIExTQXMgYW5kIA0KPj4+IHNlY3Rpb24NCj4+PiA4IHNob3VsZCByZWZsZWN0 IHRoaXMuIEFsc28sIE9TUEYgUHJlZml4L0xpbmsgQXR0cmlidXRlcyBpcyBub3cgUkZDIDc2ODQu DQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gQWNlZQ0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+PiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPj4+PiBT ZW50OiBNb25kYXksIERlY2VtYmVyIDE0LCAyMDE1IDc6MjMgUE0NCj4+Pj4gVG86IEdyZWdvcnkg TWlyc2t5OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPj4+PiBDYzogZHJh ZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lQHRvb2xzLmlldGYub3JnDQo+Pj4+IFN1YmplY3Q6 IFJlOiBbbXBsc10gUHJvZ3Jlc3NpbmcgUmVzZGllbmNlIFRpbWUgTWVhc3VyZW1lbnQgZHJhZnQg DQo+Pj4+IFdvcmtpbmcgR3JvdXAgYW5kIGF1dGhvcnMsIDxjaGFpciBoYXQgb2ZmPiBBcyBhIG1h dHRlciBvZiBmYWN0IEkgDQo+Pj4+IGJlbGlldmUgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgcHJv Z3Jlc3NlZC4NCj4+Pj4gPGNoYWlyIGhhdCBvbj4NCj4+Pj4gVGhpcyBkcmFmdCBoYXMgYmVlbiBh IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgc2luY2UgZWFybHkgQXVndXN0LCANCj4+Pj4gYnV0IHRo ZXJlIGhhcyBiZWVuIG5vIGRpc2N1c3Npb24gb24gdGhlIGRvY3VtZW50IG9uIHRoZSB3ZyBtYWls aW5nIGxpc3QuDQo+Pj4+IFRoZXJlIGFyZSBvZiBjb3Vyc2UgdHdvIHdheXMgaWYgaW50ZXJwcmV0 aW5nIHRoaXMuDQo+Pj4+IC0gdGhlcmUgaXMgdG90YWwgYWdyZWVtZW50IG9uIHRoZSBkcmFmdA0K Pj4+PiAtIHRoZXJlIGlzIG5vIGludHJlc3QgaW4gdGhlIGRyYWZ0DQo+Pj4+IEkgaGF2ZSBubyBi YXNpcyB0byBkZWNpZGUgd2hpY2ggaXMgdGhlIGNhc2UuDQo+Pj4+IENhbiB3ZSBwbGVzZSBoYXZl IGF0IGxlYXN0IGEgZmV3IChub24tYXV0aG9yKSBjb21tZW50cyBvbiB0aGUgDQo+Pj4+IG1haWxp bmcgbGlzdCBpZiBpdCBpcyB0aW1lIHRvIHN0YXJ0IHRoZSB3Z2xjLg0KPj4+PiAvTG9hDQo+Pj4+ IG1wbHMgd2cgY28tY2hhaXINCj4+Pj4gT24gMjAxNS0xMi0xNSAwNzoyMSwgR3JlZ29yeSBNaXJz a3kgd3JvdGU6DQo+Pj4+IERlYXIgQ2hhaXJzIG9mIHRoZSBNUExTIFdHLA0KPj4+Pj4gYXV0aG9y cyBvZiB0aGUgUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQgaW4gTVBMUyBOZXR3b3JrIGRyYWZ0 IA0KPj4+Pj4gYmVsaWV2ZSB0aGF0IGFsbCBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIFdH IGFkb3B0aW9uIGNhbGwgDQo+Pj4+PiBiZWVuIGFkZHJlc3NlZC4NCj4+Pj4+IFRodXMsIGF1dGhv cnMgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIENoYWlycyB0byBjb25zaWRlciBXRyBMQyBhcyAN Cj4+Pj4+IHRoZSBuZXh0IHN0ZXAuDQo+Pj4+PiAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZyANCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBtcGxzIG1haWxp bmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+IG1wbHNAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtcGxzIG1h aWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+DQoNCg0K From nobody Sun Jan 31 18:38:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747AE1A8895 for ; Sun, 31 Jan 2016 18:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgp21pFCweBU for ; Sun, 31 Jan 2016 18:38:49 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 232F21A8893 for ; Sun, 31 Jan 2016 18:38:48 -0800 (PST) Received: (qmail 29206 invoked by uid 0); 1 Feb 2016 02:38:46 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 1 Feb 2016 02:38:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Cqea1s00C2SSUrH01qedl5; Sun, 31 Jan 2016 19:38:45 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7aQ_Q-yQQ-AA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=IRDgFnn-AAAA:8 a=0FD05c-RAAAA:8 a=_VeMNle1_WDKi0L6hMAA:9 a=keXadQ7Acx8oY2k9:21 a=MkqXAaEH2ppRkKTq:21 a=QEXdDO2ut3YA:10 a=ZgsxABZQttoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=PmsqOgK3Irn0MsdbXWwEPfFR0qapJaVIJO8oj1LDxeg=; b=YvHTCjqjI48zmQKWSFTpEY9Wvg4n2auyEAw3FtvdB7oNPzFXrK/wLtnXSzOQ95QG006h/Lz829Or6VS1ghTh9nvyoLmTKSMopyPKrQYhkEA4aupxgvNI/hS0cErtsk9f; Received: from box313.bluehost.com ([69.89.31.113]:35162 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aQ4Nv-000302-DR; Sun, 31 Jan 2016 19:38:35 -0700 To: Gregory Mirsky , Alexander Vainshtein References: <56AE236C.8010005@labn.net> <7347100B5761DC41A166AC17F22DF112219B9665@eusaamb103.ericsson.se> From: Lou Berger Message-ID: <56AEC520.4070505@labn.net> Date: Sun, 31 Jan 2016 21:38:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF112219B9665@eusaamb103.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-ietf-mpls-residence-time@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Progressing Residence Time Measurement draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 02:38:51 -0000 Greg, See below. On 1/31/2016 8:28 PM, Gregory Mirsky wrote: > Hi Lou, > thank you for your thorough review of RTM and thoughtful comments on proposed RSVP-TE extension. Greatly appreciate helping us to reach to DetNet community for consideration of RTM and helpful inputs. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Sunday, January 31, 2016 7:08 AM > To: Alexander Vainshtein > Cc: mpls@ietf.org; Acee Lindem (acee); Gregory Mirsky; Loa Andersson; draft-ietf-mpls-residence-time@ietf.org > Subject: Re: [mpls] Progressing Residence Time Measurement draft > > Sasha, > See below. > > On 1/31/2016 9:50 AM, Alexander Vainshtein wrote: >> Lou, >> First of all, lots of thanks for the comments - both for ones you have sent and - in advance - for one dealing with RSVP-TE that you've promised to send. >> >> Second, I wonder which TE LSPs beyond ones set up by RSVP-TE ones you have in mind. >> >> If you are speaking about statically configured LSPs (and these, in a way, are always TE LSPs), I do not foresee any problem with extending RTM to them. > Yes. Or controller based. > GIM>> Would you suggest to consider extension to PCEP in this document or that could be in the new document? I think a new document. This document should just allow for it and at most suggest it as an example. (Personal opinion.) > >> If, however, you are speaking about LSPs that have been set up using Segment Routing (SR), I doubt RTM can work with these because these LSPs could (and, most probably, probably would) include multiple ECMP sub-paths between specific "pinned" nodes. > Haven't really dug in enough on SR to have an opinion... > GIM>> SR is very interesting scenario and may be the justification to use generic IGP TLV to advertise RTM capability. But RTM handling in SR data plane, as I think of it, requires additional consideration. Could that be in the new document? Same answer. But feel more strongly on this one. Thanks, Lou >> So I am not sure extending (even at the level of a declaration without providing any details) applicability of RTP to all TE LSPs is the right way to go. > I think the fully pinned/ER case should be covered -- and that's what I was really trying to refer to. > GIM>> I think that fully ER path would provide the best result for PTP and thus RTM but pinning RTM-capable nodes with loosely-routed segments in between may still be useful scenario. I'll ask Stefano to comment on that from PTP point of view. > > Thanks, > Lou > >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Sunday, January 31, 2016 4:27 PM >> To: Acee Lindem (acee); Gregory Mirsky; Loa Andersson; >> draft-ietf-mpls-residence-time@ietf.org >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >> >> So this thread triggered me to reread the draft. I don't really have any time sync experience, so won't be commenting on those aspects of the draft - but I did just send a message off to the DetNet WG as they be interested in using this at some point and are likely to have some folks with 1588 knowledge. >> >> The following comment is independent of which LSA types are used, as discussed below, but others may feel it impacts the choice. >> >> Should the solution really scoped to just RSVP controlled TE LSPs? It seems to me it should work for any TE LSP, and any TE LSP setup mechanism that can provide the participating nodes with the required information. Does this make sense? >> >> I think the following changes are one way to make this change: >> OLD >> >> The scope of >> this document is on LSPs instantiated using RSVP-TE [RFC3209 ] because >> the LSP's path can be determined. >> NEW >> >> The scope of this document is on TE LSPs, e.g., those instantiated using >> RSVP-TE [RFC3209 ], because the LSP's path can be determined. >> >> And add text that describes the following in a new section, perhaps at >> 4.6 or 4.8 "Non-RSVP controlled LSPs" >> When the TE LSP is controlled via mechanisms other than RSVP-TE, the following information needs to be provided to the RTM capable nodes along the LSP path: >> - RTM role (ingress, transit, egress) >> - RTM neighbors >> - RTM hop counts (as needed) >> - Anything else I'm sure I missed! >> The method used to convey this information is out of scope of this document. >> >> I have an RSVP specific comment that I'll send separately. >> >> Thanks, >> Lou >> >> PS I think this is important work and hope to see it completed soon. >> >> On 1/31/2016 7:50 AM, Acee Lindem (acee) wrote: >>> Hi Greg, >>> That sounds like a good plan. >>> Thanks, >>> Acee >>> >>> On 1/30/16, 8:36 PM, "Gregory Mirsky" wrote: >>> >>>> Hi Acee, >>>> thank you for your thorough review and OSPF insights. >>>> I've updated reference to RFC 7684 in the new -01 version. >>>> When we were starting work on RTM we intended to address LDP >>>> signaled IP/MPLS networks as well and that, as I recall, was the >>>> reason to use more generic IGP TLVs rather than TE-specific. Since >>>> LDP drifted out of scope, I agree, use of TE advertisements is more >>>> suitable. We'll work on that and share new update with you and the IGP WGs. >>>> >>>> Regards, >>>> Greg >>>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Acee Lindem >>>> (acee) >>>> Sent: Thursday, January 28, 2016 4:55 PM >>>> To: Loa Andersson >>>> Cc: mpls@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org >>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >>>> >>>> I’ve read the subject draft and think it offers a useful function to >>>> facilitate more accurate time synchronization in NTP/PTP deployments. >>>> One question I have is why the capability is signaled in the generic >>>> IGP TLV LSAs and LSPs rather than the TE advertisements when the >>>> document is scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is >>>> that we are waiting on implementations of the OSPFv3 Extended LSAs >>>> draft. Having said that, >>>> OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and >>>> section >>>> 8 should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684. >>>> >>>> Thanks, >>>> Acee >>>>> -----Original Message----- >>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Monday, December 14, 2015 7:23 PM >>>>> To: Gregory Mirsky; mpls-chairs@ietf.org; mpls@ietf.org >>>>> Cc: draft-ietf-mpls-residence-time@tools.ietf.org >>>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft >>>>> Working Group and authors, As a matter of fact I >>>>> believe this document should be progressed. >>>>> >>>>> This draft has been a working group document since early August, >>>>> but there has been no discussion on the document on the wg mailing list. >>>>> There are of course two ways if interpreting this. >>>>> - there is total agreement on the draft >>>>> - there is no intrest in the draft >>>>> I have no basis to decide which is the case. >>>>> Can we plese have at least a few (non-author) comments on the >>>>> mailing list if it is time to start the wglc. >>>>> /Loa >>>>> mpls wg co-chair >>>>> On 2015-12-15 07:21, Gregory Mirsky wrote: >>>>> Dear Chairs of the MPLS WG, >>>>>> authors of the Residence Time Measurement in MPLS Network draft >>>>>> believe that all comments received during the WG adoption call >>>>>> been addressed. >>>>>> Thus, authors would like to ask the WG Chairs to consider WG LC as >>>>>> the next step. >>>>>> Regards, >>>>>> Greg >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > From nobody Sun Jan 31 22:25:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91A1ACE37; Sun, 31 Jan 2016 22:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRyNA7Wo3I8n; Sun, 31 Jan 2016 22:25:39 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34C31ACE3C; Sun, 31 Jan 2016 22:25:39 -0800 (PST) Received: from [192.168.1.13] (unknown [49.149.222.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 84BDC180137F; Mon, 1 Feb 2016 07:25:36 +0100 (CET) To: "mpls@ietf.org" References: <5694D729.5000505@pi.nu> From: Loa Andersson Message-ID: <56AEFA53.5000301@pi.nu> Date: Mon, 1 Feb 2016 14:25:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5694D729.5000505@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: [mpls] Closed - Re: Poll to see if we have consensus to adopt draft-cui-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:25:41 -0000 Working, My apologies - I thought I missed on response on the IPR poll, but after checking the MPLS wg mailing list archive I found it :)! This poll for working group adoption is closed. We have a new working group document, could the authors please post a new version called draft-ietf-mpls-tp-mfp-use-case-and-requirements, with no other changes than file name and date. /Loa On 2016-01-12 18:36, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting draft-cui-mpls-tp-mfp- > use-case-and-requirements as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR disclosures against this document. > > We have an IPR poll running in parallel, his poll ends January 27, 2016; > or when the IPR poll has concluded if that is later than January 27. > > /Loa