From nobody Thu Feb 2 14:56:45 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7B12943E; Thu, 2 Feb 2017 14:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 o7KOYoKHfccz; Thu, 2 Feb 2017 14:56:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA7A129421; Thu, 2 Feb 2017 14:56:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C5931B81022; Thu, 2 Feb 2017 14:56:42 -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: <20170202225642.C5931B81022@rfc-editor.org> Date: Thu, 2 Feb 2017 14:56:42 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] STD 84, RFC 8077 on Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:56:44 -0000 A new Request for Comments is now available in online RFC libraries. STD 84 RFC 8077 Title: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) Author: L. Martini, Ed., G. Heron, Ed. Status: Standards Track Stream: IETF Date: February 2017 Mailbox: lmartini@monoski.com, giheron@cisco.com Pages: 35 Characters: 80972 Obsoletes: RFC 4447, RFC 6723 See Also: STD 84 I-D Tag: draft-ietf-pals-rfc4447bis-05.txt URL: https://www.rfc-editor.org/info/rfc8077 DOI: 10.17487/RFC8077 Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents. This document is a rewrite of RFC 4447 for publication as an Internet Standard. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now an Internet 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/retrieve/bulk 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 Feb 6 00:53:03 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E05129CB4 for ; Mon, 6 Feb 2017 00:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 duG_Uws3SWjt for ; Mon, 6 Feb 2017 00:53:00 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 EC4B6129CB2 for ; Mon, 6 Feb 2017 00:52:59 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id u143so43465767oif.3 for ; Mon, 06 Feb 2017 00:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fDARzXfF71XngqTxjhF39nAVVPWu27h3qzsoRgE4gS0=; b=i2mlHn7plETciRjJL5zZLXzgDkjUZeC2pBHq9Lvs2NZw0WpIDXlVoohrwIvoJe3FE4 Y+uUvNIKyhcY+cQvDOrLI7ypwnuXfSZkRbuyA4exV7uemAyo4il4BBZNei3EBKPWK27D r12UC8mjp7nJ2qzb6hJNTNgKe6nJ0wkcLi9XJWC5tBLBUkY9xd64fcp1HRRhCal1CTwK g/3J7PYCb7qVVajDHK8UmN6meEI7IKZAxxwAYY/MljO4Zy9XJBrPjb9PyTan0NbTcdNM NPXl/1iH5zOXt9ZjjsJYkrbAqPjz/emjHsjowI2ExSiaqJ9qiSdfvfosiSNxnOZMUgyP NMFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fDARzXfF71XngqTxjhF39nAVVPWu27h3qzsoRgE4gS0=; b=OhFvRG27EtZo58vQ5llH1lig7gwQb+3gbi3RFJrp5N+JKC3ksJ00d9FexqL2oFdz5y zrP5HbQI+/DRJconjj9t8pzzs7Pz+LIvIsoQObm8Oak9fiZAsO8+y6Yg+bJ+Z51oEog3 S5SXdgWiX38kuMwZ5sCkJ9j4Ws7XmLyC8smPgG6rsnAFqAJmgoClRtGq4iD09JQ5wjZy 6T7M0Jwk3vuRGBbEzCa5aBUlK+SB7ioabDOQVvm07xlbkjn3pz7yY6k1K+j8m2bn2S+Z svqwIzw/53X+x38h55cRwfxhbV9gIpAp4J4WOYR1x8jwlfsXErtYBXUrqzgiQZS3YFJD VoAA== X-Gm-Message-State: AMke39l3m30492657CWFwbJseBbGuRDZopNNhWhUS79ZJH3xymV9exZb2Zx8kYrGf+szYV6NDkfJckPWt3AMiw== X-Received: by 10.202.79.208 with SMTP id d199mr4027645oib.199.1486371179289; Mon, 06 Feb 2017 00:52:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Mon, 6 Feb 2017 00:52:38 -0800 (PST) In-Reply-To: <20170202225642.C5931B81022@rfc-editor.org> References: <20170202225642.C5931B81022@rfc-editor.org> From: "Andrew G. Malis" Date: Mon, 6 Feb 2017 09:52:38 +0100 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=001a113d6768256dcb0547d8c26d Archived-At: Cc: "Giles Heron \(giheron\)" , lmartini@monoski.com Subject: [Pals] Fwd: STD 84, RFC 8077 on Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 08:53:01 -0000 --001a113d6768256dcb0547d8c26d Content-Type: text/plain; charset=UTF-8 Congratulations to Giles and Luca on their (and our) new Internet Standard! Cheers, Andy ---------- Forwarded message ---------- From: Date: Thu, Feb 2, 2017 at 11:56 PM Subject: [Pals] STD 84, RFC 8077 on Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. STD 84 RFC 8077 Title: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) Author: L. Martini, Ed., G. Heron, Ed. Status: Standards Track Stream: IETF Date: February 2017 Mailbox: lmartini@monoski.com, giheron@cisco.com Pages: 35 Characters: 80972 Obsoletes: RFC 4447, RFC 6723 See Also: STD 84 I-D Tag: draft-ietf-pals-rfc4447bis-05.txt URL: https://www.rfc-editor.org/info/rfc8077 DOI: 10.17487/RFC8077 Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents. This document is a rewrite of RFC 4447 for publication as an Internet Standard. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now an Internet 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/retrieve/bulk 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 _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --001a113d6768256dcb0547d8c26d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Congratulations to Giles and Luca on their (and our) new I= nternet Standard!

Cheers,
Andy

<= div class=3D"gmail_quote">---------- Forwarded message ----------
From: = <rfc-editor@rfc-editor.org>
Date= : Thu, Feb 2, 2017 at 11:56 PM
Subject: [Pals] STD 84, RFC 8077 on Pseud= owire Setup and Maintenance Using the Label Distribution Protocol (LDP)
= To: ietf-announce@ietf.org, <= a href=3D"mailto:rfc-dist@rfc-editor.org">rfc-dist@rfc-editor.org
Cc= : drafts-update-ref@iana.org<= /a>, pals@ietf.org, rfc-editor@rfc-editor.org


A new R= equest for Comments is now available in online RFC libraries.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 STD 84
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8077

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Pseudowire Setup and= Maintenance Using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the L= abel Distribution Protocol (LDP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0L. Martini, Ed.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 G. He= ron, Ed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0February 2017 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 lmartini@monoski.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 giheron@cisco.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 35
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 80972
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Obsoletes:=C2=A0 RFC 4447, RFC 6723
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See Also:=C2=A0 =C2=A0STD 84

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-pals-rfc4447bi= s-05.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc8077

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC807= 7

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
and Ethernet) can be emulated over an MPLS backbone by
encapsulating the Layer 2 Protocol Data Units (PDUs) and then
transmitting them over pseudowires (PWs).=C2=A0 It is also possible to use<= br> pseudowires to provide low-rate Time-Division Multiplexed and
Synchronous Optical NETworking circuit emulation over an MPLS-enabled
network.=C2=A0 This document specifies a protocol for establishing and
maintaining the pseudowires, using extensions to the Label
Distribution Protocol (LDP).=C2=A0 Procedures for encapsulating Layer 2
PDUs are specified in other documents.

This document is a rewrite of RFC 4447 for publication as an
Internet Standard.

This document is a product of the Pseudowire And LDP-enabled Services Worki= ng Group of the IETF.

This is now an Internet Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/sta= ndards) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinf= o/ietf-announce
=C2=A0 https://mailman.rfc-editor.org/m= ailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/s= earch
For downloading RFCs, see https://www.rfc-editor.org/re= trieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

--001a113d6768256dcb0547d8c26d-- From nobody Mon Feb 6 04:59:36 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CB129D5A for ; Mon, 6 Feb 2017 04:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qnmU-l-stI4Z for ; Mon, 6 Feb 2017 04:59:26 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 87D8A129CDB for ; Mon, 6 Feb 2017 04:59:25 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id v77so114003848wmv.0 for ; Mon, 06 Feb 2017 04:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YzApp9nbx7/8JA3rNhSuoyXPV/9MLtrDRdDbquruEtM=; b=fdVtMr8ZqeXTfVXpbzZuBOjlfx9G5aNI1KvuPuPfhh0PWHjUmknlzi6YbJ5fgHgkSX yCaC5JnyxYSfpq5FF2e267cfQ8WkS5oEfDKn2eye68qYnAJifLOVxhbQ29aiQIIh2w1q p/KrahyDiBQyI2dmQGmllPXiNXGRf3p+XPO33XkkWK9T43DQptnk3G7jDwSHir4ByTQO 6+QSmeNIefZVcWTHZklFJ5iFm83peNYrEnRsGv9t30/4QK4VL2nB295IOL4B+5B1pqlj N02yc8NDW4gc4eoa8mcFAlZRVHDxJjDkskRs2VGH3wp45PTScVjFMmiY0JJswns0wTMD T4cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YzApp9nbx7/8JA3rNhSuoyXPV/9MLtrDRdDbquruEtM=; b=DSSKW7ForET7yZALm/fEL7tObEEWfT0RPfm7op76ON6lLW4xOIm0NJJifiP1+reGwN koLSPjlUrL0lzKkNqQ3rnuexkWbIZm7Jo/3Rz3ps8ehxswyu2E1OJpgA36gB9Edrz3/b rTRTwau6yHiJGqWaPtoYJqcBHncl9FQFyZbnDInCbeU7Wb3cKhWydntCNZkXGYHXjZDP ebLq8aMXS/hAGiljeJHBVjJIljvsLbozF9NrjtcowofbQ6OtACORATNkvlCMbw1f4H4B iYwhvwaS3+QKTGA3lIwfcKr2/Iwy+FUX0tfV5STDJTEEC1VcFvmOVbVIAHc5z5Mh4r3n GpXA== X-Gm-Message-State: AMke39l8d/6YioYyoqSJOkohKxSNBOUvaOhbpAHzTIpEMgrQkY0mjaeTdRORZzzFZ83PcA== X-Received: by 10.223.146.228 with SMTP id 91mr9243724wrn.203.1486385964017; Mon, 06 Feb 2017 04:59:24 -0800 (PST) Received: from ams-giheron-nitro3.cisco.com ([173.38.220.38]) by smtp.gmail.com with ESMTPSA id 123sm12780161wml.6.2017.02.06.04.59.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 04:59:23 -0800 (PST) From: Giles Heron Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FD329A60-21A6-48F4-ACDD-CE472CEC9932" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 12:59:21 +0000 In-Reply-To: To: "Andrew G. Malis" References: <20170202225642.C5931B81022@rfc-editor.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: lmartini@monoski.com, "pals@ietf.org" Subject: Re: [Pals] STD 84, RFC 8077 on Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:59:34 -0000 --Apple-Mail=_FD329A60-21A6-48F4-ACDD-CE472CEC9932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii thanks Andy > On 6 Feb 2017, at 08:52, Andrew G. Malis wrote: >=20 > Congratulations to Giles and Luca on their (and our) new Internet = Standard! >=20 > Cheers, > Andy >=20 > ---------- Forwarded message ---------- > From: > > Date: Thu, Feb 2, 2017 at 11:56 PM > Subject: [Pals] STD 84, RFC 8077 on Pseudowire Setup and Maintenance = Using the Label Distribution Protocol (LDP) > To: ietf-announce@ietf.org , = rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org , = pals@ietf.org , rfc-editor@rfc-editor.org = >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > STD 84 > RFC 8077 >=20 > Title: Pseudowire Setup and Maintenance Using > the Label Distribution Protocol (LDP) > Author: L. Martini, Ed., > G. Heron, Ed. > Status: Standards Track > Stream: IETF > Date: February 2017 > Mailbox: lmartini@monoski.com = , > giheron@cisco.com > Pages: 35 > Characters: 80972 > Obsoletes: RFC 4447, RFC 6723 > See Also: STD 84 >=20 > I-D Tag: draft-ietf-pals-rfc4447bis-05.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8077 = >=20 > DOI: 10.17487/RFC8077 >=20 > Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, > and Ethernet) can be emulated over an MPLS backbone by > encapsulating the Layer 2 Protocol Data Units (PDUs) and then > transmitting them over pseudowires (PWs). It is also possible to use > pseudowires to provide low-rate Time-Division Multiplexed and > Synchronous Optical NETworking circuit emulation over an MPLS-enabled > network. This document specifies a protocol for establishing and > maintaining the pseudowires, using extensions to the Label > Distribution Protocol (LDP). Procedures for encapsulating Layer 2 > PDUs are specified in other documents. >=20 > This document is a rewrite of RFC 4447 for publication as an > Internet Standard. >=20 > This document is a product of the Pseudowire And LDP-enabled Services = Working Group of the IETF. >=20 > This is now an Internet Standard. >=20 > 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. >=20 > 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 = >=20 > For searching the RFC series, see https://www.rfc-editor.org/search = > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk = >=20 > 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. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals = >=20 --Apple-Mail=_FD329A60-21A6-48F4-ACDD-CE472CEC9932 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii thanks Andy

On 6 Feb 2017, at 08:52, Andrew = G. Malis <agmalis@gmail.com> wrote:

Congratulations to Giles and Luca = on their (and our) new Internet Standard!

Cheers,
Andy

---------- Forwarded message ----------
From: <rfc-editor@rfc-editor.org>
Date: = Thu, Feb 2, 2017 at 11:56 PM
Subject: [Pals] STD 84, RFC = 8077 on Pseudowire Setup and Maintenance Using the Label Distribution = Protocol (LDP)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org


A new Request for Comments is now available in online RFC = libraries.

        STD 84
        RFC 8077

        Title:      Pseudowire Setup = and Maintenance Using
                    = the Label Distribution Protocol (LDP)
        Author:     L. Martini, = Ed.,
                    G. = Heron, Ed.
        Status:     Standards = Track
        Stream:     IETF
=         Date:       February = 2017
        Mailbox:    lmartini@monoski.com,
                    giheron@cisco.com
        Pages:      35
        Characters: 80972
        Obsoletes:  RFC 4447, RFC 6723
        See Also:   STD 84

        I-D Tag:    = draft-ietf-pals-rfc4447bis-05.txt

        URL:        https://www.rfc-editor.org/info/rfc8077

        DOI:        = 10.17487/RFC8077

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
and Ethernet) can be emulated over an MPLS backbone by
encapsulating the Layer 2 Protocol Data Units (PDUs) and then
transmitting them over pseudowires (PWs).  It is also possible to = use
pseudowires to provide low-rate Time-Division Multiplexed and
Synchronous Optical NETworking circuit emulation over an MPLS-enabled
network.  This document specifies a protocol for establishing = and
maintaining the pseudowires, using extensions to the Label
Distribution Protocol (LDP).  Procedures for encapsulating Layer = 2
PDUs are specified in other documents.

This document is a rewrite of RFC 4447 for publication as an
Internet Standard.

This document is a product of the Pseudowire And LDP-enabled Services = Working Group of the IETF.

This is now an Internet 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/retrieve/bulk

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


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


= --Apple-Mail=_FD329A60-21A6-48F4-ACDD-CE472CEC9932-- From nobody Mon Feb 6 07:16:39 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9363E129E33 for ; Mon, 6 Feb 2017 07:16:37 -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 autolearn_force=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 LZ_-JTO21nV8 for ; Mon, 6 Feb 2017 07:16:36 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C79129E25 for ; Mon, 6 Feb 2017 07:16:35 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id v16FGSEG010083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2017 08:16:29 -0700 (MST) To: "Andrew G. Malis" , "pals@ietf.org" References: <20170202225642.C5931B81022@rfc-editor.org> From: Luca Martini Organization: Monoski Message-ID: <58989347.10201@monoski.com> Date: Mon, 6 Feb 2017 08:16:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Giles Heron \(giheron\)" Subject: Re: [Pals] Fwd: STD 84, RFC 8077 on Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:16:37 -0000 Thanks Andy! Now i have to update my license plate .... ;-) Luca On 02/06/17 01:52, Andrew G. Malis wrote: > Congratulations to Giles and Luca on their (and our) new Internet > Standard! > > Cheers, > Andy > > ---------- Forwarded message ---------- > From: > > Date: Thu, Feb 2, 2017 at 11:56 PM > Subject: [Pals] STD 84, RFC 8077 on Pseudowire Setup and Maintenance > Using the Label Distribution Protocol (LDP) > To: ietf-announce@ietf.org , > rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org , > pals@ietf.org , rfc-editor@rfc-editor.org > > > > A new Request for Comments is now available in online RFC libraries. > > STD 84 > RFC 8077 > > Title: Pseudowire Setup and Maintenance Using > the Label Distribution Protocol (LDP) > Author: L. Martini, Ed., > G. Heron, Ed. > Status: Standards Track > Stream: IETF > Date: February 2017 > Mailbox: lmartini@monoski.com , > giheron@cisco.com > Pages: 35 > Characters: 80972 > Obsoletes: RFC 4447, RFC 6723 > See Also: STD 84 > > I-D Tag: draft-ietf-pals-rfc4447bis-05.txt > > URL: https://www.rfc-editor.org/info/rfc8077 > > > DOI: 10.17487/RFC8077 > > Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, > and Ethernet) can be emulated over an MPLS backbone by > encapsulating the Layer 2 Protocol Data Units (PDUs) and then > transmitting them over pseudowires (PWs). It is also possible to use > pseudowires to provide low-rate Time-Division Multiplexed and > Synchronous Optical NETworking circuit emulation over an MPLS-enabled > network. This document specifies a protocol for establishing and > maintaining the pseudowires, using extensions to the Label > Distribution Protocol (LDP). Procedures for encapsulating Layer 2 > PDUs are specified in other documents. > > This document is a rewrite of RFC 4447 for publication as an > Internet Standard. > > This document is a product of the Pseudowire And LDP-enabled Services > Working Group of the IETF. > > This is now an Internet 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/retrieve/bulk > > > 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 > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Tue Feb 7 10:13:25 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B390B129DCA; Tue, 7 Feb 2017 10:13:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148649120072.19411.7489137402403290375.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 10:13:20 -0800 Archived-At: Cc: draft-ietf-pals-mpls-tp-dual-homing-protection.all@ietf.org, ietf@ietf.org, pals@ietf.org Subject: [Pals] Review of draft-ietf-pals-mpls-tp-dual-homing-protection-05 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:13:21 -0000 Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-pals-mpls-tp-dual-homing-protection-05 Reviewer: Russ Housley Review Date: 2017-02-07 IETF LC End Date: 2017-02-13 IESG Telechat date: 2017-03-02 Summary: Ready Major Concerns: None Minor Concerns: None Nits: In the last sentence of the first paragraph of Section 1, the document says: "This mechanism is only applicable ..." I believe that this is a reference to the repair mechanism that is defined in [I-D.ietf-pals-endpoint-fast-protection], not the mechanism that is defined in this document. Please replace "This mechanism" with a clear reference. Notes: I see that draft-cheng-pwe3-mpls-tp-dual-homing-protection the earlier Internet-Draft file name for this document. An IPR declaration was issued against that earlier name. The shepherd write-up indicates that "The WG were not concerned about the IPR disclosure." However, it is unclear to me whether we should ask for the IPR declaration to be issued against the current Internet-Draft file name. From nobody Wed Feb 8 06:05:27 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08012949F; Wed, 8 Feb 2017 06:05:25 -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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148656272580.3834.8673821336381751534.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 06:05:25 -0800 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, db3546@att.com, pals@ietf.org Subject: [Pals] pals - Not having a session at IETF 98 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:05:26 -0000 Andrew Malis, a chair of the pals working group, indicated that the pals working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Feb 8 10:53:58 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B1D129D5A; Wed, 8 Feb 2017 10:53:44 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4SnA9Qp83rIN; Wed, 8 Feb 2017 10:53:43 -0800 (PST) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 8C36912942F; Wed, 8 Feb 2017 10:53:40 -0800 (PST) Received: by mail-wr0-x241.google.com with SMTP id 89so9580023wrr.1; Wed, 08 Feb 2017 10:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dSh5msw0htlLNOsZ/NeV73oOzEIZnCDE3zTnMjv/iQ8=; b=iI/ImBSHNj0YjSA7Cirb5WhKKkzGiqXhga3PfylThA4CRA4JphKtPYtVyuAqoVVVd4 u0kt1+h1c1Z8PHWF+cMVgm+MsEbeoM6N4IAFX9JPF6urM1T71sn/c2006omCXA80YLia PCSUI/WhXbDwY5hi/h0BQ2c9LLRrfNC76M3Y6j/8ATjfTV5EdPXzvsFkGSiphW1WyZZu YQPwY/hjYugiltGIOiN5nRcHlZKJ4hX1buV5MgOMoUt16x1dGPWJHXiNSOHZXJbDVxvM yySMyZAVNONSGT0aqy5IDH5OpfUkHW8EUh+9Wz6O0emF4D/vXIvdcpFPKHEflKiE76je Gwsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dSh5msw0htlLNOsZ/NeV73oOzEIZnCDE3zTnMjv/iQ8=; b=tTjV+Eyij9CKrf+tFyU0mpW0oSCiBnceDMfEBoXmcgMPHKftx+PRG8d5viTJgTwisr FaWx6VbxeLGhTuiGY+4uzJXadBTnKnsV7iZSaz8LVbqrzIuBDqf0w7KJpwR6eg9NCHBq moYEMQ0/r2MJh0JvFhpL/IO6uaovLCmt8PTjrmScjKoLgUuV1wginxFtjuXWFbxPEOqK bKLQ/1/1/5tnx03xswmyM6wZl44WvBRhRUbDN+iLCr8awfLLcTjiu8bl9hEqGQuqNv3R xmHgg3wkQuqtRtD3Qg9CzWYEVF0J9x2xPRGS9ZoBaE+f8t1UK/x11HmjH//Q6wnDCcWG BIvA== X-Gm-Message-State: AIkVDXIHH8ojbzAQxZSk6NQVgMyZ6AXOFX4+K6DuCPZ3s8B1RT6QiAmWpirVLkW2d4htlQ== X-Received: by 10.223.154.165 with SMTP id a34mr11930137wrc.193.1486580018862; Wed, 08 Feb 2017 10:53: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 h3sm14502051wrb.31.2017.02.08.10.53.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 10:53:38 -0800 (PST) To: Russ Housley , gen-art@ietf.org References: <148649120072.19411.7489137402403290375.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: Date: Wed, 8 Feb 2017 18:53:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148649120072.19411.7489137402403290375.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-pals-mpls-tp-dual-homing-protection.all@ietf.org, ietf@ietf.org, pals@ietf.org Subject: Re: [Pals] Review of draft-ietf-pals-mpls-tp-dual-homing-protection-05 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:53:45 -0000 Hi Russ Thank you for the review. I would like to respond to one point: > Notes: > > I see that draft-cheng-pwe3-mpls-tp-dual-homing-protection the > earlier > Internet-Draft file name for this document. An IPR declaration was > issued against that earlier name. The shepherd write-up indicates > that > "The WG were not concerned about the IPR disclosure." However, it is > unclear to me whether we should ask for the IPR declaration to be > issued > against the current Internet-Draft file name. > The authors all responded including of course the author from the company that filed the IPR. All indicated that no additional IPR was known about. The IPR disclosure shows up in datatracker. We do not normally chase companies to update their IPR disclosures, as documents progress, and indeed if we chase them to do this update we need to chase them shortly for a further one as the draft becomes an RFC. Since you pointed it out we have asked the author to ask his patent dept to do the update, but I hope that this does not become an IETF policy making it even harder to pass the IPR checks that we put in place in RTG. Thanks Stewart From nobody Thu Feb 9 06:37:53 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1424D129A88; Thu, 9 Feb 2017 06:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lYHuwvj2XM3L; Thu, 9 Feb 2017 06:37:50 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 A9279129A87; Thu, 9 Feb 2017 06:37:50 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id 65so4228427otq.2; Thu, 09 Feb 2017 06:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mu0+H2BzEeevcUgZfofM1NK+JtkhdUbHZwrm+aUp8zQ=; b=OvBrwUA+2/ZS/19DwW0Xz+gg3juahxZMOLAocKrWyzIwHEUmcv8FBvOLJPz+J8pJqA rBbE18CKHXhUhYNCsGqJu7stdfn1Gx/VGIeN7O8VnT8uXiq5uLRlkzHB/pkyfydtjiJs oaarcfFATVyqU6Mmzi+7ebmCG59MVkNvhQKRVz5dO4yAtiCpG486HP4BvE83kq4US6f3 2o3sznRtV1mVKKBi3UE/3zHuVr8KZoDXooumTHf6BIj1sc7PW5oOZfLlIVQ/WPEqCxRd HdUbZzbigOzAqe0y8p+Ffwq6jsFT2ppQnD7UoazvcdAlKShSSv7g+xYGjUzrh2Dm0Ced Rkyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mu0+H2BzEeevcUgZfofM1NK+JtkhdUbHZwrm+aUp8zQ=; b=p9Y01jluF5OGBJGx5RVbJwSNxIqv0d4m9+nruwGy4EydQBNKqFXqn8F+/yok30DM7Z vZLVTZZpEnS6papAlQhKYxLPL+wiT7sJpccmf4s9VL3cyM7DzTZmCytV27chXFvDgUdM AlLEMdXkqNzyzKtOmBltXSTi4y7r0Io7zSRFZGKmtRTwTVJUEYshVx+2pHnQJ6sjaLmY pVF3oKDMXMNdP9KbTNXIxagbRFtPqj3/xlVF8tDLdwfVEKUtacSwDkcg9NKvpVTVtVk5 trlEnt5aBljuD8ztlniEDbdtZ093TfqW4l7zaiNxE4yS+nkZD7Bqb1XB7RF5lDhe3hIc I2MQ== X-Gm-Message-State: AMke39lEvqcQkR5p+WwoIPG7Qn1MTC65pw92u1msQ4kGjbrkH326SrSCcilHvmiDeKKD5P/ahvs5GZQ+7eJseA== X-Received: by 10.157.8.42 with SMTP id 39mr1696680oty.249.1486651069979; Thu, 09 Feb 2017 06:37:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Thu, 9 Feb 2017 06:37:29 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Thu, 9 Feb 2017 15:37:29 +0100 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c048a90ee62b2054819ecf8 Archived-At: Cc: "Serbest, Yetik" , princy@juniper.net, "Boddapati, Suresh \(Nokia - US\)" , draft-ietf-pals-vpls-pim-snooping@ietf.org, xcai@juniper.net Subject: Re: [Pals] PALS Working Group last call for draft-ietf-pals-vpls-pim-snooping X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:37:52 -0000 --94eb2c048a90ee62b2054819ecf8 Content-Type: text/plain; charset=UTF-8 This ends the WG last call for this draft. Cheers, Andy On Mon, Jan 23, 2017 at 1:10 PM, Andrew G. Malis wrote: > Having heard from all of the authors and major contributors regarding IPR, > this starts the WG last call for https://tools.ietf.org/html/draft- > ietf-pals-vpls-pim-snooping-04 . This last call will last for two weeks, > ending on February 6. Please review the draft and send all comments to > pals@ietf.org. > > Thanks, > Andy > > --94eb2c048a90ee62b2054819ecf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This ends the WG last call for this draft.

<= div>Cheers,
Andy


On Mon, Jan 23, 2017 at 1:10 PM, Andrew= G. Malis <agmalis@gmail.com> wrote:
= Having heard from all of the authors and major contributors regarding IPR, = this starts the WG=C2=A0last=C2=A0call=C2=A0for=C2=A0https://tools.ietf.org/html/draft-ietf-pals-vpls-pim-snooping-04=C2=A0. This=C2=A0last=C2=A0call= =C2=A0will=C2=A0last=C2=A0for two weeks, ending on February 6. Please review= the draft and send all comments to=C2=A0pals@ietf.= org.

Thanks,
An= dy


--94eb2c048a90ee62b2054819ecf8-- From nobody Sun Feb 12 16:00:05 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB13129400; Sun, 12 Feb 2017 16:00:03 -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 autolearn_force=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 XJiT3AUaX3DO; Sun, 12 Feb 2017 15:59:59 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3D8120726; Sun, 12 Feb 2017 15:59:59 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id v1CNv2FV011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 12 Feb 2017 16:57:02 -0700 (MST) To: "Andrew G. Malis" , George Swallow , Elisa Bellagamba References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> From: Luca Martini Organization: Monoski Message-ID: <58A0F649.7090301@monoski.com> Date: Sun, 12 Feb 2017 16:56:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-pals-status-reduction@ietf.org" , "pals-chairs@ietf.org" , "pals@ietf.org" , "BRUNGARD, DEBORAH A" , "adrian@olddog.co.uk" Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:00:03 -0000 Adrian, Sorry for the late response , this fell though the cracks. I'm having some trouble with the ID submission tool, but the revision will be out shortly. Comments below: Thanks. Luca > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk > ] > > Sent: Wednesday, September 28, 2016 9:05 AM > > To: rtg-ads@ietf.org > > Cc: rtg-dir@ietf.org ; > draft-ietf-pals-status-reduction.all@ietf.org > ; > > pals@ietf.org > > Subject: RtgDir review of draft-ietf-pals-status-reduction-01.txt > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for > this draft. The > > Routing Directorate seeks to review all routing or > routing-related drafts as > > they pass through IETF last call and IESG review, and sometimes > on special > > request. The purpose of the review is to provide assistance to > the Routing > > ADs. > > For more information about the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > > Although these comments are primarily for the use of the Routing > ADs, it > > would > > be helpful if you could consider them along with any other IETF > Last Call > > comments that you receive, and strive to resolve them through > discussion or > > by > > updating the draft. > > > > Document: draft-ietf-pals-status-reduction-01.txt > > Reviewer: Adrian Farrel > > Review Date: 27 September 2016 > > IETF LC End Date: Not yet started > > Intended Status: Standards Track > > > > ==Summary:== > > I have some minor concerns about this document that I think > should be > > resolved > > before publication. > > The volume of minor concerns add up to a significant concern > although no > > one > > issue is large. I recommend that the Routing ADs discuss these > issues further > > with the authors and consider whether an updated I-D would need > to be > > re-reviewed by the WG. > > > > ==Comments:== > > This document defines a mechanism to "bundle" status reports on > the PWs > > carried > > on an MPLS tunnel. The effect is to significantly reduce the > number of > > messages > > need in the (normal) stable state. > > I don't see any problems with the mechanism defined and I am > sure it would > > work. > > The writing style is mainly clear. > > However, there is a host of minor issues and holes in the > documentation that > > puts the specification below the level necessary to guarantee > interoperable > > implementations. > > My review is not as an implementer, and it worries me that if I > find so many > > questions and issues, an implementer would find far more. > > I checked to see whether anyone had commented in WGLC that they > had read > > the > > document and I didn't see anything (perhaps my list subscription > is broken?) > > > I agree with your comment. In fact the mechanism is a bit complex, and I went out of my way to ask people a few years ago to check it for problems. At the time we fine tuned some things, and did not find any major issues. I welcome anybody taking a close look at this ! > > ==Minor Issues:== > > > > Section 1.3 > > I think you need to give a reference for the base BNF you are using. > > You could choose from RFC 5234 or RFC 5511. > > But it seems peculiar that you have set out to define your own > notation for > > things that can be expressed in existing BNF. > OK, maybe George has something to add here , as I cannot remember adding this section. > > > > > Section 4 > > The figure makes it look like MPLS labels are 32 bits long. > > I guess you could fix this by s/label/label stack entry/ > > Or you could show all of the LSE fields. > > > I changed it. I meant "Label" in a more liberal term , as you guessed. > > Section 4 > > You have not described all of the fields in the figure. > What did I miss ? > > > > > Section 4 > > You have... > > Channel type 0xZZ pending IANA allocation. > > ...but no mention in the IANA section > > The figure shows "0xZZ PW OAM Message", but surely this is > > "PW Status Reduction Message" > > > Sure , but it has not been allocated yet. This is for the RFC editor to replace the text once the allocation is dune. > > > Section 4 > > In the description of the Session ID CRC16 seed really > "recommended"? > > I mean, is this "RECOMMENDED", and if so, why? > > > You *do* need a locally selected, locally unique value. > > It does not need to be unique over time, but you may need suggest a > > damping mechanism on re-use of session ID. > > However, recommending this mechanism for generating session IDs > seems > > to me to be over-weaning. What is the reason? > > > no - this is just a suggestion. Since this is local , it does not matter , but I wanted a staring point that is known to work in case some junior coder needed it. Yes I agree that there should be a re-use and damping mechanism, but that is over specifying it a bit. > > Section 4 > > There are a number of rules expressed here about the setting of the > > message fields (such as the Refresh Timer that is a "non zero > unsigned > > 16 bit integer value greater or equal to 10"). What happens if a > > message is received that violates one of these rules. > > > the remote PE will return a notification - 6 "PW configuration not supported." . I'll add text to clarify this. > > > Section 4 > > OLD > > 7 bits of flags reserved for future use, they MUST be set > to 0 on > > transmission, and ignored on reception. > > NEW > > 6 bits of flags reserved for future use, they MUST be set > to 0 on > > transmission, and ignored on reception. > > END > > > good catch - thanks. > > > Section 4 > > Do you want IANA to track the flags field? > > > no. I think this needs to be allocated by a new RFC. Is that not the default ? Making flags easy to allocate when there are only 6 bits is not wise and will lead to misuse. > > Section 4 > > You have... > > It should be noted that the Checksum, Message Sequence > Number, Last > > Received Message Sequence Number, Message Type, Flags, and > control > > message body are OPTIONAL. > > This *sounds* like each field is individually optional. But that > is not > > the case, I think (because the resulting message would be > impossible to > > parse). So you need to clarify. > > Probably that the length field indicates where the sequence > stops, or > > that the whole set may be omitted or included en mass. > > > yes- they are not OPTIONAL at random, but rather in sequence with the length field used to parse where things stop.... I'll add text to clarify this. NEW: It should be noted that the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and control message body are OPTIONAL. The length field is used to parse how many optional fields are included. Hence all optional fields that precede a specific field that needs to be included in a specific implementation MUST be included if that optional field is also included. > > > Section 5 opening paragraphs are confusing. > > Either you have a "control message" or you have a "control construct > > carried on a status reduction message". > > - It is possible you mean the former. > no - the control message is the full message, while the control message construct is only the control information without the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags. what is missing is this : A PW refresh reduction message is also called a PW status refresh reduction Control Message if it contains a control message construct. > > That is "There are two status reduction messages defined in this > > document and they are both control messages: the Notification > message > > and the PW Configuration message. > > - It is possible you mean have the latter. > > Thus, when you talk about the "message sequence number of the > control > > message" you really mean the "message sequence number of the > status > > reduction message that carries the control construct". > > You can probably note that the control construct can be carried on > > a Notification message or a PW Configuration message. > > You should probably also say whether the control construct can be > > carried on other (future) messages. > > > the notification message is a different type , and cannot carry the control construct. the text I added should clarify that once a control structure is added , ad pw refresh message is also known as a PW status refresh reduction Control Message. However i also fixed the text to say "message sequence number" instead of "control message sequence number" for clarity. > > Section 5 > > In 8.3 you list a number of notification codes. A little can be > deduced > > from their names, but you do not describe anywhere when or why > most of > > them are used (5.0.2.3 and 6 are the exceptions). You should, and > > section 5 or 6 is probably the place. > These are really obvious. I do not see the point of adding obvious text. Go look at all the BGP specs , most of them are extremely unreadable, this is much more clear then any of those. like if i receive an ack message sequence number that is after the last message i sent , clearly is have a "Unacknowledged control message" error... > > > Section 5.0.1 > > What is the setting of the C flag on the Notification message? > > > The notification message has a different message type , and no C flag defined in it. i will add this : The 7 bits of flags are reserved for future use, they MUST be set to 0 transmission, and ignored on reception. > > Section 5.0.2 > > The message has no > > preset length limit, however its total length will be limited > by the > > transport network Maximum Transmit Unit (MTU). > > This is fine, however: > > - You probably want to add "Status Reduction messages MUST NOT be > > fragmented." > yes. i thought this was obvious since there is no specification on how to fragment the message itself... , but i will add it. > > > - You probably also want "If a sender has more configuration > information > > to send than will fit into one PW Configuration Message it may > send > > further messages carrying further TLVs." > yes. i thought this was obvious as well since we have a C bit. However i will add it. > > > > Section 5.0.2 > > I think you need to define a generic TLV format so that new TLVs can > > be added and parsed over. Since you use a common format for your > TLVs, > > this should not be hard. > ok, but a TLV is a TLV .... i will add a picture of a TLV. > > > However, you also need to describe how "unknown" TLVs are handled. > > > The unknown TLVs are handled as per section 4 . I will add a bit of text there to clarify that the U bit applies unknown TLVs inside a known message as well as a completely unknown message. Thanks for catching this. > > Section 5.0.2.1 > > Is the MPLS-TP Tunnel ID TLV optional? 5.0.2.2 shows the PW ID > > configured List TLV as optional, so it looks like the MPLS-TP > Tunnel ID > > might be mandatory TLV. > > Furthermore, you seem to have said that the order of TLVs is > arbitrary > > but wouldn't it be best to have this TLV show up first? > > What happens if there are multiple of this TLV present? > > > There are multiple combinations of configuration TLVs that can result in invalid configurations for multiple reasons. All result in returning a notification of "PW configuration not supported". That is explained in section 6 > > > Section 5.0.2.2 (and 5.0.2.3) > > The number of PW Path IDs in the TLV will be inferred by the > length > > of the TLV up to a maximum of 8. > > Now, "The PW Path ID is a 32 octet pseudowire path identifier" > > 8*32=256 > > The Length field has 8 bits and so encodes a maximum of 255 octets. > > So you can actually only carry 7 PW Path IDs in this TLV. > > Furthermore, Length values that are not a multiple of 32 are an > > encoding error, but you haven't stated how to handle encoding > errors. > > What happens if the same PW Path ID appears twice in a list? > yes good catch - 7 is the correct number. There are multiple combinations of configuration TLVs that can result in invalid configurations for multiple reasons. All result in returning a notification of "PW configuration not supported". > > > > > Section 6 > > A PE that desires to use the PW configuration message to > verify the > > configuration of PWs on a particular LSP, should advertise its PW > > configuration to the remote PE on LSPs that have active keepalive > > sessions. > > I think that probably hidden in here is "MUST NOT include a PW > > configuration message on a status reduction message unless the local > > protocol state is ACTIVE." > > > Yes, this is implied in "A PE that desires to use the PW configuration message to verify the configuration of PWs on a particular LSP, should advertise its PW configuration to the remote PE on LSPs that have active keepalive sessions. " I will add it for clarity. > > Section 6 > > the following action SHOULD be taken: > > -i. The local PW MUST be considered in "Not Forwarding" > State. > > That creates a composite "SHOULD-MUST" which is not very clear. > > Suggest you change to... > > the following actions are taken: > > -i. MUST > > -ii. SHOULD > > -iii. SHOULD > > > Yes , i fixed it as you suggested. > > Section 7 > > Why does this section not discuss the Checksum field? Doesn't > this add > > a measure of security (at least against simple, random attacks)? > no. This protocol is for a direct attached point to point link. I'm not clear how this would help in a attack given that anybody knows how to calculate the checksum. > > Should you also give guidance (here or in section 4) about when > it is > > acceptable to use a zero checksum. > > > since i do not think that the checksum adds any security, i'm not clear how it helps. Any transport link will have it's own error checking mechanism anyway... This was only here in case some nasty people come along an put this into a pseudoiwire ;-). And they should not ! > > Section 8.1 - meta-point to be addressed before the following issue > > with this section... > > You seem to have an overly-complex assignment policy for this > registry. > > All of the types seem to have equal weight (i.e., there are no > "special > > purpose" values yet you cover the range with: > > - Expert review > > - IETF review > > - FCFS > > Since FCFS guarantees an assignment without any further review, why > > would anyone bother with Expert Review. For that matter, why would > > anyone bother with IETF Review? > > So, why not make life easier and say all code points are FCFS? > > > because when one range is exhausted, the next range will be harder to exhaust , and so forth. >From past experience, this allocation policy is better at protecting the limited resources , then FCFS when i cannot foresee all possible outcomes... > > Section 8.1 > > s/IETF consensus/IETF review/ > > > fixed. > > > Section 8.1 > > You have a range assigned by Expert Review. It is a requirement that > > you give guidance to the experts about how they should review > > requests. > > > we did not do that in the past. I assume that the Expert is an Expert in this field , and has good judgment. maybe i should add "at sole discretion of the expert" ? > > Section 8.1 > > The values 128 through 254 are assigned using FCFS. You cannot then > > attempt to further constrain how the values are used (e.g., "for > vendor > > proprietary extensions"), and you should avoid the word > "reserved" since > > it has special meaning for IANA. > ??? i want the vendor proprietary extensions to be FCFS, does this not say that ? the point is that if something is not a proprietary extension it should not use this. for example it prevents people like me from using FEC type 128 for a standard protocol ...;-) > > > > Section 8.2 > > I have essentially an identical set of points about 8.2 carried > from 8.1 > > > > Section 8.3 > > Again the same set of comments. > > Additionally, you need to tell IANA what the "Error?" column > means. This > > is probably... > > For each value assigned IANA should also track whether the value > > constitutes an error as described in Section 5.0.1. When > values are > > assigned by IETF Review, the setting of this column must be > > documented in the RFC that requests the allocation. For Expert > > Review and FCFS assignments, the setting of this column must > be made > > clear by the requested at the time of assignment. > > > ok will add it. > > ==Nits:== > > > > I believe Luca may want to change his reported affiliation. > > > ok. > > > Abstract > > OLD > > This document describes a method for generating an aggregated > > pseudowire status message on Multi-Protocol Label Switching > (MPLS) > > network Label Switched Path (LSP). > > NEW > > This document describes a method for generating an aggregated > > pseudowire status message transmitted on a Multi-Protocol Label > > Switching (MPLS) Label Switched Path (LSP) to indicate the > status of > > one or more pseudowires carried on the LSP. > > END > fixed. > > > > > Introduction > > Expand "PW" on first use. > > s/they are setup/they are set up/ > > > > Section 2 > > "MPLS Generic Associated Channel" needs a reference to 5586 > fixed. > > > > > Throughout the document you need to be consistent (and with > prior art) > > about capitalisation ("generic associated channel" or "Generic > Associated > > Channel" etc.) and abbreviations ("GACH" or "G-ACh" etc.) > > > yes- i fixed what I found , and the great RFC editor will do the rest. > > > Section 4 > > Message Sequence Number > > s/A unsigned/An unsigned/ > > > > Section 4 (from the figure) > > OLD > > | Last Received Seq Number | Message Type |U C Flags | > > NEW > > | Last Received Seq Number | Message Type |U|C|Flags | > > END > > > no C in notification messages.... Besides this I'm unclear what is different in your suggestion. > > Section 4 Unknown flag bit. > > s/MUST be acknowledge/MUST be acknowledged/ > > > ok > > > The sub-section numbering in Section 5 is broken. You can have, > > for example, "5.0.1". > > > fixed > > > In a number of places you have "sub-TLVs" and in other places > "TLVs". > > I think they are all "TLVs". > yes, i mean sub-tlv because it's within another tlv. > > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It is > > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP > suddenly > > come from since you want this to work for all LSPs (see also 8.2). > > > no, this is what this is . If you want an MPLS tunnel ID , it would be different. > > 2.1.1, 2.1.3, and 5.0.2.3 > > "unprovisioned" > > I think the word is "deprovisioned" > > > unprovisioned means it is not provisioned. deprovisioned , i take to mean that it was once provisioned, now it is not .... I like the more generic "unprovisioned" > > Section 6 > > If > > a PE receives such a notification it should stop sending PW > > configuration control messages for the duration of the PW refresh > > reduction keepalive session. > > s/should/SHOULD/ > fixed. > > > > > Section 8 > > All the registries in this section are to be created or > updated as > > apropriate in the PW Name Spaces. > > No such name space error. > > I think you mean "Pseudowire Name Spaces (PWE3)" > > s/apropriate/appropriate/ > > > > s/10. Author's Addresses/10. Authors' Addresses/ > fixed. From nobody Sun Feb 12 16:21:25 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE7E129401; Sun, 12 Feb 2017 16:21:25 -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.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148694528504.6199.9860275984588790384.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 16:21:25 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-status-reduction-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : MPLS LSP PW status refresh reduction for Static Pseudowires Authors : Luca Martini George Swallow Elisa Bellagamba Filename : draft-ietf-pals-status-reduction-02.txt Pages : 18 Date : 2017-02-12 Abstract: This document describes a method for generating an aggregated pseudowire status message transmitted on a Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more pseudowires carried on the LSP. The method for transmitting the pseudowire (PW) status information is not new, however this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-status-reduction/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-status-reduction-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-status-reduction-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 Sun Feb 12 16:23:14 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB1129417; Sun, 12 Feb 2017 16:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hJIfYuIMieZh; Sun, 12 Feb 2017 16:23:08 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 D71C41294A9; Sun, 12 Feb 2017 16:23:07 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id s203so42905680oie.1; Sun, 12 Feb 2017 16:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pNahDRnstL8do1zfVM1LMR8Ik0qHJUW504ijxDg3gLw=; b=eEAetdjrulOK7vUt2vfWlgtXaQAXnovjJ8Cl0DV5eH6vyvgm8DqDVW7+5qmHi2j2cP MsT7OZJsHI6y72cj6EJQSl3Tyae2Sd/2cFRJ2OySDbr2dwjs2C7H8P8Jmr5ILmS/oex0 QMC2hHGKguYlyVizlgK7kgMUbSKKWPKiQPk0zoW7CRqLCjur0YmSb+/b4psVO4U3GyMC mZiXmJIN9jV9ERJyBzhEceWseZaNBlsIARpgzcI+6/RZskg0OOtzLW7iw+DOUQE350yv P/PZ+1Sek2WbScPTqSqJVDWbViJIhoowqKTubvwa5wLfeuMbBwAkmOWTli4h1PgRzzoY uvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pNahDRnstL8do1zfVM1LMR8Ik0qHJUW504ijxDg3gLw=; b=HKzXXEj+mL2fOSezuW/c2dU/RlRibgtaRKNEfHhYC3xe3VRtWuH9ocUd8aOqqwkK/y jQPYk/rqf2W9fqgcobMClBtq9mVtTV+Fgh7ZecXw5h18zFD9IEOC5Y58HdcROA0pWrJZ dxu0yL9wmcmAkSmVc+L507sr4BHdGrLet4oTMoTnFFyX5+e8eRUO1dU+YLAB3n70aMkt fNXTA6LtROaLxS1msTPp6g3xHVOpDyBzS1nlDSl1HG95gHhDUDdHKdiscOfjfMrEtx7V x1++8BQDSeXJJKRLPdWWfNRnnJLFMHjAol3nJ9DIzEfiW+rsuJw/wJt5vJrrwaprLyl5 mIFw== X-Gm-Message-State: AMke39nNyUKv3jvwm6NXFYLhenLEN9NfM1TyZv4MUNIxQ365uq5CzlOI9iIIgTJTuTv2TW++Jv9q9UGuLnB3EQ== X-Received: by 10.202.79.208 with SMTP id d199mr10076836oib.199.1486945387085; Sun, 12 Feb 2017 16:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Sun, 12 Feb 2017 16:22:46 -0800 (PST) In-Reply-To: <58A0F649.7090301@monoski.com> References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <58A0F649.7090301@monoski.com> From: "Andrew G. Malis" Date: Sun, 12 Feb 2017 19:22:46 -0500 Message-ID: To: Luca Martini Content-Type: multipart/alternative; boundary=001a113d67689908fb05485e73fd Archived-At: Cc: Elisa Bellagamba , "BRUNGARD, DEBORAH A" , "pals@ietf.org" , "pals-chairs@ietf.org" , "draft-ietf-pals-status-reduction@ietf.org" , "adrian@olddog.co.uk" , George Swallow Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:23:13 -0000 --001a113d67689908fb05485e73fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luca et al, I just confirmed the submission for -02 and it=E2=80=99s up. Cheers, Andy On Sun, Feb 12, 2017 at 6:56 PM, Luca Martini wrote: > Adrian, > Sorry for the late response , this fell though the cracks. > I'm having some trouble with the ID submission tool, but the revision > will be out shortly. > Comments below: > Thanks. > Luca > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk > > ] > > > Sent: Wednesday, September 28, 2016 9:05 AM > > > To: rtg-ads@ietf.org > > > Cc: rtg-dir@ietf.org ; > > draft-ietf-pals-status-reduction.all@ietf.org > > ; > > > pals@ietf.org > > > Subject: RtgDir review of draft-ietf-pals-status-reduction-01.txt > > > > > > Hello, > > > > > > I have been selected as the Routing Directorate reviewer for > > this draft. The > > > Routing Directorate seeks to review all routing or > > routing-related drafts as > > > they pass through IETF last call and IESG review, and sometimes > > on special > > > request. The purpose of the review is to provide assistance to > > the Routing > > > ADs. > > > For more information about the Routing Directorate, please see > > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > > > > > Although these comments are primarily for the use of the Routing > > ADs, it > > > would > > > be helpful if you could consider them along with any other IETF > > Last Call > > > comments that you receive, and strive to resolve them through > > discussion or > > > by > > > updating the draft. > > > > > > Document: draft-ietf-pals-status-reduction-01.txt > > > Reviewer: Adrian Farrel > > > Review Date: 27 September 2016 > > > IETF LC End Date: Not yet started > > > Intended Status: Standards Track > > > > > > =3D=3DSummary:=3D=3D > > > I have some minor concerns about this document that I think > > should be > > > resolved > > > before publication. > > > The volume of minor concerns add up to a significant concern > > although no > > > one > > > issue is large. I recommend that the Routing ADs discuss these > > issues further > > > with the authors and consider whether an updated I-D would need > > to be > > > re-reviewed by the WG. > > > > > > =3D=3DComments:=3D=3D > > > This document defines a mechanism to "bundle" status reports on > > the PWs > > > carried > > > on an MPLS tunnel. The effect is to significantly reduce the > > number of > > > messages > > > need in the (normal) stable state. > > > I don't see any problems with the mechanism defined and I am > > sure it would > > > work. > > > The writing style is mainly clear. > > > However, there is a host of minor issues and holes in the > > documentation that > > > puts the specification below the level necessary to guarantee > > interoperable > > > implementations. > > > My review is not as an implementer, and it worries me that if I > > find so many > > > questions and issues, an implementer would find far more. > > > I checked to see whether anyone had commented in WGLC that they > > had read > > > the > > > document and I didn't see anything (perhaps my list subscription > > is broken?) > > > > > > I agree with your comment. In fact the mechanism is a bit complex, and I > went out of my way to ask people a few years ago to check it for problems= . > At the time we fine tuned some things, and did not find any major > issues. I welcome anybody taking a close look at this ! > > > > =3D=3DMinor Issues:=3D=3D > > > > > > Section 1.3 > > > I think you need to give a reference for the base BNF you are > using. > > > You could choose from RFC 5234 or RFC 5511. > > > But it seems peculiar that you have set out to define your own > > notation for > > > things that can be expressed in existing BNF. > > > OK, maybe George has something to add here , as I cannot remember adding > this section. > > > > > > > > Section 4 > > > The figure makes it look like MPLS labels are 32 bits long. > > > I guess you could fix this by s/label/label stack entry/ > > > Or you could show all of the LSE fields. > > > > > > I changed it. I meant "Label" in a more liberal term , as you guessed. > > > > Section 4 > > > You have not described all of the fields in the figure. > > > What did I miss ? > > > > > > > > Section 4 > > > You have... > > > Channel type 0xZZ pending IANA allocation. > > > ...but no mention in the IANA section > > > The figure shows "0xZZ PW OAM Message", but surely this is > > > "PW Status Reduction Message" > > > > > > Sure , but it has not been allocated yet. This is for the RFC editor to > replace the text once the allocation is dune. > > > > > > Section 4 > > > In the description of the Session ID CRC16 seed really > > "recommended"? > > > I mean, is this "RECOMMENDED", and if so, why? > > > > > > You *do* need a locally selected, locally unique value. > > > It does not need to be unique over time, but you may need suggest= a > > > damping mechanism on re-use of session ID. > > > However, recommending this mechanism for generating session IDs > > seems > > > to me to be over-weaning. What is the reason? > > > > > > no - this is just a suggestion. Since this is local , it does not matter > , but I wanted a staring point that is known to work in case some junior > coder needed it. > Yes I agree that there should be a re-use and damping mechanism, but > that is over specifying it a bit. > > > > Section 4 > > > There are a number of rules expressed here about the setting of t= he > > > message fields (such as the Refresh Timer that is a "non zero > > unsigned > > > 16 bit integer value greater or equal to 10"). What happens if a > > > message is received that violates one of these rules. > > > > > > the remote PE will return a notification - 6 "PW configuration not > supported." . I'll add text to clarify this. > > > > > Section 4 > > > OLD > > > 7 bits of flags reserved for future use, they MUST be set > > to 0 on > > > transmission, and ignored on reception. > > > NEW > > > 6 bits of flags reserved for future use, they MUST be set > > to 0 on > > > transmission, and ignored on reception. > > > END > > > > > > good catch - thanks. > > > > > Section 4 > > > Do you want IANA to track the flags field? > > > > > > no. > I think this needs to be allocated by a new RFC. Is that not the default = ? > Making flags easy to allocate when there are only 6 bits is not wise and > will lead to misuse. > > > > Section 4 > > > You have... > > > It should be noted that the Checksum, Message Sequence > > Number, Last > > > Received Message Sequence Number, Message Type, Flags, and > > control > > > message body are OPTIONAL. > > > This *sounds* like each field is individually optional. But that > > is not > > > the case, I think (because the resulting message would be > > impossible to > > > parse). So you need to clarify. > > > Probably that the length field indicates where the sequence > > stops, or > > > that the whole set may be omitted or included en mass. > > > > > > yes- they are not OPTIONAL at random, but rather in sequence with the > length field used to parse where things stop.... > I'll add text to clarify this. > NEW: > It should be noted that the Checksum, Message Sequence Number, Last > Received Message Sequence Number, Message Type, Flags, and control > message body are OPTIONAL. The length field is used to parse how many > optional fields are included. Hence all optional fields that precede a > specific field that needs to be included in a specific implementation > MUST be included if that optional field is also included. > > > > > Section 5 opening paragraphs are confusing. > > > Either you have a "control message" or you have a "control > construct > > > carried on a status reduction message". > > > - It is possible you mean the former. > > > no - the control message is the full message, while the control message > construct is only the control information without the Checksum, > Message Sequence Number, Last Received Message Sequence Number, > Message Type, Flags. > what is missing is this : > > A PW refresh reduction message is also called a PW status refresh > reduction Control Message if it contains a control message construct. > > > > That is "There are two status reduction messages defined in thi= s > > > document and they are both control messages: the Notification > > message > > > and the PW Configuration message. > > > - It is possible you mean have the latter. > > > Thus, when you talk about the "message sequence number of the > > control > > > message" you really mean the "message sequence number of the > > status > > > reduction message that carries the control construct". > > > You can probably note that the control construct can be carried > on > > > a Notification message or a PW Configuration message. > > > You should probably also say whether the control construct can = be > > > carried on other (future) messages. > > > > > > the notification message is a different type , and cannot carry the > control construct. > the text I added should clarify that once a control structure is added , > ad pw refresh message is also known as a PW status refresh reduction > Control Message. > However i also fixed the text to say "message sequence number" instead > of "control message sequence number" for clarity. > > > > Section 5 > > > In 8.3 you list a number of notification codes. A little can be > > deduced > > > from their names, but you do not describe anywhere when or why > > most of > > > them are used (5.0.2.3 and 6 are the exceptions). You should, and > > > section 5 or 6 is probably the place. > > > These are really obvious. I do not see the point of adding obvious text. > Go look at all the BGP specs , most of them are extremely unreadable, > this is much more clear then any of those. > like if i receive an ack message sequence number that is after the last > message i sent , clearly is have a "Unacknowledged control message" > error... > > > > > > Section 5.0.1 > > > What is the setting of the C flag on the Notification message? > > > > > > The notification message has a different message type , and no C flag > defined in it. > i will add this : > The 7 bits of flags are reserved for future use, they MUST be set to 0 > transmission, and ignored on reception. > > > > Section 5.0.2 > > > The message has no > > > preset length limit, however its total length will be limited > > by the > > > transport network Maximum Transmit Unit (MTU). > > > This is fine, however: > > > - You probably want to add "Status Reduction messages MUST NOT be > > > fragmented." > > > yes. i thought this was obvious since there is no specification on how > to fragment the message itself... , but i will add it. > > > > > - You probably also want "If a sender has more configuration > > information > > > to send than will fit into one PW Configuration Message it may > > send > > > further messages carrying further TLVs." > > > yes. i thought this was obvious as well since we have a C bit. However i > will add it. > > > > > > > Section 5.0.2 > > > I think you need to define a generic TLV format so that new TLVs > can > > > be added and parsed over. Since you use a common format for your > > TLVs, > > > this should not be hard. > > > ok, but a TLV is a TLV .... i will add a picture of a TLV. > > > > > However, you also need to describe how "unknown" TLVs are handled= . > > > > > > The unknown TLVs are handled as per section 4 . I will add a bit of text > there to clarify that the U bit applies unknown TLVs inside a known > message as well as a completely unknown message. Thanks for catching this= . > > > > Section 5.0.2.1 > > > Is the MPLS-TP Tunnel ID TLV optional? 5.0.2.2 shows the PW ID > > > configured List TLV as optional, so it looks like the MPLS-TP > > Tunnel ID > > > might be mandatory TLV. > > > Furthermore, you seem to have said that the order of TLVs is > > arbitrary > > > but wouldn't it be best to have this TLV show up first? > > > What happens if there are multiple of this TLV present? > > > > > > There are multiple combinations of configuration TLVs that can result in > invalid configurations for multiple reasons. > All result in returning a notification of "PW configuration not > supported". > That is explained in section 6 > > > > > Section 5.0.2.2 (and 5.0.2.3) > > > The number of PW Path IDs in the TLV will be inferred by the > > length > > > of the TLV up to a maximum of 8. > > > Now, "The PW Path ID is a 32 octet pseudowire path identifier" > > > 8*32=3D256 > > > The Length field has 8 bits and so encodes a maximum of 255 octet= s. > > > So you can actually only carry 7 PW Path IDs in this TLV. > > > Furthermore, Length values that are not a multiple of 32 are an > > > encoding error, but you haven't stated how to handle encoding > > errors. > > > What happens if the same PW Path ID appears twice in a list? > > > yes good catch - 7 is the correct number. > There are multiple combinations of configuration TLVs that can result in > invalid configurations for multiple reasons. > All result in returning a notification of "PW configuration not > supported". > > > > > > > > Section 6 > > > A PE that desires to use the PW configuration message to > > verify the > > > configuration of PWs on a particular LSP, should advertise its > PW > > > configuration to the remote PE on LSPs that have active > keepalive > > > sessions. > > > I think that probably hidden in here is "MUST NOT include a PW > > > configuration message on a status reduction message unless the > local > > > protocol state is ACTIVE." > > > > > > Yes, this is implied in "A PE that desires to use the PW configuration > message to verify the configuration of PWs on a particular LSP, should > advertise its PW configuration to the remote PE on LSPs that have active > keepalive sessions. " > I will add it for clarity. > > > > > Section 6 > > > the following action SHOULD be taken: > > > -i. The local PW MUST be considered in "Not Forwarding" > > State. > > > That creates a composite "SHOULD-MUST" which is not very clear. > > > Suggest you change to... > > > the following actions are taken: > > > -i. MUST > > > -ii. SHOULD > > > -iii. SHOULD > > > > > > Yes , i fixed it as you suggested. > > > > Section 7 > > > Why does this section not discuss the Checksum field? Doesn't > > this add > > > a measure of security (at least against simple, random attacks)? > > > no. This protocol is for a direct attached point to point link. I'm not > clear how this would help in a attack given that anybody knows how to > calculate the checksum. > > > > > Should you also give guidance (here or in section 4) about when > > it is > > > acceptable to use a zero checksum. > > > > > > since i do not think that the checksum adds any security, i'm not clear > how it helps. Any transport link will have it's own error checking > mechanism anyway... This was only here in case some nasty people come > along an put this into a pseudoiwire ;-). And they should not ! > > > > Section 8.1 - meta-point to be addressed before the following iss= ue > > > with this section... > > > You seem to have an overly-complex assignment policy for this > > registry. > > > All of the types seem to have equal weight (i.e., there are no > > "special > > > purpose" values yet you cover the range with: > > > - Expert review > > > - IETF review > > > - FCFS > > > Since FCFS guarantees an assignment without any further review, w= hy > > > would anyone bother with Expert Review. For that matter, why wou= ld > > > anyone bother with IETF Review? > > > So, why not make life easier and say all code points are FCFS? > > > > > > because when one range is exhausted, the next range will be harder to > exhaust , and so forth. > From past experience, this allocation policy is better at protecting > the limited resources , then FCFS when i cannot foresee all possible > outcomes... > > > > Section 8.1 > > > s/IETF consensus/IETF review/ > > > > > > fixed. > > > > > Section 8.1 > > > You have a range assigned by Expert Review. It is a requirement > that > > > you give guidance to the experts about how they should review > > > requests. > > > > > > we did not do that in the past. I assume that the Expert is an Expert > in this field , and has good judgment. > maybe i should add "at sole discretion of the expert" ? > > > > Section 8.1 > > > The values 128 through 254 are assigned using FCFS. You cannot th= en > > > attempt to further constrain how the values are used (e.g., "for > > vendor > > > proprietary extensions"), and you should avoid the word > > "reserved" since > > > it has special meaning for IANA. > > > ??? i want the vendor proprietary extensions to be FCFS, does this not > say that ? > the point is that if something is not a proprietary extension it should > not use this. > for example it prevents people like me from using FEC type 128 for a > standard protocol ...;-) > > > > > > > > Section 8.2 > > > I have essentially an identical set of points about 8.2 carried > > from 8.1 > > > > > > Section 8.3 > > > Again the same set of comments. > > > Additionally, you need to tell IANA what the "Error?" column > > means. This > > > is probably... > > > For each value assigned IANA should also track whether the val= ue > > > constitutes an error as described in Section 5.0.1. When > > values are > > > assigned by IETF Review, the setting of this column must be > > > documented in the RFC that requests the allocation. For Exper= t > > > Review and FCFS assignments, the setting of this column must > > be made > > > clear by the requested at the time of assignment. > > > > > > ok will add it. > > > > =3D=3DNits:=3D=3D > > > > > > I believe Luca may want to change his reported affiliation. > > > > > > ok. > > > > > Abstract > > > OLD > > > This document describes a method for generating an aggregated > > > pseudowire status message on Multi-Protocol Label Switching > > (MPLS) > > > network Label Switched Path (LSP). > > > NEW > > > This document describes a method for generating an aggregated > > > pseudowire status message transmitted on a Multi-Protocol Labe= l > > > Switching (MPLS) Label Switched Path (LSP) to indicate the > > status of > > > one or more pseudowires carried on the LSP. > > > END > > > fixed. > > > > > > > > Introduction > > > Expand "PW" on first use. > > > s/they are setup/they are set up/ > > > > > > Section 2 > > > "MPLS Generic Associated Channel" needs a reference to 5586 > > > fixed. > > > > > > > > Throughout the document you need to be consistent (and with > > prior art) > > > about capitalisation ("generic associated channel" or "Generic > > Associated > > > Channel" etc.) and abbreviations ("GACH" or "G-ACh" etc.) > > > > > > yes- i fixed what I found , and the great RFC editor will do the rest. > > > > > Section 4 > > > Message Sequence Number > > > s/A unsigned/An unsigned/ > > > > > > Section 4 (from the figure) > > > OLD > > > | Last Received Seq Number | Message Type |U C Flags > | > > > NEW > > > | Last Received Seq Number | Message Type |U|C|Flags > | > > > END > > > > > > no C in notification messages.... Besides this I'm unclear what is > different in your suggestion. > > > > Section 4 Unknown flag bit. > > > s/MUST be acknowledge/MUST be acknowledged/ > > > > > > ok > > > > > The sub-section numbering in Section 5 is broken. You can have, > > > for example, "5.0.1". > > > > > > fixed > > > > > In a number of places you have "sub-TLVs" and in other places > > "TLVs". > > > I think they are all "TLVs". > > > yes, i mean sub-tlv because it's within another tlv. > > > > > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It > is > > > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP > > suddenly > > > come from since you want this to work for all LSPs (see also 8.2)= . > > > > > > no, this is what this is . If you want an MPLS tunnel ID , it would be > different. > > > > 2.1.1, 2.1.3, and 5.0.2.3 > > > "unprovisioned" > > > I think the word is "deprovisioned" > > > > > > unprovisioned means it is not provisioned. deprovisioned , i take to > mean that it was once provisioned, now it is not .... > I like the more generic "unprovisioned" > > > > Section 6 > > > If > > > a PE receives such a notification it should stop sending PW > > > configuration control messages for the duration of the PW > refresh > > > reduction keepalive session. > > > s/should/SHOULD/ > > > fixed. > > > > > > > > Section 8 > > > All the registries in this section are to be created or > > updated as > > > apropriate in the PW Name Spaces. > > > No such name space error. > > > I think you mean "Pseudowire Name Spaces (PWE3)" > > > s/apropriate/appropriate/ > > > > > > s/10. Author's Addresses/10. Authors' Addresses/ > > > fixed. > > > --001a113d67689908fb05485e73fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Luca et al,

I just confirmed the submis= sion for -02 and it=E2=80=99s up.

Cheers,
Andy


On Sun, Feb 12, 2017 at 6:56 PM, Luca Martini <lmartin= i@monoski.com> wrote:
Adria= n,
Sorry for the late response , this fell though the cracks.
I'm having some trouble with the ID submission tool, but the revision will be out shortly.
Comments below:
Thanks.
Luca

>=C2=A0 =C2=A0 =C2=A0> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0> From: Adrian Farrel [mailto:adrian@olddog.co.uk
>=C2=A0 =C2=A0 =C2=A0<mailto:a= drian@olddog.co.uk>]
>=C2=A0 =C2=A0 =C2=A0> Sent: Wednesday, September 28, 2016 9:05 AM >=C2=A0 =C2=A0 =C2=A0> To: rtg-ads@ietf.org <mailto:rtg-ads@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> Cc: rtg-di= r@ietf.org <mailto:rtg-dir@ietf.= org>;
>=C2=A0 =C2=A0 =C2=A0draft-ietf-pals-status-reduction.all@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-ietf-pals-status-reduction.all@ietf.org= >;
>=C2=A0 =C2=A0 =C2=A0> pals@ietf.org <mailto:pals@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> Subject: RtgDir review of draft-ietf-pals-stat= us-reduction-01.txt
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Hello,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I have been selected as the Routing Directorat= e reviewer for
>=C2=A0 =C2=A0 =C2=A0this draft. The
>=C2=A0 =C2=A0 =C2=A0> Routing Directorate seeks to review all routin= g or
>=C2=A0 =C2=A0 =C2=A0routing-related drafts as
>=C2=A0 =C2=A0 =C2=A0> they pass through IETF last call and IESG revi= ew, and sometimes
>=C2=A0 =C2=A0 =C2=A0on special
>=C2=A0 =C2=A0 =C2=A0> request. The purpose of the review is to provi= de assistance to
>=C2=A0 =C2=A0 =C2=A0the Routing
>=C2=A0 =C2=A0 =C2=A0> ADs.
>=C2=A0 =C2=A0 =C2=A0> For more information about the Routing Directo= rate, please see
>=C2=A0 =C2=A0 =C2=A0> http://trac.tools.i= etf.org/area/rtg/trac/wiki/RtgDir
>=C2=A0 =C2=A0 =C2=A0<http://trac.tools.ie= tf.org/area/rtg/trac/wiki/RtgDir>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Although these comments are primarily for the = use of the Routing
>=C2=A0 =C2=A0 =C2=A0ADs, it
>=C2=A0 =C2=A0 =C2=A0> would
>=C2=A0 =C2=A0 =C2=A0> be helpful if you could consider them along wi= th any other IETF
>=C2=A0 =C2=A0 =C2=A0Last Call
>=C2=A0 =C2=A0 =C2=A0> comments that you receive, and strive to resol= ve them through
>=C2=A0 =C2=A0 =C2=A0discussion or
>=C2=A0 =C2=A0 =C2=A0> by
>=C2=A0 =C2=A0 =C2=A0> updating the draft.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Document: draft-ietf-pals-status-reductio= n-01.txt
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 Reviewer: Adrian Farrel
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 Review Date: 27 September 2016
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 IETF LC End Date: Not yet started
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 Intended Status: Standards Track
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> =3D=3DSummary:=3D=3D
>=C2=A0 =C2=A0 =C2=A0> I have some minor concerns about this document= that I think
>=C2=A0 =C2=A0 =C2=A0should be
>=C2=A0 =C2=A0 =C2=A0> resolved
>=C2=A0 =C2=A0 =C2=A0> before publication.
>=C2=A0 =C2=A0 =C2=A0> The volume of minor concerns add up to a signi= ficant concern
>=C2=A0 =C2=A0 =C2=A0although no
>=C2=A0 =C2=A0 =C2=A0> one
>=C2=A0 =C2=A0 =C2=A0> issue is large. I recommend that the Routing A= Ds discuss these
>=C2=A0 =C2=A0 =C2=A0issues further
>=C2=A0 =C2=A0 =C2=A0> with the authors and consider whether an updat= ed I-D would need
>=C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0> re-reviewed by the WG.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> =3D=3DComments:=3D=3D
>=C2=A0 =C2=A0 =C2=A0> This document defines a mechanism to "bun= dle" status reports on
>=C2=A0 =C2=A0 =C2=A0the PWs
>=C2=A0 =C2=A0 =C2=A0> carried
>=C2=A0 =C2=A0 =C2=A0> on an MPLS tunnel. The effect is to significan= tly reduce the
>=C2=A0 =C2=A0 =C2=A0number of
>=C2=A0 =C2=A0 =C2=A0> messages
>=C2=A0 =C2=A0 =C2=A0> need in the (normal) stable state.
>=C2=A0 =C2=A0 =C2=A0> I don't see any problems with the mechanis= m defined and I am
>=C2=A0 =C2=A0 =C2=A0sure it would
>=C2=A0 =C2=A0 =C2=A0> work.
>=C2=A0 =C2=A0 =C2=A0> The writing style is mainly clear.
>=C2=A0 =C2=A0 =C2=A0> However, there is a host of minor issues and h= oles in the
>=C2=A0 =C2=A0 =C2=A0documentation that
>=C2=A0 =C2=A0 =C2=A0> puts the specification below the level necessa= ry to guarantee
>=C2=A0 =C2=A0 =C2=A0interoperable
>=C2=A0 =C2=A0 =C2=A0> implementations.
>=C2=A0 =C2=A0 =C2=A0> My review is not as an implementer, and it wor= ries me that if I
>=C2=A0 =C2=A0 =C2=A0find so many
>=C2=A0 =C2=A0 =C2=A0> questions and issues, an implementer would fin= d far more.
>=C2=A0 =C2=A0 =C2=A0> I checked to see whether anyone had commented = in WGLC that they
>=C2=A0 =C2=A0 =C2=A0had read
>=C2=A0 =C2=A0 =C2=A0> the
>=C2=A0 =C2=A0 =C2=A0> document and I didn't see anything (perhap= s my list subscription
>=C2=A0 =C2=A0 =C2=A0is broken?)
>=C2=A0 =C2=A0 =C2=A0>
>
I agree with your comment. In fact the mechanism is a bit compl= ex, and I
went out of my way to ask people a few years ago to check it for problems.<= br> At the time we fine tuned some things, and did not find any major
issues. I welcome anybody taking a close look at this !

>=C2=A0 =C2=A0 =C2=A0> =3D=3DMinor Issues:=3D=3D
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 1.3
>=C2=A0 =C2=A0 =C2=A0> I think you need to give a reference for the b= ase BNF you are using.
>=C2=A0 =C2=A0 =C2=A0> You could choose from RFC 5234 or RFC 5511. >=C2=A0 =C2=A0 =C2=A0> But it seems peculiar that you have set out to= define your own
>=C2=A0 =C2=A0 =C2=A0notation for
>=C2=A0 =C2=A0 =C2=A0> things that can be expressed in existing BNF.<= br> >
OK, maybe George has something to add here , as I cannot remember ad= ding
this section.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> The figure makes it look like MPLS labels are = 32 bits long.
>=C2=A0 =C2=A0 =C2=A0> I guess you could fix this by s/label/label st= ack entry/
>=C2=A0 =C2=A0 =C2=A0> Or you could show all of the LSE fields.
>=C2=A0 =C2=A0 =C2=A0>
>
I changed it. I meant "Label" in a more liberal term , as = you guessed.

>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> You have not described all of the fields in th= e figure.
>
What did I miss ?
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> You have...
>=C2=A0 =C2=A0 =C2=A0> Channel type 0xZZ pending IANA allocation.
>=C2=A0 =C2=A0 =C2=A0> ...but no mention in the IANA section
>=C2=A0 =C2=A0 =C2=A0> The figure shows "0xZZ PW OAM Message&quo= t;, but surely this is
>=C2=A0 =C2=A0 =C2=A0> "PW Status Reduction Message"
>=C2=A0 =C2=A0 =C2=A0>
>
Sure , but it has not been allocated yet. This is for the RFC editor= to
replace the text once the allocation is dune.

>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> In the description of the Session ID CRC16 see= d really
>=C2=A0 =C2=A0 =C2=A0"recommended"?
>=C2=A0 =C2=A0 =C2=A0> I mean, is this "RECOMMENDED", and i= f so, why?
>

>=C2=A0 =C2=A0 =C2=A0> You *do* need a locally selected, locally uniq= ue value.
>=C2=A0 =C2=A0 =C2=A0> It does not need to be unique over time, but y= ou may need suggest a
>=C2=A0 =C2=A0 =C2=A0> damping mechanism on re-use of session ID.
>=C2=A0 =C2=A0 =C2=A0> However, recommending this mechanism for gener= ating session IDs
>=C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0> to me to be over-weaning. What is the reason?<= br> >=C2=A0 =C2=A0 =C2=A0>
>
no - this is just a suggestion. Since this is local , it does not ma= tter
, but I wanted a staring point that is known to work in case some junior coder needed it.
Yes I agree that there should be a re-use and damping mechanism, but
that is over specifying it a bit.

>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> There are a number of rules expressed here abo= ut the setting of the
>=C2=A0 =C2=A0 =C2=A0> message fields (such as the Refresh Timer that= is a "non zero
>=C2=A0 =C2=A0 =C2=A0unsigned
>=C2=A0 =C2=A0 =C2=A0> 16 bit integer value greater or equal to 10&qu= ot;).=C2=A0 What happens if a
>=C2=A0 =C2=A0 =C2=A0> message is received that violates one of these= rules.
>=C2=A0 =C2=A0 =C2=A0>
>
the remote PE will return a notification - 6=C2=A0 "PW configur= ation not
supported." . I'll add text to clarify this.
>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> OLD
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 7 bits of flags res= erved for future use, they MUST be set
>=C2=A0 =C2=A0 =C2=A0to 0 on
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 transmission, and i= gnored on reception.
>=C2=A0 =C2=A0 =C2=A0> NEW
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 6 bits of flags res= erved for future use, they MUST be set
>=C2=A0 =C2=A0 =C2=A0to 0 on
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 transmission, and i= gnored on reception.
>=C2=A0 =C2=A0 =C2=A0> END
>=C2=A0 =C2=A0 =C2=A0>
>
good catch - thanks.
>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> Do you want IANA to track the flags field?
>=C2=A0 =C2=A0 =C2=A0>
>
no.
I think this needs to be allocated by a new RFC. Is that not the default ?<= br> Making flags easy to allocate when there are only 6 bits is not wise and will lead to misuse.

>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> You have...
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 It should be noted that the Check= sum, Message Sequence
>=C2=A0 =C2=A0 =C2=A0Number, Last
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Received Message Sequence Number,= Message Type, Flags, and
>=C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 message body are OPTIONAL.
>=C2=A0 =C2=A0 =C2=A0> This *sounds* like each field is individually = optional. But that
>=C2=A0 =C2=A0 =C2=A0is not
>=C2=A0 =C2=A0 =C2=A0> the case, I think (because the resulting messa= ge would be
>=C2=A0 =C2=A0 =C2=A0impossible to
>=C2=A0 =C2=A0 =C2=A0> parse). So you need to clarify.
>=C2=A0 =C2=A0 =C2=A0> Probably that the length field indicates where= the sequence
>=C2=A0 =C2=A0 =C2=A0stops, or
>=C2=A0 =C2=A0 =C2=A0> that the whole set may be omitted or included = en mass.
>=C2=A0 =C2=A0 =C2=A0>
>
yes- they are not OPTIONAL at random, but rather in sequence with th= e
length field used to parse where things stop....
I'll add text to clarify this.
NEW:
It should be noted that the Checksum, Message Sequence Num= ber, Last
Received Message Sequence Number, Message Type, Flags, and control
message body are OPTIONAL. The length field is used to parse how man= y
optional fields are included. Hence all optional fields that precede a
specific field that needs to be included in a specific implementation
MUST be included if that optional field is also included.
>
>=C2=A0 =C2=A0 =C2=A0> Section 5 opening paragraphs are confusing. >=C2=A0 =C2=A0 =C2=A0> Either you have a "control message" = or you have a "control construct
>=C2=A0 =C2=A0 =C2=A0> carried on a status reduction message". >=C2=A0 =C2=A0 =C2=A0> - It is possible you mean the former.
>
no - the control message is the full message, while the control mess= age
construct is only the control information without the Checksum,
=C2=A0Message Sequence Number, Last Received Message Seque= nce Number,
Message Type, Flags.
what is missing is this :

A PW refresh reduction message is also called a PW status refresh
reduction Control Message if it contains a=C2=A0 control message construct.=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0That is "There are two status= reduction messages defined in this
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0document and they are both control= messages: the Notification
>=C2=A0 =C2=A0 =C2=A0message
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0and the PW Configuration message.<= br> >=C2=A0 =C2=A0 =C2=A0> - It is possible you mean have the latter.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Thus, when you talk about the &quo= t;message sequence number of the
>=C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0message" you really mean the = "message sequence number of the
>=C2=A0 =C2=A0 =C2=A0status
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0reduction message that carries the= control construct".
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0You can probably note that the con= trol construct can be carried on
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0a Notification message or a PW Con= figuration message.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0You should probably also say wheth= er the control construct can be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0carried on other (future) messages= .
>=C2=A0 =C2=A0 =C2=A0>
>
the notification message is a different type , and cannot carry the<= br> control construct.
the text I added should clarify that once a control structure is added , ad pw refresh message is also known as a PW status refresh reduction
Control Message.
However i also fixed the text to say "message sequence number" in= stead
of "control message sequence number" for clarity.

>=C2=A0 =C2=A0 =C2=A0> Section 5
>=C2=A0 =C2=A0 =C2=A0> In 8.3 you list a number of notification codes= . A little can be
>=C2=A0 =C2=A0 =C2=A0deduced
>=C2=A0 =C2=A0 =C2=A0> from their names, but you do not describe anyw= here when or why
>=C2=A0 =C2=A0 =C2=A0most of
>=C2=A0 =C2=A0 =C2=A0> them are used (5.0.2.3 and 6 are the exception= s). You should, and
>=C2=A0 =C2=A0 =C2=A0> section 5 or 6 is probably the place.
>
These are really obvious. I do not see the point of adding obvious t= ext.
Go look at all the BGP specs , most of them are extremely unreadable,
this is much more clear then any of those.
like if i receive an ack message sequence number that is after the last
message i sent , clearly is have a "Unacknowledged control message&quo= t; error...

>
>=C2=A0 =C2=A0 =C2=A0> Section 5.0.1
>=C2=A0 =C2=A0 =C2=A0> What is the setting of the C flag on the Notif= ication message?
>=C2=A0 =C2=A0 =C2=A0>
>
The notification message has a different message type , and no C fla= g
defined in it.
i will add this :
=C2=A0The 7 bits of flags are reserved for future use, they MUST be set to = 0
transmission, and ignored on reception.

>=C2=A0 =C2=A0 =C2=A0> Section 5.0.2
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The message has no
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 preset length limit, however its = total length will be limited
>=C2=A0 =C2=A0 =C2=A0by the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 transport network Maximum Transmi= t Unit (MTU).
>=C2=A0 =C2=A0 =C2=A0> This is fine, however:
>=C2=A0 =C2=A0 =C2=A0> - You probably want to add "Status Reduct= ion messages MUST NOT be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0fragmented."
>
yes. i thought this was obvious since there is no specification on h= ow
to fragment the message itself... , but i will add it.
>
>=C2=A0 =C2=A0 =C2=A0> - You probably also want "If a sender has= more configuration
>=C2=A0 =C2=A0 =C2=A0information
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0to send than will fit into one PW = Configuration Message it may
>=C2=A0 =C2=A0 =C2=A0send
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0further messages carrying further = TLVs."
>
yes. i thought this was obvious as well since we have a C bit. Howev= er i
will add it.

>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 5.0.2
>=C2=A0 =C2=A0 =C2=A0> I think you need to define a generic TLV forma= t so that new TLVs can
>=C2=A0 =C2=A0 =C2=A0> be added and parsed over. Since you use a comm= on format for your
>=C2=A0 =C2=A0 =C2=A0TLVs,
>=C2=A0 =C2=A0 =C2=A0> this should not be hard.
>
ok, but a TLV is a TLV .... i will add a picture of a TLV.
>
>=C2=A0 =C2=A0 =C2=A0> However, you also need to describe how "u= nknown" TLVs are handled.
>=C2=A0 =C2=A0 =C2=A0>
>
The unknown TLVs are handled as per section 4 . I will add a bit of = text
there to clarify that the U bit applies unknown TLVs inside a known
message as well as a completely unknown message. Thanks for catching this.<= br>
>=C2=A0 =C2=A0 =C2=A0> Section 5.0.2.1
>=C2=A0 =C2=A0 =C2=A0> Is the MPLS-TP Tunnel ID TLV optional? 5.0.2.2= shows the PW ID
>=C2=A0 =C2=A0 =C2=A0> configured List TLV as optional, so it looks l= ike the MPLS-TP
>=C2=A0 =C2=A0 =C2=A0Tunnel ID
>=C2=A0 =C2=A0 =C2=A0> might be mandatory TLV.
>=C2=A0 =C2=A0 =C2=A0> Furthermore, you seem to have said that the or= der of TLVs is
>=C2=A0 =C2=A0 =C2=A0arbitrary
>=C2=A0 =C2=A0 =C2=A0> but wouldn't it be best to have this TLV s= how up first?
>=C2=A0 =C2=A0 =C2=A0> What happens if there are multiple of this TLV= present?
>=C2=A0 =C2=A0 =C2=A0>
>
There are multiple combinations of configuration TLVs that can resul= t in
invalid configurations for multiple reasons.
All result in returning a notification of "PW=C2=A0 configuration not = supported".
That is explained in section 6
>
>=C2=A0 =C2=A0 =C2=A0> Section 5.0.2.2 (and 5.0.2.3)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The number of PW Path IDs in the = TLV will be inferred by the
>=C2=A0 =C2=A0 =C2=A0length
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 of the TLV up to a maximum of 8.<= br> >=C2=A0 =C2=A0 =C2=A0> Now, "The PW Path ID is a 32 octet pseudo= wire path identifier"
>=C2=A0 =C2=A0 =C2=A0> 8*32=3D256
>=C2=A0 =C2=A0 =C2=A0> The Length field has 8 bits and so encodes a m= aximum of 255 octets.
>=C2=A0 =C2=A0 =C2=A0> So you can actually only carry 7 PW Path IDs i= n this TLV.
>=C2=A0 =C2=A0 =C2=A0> Furthermore, Length values that are not a mult= iple of 32 are an
>=C2=A0 =C2=A0 =C2=A0> encoding error, but you haven't stated how= to handle encoding
>=C2=A0 =C2=A0 =C2=A0errors.
>=C2=A0 =C2=A0 =C2=A0> What happens if the same PW Path ID appears tw= ice in a list?
>
yes good catch - 7 is the correct number.
There are multiple combinations of configuration TLVs that can result in invalid configurations for multiple reasons.
All result in returning a notification of "PW=C2=A0 configuration not = supported".
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 6
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 A PE that desires to use the PW c= onfiguration message to
>=C2=A0 =C2=A0 =C2=A0verify the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 configuration of PWs on a particu= lar LSP, should advertise its PW
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 configuration to the remote PE on= LSPs that have active keepalive
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 sessions.
>=C2=A0 =C2=A0 =C2=A0> I think that probably hidden in here is "= MUST NOT include a PW
>=C2=A0 =C2=A0 =C2=A0> configuration message on a status reduction me= ssage unless the local
>=C2=A0 =C2=A0 =C2=A0> protocol state is ACTIVE."
>=C2=A0 =C2=A0 =C2=A0>
>
Yes, this is implied in "A PE that desires to use the PW config= uration
message to verify the configuration of PWs on a particular= LSP, should
advertise its PW configuration to the remote PE on LSPs that have active keepalive sessions. "
I will add it for clarity.


>=C2=A0 =C2=A0 =C2=A0> Section 6
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the following action SHOULD be ta= ken:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-i. The local= PW MUST be considered in "Not Forwarding"
>=C2=A0 =C2=A0 =C2=A0State.
>=C2=A0 =C2=A0 =C2=A0> That creates a composite "SHOULD-MUST&quo= t; which is not very clear.
>=C2=A0 =C2=A0 =C2=A0> Suggest you change to...
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the following actions are taken:<= br> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-i. MUST
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-ii. SHOULD >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-iii. SHOULD<= br> >=C2=A0 =C2=A0 =C2=A0>
>
Yes , i fixed it as you suggested.

>=C2=A0 =C2=A0 =C2=A0> Section 7
>=C2=A0 =C2=A0 =C2=A0> Why does this section not discuss the Checksum= field? Doesn't
>=C2=A0 =C2=A0 =C2=A0this add
>=C2=A0 =C2=A0 =C2=A0> a measure of security (at least against simple= , random attacks)?
>
no. This protocol is for a direct attached point to point link. I= 9;m not
clear how this would help in a attack given that anybody knows how to
calculate the checksum.


>=C2=A0 =C2=A0 =C2=A0> Should you also give guidance (here or in sect= ion 4) about when
>=C2=A0 =C2=A0 =C2=A0it is
>=C2=A0 =C2=A0 =C2=A0> acceptable to use a zero checksum.
>=C2=A0 =C2=A0 =C2=A0>
>
since i do not think that the checksum adds any security, i'm no= t clear
how it helps. Any transport link will have it's own error checking
mechanism anyway... This was only here in case some nasty people come
along an put this into a pseudoiwire ;-). And they should not !

>=C2=A0 =C2=A0 =C2=A0> Section 8.1 - meta-point to be addressed befor= e the following issue
>=C2=A0 =C2=A0 =C2=A0> with this section...
>=C2=A0 =C2=A0 =C2=A0> You seem to have an overly-complex assignment = policy for this
>=C2=A0 =C2=A0 =C2=A0registry.
>=C2=A0 =C2=A0 =C2=A0> All of the types seem to have equal weight (i.= e., there are no
>=C2=A0 =C2=A0 =C2=A0"special
>=C2=A0 =C2=A0 =C2=A0> purpose" values yet you cover the range w= ith:
>=C2=A0 =C2=A0 =C2=A0> - Expert review
>=C2=A0 =C2=A0 =C2=A0> - IETF review
>=C2=A0 =C2=A0 =C2=A0> - FCFS
>=C2=A0 =C2=A0 =C2=A0> Since FCFS guarantees an assignment without an= y further review, why
>=C2=A0 =C2=A0 =C2=A0> would anyone bother with Expert Review.=C2=A0 = For that matter, why would
>=C2=A0 =C2=A0 =C2=A0> anyone bother with IETF Review?
>=C2=A0 =C2=A0 =C2=A0> So, why not make life easier and say all code = points are FCFS?
>=C2=A0 =C2=A0 =C2=A0>
>
because when one range is exhausted, the next range will be harder t= o
exhaust , and so forth.
>From past experience, this allocation policy is=C2=A0 better at protecting<= br> the limited resources , then FCFS when i cannot foresee all possible
outcomes...

>=C2=A0 =C2=A0 =C2=A0> Section 8.1
>=C2=A0 =C2=A0 =C2=A0> s/IETF consensus/IETF review/
>=C2=A0 =C2=A0 =C2=A0>
>
fixed.
>
>=C2=A0 =C2=A0 =C2=A0> Section 8.1
>=C2=A0 =C2=A0 =C2=A0> You have a range assigned by Expert Review. It= is a requirement that
>=C2=A0 =C2=A0 =C2=A0> you give guidance to the experts about how the= y should review
>=C2=A0 =C2=A0 =C2=A0> requests.
>=C2=A0 =C2=A0 =C2=A0>
>
we did not do that in the past.=C2=A0 I assume that the Expert is an= Expert
in this field , and has good judgment.
maybe i should add "at sole discretion of the expert" ?

>=C2=A0 =C2=A0 =C2=A0> Section 8.1
>=C2=A0 =C2=A0 =C2=A0> The values 128 through 254 are assigned using = FCFS. You cannot then
>=C2=A0 =C2=A0 =C2=A0> attempt to further constrain how the values ar= e used (e.g., "for
>=C2=A0 =C2=A0 =C2=A0vendor
>=C2=A0 =C2=A0 =C2=A0> proprietary extensions"), and you should = avoid the word
>=C2=A0 =C2=A0 =C2=A0"reserved" since
>=C2=A0 =C2=A0 =C2=A0> it has special meaning for IANA.
>
??? i want the vendor proprietary extensions to be FCFS, does this n= ot
say that ?
the point is that if something is not a proprietary extension it should
not use this.
for example it prevents people like me from using FEC type 128 for a
standard protocol ...;-)


>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 8.2
>=C2=A0 =C2=A0 =C2=A0> I have essentially an identical set of points = about 8.2 carried
>=C2=A0 =C2=A0 =C2=A0from 8.1
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 8.3
>=C2=A0 =C2=A0 =C2=A0> Again the same set of comments.
>=C2=A0 =C2=A0 =C2=A0> Additionally, you need to tell IANA what the &= quot;Error?" column
>=C2=A0 =C2=A0 =C2=A0means. This
>=C2=A0 =C2=A0 =C2=A0> is probably...
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 For each value assigned IANA shou= ld also track whether the value
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 constitutes an error as described= in Section 5.0.1.=C2=A0 When
>=C2=A0 =C2=A0 =C2=A0values are
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 assigned by IETF Review, the sett= ing of this column must be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 documented in the RFC that reques= ts the allocation.=C2=A0 For Expert
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Review and FCFS assignments, the = setting of this column must
>=C2=A0 =C2=A0 =C2=A0be made
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 clear by the requested at the tim= e of assignment.
>=C2=A0 =C2=A0 =C2=A0>
>
ok will add it.

>=C2=A0 =C2=A0 =C2=A0> =3D=3DNits:=3D=3D
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I believe Luca may want to change his reported= affiliation.
>=C2=A0 =C2=A0 =C2=A0>
>
ok.
>
>=C2=A0 =C2=A0 =C2=A0> Abstract
>=C2=A0 =C2=A0 =C2=A0> OLD
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This document describes a method = for generating an aggregated
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 pseudowire status message on Mult= i-Protocol Label Switching
>=C2=A0 =C2=A0 =C2=A0(MPLS)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 network Label Switched Path (LSP)= .
>=C2=A0 =C2=A0 =C2=A0> NEW
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 This document describes a method = for generating an aggregated
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 pseudowire status message transmi= tted on a Multi-Protocol Label
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Switching (MPLS) Label Switched P= ath (LSP) to indicate the
>=C2=A0 =C2=A0 =C2=A0status of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 one or more pseudowires carried o= n the LSP.
>=C2=A0 =C2=A0 =C2=A0> END
>
fixed.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Introduction
>=C2=A0 =C2=A0 =C2=A0> Expand "PW" on first use.
>=C2=A0 =C2=A0 =C2=A0> s/they are setup/they are set up/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 2
>=C2=A0 =C2=A0 =C2=A0> "MPLS Generic Associated Channel" ne= eds a reference to 5586
>
fixed.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Throughout the document you need to be consist= ent (and with
>=C2=A0 =C2=A0 =C2=A0prior art)
>=C2=A0 =C2=A0 =C2=A0> about capitalisation ("generic associated= channel" or "Generic
>=C2=A0 =C2=A0 =C2=A0Associated
>=C2=A0 =C2=A0 =C2=A0> Channel" etc.) and abbreviations ("G= ACH" or "G-ACh" etc.)
>=C2=A0 =C2=A0 =C2=A0>
>
yes-=C2=A0 i fixed what I found , and the great RFC editor will do t= he rest.
>
>=C2=A0 =C2=A0 =C2=A0> Section 4
>=C2=A0 =C2=A0 =C2=A0> Message Sequence Number
>=C2=A0 =C2=A0 =C2=A0> s/A unsigned/An unsigned/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 4 (from the figure)
>=C2=A0 =C2=A0 =C2=A0> OLD
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 |=C2=A0 Last Received Seq Number= =C2=A0 =C2=A0 =C2=A0| Message Type=C2=A0 |U C Flags=C2=A0 =C2=A0 =C2=A0 | >=C2=A0 =C2=A0 =C2=A0> NEW
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 |=C2=A0 Last Received Seq Number= =C2=A0 =C2=A0 =C2=A0| Message Type=C2=A0 |U|C|Flags=C2=A0 =C2=A0 =C2=A0 | >=C2=A0 =C2=A0 =C2=A0> END
>=C2=A0 =C2=A0 =C2=A0>
>
no C in notification messages.... Besides this I'm unclear what = is
different in your suggestion.

>=C2=A0 =C2=A0 =C2=A0> Section 4 Unknown flag bit.
>=C2=A0 =C2=A0 =C2=A0> s/MUST be acknowledge/MUST be acknowledged/ >=C2=A0 =C2=A0 =C2=A0>
>
ok
>
>=C2=A0 =C2=A0 =C2=A0> The sub-section numbering in Section 5 is brok= en. You can have,
>=C2=A0 =C2=A0 =C2=A0> for example, "5.0.1".
>=C2=A0 =C2=A0 =C2=A0>
>
fixed
>
>=C2=A0 =C2=A0 =C2=A0> In a number of places you have "sub-TLVs&= quot; and in other places
>=C2=A0 =C2=A0 =C2=A0"TLVs".
>=C2=A0 =C2=A0 =C2=A0> I think they are all "TLVs".
>
yes, i mean sub-tlv because it's within another tlv.


>=C2=A0 =C2=A0 =C2=A0> In 5.0.2.1 "the address of the MPLS-TP tu= nnel ID" is confused. It is
>=C2=A0 =C2=A0 =C2=A0> "the identifier of the MPLS tunnel".= Indeed, where did MPLS-TP
>=C2=A0 =C2=A0 =C2=A0suddenly
>=C2=A0 =C2=A0 =C2=A0> come from since you want this to work for all = LSPs (see also 8.2).
>=C2=A0 =C2=A0 =C2=A0>
>
no, this is what this is . If you want an MPLS tunnel ID , it would = be
different.

>=C2=A0 =C2=A0 =C2=A0> 2.1.1, 2.1.3, and 5.0.2.3
>=C2=A0 =C2=A0 =C2=A0> "unprovisioned"
>=C2=A0 =C2=A0 =C2=A0> I think the word is "deprovisioned"<= br> >=C2=A0 =C2=A0 =C2=A0>
>
unprovisioned means it is not provisioned. deprovisioned , i take to=
mean that it was once provisioned, now it is not ....
I like the more generic "unprovisioned"

>=C2=A0 =C2=A0 =C2=A0> Section 6
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 If
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 a PE receives such a notification= it should stop sending PW
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 configuration control messages fo= r the duration of the PW refresh
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 reduction keepalive session.
>=C2=A0 =C2=A0 =C2=A0> s/should/SHOULD/
>
fixed.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 8
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 All the registries in this sectio= n are to be created or
>=C2=A0 =C2=A0 =C2=A0updated as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 apropriate in the PW Name Spaces.=
>=C2=A0 =C2=A0 =C2=A0> No such name space error.
>=C2=A0 =C2=A0 =C2=A0> I think you mean "Pseudowire Name Spaces = (PWE3)"
>=C2=A0 =C2=A0 =C2=A0> s/apropriate/appropriate/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> s/10. Author's Addresses/10. Authors' = Addresses/
>
fixed.



--001a113d67689908fb05485e73fd-- From nobody Mon Feb 13 10:59:38 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EE51297CE; Mon, 13 Feb 2017 10:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 WzLY5-jIy4nR; Mon, 13 Feb 2017 10:59:35 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE291297B8; Mon, 13 Feb 2017 10:59:35 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DIxUNL025350; Mon, 13 Feb 2017 18:59:30 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DIxQZC025329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2017 18:59:28 GMT From: "Adrian Farrel" To: "'Luca Martini'" , "'Andrew G. Malis'" , "'George Swallow'" , "'Elisa Bellagamba'" References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <58A0F649.7090301@monoski.com> In-Reply-To: <58A0F649.7090301@monoski.com> Date: Mon, 13 Feb 2017 18:59:24 -0000 Message-ID: <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4vo8J6wBQZFbSvY6b5rTwOAF7nwH7KBPWAn2FA1kCSZrYWJ5kvt4w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.001 X-TM-AS-Result: No--20.801-10.0-31-10 X-imss-scan-details: No--20.801-10.0-31-10 X-TMASE-MatchedRID: EMyCvCfVN1Fm2M+WdBiaRLdQIb8hCnY+EtdrY/Wb3fOp0TM4Pvf0QVdW JfEqbx6MtnL5EJYaKJT89WDKQGB2Ljxz5tDhhD0GnhHKNOYbLL49Z8UKMHjz4ZgWnaLDiGghIE9 v7dw1ta66dfDybokxRLVN0yuAcuwfWNPIxk1QrbR2IsPC9Z62GJE+3DCX3uibCVuEXtlNqcs9CU on0NTGec4WZ2e8JNtqmea15mW1PaXypyieQZBHiH/pBSMMVbhlpfVcx39Kq+7+9hPYcyW1ZI/x1 Ofbpz/fjXsFLEEP2Yq6oOKV8cM+m63gEYRSDbsNT7RVRbrn8wsZYA38gj3BxM2mvbig5LjGrX2B 4yCTgci5F0lgaETIUiuPV88ja/tdeaJohvG878aRfvUfL+585u4dka7Cjort9YBezwhBfW4b4fB 6yXNvBizSHqTnTaYvvTyMtG3v9FQIaofrtSGke3pwT5vp/xalLAnNohUyMa0ujyxRHwe+HMbK+p u0ZYwRtObqKvOLcVCw/gB9oTBycVUOzv+ERMvrJmbrB1j4XwpUXmZR3qwgxpsoi2XrUn/Jsuf7R WbvUtyrusVRy4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: draft-ietf-pals-status-reduction@ietf.org, pals-chairs@ietf.org, "'BRUNGARD, DEBORAH A'" , pals@ietf.org Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:59:37 -0000 Hi Luca, Love monoski.com! You've done a fine job with this. Thanks. Just cutting down to a few minor points that are so trivial I'm ashamed = to type... > > > Section 4 > > > You have not described all of the fields in the figure. > > > What did I miss ? - MPLS LSP (tunnel) Label Stack Entry=20 - GAL - 0 0 0 1 - Version - Reserved =20 But these probably only need a group entry pointing at another doc. > > > > > > Section 4 > > > You have... > > > Channel type 0xZZ pending IANA allocation. > > > ...but no mention in the IANA section > > > The figure shows "0xZZ PW OAM Message", but surely this is > > > "PW Status Reduction Message" > > > > > > Sure , but it has not been allocated yet. This is for the RFC editor = to > replace the text once the allocation is dune. Yeah, but if you don't have 0xZZ or "PW OAM Message" in the IANA = Considerations section (section 8) it seems unlikely that IANA will do = anything and so the RFC Editor will not be able to replace ZZ with = anything. > > > Section 4 > > > Do you want IANA to track the flags field? > no. > I think this needs to be allocated by a new RFC. Is that not the = default ? > Making flags easy to allocate when there are only 6 bits is not wise = and > will lead to misuse. You would still need an RFC to allocate the flags. The difference is that, without the registry, several RFCs may become = "confused" about which flags they have allocated. The IANA registry provides a way of preventing clashes. > > > Section 5 > > > In 8.3 you list a number of notification codes. A little can = be > > deduced > > > from their names, but you do not describe anywhere when or why > > most of > > > them are used (5.0.2.3 and 6 are the exceptions). You should, = and > > > section 5 or 6 is probably the place. > > > These are really obvious. I do not see the point of adding obvious = text. > Go look at all the BGP specs , most of them are extremely unreadable, > this is much more clear then any of those. > like if i receive an ack message sequence number that is after the = last > message i sent , clearly is have a "Unacknowledged control message" = error... Ah, and there was I thinking that this would be a "Control message = acknowledgement" error, while "Unacknowledged control message" would be = used when a control message went unacknowledged. :-) I don't think "other documents are worse" is the best argument you've = ever used, but I'm not going to fight this. It's up to the AD and = shepherd. > > > Section 8.1 > > > You have a range assigned by Expert Review. It is a = requirement that > > > you give guidance to the experts about how they should review > > > requests. > > we did not do that in the past. I assume that the Expert is an Expert > in this field , and has good judgment. > maybe i should add "at sole discretion of the expert" ? Times may have changed. Let's leave this for the AD to worry about. > > > Section 8.1 > > > The values 128 through 254 are assigned using FCFS. You cannot = then > > > attempt to further constrain how the values are used (e.g., = "for > > vendor > > > proprietary extensions"), and you should avoid the word > > "reserved" since > > > it has special meaning for IANA. > > > ??? i want the vendor proprietary extensions to be FCFS, does this not > say that ? > the point is that if something is not a proprietary extension it = should > not use this. > for example it prevents people like me from using FEC type 128 for a > standard protocol ...;-) Afraid it doesn't FCFS means "open season". Anyone can get a FCFS code point for any use. Again, the AD can help sort this out. > > > The sub-section numbering in Section 5 is broken. You can = have, > > > for example, "5.0.1". > > > > > > fixed > > > > > In a number of places you have "sub-TLVs" and in other places > > "TLVs". > > > I think they are all "TLVs". > > > yes, i mean sub-tlv because it's within another tlv. >=20 >=20 > > > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. = It is > > > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP > > suddenly > > > come from since you want this to work for all LSPs (see also = 8.2). > > > > > > no, this is what this is . If you want an MPLS tunnel ID , it would be > different. Shrug. I don't think it's an address. I think its and ID. > > > 2.1.1, 2.1.3, and 5.0.2.3 > > > "unprovisioned" > > > I think the word is "deprovisioned" > > unprovisioned means it is not provisioned. deprovisioned , i take to > mean that it was once provisioned, now it is not .... > I like the more generic "unprovisioned" Hmmm. The phrase would be "not provisioned".=20 "unprovisioned" apparently gives rise to confusion :-) From nobody Mon Feb 13 15:28:46 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12F812953B; Mon, 13 Feb 2017 15:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DIygfbzhzUHj; Mon, 13 Feb 2017 15:28:43 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 00AD3129430; Mon, 13 Feb 2017 15:28:42 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1DNPJDT009197; Mon, 13 Feb 2017 18:28:42 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 28knbeshw2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Feb 2017 18:28:41 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1DNSeOn020847; Mon, 13 Feb 2017 18:28:40 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1DNSQEj020635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Feb 2017 18:28:34 -0500 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 13 Feb 2017 23:28:14 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.162]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 18:28:13 -0500 From: "BRUNGARD, DEBORAH A" To: "adrian@olddog.co.uk" , "'Luca Martini'" , "'Andrew G. Malis'" , "'George Swallow'" , "'Elisa Bellagamba'" Thread-Topic: RtgDir review of draft-ietf-pals-status-reduction-01.txt Thread-Index: AQHShYu4xh/k4mkLtEaCzQfvf5QyDaFnn08A///RhuA= Date: Mon, 13 Feb 2017 23:28:12 +0000 Message-ID: References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <58A0F649.7090301@monoski.com> <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> In-Reply-To: <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.215.219] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-13_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702130219 Archived-At: Cc: "draft-ietf-pals-status-reduction@ietf.org" , "pals-chairs@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:28:45 -0000 TXVjaCB0aGFua3MgQWRyaWFuIGZvciB5b3VyIHZlcnkgY2FyZWZ1bCByZXZpZXcgLSBhbmQgdGhh bmtzIEx1Y2EgZm9yIHBpY2tpbmcgdXAgdGhlIHBlbiBvbiB0aGlzIGxvbmcgc3RhbmRpbmcgdW5w cm92aXNpb25lZCBkb2N1bWVudDotKQ0KDQpCZWxvdywgYW5zd2VycyBmb3IgQUQgaXRlbXMsIGFu ZCBhIGNvdXBsZSBvZiBvdGhlcnMgd2hpY2ggSSBjb3VsZCBub3QgcmVzaXN0Lg0KDQpEZWJvcmFo DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWRyaWFuIEZhcnJlbCBb bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWtdDQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTMs IDIwMTcgMTo1OSBQTQ0KPiBUbzogJ0x1Y2EgTWFydGluaScgPGxtYXJ0aW5pQG1vbm9za2kuY29t PjsgJ0FuZHJldyBHLiBNYWxpcycNCj4gPGFnbWFsaXNAZ21haWwuY29tPjsgJ0dlb3JnZSBTd2Fs bG93JyA8c3dhbGxvdy5pZXRmQGdtYWlsLmNvbT47ICdFbGlzYQ0KPiBCZWxsYWdhbWJhJyA8RWxp c2EuYmVsbGFnYW1iYUBnbWFpbC5jb20+DQo+IENjOiBkcmFmdC1pZXRmLXBhbHMtc3RhdHVzLXJl ZHVjdGlvbkBpZXRmLm9yZzsgcGFscy1jaGFpcnNAaWV0Zi5vcmc7IEJSVU5HQVJELA0KPiBERUJP UkFIIEEgPGRiMzU0NkBhdHQuY29tPjsgcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUnRn RGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXBhbHMtc3RhdHVzLXJlZHVjdGlvbi0wMS50eHQNCj4g DQo+IEhpIEx1Y2EsDQo+IA0KPiBMb3ZlIG1vbm9za2kuY29tIQ0KPiANCj4gWW91J3ZlIGRvbmUg YSBmaW5lIGpvYiB3aXRoIHRoaXMuIFRoYW5rcy4NCj4gDQo+IEp1c3QgY3V0dGluZyBkb3duIHRv IGEgZmV3IG1pbm9yIHBvaW50cyB0aGF0IGFyZSBzbyB0cml2aWFsIEknbSBhc2hhbWVkIHRvDQo+ IHR5cGUuLi4NCj4gDQo+ID4gPiAgICAgPiBTZWN0aW9uIDQNCj4gPiA+ICAgICA+IFlvdSBoYXZl IG5vdCBkZXNjcmliZWQgYWxsIG9mIHRoZSBmaWVsZHMgaW4gdGhlIGZpZ3VyZS4NCj4gPiA+DQo+ ID4gV2hhdCBkaWQgSSBtaXNzID8NCj4gDQo+IC0gIE1QTFMgTFNQICh0dW5uZWwpIExhYmVsIFN0 YWNrIEVudHJ5DQo+IC0gIEdBTA0KPiAtIDAgMCAwIDENCj4gLSBWZXJzaW9uDQo+IC0gUmVzZXJ2 ZWQNCj4gDQo+IEJ1dCB0aGVzZSBwcm9iYWJseSBvbmx5IG5lZWQgYSBncm91cCBlbnRyeSBwb2lu dGluZyBhdCBhbm90aGVyIGRvYy4NCj4gDQo+ID4gPiAgICAgPg0KPiA+ID4gICAgID4gU2VjdGlv biA0DQo+ID4gPiAgICAgPiBZb3UgaGF2ZS4uLg0KPiA+ID4gICAgID4gQ2hhbm5lbCB0eXBlIDB4 WlogcGVuZGluZyBJQU5BIGFsbG9jYXRpb24uDQo+ID4gPiAgICAgPiAuLi5idXQgbm8gbWVudGlv biBpbiB0aGUgSUFOQSBzZWN0aW9uDQo+ID4gPiAgICAgPiBUaGUgZmlndXJlIHNob3dzICIweFpa IFBXIE9BTSBNZXNzYWdlIiwgYnV0IHN1cmVseSB0aGlzIGlzDQo+ID4gPiAgICAgPiAiUFcgU3Rh dHVzIFJlZHVjdGlvbiBNZXNzYWdlIg0KPiA+ID4gICAgID4NCj4gPiA+DQo+ID4gU3VyZSAsIGJ1 dCBpdCBoYXMgbm90IGJlZW4gYWxsb2NhdGVkIHlldC4gVGhpcyBpcyBmb3IgdGhlIFJGQyBlZGl0 b3IgdG8NCj4gPiByZXBsYWNlIHRoZSB0ZXh0IG9uY2UgdGhlIGFsbG9jYXRpb24gaXMgZHVuZS4N Cj4gDQo+IFllYWgsIGJ1dCBpZiB5b3UgZG9uJ3QgaGF2ZSAweFpaIG9yICJQVyBPQU0gTWVzc2Fn ZSIgaW4gdGhlIElBTkENCj4gQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiAoc2VjdGlvbiA4KSBpdCBz ZWVtcyB1bmxpa2VseSB0aGF0IElBTkEgd2lsbCBkbyBhbnl0aGluZw0KPiBhbmQgc28gdGhlIFJG QyBFZGl0b3Igd2lsbCBub3QgYmUgYWJsZSB0byByZXBsYWNlIFpaIHdpdGggYW55dGhpbmcuDQo+ IA0KW2RlYm9yYWhdIEFncmVlIHdpdGggQWRyaWFuLg0KDQo+ID4gPiAgICAgPiBTZWN0aW9uIDQN Cj4gPiA+ICAgICA+IERvIHlvdSB3YW50IElBTkEgdG8gdHJhY2sgdGhlIGZsYWdzIGZpZWxkPw0K PiA+IG5vLg0KPiA+IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBhbGxvY2F0ZWQgYnkgYSBuZXcg UkZDLiBJcyB0aGF0IG5vdCB0aGUgZGVmYXVsdCA/DQo+ID4gTWFraW5nIGZsYWdzIGVhc3kgdG8g YWxsb2NhdGUgd2hlbiB0aGVyZSBhcmUgb25seSA2IGJpdHMgaXMgbm90IHdpc2UgYW5kDQo+ID4g d2lsbCBsZWFkIHRvIG1pc3VzZS4NCj4gDQo+IFlvdSB3b3VsZCBzdGlsbCBuZWVkIGFuIFJGQyB0 byBhbGxvY2F0ZSB0aGUgZmxhZ3MuDQo+IFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQsIHdpdGhvdXQg dGhlIHJlZ2lzdHJ5LCBzZXZlcmFsIFJGQ3MgbWF5IGJlY29tZQ0KPiAiY29uZnVzZWQiIGFib3V0 IHdoaWNoIGZsYWdzIHRoZXkgaGF2ZSBhbGxvY2F0ZWQuDQo+IFRoZSBJQU5BIHJlZ2lzdHJ5IHBy b3ZpZGVzIGEgd2F5IG9mIHByZXZlbnRpbmcgY2xhc2hlcy4NCj4gDQpbZGVib3JhaF0gQWdyZWUg d2l0aCBBZHJpYW4uDQoNCj4gPiA+ICAgICA+IFNlY3Rpb24gNQ0KPiA+ID4gICAgID4gSW4gOC4z IHlvdSBsaXN0IGEgbnVtYmVyIG9mIG5vdGlmaWNhdGlvbiBjb2Rlcy4gQSBsaXR0bGUgY2FuIGJl DQo+ID4gPiAgICAgZGVkdWNlZA0KPiA+ID4gICAgID4gZnJvbSB0aGVpciBuYW1lcywgYnV0IHlv dSBkbyBub3QgZGVzY3JpYmUgYW55d2hlcmUgd2hlbiBvciB3aHkNCj4gPiA+ICAgICBtb3N0IG9m DQo+ID4gPiAgICAgPiB0aGVtIGFyZSB1c2VkICg1LjAuMi4zIGFuZCA2IGFyZSB0aGUgZXhjZXB0 aW9ucykuIFlvdSBzaG91bGQsIGFuZA0KPiA+ID4gICAgID4gc2VjdGlvbiA1IG9yIDYgaXMgcHJv YmFibHkgdGhlIHBsYWNlLg0KPiA+ID4NCj4gPiBUaGVzZSBhcmUgcmVhbGx5IG9idmlvdXMuIEkg ZG8gbm90IHNlZSB0aGUgcG9pbnQgb2YgYWRkaW5nIG9idmlvdXMgdGV4dC4NCj4gPiBHbyBsb29r IGF0IGFsbCB0aGUgQkdQIHNwZWNzICwgbW9zdCBvZiB0aGVtIGFyZSBleHRyZW1lbHkgdW5yZWFk YWJsZSwNCj4gPiB0aGlzIGlzIG11Y2ggbW9yZSBjbGVhciB0aGVuIGFueSBvZiB0aG9zZS4NCj4g PiBsaWtlIGlmIGkgcmVjZWl2ZSBhbiBhY2sgbWVzc2FnZSBzZXF1ZW5jZSBudW1iZXIgdGhhdCBp cyBhZnRlciB0aGUgbGFzdA0KPiA+IG1lc3NhZ2UgaSBzZW50ICwgY2xlYXJseSBpcyBoYXZlIGEg IlVuYWNrbm93bGVkZ2VkIGNvbnRyb2wgbWVzc2FnZSIgZXJyb3IuLi4NCj4gDQo+IEFoLCBhbmQg dGhlcmUgd2FzIEkgdGhpbmtpbmcgdGhhdCB0aGlzIHdvdWxkIGJlIGEgIkNvbnRyb2wgbWVzc2Fn ZQ0KPiBhY2tub3dsZWRnZW1lbnQiIGVycm9yLCB3aGlsZSAiVW5hY2tub3dsZWRnZWQgY29udHJv bCBtZXNzYWdlIiB3b3VsZCBiZQ0KPiB1c2VkIHdoZW4gYSBjb250cm9sIG1lc3NhZ2Ugd2VudCB1 bmFja25vd2xlZGdlZC4gOi0pDQo+IA0KPiBJIGRvbid0IHRoaW5rICJvdGhlciBkb2N1bWVudHMg YXJlIHdvcnNlIiBpcyB0aGUgYmVzdCBhcmd1bWVudCB5b3UndmUgZXZlcg0KPiB1c2VkLCBidXQg SSdtIG5vdCBnb2luZyB0byBmaWdodCB0aGlzLiBJdCdzIHVwIHRvIHRoZSBBRCBhbmQgc2hlcGhl cmQuDQpbZGVib3JhaF0gDQpBZ3JlZSB3aXRoIEFkcmlhbiAtIGhhbGYgb2YgdGhlc2UgYXJlIG5v dGVkIGluIHRoZSBhcHByb3ByaWF0ZSBzZWN0aW9uLCBzbyBpdCdzIG9ubHkgYSBjb3VwbGUgb2Yg dGhlbSB3aGljaCBzdGlsbCBuZWVkIHRvIGJlIGFkZGVkLg0KPiANCj4gPiA+ICAgICA+IFNlY3Rp b24gOC4xDQo+ID4gPiAgICAgPiBZb3UgaGF2ZSBhIHJhbmdlIGFzc2lnbmVkIGJ5IEV4cGVydCBS ZXZpZXcuIEl0IGlzIGEgcmVxdWlyZW1lbnQgdGhhdA0KPiA+ID4gICAgID4geW91IGdpdmUgZ3Vp ZGFuY2UgdG8gdGhlIGV4cGVydHMgYWJvdXQgaG93IHRoZXkgc2hvdWxkIHJldmlldw0KPiA+ID4g ICAgID4gcmVxdWVzdHMuDQo+ID4NCj4gPiB3ZSBkaWQgbm90IGRvIHRoYXQgaW4gdGhlIHBhc3Qu ICBJIGFzc3VtZSB0aGF0IHRoZSBFeHBlcnQgaXMgYW4gRXhwZXJ0DQo+ID4gaW4gdGhpcyBmaWVs ZCAsIGFuZCBoYXMgZ29vZCBqdWRnbWVudC4NCj4gPiBtYXliZSBpIHNob3VsZCBhZGQgImF0IHNv bGUgZGlzY3JldGlvbiBvZiB0aGUgZXhwZXJ0IiA/DQo+IA0KPiBUaW1lcyBtYXkgaGF2ZSBjaGFu Z2VkLg0KPiBMZXQncyBsZWF2ZSB0aGlzIGZvciB0aGUgQUQgdG8gd29ycnkgYWJvdXQuDQpbZGVi b3JhaF0gDQpBcyBBZHJpYW4gbm90ZWQsIG11Y2ggbW9yZSBpcyBuZWVkZWQgdG8gZ3VpZGUgd2hl biB1c2luZyAiRXhwZXJ0IHJldmlldyIuIEluIDUyMjZiaXMsICBSRkM3NzUyIGlzIGdpdmVuIGFz IGFuIGV4YW1wbGUgZm9yIHJlZmVyZW5jZS4gQnV0IEknbSB3b25kZXJpbmcsIHdoeSBub3QgdXNl ICJJRVRGIHJldmlldyI/IEl0J3MgdXNlZCBmb3Igb3RoZXIgRy1BQ2ggdHlwZXMuIENoZWNrIHdp dGggeW91ciBDaGFpcnMuDQo+IA0KPiA+ID4gICAgID4gU2VjdGlvbiA4LjENCj4gPiA+ICAgICA+ IFRoZSB2YWx1ZXMgMTI4IHRocm91Z2ggMjU0IGFyZSBhc3NpZ25lZCB1c2luZyBGQ0ZTLiBZb3Ug Y2Fubm90IHRoZW4NCj4gPiA+ICAgICA+IGF0dGVtcHQgdG8gZnVydGhlciBjb25zdHJhaW4gaG93 IHRoZSB2YWx1ZXMgYXJlIHVzZWQgKGUuZy4sICJmb3INCj4gPiA+ICAgICB2ZW5kb3INCj4gPiA+ ICAgICA+IHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMiKSwgYW5kIHlvdSBzaG91bGQgYXZvaWQgdGhl IHdvcmQNCj4gPiA+ICAgICAicmVzZXJ2ZWQiIHNpbmNlDQo+ID4gPiAgICAgPiBpdCBoYXMgc3Bl Y2lhbCBtZWFuaW5nIGZvciBJQU5BLg0KPiA+ID4NCj4gPiA/Pz8gaSB3YW50IHRoZSB2ZW5kb3Ig cHJvcHJpZXRhcnkgZXh0ZW5zaW9ucyB0byBiZSBGQ0ZTLCBkb2VzIHRoaXMgbm90DQo+ID4gc2F5 IHRoYXQgPw0KPiA+IHRoZSBwb2ludCBpcyB0aGF0IGlmIHNvbWV0aGluZyBpcyBub3QgYSBwcm9w cmlldGFyeSBleHRlbnNpb24gaXQgc2hvdWxkDQo+ID4gbm90IHVzZSB0aGlzLg0KPiA+IGZvciBl eGFtcGxlIGl0IHByZXZlbnRzIHBlb3BsZSBsaWtlIG1lIGZyb20gdXNpbmcgRkVDIHR5cGUgMTI4 IGZvciBhDQo+ID4gc3RhbmRhcmQgcHJvdG9jb2wgLi4uOy0pDQo+IA0KPiBBZnJhaWQgaXQgZG9l c24ndA0KPiBGQ0ZTIG1lYW5zICJvcGVuIHNlYXNvbiIuIEFueW9uZSBjYW4gZ2V0IGEgRkNGUyBj b2RlIHBvaW50IGZvciBhbnkgdXNlLg0KPiBBZ2FpbiwgdGhlIEFEIGNhbiBoZWxwIHNvcnQgdGhp cyBvdXQuDQpbZGVib3JhaF0gDQpBcyBBZHJpYW4gc2F5cywgRkNGUyBkb2Vzbid0IGhhdmUgYW55 IHJlc3RyaWN0aW9ucyAoNTIyNmJpcykuDQo+IA0KPiA+ID4gICAgID4gVGhlIHN1Yi1zZWN0aW9u IG51bWJlcmluZyBpbiBTZWN0aW9uIDUgaXMgYnJva2VuLiBZb3UgY2FuIGhhdmUsDQo+ID4gPiAg ICAgPiBmb3IgZXhhbXBsZSwgIjUuMC4xIi4NCj4gPiA+ICAgICA+DQo+ID4gPg0KPiA+IGZpeGVk DQo+ID4gPg0KPiA+ID4gICAgID4gSW4gYSBudW1iZXIgb2YgcGxhY2VzIHlvdSBoYXZlICJzdWIt VExWcyIgYW5kIGluIG90aGVyIHBsYWNlcw0KPiA+ID4gICAgICJUTFZzIi4NCj4gPiA+ICAgICA+ IEkgdGhpbmsgdGhleSBhcmUgYWxsICJUTFZzIi4NCj4gPiA+DQo+ID4geWVzLCBpIG1lYW4gc3Vi LXRsdiBiZWNhdXNlIGl0J3Mgd2l0aGluIGFub3RoZXIgdGx2Lg0KPiA+DQo+ID4NCj4gPiA+ICAg ICA+IEluIDUuMC4yLjEgInRoZSBhZGRyZXNzIG9mIHRoZSBNUExTLVRQIHR1bm5lbCBJRCIgaXMg Y29uZnVzZWQuIEl0IGlzDQo+ID4gPiAgICAgPiAidGhlIGlkZW50aWZpZXIgb2YgdGhlIE1QTFMg dHVubmVsIi4gSW5kZWVkLCB3aGVyZSBkaWQgTVBMUy1UUA0KPiA+ID4gICAgIHN1ZGRlbmx5DQo+ ID4gPiAgICAgPiBjb21lIGZyb20gc2luY2UgeW91IHdhbnQgdGhpcyB0byB3b3JrIGZvciBhbGwg TFNQcyAoc2VlIGFsc28gOC4yKS4NCj4gPiA+ICAgICA+DQo+ID4gPg0KPiA+IG5vLCB0aGlzIGlz IHdoYXQgdGhpcyBpcyAuIElmIHlvdSB3YW50IGFuIE1QTFMgdHVubmVsIElEICwgaXQgd291bGQg YmUNCj4gPiBkaWZmZXJlbnQuDQo+IA0KPiBTaHJ1Zy4NCj4gSSBkb24ndCB0aGluayBpdCdzIGFu IGFkZHJlc3MuIEkgdGhpbmsgaXRzIGFuZCBJRC4NCltkZWJvcmFoXSANCkFncmVlIHdpdGggQWRy aWFuIC0gaXQncyBhbiBJRC4gT25lIGNhbiB1c2UgYW4gSVAgYWRkcmVzcyBmb3IgaXQsIGJ1dCBp dCdzIGFuIElEIChSRkM2MzcwKS4gSW4gdGhpcyBzZWN0aW9uICg1LjIuMSksIHNldmVyYWwgTVBM Uy9zL01QTFMtVFAgbmVlZGVkLg0KPiANCj4gPiA+ICAgICA+IDIuMS4xLCAyLjEuMywgYW5kIDUu MC4yLjMNCj4gPiA+ICAgICA+ICJ1bnByb3Zpc2lvbmVkIg0KPiA+ID4gICAgID4gSSB0aGluayB0 aGUgd29yZCBpcyAiZGVwcm92aXNpb25lZCINCj4gID4NCj4gPiB1bnByb3Zpc2lvbmVkIG1lYW5z IGl0IGlzIG5vdCBwcm92aXNpb25lZC4gZGVwcm92aXNpb25lZCAsIGkgdGFrZSB0bw0KPiA+IG1l YW4gdGhhdCBpdCB3YXMgb25jZSBwcm92aXNpb25lZCwgbm93IGl0IGlzIG5vdCAuLi4uDQo+ID4g SSBsaWtlIHRoZSBtb3JlIGdlbmVyaWMgInVucHJvdmlzaW9uZWQiDQo+IA0KPiBIbW1tLiBUaGUg cGhyYXNlIHdvdWxkIGJlICJub3QgcHJvdmlzaW9uZWQiLg0KPiAidW5wcm92aXNpb25lZCIgYXBw YXJlbnRseSBnaXZlcyByaXNlIHRvIGNvbmZ1c2lvbiA6LSkNCj4gDQpbZGVib3JhaF0gDQpMb29r aW5nIGF0IDUuMi4zLCBpdCBzYXlzICJhIGxpc3Qgb2YgdGhlIFBXcyB0aGF0IGhhdmUgYmVlbiB1 bnByb3Zpc2lvbmVkIG9uIHRoZSBMU1AuIiBTbyB0aGlzIGlzIGNvbmZ1c2luZywgYXMgQWRyaWFu IHNheXMsIGl0IGluZmVycyB0aGV5IGhhdmUgYmVlbiAiZGVwcm92aXNpb25lZCIuIElmIHRoZXkg aGF2ZSBub3QgYmVlbiBwcm92aXNpb25lZCwgdGhlIHNlbnRlbmNlIHdvdWxkIHNheSAodG8gbWUp LCAidGhhdCBhcmUgdW5wcm92aXNpb25lZCBvbiB0aGUgTFNQIiAoImFyZSIgaXMgYWxzbyB1c2Vk IGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCkuIFNvIHRvIG1lLCBpZiBmaXggdGhpcyBzZW50 ZW5jZSB0byAiYXJlIiwgYW5kIGF0IHRoZSBmaXJzdCB1c2Ugb2YgInVucHJvdmlzaW9uZWQiIGlu IHRoZSBkb2N1bWVudCwgcHV0ICIobm90IHByb3Zpc2lvbmVkKSIsIGl0IHNob3VsZCBiZSBjbGVh ci4gVGhlbiBob3BlZnVsbHkgInVuY29uZmlndXJlZCIgaXMgbm90IGNvbmZ1c2luZzotKSBBbmQg SSdtIHN1cmUgZHVyaW5nIElFU0cgcmV2aWV3LCB3ZSB3aWxsIGhlYXIgaWYgb3RoZXJzIGZpbmQg aXQgbm90IHVuLWNvbmZ1c2luZy4NCg0KDQo= From nobody Mon Feb 13 16:44:32 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FE712979D; Mon, 13 Feb 2017 16:44:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148703306292.22169.5868946919175397612.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 16:44:22 -0800 Archived-At: Cc: draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org, ietf@ietf.org, pals@ietf.org Subject: [Pals] Review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 00:44:23 -0000 Reviewer: Jouni Korhonen Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pals-mpls-tp-dual-homing-coordination-?? Reviewer: Jouni Korhonen Review Date: 2017-02-13 IETF LC End Date: 2017-02-13 IESG Telechat date: 2017-03-02 Summary: The document is ready. I have few questions, though, that most likely are obvious to the document authors and to the WG. Major issues: None. Minor issues: Not really an issue, but more of thinking out loud. There is no text in Section 3.2. what happens, say, when PE1 sends DHC+Status TLV and PE2 sends DHC+Switching TLV both reporting a failure of PW1. I am not sure if this is a relevant case, but I could expect there can be a sequence of events that cause these DHC messages to cross between PE1 and PE2? Nits/editorial comments: * The document uses few acronyms without expanding them. Those should be checked. * In Section 3.2. s/table 1 ./Table 1. * There are multiple occurrences of "table 1" that should be "Table 1". There are multiple occurrences of "figure 5" that should be "Figure 5". There are multiple occurrences of "figure 1" that should be "Figure 1". * Section 3.2. says "..using the DHC message above." Since the message is quite a bit above I would rewrite this as "..using the DHC message defined in Section 3.1." * Section 3.2. protection procedures would greatly benefit clarity/readability having one or two signaling flow figures assisting the textual description how the PW failures are signaled between the PEs (using the DHCs and sometimes assisted with OAM messaging). From nobody Mon Feb 13 19:09:50 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004C6129409; Mon, 13 Feb 2017 19:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=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 KHblW8a4_PqV; Mon, 13 Feb 2017 19:09:41 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 282EC129991; Mon, 13 Feb 2017 19:03:51 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec58a27390d0a-8416f; Tue, 14 Feb 2017 11:03:45 +0800 (CST) X-RM-TRANSID: 2eec58a27390d0a-8416f X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.86]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee458a2738fe69-56c71; Tue, 14 Feb 2017 11:03:44 +0800 (CST) X-RM-TRANSID: 2ee458a2738fe69-56c71 From: "Weiqiang Cheng" To: "'Jouni Korhonen'" , References: <148703306292.22169.5868946919175397612.idtracker@ietfa.amsl.com> In-Reply-To: <148703306292.22169.5868946919175397612.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 11:03:52 +0800 Message-ID: <011201d2866e$f8f2ec40$ead8c4c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdKGW5D/ERp+i/EBTWC4nomVg8XnNgAExSNA Content-Language: zh-cn Archived-At: Cc: pals@ietf.org, ietf@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org Subject: Re: [Pals] Review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 03:09:42 -0000 Hi Jouni, Thank you very much for your careful review and valuable comments. We authors will fix those issues late. B.R. Weiqiang Cheng -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Pals [mailto:pals-bounces@ietf.org] =B4=FA=B1=ED = Jouni Korhonen =B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA2=D4=C214=C8=D5 8:44 =CA=D5=BC=FE=C8=CB: gen-art@ietf.org =B3=AD=CB=CD: = draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org; ietf@ietf.org; pals@ietf.org =D6=F7=CC=E2: [Pals] Review of = draft-ietf-pals-mpls-tp-dual-homing-coordination-05 Reviewer: Jouni Korhonen Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the IESG = for the IETF Chair. Please treat these comments just like any other last = call comments. For more information, please see the FAQ at . Document: draft-ietf-pals-mpls-tp-dual-homing-coordination-?? Reviewer: Jouni Korhonen Review Date: 2017-02-13 IETF LC End Date: 2017-02-13 IESG Telechat date: 2017-03-02 Summary: The document is ready. I have few questions, though, that most likely = are obvious to the document authors and to the WG. Major issues: None. Minor issues: Not really an issue, but more of thinking out loud. There is no text in Section 3.2. what happens, say, when PE1 sends DHC+Status TLV and PE2 sends DHC+Switching TLV both reporting a failure of PW1. I am not = sure if this is a relevant case, but I could expect there can be a sequence = of events that cause these DHC messages to cross between PE1 and PE2? Nits/editorial comments:=20 * The document uses few acronyms without expanding them. Those should be checked. * In Section 3.2. s/table 1 ./Table 1. * There are multiple occurrences of "table 1" that should be "Table 1". There are multiple occurrences of "figure 5" that should be "Figure = 5". There are multiple occurrences of "figure 1" that should be "Figure = 1". * Section 3.2. says "..using the DHC message above." Since the message = is quite a bit above I would rewrite this as "..using the DHC message = defined in Section 3.1." * Section 3.2. protection procedures would greatly benefit clarity/readability having one or two signaling flow figures assisting = the textual description how the PW failures are signaled between the PEs = (using the DHCs and sometimes assisted with OAM messaging). _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals From nobody Wed Feb 15 12:59:14 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4D5129B85; Wed, 15 Feb 2017 12:59:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148719234882.31523.13631897857974710934.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 12:59:08 -0800 Archived-At: Cc: ipr-announce@ietf.org, pals@ietf.org Subject: [Pals] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-coordination X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:59:09 -0000 Dear Weiqiang Cheng, Lei Wang, Han Li, Jie Dong, Alessandro D'Alessandro: An IPR disclosure that pertains to your Internet-Draft entitled "Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection" (draft-ietf-pals-mpls-tp-dual-homing-coordination) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2954/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-coordination" Thank you IETF Secretariat From nobody Wed Feb 15 14:14:38 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1040E129869; Wed, 15 Feb 2017 14:14:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148719687305.31641.10068900510486320895.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 14:14:33 -0800 Archived-At: Cc: ipr-announce@ietf.org, pals@ietf.org Subject: [Pals] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-protection X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:14:33 -0000 Dear Weiqiang Cheng, Lei Wang, Han Li, Shahram Davari, Jie Dong: An IPR disclosure that pertains to your Internet-Draft entitled "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires" (draft-ietf-pals-mpls-tp-dual-homing-protection) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2955/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-protection" Thank you IETF Secretariat From nobody Thu Feb 16 10:09:55 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCF51294F8; Thu, 16 Feb 2017 10:09:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ir4BnxBx2KcB; Thu, 16 Feb 2017 10:09:51 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 B67A21294F5; Thu, 16 Feb 2017 10:09:48 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id t47so16523932ota.1; Thu, 16 Feb 2017 10:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qpjcMF05ClKPP3tZ1eBnBiy8Q1hdI3gkTSEdHmq2W0k=; b=M9ituHuG2BcxspH25zEvlEsFwpKvcu/g6tUzPuVIpm+uha3RXm870a8np2X8YSsiEq P5n0VaOeqeXjI7LtDAEFB5mQjnNBwVFJbv8iRH1EWQuNebzF6zDLg1KNE/eNMrHUjGbo TlKVsTqP3mbyv/hl1gjfS6fxn/nZfbEpNYwj08mo6GKYfFbfe8ibSQV8+zR2M+RgAP/g PGdnuS/UacuiGpRpwOep/TqQO880LQs31IZg/FlXP8RgvAhK4vKuTwL9DnBYu7C2rslL 4meIhAs7iENjix4eibjNEvFJVErv/qY5wwi8d5xLabvRstI9qHpwm7o6lN1O1f5V1jax iuhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpjcMF05ClKPP3tZ1eBnBiy8Q1hdI3gkTSEdHmq2W0k=; b=cMch7WZLMvg9JznFtLTDi/sDUlsccZA0PDgVYst9x1dnZoFzgzsumrDgXzP8ccknsD tJ3n/02lkbRb+hxDn+/FwRWzSPm2BeJg4g9DYKSc8PF/xEMBaQxbbMZnDwGDq5hyyCWG ruPLGI6CwSIK+PuM51kNL7ECgicoYhmiR2aLRV0rTKsY5XHG/Qkqr5qv1CLoXMlD2XCn TVltaHDrYBXmB7107q54bFd3FQ/jgBtyJBHkvd/uEajKqx/JYxq6I4oB/zCKsT2IdorB kHHDZZA53VKEO1VuAsAToSoYfunL5b4QdhGn288NPKlbShf6TGeG7JlqcWflymnSpVAt 8GKQ== X-Gm-Message-State: AMke39mLn3PqlOkg9LTl+tev9A12PCEY/fqEpI9hJ2B6ubDcG2UFufBCNvRhHhMBWViAfqKrEhfoTfY6m4yW8A== X-Received: by 10.157.35.89 with SMTP id k25mr1942046otd.209.1487268588151; Thu, 16 Feb 2017 10:09:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Thu, 16 Feb 2017 10:09:27 -0800 (PST) In-Reply-To: <148719234882.31523.13631897857974710934.idtracker@ietfa.amsl.com> References: <148719234882.31523.13631897857974710934.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 16 Feb 2017 13:09:27 -0500 Message-ID: To: IETF Secretariat Content-Type: multipart/alternative; boundary=001a11402a2ae1eadc0548a9b3b6 Archived-At: Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" , ipr-announce@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, "pals@ietf.org" Subject: Re: [Pals] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-coordination X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:09:53 -0000 --001a11402a2ae1eadc0548a9b3b6 Content-Type: text/plain; charset=UTF-8 All, This is not a new IPR statement, but rather an update of an existing IPR statement to copy it from the individual draft to the WG draft. Cheers, Andy On Wed, Feb 15, 2017 at 3:59 PM, IETF Secretariat wrote: > Dear Weiqiang Cheng, Lei Wang, Han Li, Jie Dong, Alessandro D'Alessandro: > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires > Protection" (draft-ietf-pals-mpls-tp-dual-homing-coordination) was > submitted to the IETF Secretariat on and has been posted on the "IETF > Page of > Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2954/). The title of the IPR disclosure > is > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-pals-mpls-tp-dual-homing-coordination" > > > Thank you > > IETF Secretariat > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > --001a11402a2ae1eadc0548a9b3b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

This is not a new IPR statemen= t, but rather an update of an existing IPR statement to copy it from the in= dividual draft to the WG draft.

Cheers,
= Andy


On Wed, Feb 15, 2017 at 3:59 PM, IETF Secretariat <ietf-ip= r@ietf.org> wrote:
Dear Wei= qiang Cheng, Lei Wang, Han Li, Jie Dong, Alessandro D'Alessandro:


An IPR disclosure that pertains to your Internet-Draft entitled
"Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudow= ires
Protection" (draft-ietf-pals-mpls-tp-dual-homing-coordination) wa= s
submitted to the IETF Secretariat on=C2=A0 and has been posted on the "= ;IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2954/). The title o= f the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-pals-mpls-tp-dual-homing-coordination"


Thank you

IETF Secretariat

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

--001a11402a2ae1eadc0548a9b3b6-- From nobody Thu Feb 16 10:10:42 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4402312966F; Thu, 16 Feb 2017 10:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b7zb7iuULtmS; Thu, 16 Feb 2017 10:10:39 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 E8B11129564; Thu, 16 Feb 2017 10:10:16 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id j15so12910715oih.2; Thu, 16 Feb 2017 10:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rp6fmTVGjm9wlWX5Gi5DAq9Z+hvo6N1x4SU6CK3EDjM=; b=kKUuEz/JF47RiDmxaQeh+fQjBnBLeEGXmZ2gSsMBW9LGgIBHayHHwxbHvZTFsQ7Ums /REfyB0wU+IeH1HKSGB1pXt4c3bCEKSEmnTM0+rx8KCD1jQ7FDIpyTroILQdALxfG4kC KGqO6LscAPDHbd0lU1GMYkqs9nQlGOvcWm18l7Jn+uqDh2wV1sX1GK33JT+ak4XeryDb udYzsSbtunMj17mSL9LRPH/BtKYsbx90wJ8mtwbjt7IlOfnWKPPgUUcJ+B0gKZjcMZvV lk6tPokl0ay1EMKDeFGRRahWeA4XbAqCs1zpcGgvdh0mFxsY31+kLONvmWu9Sl2zQEdr 5jWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rp6fmTVGjm9wlWX5Gi5DAq9Z+hvo6N1x4SU6CK3EDjM=; b=hFTVIAk9VDwqthFRMtreG0ji/F8CPuU2ArZnBX3442KZSUs+EMm5CbfhMhyQQmuY0O TeRD3Qd3txr7LV+S1Tt0WC7NsyrrPjy+1nP9Y3xiJVka8t5xHTCPI/Q9LhawgeBi52/F BP/B81sqHclBTTkMqFRabyKSJ0gLCJrYl5H8gx7H+0PNH5g1WIK9PyJQRyDFdR4u6B1k F75/HQwDbVNsAvgIcsWZJ7HbgItOIWRw4HjsKI2wRf1/9Ue+rwofVwf7DlgGM6ulPsKx wmsAONTFLsxRbgyOq0jPlJk28GChDobKbgEFE8CuohGpRtqtd+r68faL2Nsik0mGxedp 8yiw== X-Gm-Message-State: AMke39k0jmkJAj9RhkamUqvmcJf7ChFVhErJv+tNINzWw5XX9FreGjc7hy06fOfWMhkb5LwXh/RHCuJ64UrVGQ== X-Received: by 10.202.68.10 with SMTP id r10mr1944979oia.181.1487268616361; Thu, 16 Feb 2017 10:10:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Thu, 16 Feb 2017 10:09:55 -0800 (PST) In-Reply-To: <148719687305.31641.10068900510486320895.idtracker@ietfa.amsl.com> References: <148719687305.31641.10068900510486320895.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 16 Feb 2017 13:09:55 -0500 Message-ID: To: IETF Secretariat Content-Type: multipart/alternative; boundary=001a113d22e29060930548a9b5bf Archived-At: Cc: draft-ietf-pals-mpls-tp-dual-homing-protection@ietf.org, "BRUNGARD, DEBORAH A \(ATTLABS\)" , ipr-announce@ietf.org, "pals@ietf.org" Subject: Re: [Pals] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pals-mpls-tp-dual-homing-protection X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:10:41 -0000 --001a113d22e29060930548a9b5bf Content-Type: text/plain; charset=UTF-8 All, Again, this is not a new IPR statement, but rather an update of an existing IPR statement to copy it from the individual draft to the WG draft. Cheers, Andy On Wed, Feb 15, 2017 at 5:14 PM, IETF Secretariat wrote: > Dear Weiqiang Cheng, Lei Wang, Han Li, Shahram Davari, Jie Dong: > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires" > (draft-ietf-pals-mpls-tp-dual-homing-protection) was submitted to the IETF > Secretariat on and has been posted on the "IETF Page of Intellectual > Property > Rights Disclosures" (https://datatracker.ietf.org/ipr/2955/). The title > of the > IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR > related > to draft-ietf-pals-mpls-tp-dual-homing-protection" > > > Thank you > > IETF Secretariat > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > --001a113d22e29060930548a9b5bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Again, this is not a new IPR s= tatement, but rather an update of an existing IPR statement to copy it from= the individual draft to the WG draft.

Cheers,
Andy


On Wed, Feb 15, 2017 at 5:14 PM, IETF Secretariat <ie= tf-ipr@ietf.org> wrote:
Dea= r Weiqiang Cheng, Lei Wang, Han Li, Shahram Davari, Jie Dong:


An IPR disclosure that pertains to your Internet-Draft entitled
"Dual-Homing Protection for MPLS and MPLS-TP Pseudowires"
(draft-ietf-pals-mpls-tp-dual-homing-protection) was submitted to the = IETF
Secretariat on=C2=A0 and has been posted on the "IETF Page of Intellec= tual Property
Rights Disclosures" (https://datatracker.ietf.org/ip= r/2955/). The title of the
IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about I= PR related
to draft-ietf-pals-mpls-tp-dual-homing-protection"


Thank you

IETF Secretariat

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

--001a113d22e29060930548a9b5bf-- From nobody Wed Feb 22 10:04:24 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453B91296EE; Wed, 22 Feb 2017 10:04:23 -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.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148778666327.31058.7093482748288283778.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 10:04:23 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-status-reduction-03.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:04:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : MPLS LSP PW status refresh reduction for Static Pseudowires Authors : Luca Martini George Swallow Elisa Bellagamba Filename : draft-ietf-pals-status-reduction-03.txt Pages : 19 Date : 2017-02-22 Abstract: This document describes a method for generating an aggregated pseudowire status message transmitted on a Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more pseudowires carried on the LSP. The method for transmitting the pseudowire (PW) status information is not new, however this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-status-reduction/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-status-reduction-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-status-reduction-03 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 Feb 22 10:05:22 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477FB129A83; Wed, 22 Feb 2017 10:05:20 -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 autolearn_force=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 iXtXhKVuwOiy; Wed, 22 Feb 2017 10:05:19 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E345129A92; Wed, 22 Feb 2017 10:04:48 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id v1MI4evm021217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Feb 2017 11:04:40 -0700 (MST) To: adrian@olddog.co.uk, "'Andrew G. Malis'" , "'George Swallow'" , "'Elisa Bellagamba'" References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <58A0F649.7090301@monoski.com> <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> From: Luca Martini Organization: Monoski Message-ID: <58ADD2B3.8040101@monoski.com> Date: Wed, 22 Feb 2017 11:04:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-pals-status-reduction@ietf.org, pals-chairs@ietf.org, "'BRUNGARD, DEBORAH A'" , pals@ietf.org Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:05:20 -0000 Adrian, I addressed all your comments and produced v03. At the same time I also followed Debra's suggestions in her reply e-mail. There is only one minor point on the FCFS vendor ranges that if it does not work I will need to remove the FCFS ranges. See comments below. Thanks. Luca On 02/13/17 11:59, Adrian Farrel wrote: > Hi Luca, > > Love monoski.com! > > You've done a fine job with this. Thanks. > > Just cutting down to a few minor points that are so trivial I'm ashamed to type... > >>> > Section 4 >>> > You have not described all of the fields in the figure. >>> >> What did I miss ? > - MPLS LSP (tunnel) Label Stack Entry > - GAL > - 0 0 0 1 > - Version > - Reserved > > But these probably only need a group entry pointing at another doc. > Haa i see what you meant. I did not explain these fields exactly for that reason. They are not part of the specification in this document. I will add a reference to the GAL rfc for the GAL and the following fields. I agree that it would make the document easier to read. The MPLS LSP can be explained by rfc 3031. I'll add the quotes as normative. >>> > >>> > Section 4 >>> > You have... >>> > Channel type 0xZZ pending IANA allocation. >>> > ...but no mention in the IANA section >>> > The figure shows "0xZZ PW OAM Message", but surely this is >>> > "PW Status Reduction Message" >>> > >>> >> Sure , but it has not been allocated yet. This is for the RFC editor to >> replace the text once the allocation is dune. > Yeah, but if you don't have 0xZZ or "PW OAM Message" in the IANA Considerations section (section 8) it seems unlikely that IANA will do anything and so the RFC Editor will not be able to replace ZZ with anything. ok, you are right the IANA section is missing directions. I will add it. >>> > Section 4 >>> > Do you want IANA to track the flags field? >> no. >> I think this needs to be allocated by a new RFC. Is that not the default ? >> Making flags easy to allocate when there are only 6 bits is not wise and >> will lead to misuse. > You would still need an RFC to allocate the flags. > The difference is that, without the registry, several RFCs may become "confused" about which flags they have allocated. > The IANA registry provides a way of preventing clashes. OK - This sounds reasonable. I will add a registry, with policy of IETF Review. >>> > Section 5 >>> > In 8.3 you list a number of notification codes. A little can be >>> deduced >>> > from their names, but you do not describe anywhere when or why >>> most of >>> > them are used (5.0.2.3 and 6 are the exceptions). You should, and >>> > section 5 or 6 is probably the place. >>> >> These are really obvious. I do not see the point of adding obvious text. >> Go look at all the BGP specs , most of them are extremely unreadable, >> this is much more clear then any of those. >> like if i receive an ack message sequence number that is after the last >> message i sent , clearly is have a "Unacknowledged control message" error... > Ah, and there was I thinking that this would be a "Control message acknowledgement" error, while "Unacknowledged control message" would be used when a control message went unacknowledged. :-) > > I don't think "other documents are worse" is the best argument you've ever used, but I'm not going to fight this. It's up to the AD and shepherd. Yes after looking at this more closely , i will add the missing guidance where appropriate. I explained code 0x0, code 0x1 (renamed to PW configuration mismatch , which is more appropriate English) code 0x3 and code 0x4. >>> > Section 8.1 >>> > You have a range assigned by Expert Review. It is a requirement that >>> > you give guidance to the experts about how they should review >>> > requests. >> we did not do that in the past. I assume that the Expert is an Expert >> in this field , and has good judgment. >> maybe i should add "at sole discretion of the expert" ? > Times may have changed. > Let's leave this for the AD to worry about. ok, I will add an expert guidance section. The purpose of this range was to make things easy to allocate and avoid duplication. >>> > Section 8.1 >>> > The values 128 through 254 are assigned using FCFS. You cannot then >>> > attempt to further constrain how the values are used (e.g., "for >>> vendor >>> > proprietary extensions"), and you should avoid the word >>> "reserved" since >>> > it has special meaning for IANA. >>> >> ??? i want the vendor proprietary extensions to be FCFS, does this not >> say that ? >> the point is that if something is not a proprietary extension it should >> not use this. >> for example it prevents people like me from using FEC type 128 for a >> standard protocol ...;-) > Afraid it doesn't > FCFS means "open season". Anyone can get a FCFS code point for any use. > Again, the AD can help sort this out. Yes , FCFS is open , and this range is also designated for vendor proprietary extensions. The intention is that something in this range would never become IETF standard. Can IANA follow the FCFS process while this document designates this range as vendor proprietary ? if someone violates that rule, then other implementations have no duty to support these extensions as they are not standard. If you think that this will not work , I can change it to just IETF review. >>> > The sub-section numbering in Section 5 is broken. You can have, >>> > for example, "5.0.1". >>> > >>> >> fixed >>> > In a number of places you have "sub-TLVs" and in other places >>> "TLVs". >>> > I think they are all "TLVs". >>> >> yes, i mean sub-tlv because it's within another tlv. >> >> >>> > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It is >>> > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP >>> suddenly >>> > come from since you want this to work for all LSPs (see also 8.2). >>> > >>> >> no, this is what this is . If you want an MPLS tunnel ID , it would be >> different. > Shrug. > I don't think it's an address. I think its and ID. ok I think I understand now. i will replace Tunnel ID address , with simply "Tunnel ID" >>> > 2.1.1, 2.1.3, and 5.0.2.3 >>> > "unprovisioned" >>> > I think the word is "deprovisioned" > > >> unprovisioned means it is not provisioned. deprovisioned , i take to >> mean that it was once provisioned, now it is not .... >> I like the more generic "unprovisioned" > Hmmm. The phrase would be "not provisioned". > "unprovisioned" apparently gives rise to confusion :-) > > > ok, but the problem is that there is a difference between "not provisioned" and something that was once provisioned , and is now not provisioned. I will go with deprovisioned as you suggested, if it makes things clearer. I'll let the RFC editor figure out if it is correct English. Luca From nobody Fri Feb 24 09:08:25 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F31293F4; Fri, 24 Feb 2017 09:08:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148795609883.13860.14512731467844275949.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2017 09:08:18 -0800 Archived-At: Cc: stewart.bryant@gmail.com, pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, pals@ietf.org Subject: [Pals] Alexey Melnikov's No Record on draft-ietf-pals-mpls-tp-dual-homing-coordination-05: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:08:19 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-pals-mpls-tp-dual-homing-coordination-05: No Record 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-pals-mpls-tp-dual-homing-coordination/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- At the beginning of page 6 there are 2 fields: Version and Flags which I don't think are described. From nobody Mon Feb 27 00:39:35 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF11129873; Mon, 27 Feb 2017 00:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 v2uHCW1hsPEk; Mon, 27 Feb 2017 00:39:31 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 077481299C0; Mon, 27 Feb 2017 00:39:29 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec58b3e5ba35a-829a4; Mon, 27 Feb 2017 16:39:22 +0800 (CST) X-RM-TRANSID: 2eec58b3e5ba35a-829a4 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.86]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee558b3e5b922b-3afe1; Mon, 27 Feb 2017 16:39:22 +0800 (CST) X-RM-TRANSID: 2ee558b3e5b922b-3afe1 From: "Weiqiang Cheng" To: "'Alexey Melnikov'" , "'The IESG'" References: <148795609883.13860.14512731467844275949.idtracker@ietfa.amsl.com> In-Reply-To: <148795609883.13860.14512731467844275949.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 16:39:24 +0800 Message-ID: <004101d290d5$000ef620$002ce260$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdKOwJmoDa+VwYiqQZCoP8rNQo2ttwCFFLyg Content-Language: zh-cn Archived-At: Cc: stewart.bryant@gmail.com, pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, pals@ietf.org Subject: [Pals] =?utf-8?b?562U5aSNOiBBbGV4ZXkgTWVsbmlrb3YncyBObyBSZWNvcmQg?= =?utf-8?q?on_draft-ietf-pals-mpls-tp-dual-homing-coordination-05=3A_=28wi?= =?utf-8?q?th_COMMENT=29?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 08:39:33 -0000 Hi Alexey, Thanks a lot for your comments. We will fix it soon. B.R. Weiqiang Cheng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Alexey Melnikov = [mailto:aamelnikov@fastmail.fm]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B42=E6=9C=8825=E6=97=A5 = 1:08 =E6=94=B6=E4=BB=B6=E4=BA=BA: The IESG =E6=8A=84=E9=80=81: = draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org; Stewart = Bryant; pals-chairs@ietf.org; stewart.bryant@gmail.com; pals@ietf.org =E4=B8=BB=E9=A2=98: Alexey Melnikov's No Record on = draft-ietf-pals-mpls-tp-dual-homing-coordination-05: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-pals-mpls-tp-dual-homing-coordination-05: No Record 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-pals-mpls-tp-dual-homing-coor= dination/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- At the beginning of page 6 there are 2 fields: Version and Flags which I = don't think are described. From nobody Mon Feb 27 00:40:39 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A670129873; Mon, 27 Feb 2017 00:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 b4k-o0o8MF01; Mon, 27 Feb 2017 00:40:31 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8842B1299C0; Mon, 27 Feb 2017 00:40:00 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee758b3e5df2c0-827c1; Mon, 27 Feb 2017 16:39:59 +0800 (CST) X-RM-TRANSID: 2ee758b3e5df2c0-827c1 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.86]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee958b3e5de9e6-3bbd6; Mon, 27 Feb 2017 16:39:59 +0800 (CST) X-RM-TRANSID: 2ee958b3e5de9e6-3bbd6 From: "Weiqiang Cheng" To: "'Alexey Melnikov'" , "'The IESG'" References: <148795609883.13860.14512731467844275949.idtracker@ietfa.amsl.com> In-Reply-To: <148795609883.13860.14512731467844275949.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 16:40:00 +0800 Message-ID: <004201d290d5$15d79750$4186c5f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdKOwJtyZ7vIAS3EQ6yB9t8AWg54+QCFGpCg Content-Language: zh-cn Archived-At: Cc: stewart.bryant@gmail.com, pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, pals@ietf.org Subject: [Pals] =?gb2312?b?tPC4tDogIEFsZXhleSBNZWxuaWtvdidzIE5vIFJlY29y?= =?gb2312?b?ZCBvbiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1kdWFsLWhvbWluZy1jb29y?= =?gb2312?b?ZGluYXRpb24tMDU6ICh3aXRoIENPTU1FTlQp?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 08:40:33 -0000 Thanks a lot. We will fix it soon. B.R. Weiqiang Cheng -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Pals [mailto:pals-bounces@ietf.org] =B4=FA=B1=ED = Alexey Melnikov =B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA2=D4=C225=C8=D5 1:08 =CA=D5=BC=FE=C8=CB: The IESG =B3=AD=CB=CD: stewart.bryant@gmail.com; pals-chairs@ietf.org; draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org; pals@ietf.org =D6=F7=CC=E2: [Pals] Alexey Melnikov's No Record on draft-ietf-pals-mpls-tp-dual-homing-coordination-05: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-pals-mpls-tp-dual-homing-coordination-05: No Record 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-pals-mpls-tp-dual-homing-coor= din ation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- At the beginning of page 6 there are 2 fields: Version and Flags which I don't think are described. _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals From nobody Mon Feb 27 09:35:11 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDCF12A2A9; Mon, 27 Feb 2017 09:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 R1AxO-19ZP7M; Mon, 27 Feb 2017 09:35:08 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0952F12A2A1; Mon, 27 Feb 2017 09:35:07 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1RHZ1ew014530; Mon, 27 Feb 2017 17:35:03 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1RHXbQV013883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2017 17:33:41 GMT From: "Adrian Farrel" To: "'Luca Martini'" , "'Andrew G. Malis'" , "'George Swallow'" , "'Elisa Bellagamba'" References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <58A0F649.7090301@monoski.com> <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> <58ADD2B3.8040101@monoski.com> In-Reply-To: <58ADD2B3.8040101@monoski.com> Date: Mon, 27 Feb 2017 17:33:35 -0000 Message-ID: <01f301d2911f$a6354b90$f29fe2b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4vo8J6wBQZFbSvY6b5rTwOAF7nwH7KBPWAn2FA1kCSZrYWAGDYMnkATlv9o+eZMP6QA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22912.001 X-TM-AS-Result: No--12.754-10.0-31-10 X-imss-scan-details: No--12.754-10.0-31-10 X-TMASE-MatchedRID: u7Yf2n7Ca/1m2M+WdBiaRPHkpkyUphL97h2RrsKOiu0cwobK0FtcP6tY XNbyT8atP1M9wffyAbwB/7KOz8XhVaNvJJBiq11asyNb+yeIRAoFyyHXLpCyVjfzN9nCvn5I7+5 9yngNbC507dCGMytaAZERkoakswVZ+y1QXC0U0Rhor4yxPAz7Wfqk6wqWEsjCfVkB/cv6Ul1xQ9 CNI5RA3ZcxXP8ypoILIJ764D2KgwKCHDCr0YAJt56a4syijMJmF2epOtR1Cc8hzQajd8RQtqLoS LE/BAxZXU96IJqHIs9vNAyC6UCUfTHoq5wq7Ry6/Z+HiNGuxoN9LQinZ4QefGWCfbzydb0gKYOc jnHaFYKOhzOa6g8KrROiyRDJUOMzhW4WCdP/AqANpbSMWjURgFqFh5EZNIFTMbnwJWYpnk0= Archived-At: Cc: draft-ietf-pals-status-reduction@ietf.org, pals-chairs@ietf.org, "'BRUNGARD, DEBORAH A'" , pals@ietf.org Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:35:10 -0000 Hi Luca, > >>> > Section 8.1 > >>> > The values 128 through 254 are assigned using FCFS. You cannot = then > >>> > attempt to further constrain how the values are used (e.g., "for > >>> > vendor proprietary extensions"), and you should avoid the word > >>> > "reserved" since it has special meaning for IANA. > >> > >> ??? i want the vendor proprietary extensions to be FCFS, does this = not > >> say that ? > >> the point is that if something is not a proprietary extension it = should > >> not use this. > >> for example it prevents people like me from using FEC type 128 for = a > >> standard protocol ...;-) > > > > Afraid it doesn't > > FCFS means "open season". Anyone can get a FCFS code point for any = use. > > Again, the AD can help sort this out. |> Yes , FCFS is open , and this range is also designated for vendor |> proprietary extensions. The intention is that something in this range |> would never become IETF standard. > > Can IANA follow the FCFS process while this document designates this > range as vendor proprietary ? > if someone violates that rule, then other implementations have no duty > to support these extensions as they are not standard. >=20 > If you think that this will not work , I can change it to just IETF = review. No. The only rules are the rules in the registry. That is, you tell IANA = how to assign values, and they do that. Someone coming along later is = bound only by the IANA rules and not by additional words in your RFC. So you can choose from 5226, but sounds to me that you want: - a registry to be kept of values used by vendors (i.e., not just an unregulated space for them to play in) - to stop people grabbing from the vendor space when they should be writing RFCs I suggest you use "Expert Review" [RFC5226] and describe in your = document (as you would be required to) the rules that the Designated = Expert must apply. These could be: - Not used for protocol extensions that should be standardised - Only use for vendor-specific uses - Must have a clear indication of the vendor - Should have a contact email address that is not an individual (Otherwise, IETF review) A =20 From nobody Tue Feb 28 05:55:48 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E669512955D; Tue, 28 Feb 2017 05:55:46 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148829014693.30669.13118897680285987434.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 05:55:46 -0800 Archived-At: Cc: stewart.bryant@gmail.com, pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, pals@ietf.org Subject: [Pals] Stephen Farrell's No Objection on draft-ietf-pals-mpls-tp-dual-homing-coordination-05: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:55:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-pals-mpls-tp-dual-homing-coordination-05: 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-pals-mpls-tp-dual-homing-coordination/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The secdir review [1] raised some good points that I believe the authors have agreed to address, but that's yet to happen. [1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=hE2TffVz-by4u001aSosi8JK6WI From nobody Tue Feb 28 08:38:21 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC06129624; Tue, 28 Feb 2017 08:38:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148829989956.29494.7224618792577082144.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 08:38:19 -0800 Archived-At: Cc: stewart.bryant@gmail.com, pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org, pals@ietf.org Subject: [Pals] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pals-mpls-tp-dual-homing-coordination-05=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:38:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-pals-mpls-tp-dual-homing-coordination-05: 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-pals-mpls-tp-dual-homing-coordination/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor mostly editorial comments: 1) When I first saw "DHC Code Point" in figure 2, I was slightly confused because this doesn't show in the rest of the doc anymore. Maybe rename to 'DHC channel type' or use the same term in the text or directly put the value in there that will be assigned by IANA. 2) 3.1.:"After the transmission of the three messages, the dual-homing PE MUST send the most recently transmitted Dual-Node Switching TLV periodically to the other dual-homing PE on a continual basis using the DHC message." This is only if the protection is active, right? 3) 3.2.:"Whenever a change of service PW status is detected by a dual-homing PE, it MUST be reflected in the PW Status TLV and sent to the other dual-homing PE immediately using the 3 consecutive DHC messages. This way, both dual-homing PEs have the status of the working and protection PW consistently." Note, it's possible that all three messages get lost. If you want to make sure you stay in sync, you need an explicit mechanism for reliability, e.g. sending an ack. From nobody Tue Feb 28 22:48:55 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDD129469; Tue, 28 Feb 2017 22:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 O2VqMam_hmtF; Tue, 28 Feb 2017 22:48:46 -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 73ED512941D; Tue, 28 Feb 2017 22:48:45 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBX20548; Wed, 01 Mar 2017 06:48:42 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Mar 2017 06:48:41 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 1 Mar 2017 14:48:35 +0800 From: "Dongjie (Jimmy)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LXBhbHMtbXBscy10cC1kdWFsLWhvbWluZy1jb29yZGluYXRpb24tMDU6ICh3?= =?utf-8?Q?ith_COMMENT)?= Thread-Index: AQHSkeEdXSW/2QPYykKkT1H/fkjpJKF/g+FQ Date: Wed, 1 Mar 2017 06:50:17 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279358B0C4@NKGEML515-MBX.china.huawei.com> References: <148829989956.29494.7224618792577082144.idtracker@ietfa.amsl.com> In-Reply-To: <148829989956.29494.7224618792577082144.idtracker@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58B66ECA.033D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 201379164c96210eecc695711b2f21b1 Archived-At: Cc: "stewart.bryant@gmail.com" , "pals-chairs@ietf.org" , "draft-ietf-pals-mpls-tp-dual-homing-coordination@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pals-mpls-tp-dual-homing-coordination-05=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 06:48:50 -0000 SGkgTWlyamEsIA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUg bXkgcmVwbGllcyBpbmxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTWlyamEgS8O8aGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IFNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMDEsIDIwMTcgMTI6MzggQU0NCj4gVG86IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtZHVhbC1ob21pbmctY29v cmRpbmF0aW9uQGlldGYub3JnOyBTdGV3YXJ0IEJyeWFudA0KPiA8c3Rld2FydC5icnlhbnRAZ21h aWwuY29tPjsgcGFscy1jaGFpcnNAaWV0Zi5vcmc7DQo+IHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bTsgcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0 aW9uIG9uDQo+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLWR1YWwtaG9taW5nLWNvb3JkaW5hdGlv bi0wNTogKHdpdGggQ09NTUVOVCkNCj4gDQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcGFscy1tcGxz LXRwLWR1YWwtaG9taW5nLWNvb3JkaW5hdGlvbi0wNTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1w YWxzLW1wbHMtdHAtZHVhbC1ob21pbmctY29vcmRpbmF0aQ0KPiBvbi8NCj4gDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBNaW5vciBt b3N0bHkgZWRpdG9yaWFsIGNvbW1lbnRzOg0KPiANCj4gMSkgV2hlbiBJIGZpcnN0IHNhdyAiREhD IENvZGUgUG9pbnQiIGluIGZpZ3VyZSAyLCBJIHdhcyBzbGlnaHRseSBjb25mdXNlZA0KPiBiZWNh dXNlIHRoaXMgZG9lc24ndCBzaG93IGluIHRoZSByZXN0IG9mIHRoZSBkb2MgYW55bW9yZS4gTWF5 YmUgcmVuYW1lIHRvDQo+ICdESEMgY2hhbm5lbCB0eXBlJyBvciB1c2UgdGhlIHNhbWUgdGVybSBp biB0aGUgdGV4dCBvciBkaXJlY3RseSBwdXQgdGhlIHZhbHVlIGluDQo+IHRoZXJlIHRoYXQgd2ls bCBiZSBhc3NpZ25lZCBieSBJQU5BLg0KDQpUaGFua3MgZm9yIHBvaW50aW5nIG91dCB0aGlzLiBX aWxsIGNoYW5nZSB0aGlzIHRvICJESEMgQ2hhbm5lbCBUeXBlIiBpbiBuZXh0IHJldmlzaW9uLiAN Cj4gDQo+IDIpIDMuMS46IkFmdGVyIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIHRocmVlIG1lc3Nh Z2VzLCB0aGUNCj4gICAgZHVhbC1ob21pbmcgUEUgTVVTVCBzZW5kIHRoZSBtb3N0IHJlY2VudGx5 IHRyYW5zbWl0dGVkIER1YWwtTm9kZQ0KPiAgICBTd2l0Y2hpbmcgVExWIHBlcmlvZGljYWxseSB0 byB0aGUgb3RoZXIgZHVhbC1ob21pbmcgUEUgb24gYSBjb250aW51YWwNCj4gICAgYmFzaXMgdXNp bmcgdGhlIERIQyBtZXNzYWdlLiINCj4gICAgVGhpcyBpcyBvbmx5IGlmIHRoZSBwcm90ZWN0aW9u IGlzIGFjdGl2ZSwgcmlnaHQ/DQoNClllcywgdGhlIHN3aXRjaGluZyBUTFYgaXMgc2VudCBwZXJp b2RpY2FsbHkgYWZ0ZXIgdGhlIHByb3RlY3Rpb24gaXMgaW4gYWN0aXZlLiANCg0KPiANCj4gMykg My4yLjoiV2hlbmV2ZXIgYSBjaGFuZ2Ugb2Ygc2VydmljZSBQVyBzdGF0dXMgaXMgZGV0ZWN0ZWQg YnkgYSBkdWFsLWhvbWluZw0KPiAgICBQRSwgaXQgTVVTVCBiZSByZWZsZWN0ZWQgaW4gdGhlIFBX IFN0YXR1cyBUTFYgYW5kIHNlbnQgdG8gdGhlIG90aGVyDQo+ICAgIGR1YWwtaG9taW5nIFBFIGlt bWVkaWF0ZWx5IHVzaW5nIHRoZSAzIGNvbnNlY3V0aXZlIERIQyBtZXNzYWdlcy4NCj4gICAgVGhp cyB3YXksIGJvdGggZHVhbC1ob21pbmcgUEVzIGhhdmUgdGhlIHN0YXR1cyBvZiB0aGUgd29ya2lu ZyBhbmQNCj4gICAgcHJvdGVjdGlvbiBQVyBjb25zaXN0ZW50bHkuIg0KPiAgICBOb3RlLCBpdCdz IHBvc3NpYmxlIHRoYXQgYWxsIHRocmVlIG1lc3NhZ2VzIGdldCBsb3N0LiBJZiB5b3Ugd2FudCB0 byBtYWtlDQo+IHN1cmUgeW91IHN0YXkgaW4gc3luYywgeW91IG5lZWQgYW4gZXhwbGljaXQgbWVj aGFuaXNtIGZvciByZWxpYWJpbGl0eSwgZS5nLg0KPiBzZW5kaW5nIGFuIGFjay4NCg0KVGhlIDMg Y29uc2VjdXRpdmUgbWVzc2FnZSBtZWNoYW5pc20gaXMgc2ltaWxhciB0byB0aGUgbWVjaGFuaXNt IGRlZmluZWQgaW4gc2VjdGlvbiA0LjEgb2YgcmZjNjM3OCAoTVBMUy1UUCBsaW5lYXIgcHJvdGVj dGlvbikuIEl0IGNhbiBlbnN1cmUgdGhlIHN0YXRlIGV4Y2hhbmdlIGlmIG9uZSBvciB0d28gb2Yg dGhlIDMgbWVzc2FnZXMgZ2V0IGxvc3QuIEFuZCBhZnRlciB0aGUgMyBjb25zZWN1dGl2ZSBtZXNz YWdlcywgdGhlIG1lc3NhZ2Ugd2lsbCBzdGlsbCBiZSB0cmFuc21pdHRlZCBjb250aW51b3VzbHkg YXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMSBvZiB0aGlzIGRyYWZ0LCBzbyB0aGUgZHVhbC1ob21p bmcgUEVzIHdvdWxkIHN0YXkgaW4gc3luYy4gDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0K