From nobody Wed Oct 1 17:09:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426461A8857 for ; Wed, 1 Oct 2014 17:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyC-O0p9Y0dj for ; Wed, 1 Oct 2014 17:08:55 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 2E5EE1A8858 for ; Wed, 1 Oct 2014 17:08:55 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id E7157A23A0D53; Thu, 2 Oct 2014 00:08:49 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9208rix026343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 20:08:53 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 20:08:53 -0400 Received: from SG70YWXCHMBA08.zap.alcatel-lucent.com ([169.254.8.137]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 08:08:51 +0800 From: "Dutta, Pranjal K (Pranjal)" To: Loa Andersson , "Osborne, Eric" , Lizhong Jin , Eric Gray , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Thread-Index: AQHP0pA5cWHsdZwUak6ILtEmQIYAdpwcA8oA Date: Thu, 2 Oct 2014 00:08:51 +0000 Message-ID: References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com> <5419AFA0.4050609@pi.nu> In-Reply-To: <5419AFA0.4050609@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: multipart/alternative; boundary="_000_ABD110CD5D879A4BB51C269846E4CA3119E9E0SG70YWXCHMBA08zap_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4Yt7dy5Pk6w-TXzvcrtMfH6cBJE Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:08:58 -0000 --_000_ABD110CD5D879A4BB51C269846E4CA3119E9E0SG70YWXCHMBA08zap_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa and Authors, I have reviewed this document. It is sho= rt document with a simple extension. It is useful and technically sound. I = think the document is ready for WG adoption. Thanks, Pranjal -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, September 17, 2014 8:58 AM To: Osborne, Eric; Lizhong Jin; Dutta, Pranjal K (Pranjal); Eric Gray; mpls= -chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Eric, Lizhong, Pranjal and Eric, You have be selected as MPLS-RT reviewers for draft-raza-mpls- oam-ipv6-rao= . Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document= , and what can wait until the document is a working group document and the = working group has the revision control. Are you able to review this draft by Oct 1, 2014? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Date: Wed, 17 Sep 2014 06:53:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. Title : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-01.txt Pages : 5 Date : 2014-09-17 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam-ipv6-rao-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt --_000_ABD110CD5D879A4BB51C269846E4CA3119E9E0SG70YWXCHMBA08zap_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Loa and Authors,

      =              &n= bsp;            = ;  I have reviewed this document.  It is short document with= a simple extension. It is useful and technically sound. I think the docume= nt is ready for WG adoption.

Thanks,

Pranjal

 

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Wednesday, September 17, 2014 8:58 AM
To: Osborne, Eric; Lizhong Jin; Dutta, Pranjal K (Pranjal); Eric Gray; mpls= -chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt<= /p>

 

Eric, Lizhong, Pranjal and Eric,

 

You have be selected as MPLS-RT reviewers for dra= ft-raza-mpls- oam-ipv6-rao.

 

Note to authors: You have been CC'd on this email= so that you can know that this review is going on. However, please do not = review your own document.

 

Reviews should comment on whether the document is= coherent, is it useful (ie, is it likely to be actually useful in operatio= nal networks), and is the document technically sound?  We are interest= ed in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at thi= s point, but should be a good start).

 

Reviews should be sent to the document authors, W= G co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necess= ary, comments may be sent privately to only the WG chairs.

 

If you have technical comments you should try to = be explicit about what

*really* need to be resolved before adopting it a= s a working group document, and what can wait until the document is a worki= ng group document and the working group has the revision control.

 

Are you able to review this draft by Oct 1, 2014?= Please respond in a

timely fashion.  

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

-------- Original Message --------

Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao= -01.txt

Date: Wed, 17 Sep 2014 06:53:44 -0700<= /p>

From: internet-drafts@ietf= .org

Reply-To: internet-drafts@= ietf.org

To: i-d-announce@ietf.org

CC: mpls@ietf.org

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

  This draft is a work item of the Multiprot= ocol Label Switching Working Group of the IETF.

 

         = Title           : IPv6 Ro= uter Alert Option for MPLS OAM

         = Authors         : Kamran Raza<= /o:p>

        &= nbsp;           &nbs= p;      Nobo Akiya

        &= nbsp;           &nbs= p;      Carlos Pignataro

      Filename &nbs= p;      : draft-raza-mpls-oam-ipv6-rao-01.txt=

      Pages  &= nbsp;        : 5

      Date  &n= bsp;         : 2014-09-17

 

Abstract:

    RFC4379 defines the MPLS LSP P= ing/Traceroute mechanism, in which the

    Router Alert option must be se= t in the IP header of the MPLS Echo

    Request messages, and may cond= itionally be set in the IP header of

    the MPLS Echo Reply messages.&= nbsp; While a generic "Router shall examine

    packet" Option Value is u= sed for the IPv4 Router Alert Option (RAO),

    there is no generic Router Ale= rt Option Value defined for IPv6 that

    can be used.  This docume= nt allocates a new generic IPv6 Router Alert

    Option Value that can be used = by MPLS OAM tools, including the MPLS

    Echo Request and MPLS Echo Rep= ly messages for MPLS IPv6.

 

    The initial motivation to requ= est an IPv6 Router Alert Option (RAO)

    code point for MPLS OAM comes = from MPLS LSP Ping/Traceroute.

    However, this codepoint is app= licable to all MPLS OAM and not limited

    to MPLS LSP Ping/Traceroute.

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/<= /a>

 

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01=

 

A diff from the previous version is available at:=

http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam-ipv6-rao-01=

 

 

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

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org<= /a>

https:/= /www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/s= hadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= /span>

 

 

--_000_ABD110CD5D879A4BB51C269846E4CA3119E9E0SG70YWXCHMBA08zap_-- From nobody Wed Oct 1 23:51:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010801A0109 for ; Wed, 1 Oct 2014 23:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWVNNaXGoMSG for ; Wed, 1 Oct 2014 23:51:51 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3AF1A0108 for ; Wed, 1 Oct 2014 23:51:51 -0700 (PDT) Received: from [192.168.0.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C7EB31801256; Thu, 2 Oct 2014 08:51:49 +0200 (CEST) Message-ID: <542CF604.6050401@pi.nu> Date: Thu, 02 Oct 2014 08:51:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yP5vIw6WFFn4Qr0kv-ylc1ycc5c Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] IPR poll on draft-raza-mpls-oam-ipv6-rao X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 06:51:54 -0000 Working Group, The authors of draft-raza-mpls-oam-ipv6-rao have told us that the draft is ready to be accepted as a working group document. Before we do poll to see if we have consensus to accept the document as a working group document we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-raza-mpls-oam-ipv6-rao? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 2 03:48:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F821A02E5 for ; Thu, 2 Oct 2014 03:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLKKZGhAZxf0 for ; Thu, 2 Oct 2014 03:48:13 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725131A02DD for ; Thu, 2 Oct 2014 03:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1412246893; x=1413456493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tsEFPk39ZgDUOW9MflKVlv39VVCMQ/2x1+dfChSozR8=; b=fibn4r4IIvLuAiRUUYxTDgeKcALZEo6vXHruKsQOjCeJPrhM4Y5pneed /hWG3pnnqC3O5tfxxF0U6430M1zIVwFqXitlFQ7Ka8aVbp4QDYeOp2Lh3 oP9hME1g0wMPh1EACsr3K3IEX4c9x4hf/AgprwE3nByhvyFJ8W3XiJSOr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPAsLVStJA2B/2dsb2JhbABggmsjgSzSMgKBDBYBe4QDAQEBAwE6MQMGBQUJAgIBCBgeEBsXJQIEDgWINggBvQYBFwSPQBACARwzB4MugR0BBJFti0aVc4NjbIJKAQEB X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208";a="83390642" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 02 Oct 2014 10:48:12 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s92AmC2B028154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 10:48:12 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 05:48:12 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: IPR poll on draft-raza-mpls-oam-ipv6-rao Thread-Index: AQHP3g1aBmmORQHAKU67tun4LonEyZwcoJ3o Date: Thu, 2 Oct 2014 10:48:11 +0000 Message-ID: <09BCB1EF-D23A-4670-B693-C9C30DB4E7FC@cisco.com> References: <542CF604.6050401@pi.nu> In-Reply-To: <542CF604.6050401@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xWy2R1BeLq9FYADoHtyH77x8_7s Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-raza-mpls-oam-ipv6-rao X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 10:48:14 -0000 Loa, I am not aware of any IPR related to this document.=20 Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Oct 2, 2014, at 2:51 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > The authors of draft-raza-mpls-oam-ipv6-rao have told us that the > draft is ready to be accepted as a working group document. >=20 > Before we do poll to see if we have consensus to accept the document > as a working group document we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-raza-mpls-oam-ipv6-rao? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The doc= ument will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 2 05:19:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D30E1A6F68 for ; Thu, 2 Oct 2014 05:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2YiWgjL0ra2 for ; Thu, 2 Oct 2014 05:19:36 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9968D1A6EF1 for ; Thu, 2 Oct 2014 05:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1887; q=dns/txt; s=iport; t=1412252376; x=1413461976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M17ZkDrcgybzgAFp9jFWEVGAuwM4GJbRwfN9zIMgCHU=; b=ZoRjJY6r9F0nd/8hApC+VjgUwvzgRrmjVO3/1gskE3ga/Nb2C/RyNNEL BFcEfNI4eb4Logouh4DU5dLVeeipRqCLUWXuMg/0ytjV/cKYkHqM60EAL u4AELIudVstKulVoCXF0R7OdPl4g3fEb86KlzAFzSLFT9LPbQuurtWA4r k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIRCLVStJA2D/2dsb2JhbABggmsjgSwE0i4CgQwWAXuEAwEBAQQ6MQMGBQwCAgIBCBEEAQELFAkHGxcUCQgCBAENBQiINgG9GgEXBI9AEAIBHjEHBoMogR0BBI9TghqhOYNjbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208";a="83398346" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 02 Oct 2014 12:19:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s92CJJvf003607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 12:19:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 07:19:18 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-raza-mpls-oam-ipv6-rao Thread-Index: AQHP3g1asPzSyj3n8UK43lLvB2lgwZwcucTA Date: Thu, 2 Oct 2014 12:19:18 +0000 Message-ID: References: <542CF604.6050401@pi.nu> In-Reply-To: <542CF604.6050401@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/360aXxR1DsQDQeWcFY4yUGTkbFo Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-raza-mpls-oam-ipv6-rao X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:19:38 -0000 Hi Loa, I am not aware of any IPR that applies to this document. Thanks! -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, October 02, 2014 2:52 AM > To: mpls@ietf.org > Cc: draft-raza-mpls-oam-ipv6-rao@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: IPR poll on draft-raza-mpls-oam-ipv6-rao >=20 > Working Group, >=20 > The authors of draft-raza-mpls-oam-ipv6-rao have told us that the draft i= s > ready to be accepted as a working group document. >=20 > Before we do poll to see if we have consensus to accept the document as a > working group document we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-raza-mpls-oam-ipv6-rao? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. *Th= e > response needs to be sent to the MPLS wg mailing list.* The document will > not advance to the next stage until a response has been received from eac= h > author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR > that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 2 11:29:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1AB1A1AB4; Thu, 2 Oct 2014 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xng9whWkm-56; Thu, 2 Oct 2014 11:29:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B341A1A80; Thu, 2 Oct 2014 11:29:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002182935.828.68483.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 11:29:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/A-y2DaG74MSOI7VPwYD-P-uay6s Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:29:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to LDP for IPv6 Authors : Rajiv Asati Carlos Pignataro Vishwas Manral Rajiv Papneja Filename : draft-ietf-mpls-ldp-ipv6-14.txt Pages : 24 Date : 2014-10-02 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036 and RFC 6720. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ipv6-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 2 12:24:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C36E1A0365 for ; Thu, 2 Oct 2014 12:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o33mEFehMeZ2 for ; Thu, 2 Oct 2014 12:24:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBA01A1B0E for ; Thu, 2 Oct 2014 12:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1547; q=dns/txt; s=iport; t=1412277875; x=1413487475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ysJbgwHIKObTi5Lc3ow/b83sDZ4VMgySs81Xj3nZ4DI=; b=HHvhFwTZ98znKEN1ZmCOQWm/FPfafyktaa/yQc1/PGPuwj9mpGNmhgwe guWYAt1Y09Ww+8k4hIKrcWaaZXy4TI0eeFOsNOCK4gXDhi5is0BUeI1hW tdYLekrQFf7ga844sWw55fpObUaLAv4O1g/GmDWA0A17CMs6npfMRTQwa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOOlLVStJA2H/2dsb2JhbABggw6BKwTSPgKBDRYBe4QEAQEEawMGBQ4CAgEIRhsXJQIEAQ0FiD6+HgEXBI9AEAIBTweESwEEkXKLSYEsg0GRDoNjbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,640,1406592000"; d="scan'208";a="83545224" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 02 Oct 2014 19:24:34 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s92JOYG7003069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 19:24:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 14:24:34 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-raza-mpls-oam-ipv6-rao Thread-Index: AQHP3g1aSRloloiZSU6RyU2MjyCXrZwdQaAA Date: Thu, 2 Oct 2014 19:24:33 +0000 Message-ID: References: <542CF604.6050401@pi.nu> In-Reply-To: <542CF604.6050401@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.254.123] Content-Type: text/plain; charset="Windows-1252" Content-ID: <99628BDD7BA5B743B08C40015F45E9BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZeMpvn7LnkDyJxEs0lQnT9bFwOw Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-raza-mpls-oam-ipv6-rao X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:24:37 -0000 I am not aware of any IPR related to this document. =8B Kamran On 2014-10-02, 2:51 AM, "Loa Andersson" wrote: >Working Group, > >The authors of draft-raza-mpls-oam-ipv6-rao have told us that the >draft is ready to be accepted as a working group document. > >Before we do poll to see if we have consensus to accept the document >as a working group document we want to do an IPR poll on the document. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-raza-mpls-oam-ipv6-rao? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are no IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >(as MPLS WG co-chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 3 03:06:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591D81AD02D for ; Fri, 3 Oct 2014 03:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_rkUVcsDaLv for ; Fri, 3 Oct 2014 03:06:38 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA6C1AD02C for ; Fri, 3 Oct 2014 03:06:38 -0700 (PDT) Received: from [192.168.0.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B87501801510; Fri, 3 Oct 2014 12:06:36 +0200 (CEST) Message-ID: <542E752C.3020203@pi.nu> Date: Fri, 03 Oct 2014 12:06:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zokkmmAZvBawwcKWYSjZxeV7qDg Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 10:06:41 -0000 Working Group, This is to start a two week poll on adopting draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is no IPR disclosures against this document. The authors has all stated on the working group mailing list that they are unaware of any IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends October 17, 2014. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 3 04:47:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1766B1A02DD for ; Fri, 3 Oct 2014 04:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxqNPQ7OMP3X for ; Fri, 3 Oct 2014 04:47:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5181A02E0 for ; Fri, 3 Oct 2014 04:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1412336829; x=1413546429; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mww2o0Xw7uRTZl4i4OcJjGP57XaJdOp8q0/Esp4Jn3Q=; b=aUKPuWsatOxPgsbt/T9Q7bIpccZsRq9IEGIX7+0q2aqblRyH6h1q79EM KA9LG83P1xTNiuV6OFxWMTMaUi2hXj9WulIY03pqSIfq43P+ZwA+x9tq9 uparLwz64wGMdNQDPSMNpgX5eJSpgQTc0Cfl6p31LrvZuLfXApF/I8Rb5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAEeMLlStJA2N/2dsb2JhbABggw5TWATKbAqHTQKBDBYBe4QEAQEEAQEBNzEDCw4CAgEINhAbDAslAgQBDQWIPg2+dAETBASPQBEBUAeESwWPWoIai0mBLINBjQ+Df4IggUNsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,646,1406592000"; d="scan'208";a="360477376" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 03 Oct 2014 11:47:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s93Bl86Y017062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 11:47:08 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.111]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 06:47:08 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHBkfNaCaWOW0yReCcDbMIo7ZweUmIA Date: Fri, 3 Oct 2014 11:47:07 +0000 Message-ID: References: <542E752C.3020203@pi.nu> In-Reply-To: <542E752C.3020203@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.96.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <92E2DC32DC7CD745944B849668D0A05D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BE7P7g-eKPnOQHBYf8ZirBNPcvk Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 11:47:11 -0000 Support. Thanks, Nagendra On 10/3/14, 6:06 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll on adopting >draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is no IPR disclosures against this document. > >The authors has all stated on the working group mailing >list that they are unaware of any IPR claims against this draft. > >However if you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, the time to disclose >this is now. > >This poll ends October 17, 2014. > >/Loa > >for the MPLS wg co-chairs >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 3 08:59:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A351A0379; Fri, 3 Oct 2014 08:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz41QjBdAcCA; Fri, 3 Oct 2014 08:59:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB14F1A037F; Fri, 3 Oct 2014 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1412351966; x=1413561566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vi43q8F8StGOOhejq1uUu24Dzq6+7cNJx79MNPkdeHI=; b=IXlY21qnS4MA3DZ4mtpSo5kNJ4wV5eVoSEOb7OBiL3eb0lHvBWzXileW bHtkYP8ZQ4CItWxi+X7z2mMc/qWQMAdt5f8XSJ/prFv875Jq7cmJgbRSo 1ThwAZmf9JLEhR1Wn8iWnb+VgT0P2hskxR/cBbcgoy7/GxSWxNLYxNbX6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFABnHLlStJV2b/2dsb2JhbABggw5TWASCfsgDh0sCGXQWAXuEAwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEAQ0FCAGINQ2pSpVtAReBLI5RBisHBAKCcTaBHgWRdIQ8iDs7gweREYNjbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,647,1406592000"; d="scan'208";a="83821621" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 03 Oct 2014 15:59:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s93FxPTF030820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 15:59:25 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 10:59:25 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-grmas-bfd-rfc5884-clarifications-00.txt Thread-Index: AQHP3xB2zMbNL6+ypkangFD1rnC1p5wehltw Date: Fri, 3 Oct 2014 15:59:25 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D346A9D9E@xmb-rcd-x15.cisco.com> References: <20141003134634.31923.87610.idtracker@ietfa.amsl.com> In-Reply-To: <20141003134634.31923.87610.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QPTnKRHXZfe1aKmKOMCi6yKblu4 Cc: "kalyani.rajaraman@ericsson.com" Subject: [mpls] FW: New Version Notification for draft-grmas-bfd-rfc5884-clarifications-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:59:34 -0000 SGVsbG8gYWxsLA0KICBBIG5ldyBkcmFmdCAoZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtY2xhcmlm aWNhdGlvbnMpIGhhcyBiZWVuIHN1Ym1pdHRlZCBiYXNlZCBvbiBkaXNjdXNzaW9ucyBhdCBJRVRG LTkwIGZvciBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYuIFBsZWFz ZSBub3RlIHRoYXQgdGhlIGxhdHRlciB3aWxsIGJlIGRpc2NvbnRpbnVlZC4gQ29tbWVudHMvIFJl dmlld3MgYXJlIHdlbGNvbWUgZm9yIGRyYWZ0LWdybWFzLWJmZC1yZmMtNTg4NC1jbGFyaWZpY2F0 aW9ucy4NCi0gQXV0aG9ycw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IEZyaWRheSwgT2N0b2JlciAwMywgMjAxNCA3OjE3IFBNDQpUbzogTm9ibyBBa2l5YSAo bm9ibyk7IFNhbSBBbGRyaW47IEdyZWcgTWlyc2t5OyBHcmVnb3J5IE1pcnNreTsgS2FseWFuaSBS YWphcmFtYW47IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IE5vYm8gQWtpeWEg KG5vYm8pOyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBLYWx5YW5pIFJhamFy YW1hbjsgU2FtIEFsZHJpbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1ncm1hcy1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtY2xhcmlmaWNhdGlvbnMtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdv dmluZGFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWdybWFzLWJmZC1yZmM1ODg0LWNsYXJpZmljYXRpb25zDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJ Q2xhcmlmaWNhdGlvbnMgdG8gUkZDIDU4ODQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMDMNCkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTYNClVSTDogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ncm1hcy1iZmQtcmZjNTg4 NC1jbGFyaWZpY2F0aW9ucy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ncm1hcy1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncm1hcy1i ZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1 bWVudCBjbGFyaWZpZXMgdGhlIHByb2NlZHVyZXMgZm9yIGVzdGFibGlzaGluZywgbWFpbnRhaW5p bmcNCiAgIGFuZCByZW1vdmluZyBtdWx0aXBsZSwgY29uY3VycmVudCBCRkQgc2Vzc2lvbnMgZm9y IGEgZ2l2ZW4gPE1QTFMgTFNQLA0KICAgRkVDPiBkZXNjcmliZWQgaW4gUkZDNTg4NC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Oct 3 16:49:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AE1A7D85 for ; Fri, 3 Oct 2014 16:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHwJ0Tqda8pO for ; Fri, 3 Oct 2014 16:48:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE321A1A3A for ; Fri, 3 Oct 2014 16:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6133; q=dns/txt; s=iport; t=1412380137; x=1413589737; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=F4lsry7ssJEXTsgn/w47j6tc3Iu//SVS9RfG8A4Yo2M=; b=a4fjS/INfwyyM6MudxNpRFGURVRgPaORQvzBObxuBYYEziNW+U3R26YM OobWL6SWDzwaB1/6iYZCLLkOOqH0HNrFA1YBRYFy1a6aWncuTfW+3F/5r fp+LXr6SCGtEm9J/8W1cuGDFI/wFq8K0fH4GpVjLcR3Qi2T7BNoHvf+YK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAAY1L1StJA2N/2dsb2JhbABggmsjU1gEywQKh00CgQcWAXuEAwEBAQQBAQE3MQMXAgICAQgRBAEBAQoUBQQHGwwLFAkIAgQBEggBiDUBDL8fARcEj0gRAR84BoMngR4Fj1qCGox3g0KDKolog3+CIIFDbIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,651,1406592000"; d="scan'208";a="360637742" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 03 Oct 2014 23:48:55 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s93NmtOD024564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 23:48:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 18:48:55 -0500 From: "Nobo Akiya (nobo)" To: "Rakesh Gandhi (rgandhi)" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95rvpygwvJHak669hrw561NhZvCdOXggFfvg4CABQuIQA== Date: Fri, 3 Oct 2014 23:48:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_sCIjhbzVGT8xN5BBpRge-pcdKg Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 23:48:59 -0000 Hi Rakesh, et al, I see that published WG-01 has all of my comments incorporated. Thanks for = considering my comments and notifying me of their completion. Thanks! -Nobo > -----Original Message----- > From: Rakesh Gandhi (rgandhi) > Sent: Tuesday, September 30, 2014 9:41 AM > To: Nobo Akiya (nobo); Loa Andersson; mpls@ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-tsaad-mpls- > p2mp-loose-path-reopt@tools.ietf.org > Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mp= ls- > p2mp-loose-path-reopt an mpls wg doc >=20 > Thanks Nobo for the review comments. The latest draft addresses the > review comments. >=20 > Please have a look at this version: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-loose-path- > reopt-0 > 1.txt >=20 >=20 >=20 > Thanks, > Rakesh >=20 >=20 > On 2014-08-06 6:46 PM, "Nobo Akiya (nobo)" wrote: >=20 > >Hi Loa, > > > >I have read this document and support the adoption as a WG document. > >Not only does this document reduce signaling messages for P2MP-TE > >re-evaluation and re-optimization, it allow a mid-point LSR to > >re-evaluate groups of S2L sub-LSPs together without some S2L sub-LSP > >grouping heuristics, which is quite beneficial. > > > >I have few suggestions to authors, but all are not at all stoppers > >before its WG adoption. > > > > > >1. This is a protocol extension that introduces new objects and > >procedures, but the document lacks RFC2119 words (i.e. MAY, SHOULD, > >MUST, etc). It would be highly beneficial to make use of RFC2119 words > >where necessary (particularly in Sections 3 and 4). > > > > > >2. Abstract, first paragraph, last sentence was slightly difficult to > >read and had a typo. Suggested new text. > > > >[OLD] > > Existing mechanisms allow the path re-evaluation and the > > signaling of a the notification of preferred path exists for a single > > S2L sub-LSP only. > > > >[NEW] > > Existing mechanisms, a mechanism for a head-end LSR to > > trigger a new path re-evaluation and a mechanism for a mid-point LSR > > to signal an availability of a preferred path, operate on a single > > S2L sub-LSP only. > > > > > >3. Section 3, second paragraph. > > > >[snip] > > An > > ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP > > tree to trigger the re-evaluation request(s). > >[snip] > > > >It may be beneficial to clarify the reason behind specifying one or > >more S2L sub-LSPs, i.e. to specify the sub-groups. > > > > > >4. Section 3, third paragraph. > > > >I'd like to propose a bit of rephrase in the last portion of this > >sentence, for clarification purpose. > > > >[OLD] > > A mid-point LSR that expands loose next-hop(s) for one or more S2L > > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > > LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the > > P2MP-TE LSP. > > > >[NEW] > > A mid-point LSR that expands loose next-hop(s) for one or more S2L > > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > > LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths > > of the loose next-hop(s) of the P2MP-TE LSP. > > > > > >5. Section 3, third paragraph (towards the end). > > > >[snip] > > In this case, the mid-point LSR that expands loose next- > > hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L > > sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to > > the ingress node. > >[snip] > > > >Similar to comment #3 above, it may be beneficial to clarify the reason > >behind specifying one or more S2L sub-LSPs, i.e. to specify the > >sub-groups. > > > > > >6. There's also a typo in the Security Considerations section. > > > >[OLD] > >it may be desirable for a a mid-point LSR to modify > > > >[NEW] > >it may be desirable for a mid-point LSR to modify > > > >[NOTE] > >s/a a /a / > > > > > >Thanks! > > > >-Nobo > > > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > >> Sent: Wednesday, July 30, 2014 6:10 AM > >> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > >> (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org > >> Subject: [mpls] poll to see if we have support to make > >> draft-tsaad-mpls- p2mp-loose-path-reopt an mpls wg doc > >> > >> Working Group, > >> > >> This is to start a two week poll on adopting > >> draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group > >> document. > >> > >> Please send your comments (support/not support) to the mpls working > >>group mailing list (mpls@ietf.org). Please give a technical motivation > >>for your support/not support, especially if you think that the > >>document should not be adopted as a working group document. > >> > >> There is one IPR claim against this document. > >> > >> The authors and contributors has stated on the working group mailing > >>list that they are not aware of any other IPR claims against this > >>draft. > >> > >> However if you are on the the mpls working group mailing list and > >>aware of IPR that relates to this draft, the time to disclose this is > >>now. > >> > >> This poll ends August 14, 2014. > >> > >> /Loa > >> > >> for the MPLS wg co-chairs > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > From nobody Fri Oct 3 17:02:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0E1A89EF for ; Fri, 3 Oct 2014 17:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoNXZ2cAc0dP for ; Fri, 3 Oct 2014 17:02:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79341A7031 for ; Fri, 3 Oct 2014 17:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1737; q=dns/txt; s=iport; t=1412380966; x=1413590566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TBfLh1xgbCtMYQY7T/Z+bTVRdm7lGg4T2FZtYhMuFzM=; b=hNTH4QOK1pAGQsM87mXahsHPPmiG8QVT9Ma8jLKPNTY7nNUunWkv8Iap ripRAnJPx8OwU7Qf4n2qSozgsttVMpOEOQn7lryRi9+D/SeEZDJzH7R8/ QuATySyYMd4Rwtu56h5QVuHlzZbaM4bBbYa6eEPjEtWA2zSnQdYxorgOy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJI4L1StJV2U/2dsb2JhbABggmsjgSsE0lsCgQcWAXuEAwEBAQQ6MQMLDAICAgEIEQQBAQsUCQcbFxQJCAIEAQ0FCIg2Ab8tARcEj0gRAR8xBwaDJ4EeAQSPWoIajHeDQo0Sg3+CIIFDbIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,651,1406592000"; d="scan'208";a="83880302" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 04 Oct 2014 00:02:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9402ij5022765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Oct 2014 00:02:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 19:02:43 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vG87bTh/ki7A0aRm8bqOY69nZwfDbvA Date: Sat, 4 Oct 2014 00:02:43 +0000 Message-ID: References: <542E752C.3020203@pi.nu> In-Reply-To: <542E752C.3020203@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uQIhUQv0mFe7YXz_fh71jfaDlzQ Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 00:02:47 -0000 Hi Loa, I support the WG adoption of draft-raza-mpls-oam-ipv6-rao as a co-author of= this document [obviously :)]. The primary reason behind this is that this document defines the necessary = RAO code point to implement IPv6 LSP Ping/Traceroute that is RFC4379 compli= ant. Thanks! -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, October 03, 2014 6:07 AM > To: mpls@ietf.org > Cc: draft-raza-mpls-oam-ipv6-rao@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: poll to see if we have support to make draft-raza-mpls-oam-ipv6- > rao an mpls wg doc >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation fo= r > your support/not support, especially if you think that the document shoul= d > not be adopted as a working group document. >=20 > There is no IPR disclosures against this document. >=20 > The authors has all stated on the working group mailing list that they ar= e > unaware of any IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and aware o= f > IPR that relates to this draft, the time to disclose this is now. >=20 > This poll ends October 17, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 3 17:13:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5D1A89E9 for ; Fri, 3 Oct 2014 17:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HejToPGImt-1 for ; Fri, 3 Oct 2014 17:13:29 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD2E1A8741 for ; Fri, 3 Oct 2014 17:13:29 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id g10so371043pdj.32 for ; Fri, 03 Oct 2014 17:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=rOGyR/STPS76AsF/8AKEiTf9mbuTJMe+Vyq/Yj/PmG0=; b=uNKqcgFh2iiFA4wRTOghYwloCakw0lfxsxhodglCM51KJu+0Kpumt7zcWQQCe9iOjI Hg8BBurkhJZal7egH7auZKdUwoYVyrcifXffokpWwESihvAZd8nbW8iooBpFOcMsYspd 1R1u6hUdcFMRETFmHsfNyDvAxpZBJp+d+oqBmJfqOR3gNI3DtYpvGWxP5llsZtDPNAAT v4KqrNkWK3VZ2+aC5ozj8GV/r4Fym3KHk1GuO22M6lCDMfJOFd7eiJtmDE/Z59FSj0O7 1VD4zhDAOLtQR+pGO0DqQZi/8Ow2KHdrEJ0CriRJ6I+mU4JItRHf9LT2LO+En944KtlE EB6w== X-Received: by 10.70.54.8 with SMTP id f8mr3906354pdp.110.1412381609446; Fri, 03 Oct 2014 17:13:29 -0700 (PDT) Received: from [10.181.32.3] ([166.170.37.139]) by mx.google.com with ESMTPSA id c3sm5172491pdk.3.2014.10.03.17.13.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 17:13:28 -0700 (PDT) References: <542E752C.3020203@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <542E752C.3020203@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12A405) From: Sam Aldrin Date: Fri, 3 Oct 2014 17:13:26 -0700 To: Loa Andersson Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zeYTwaysHIJdtXrpqaTHCEey5Wo Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 00:13:31 -0000 Support!! It fills the missing piece in IPv6 support. Sam Sent from my iPhone > On Oct 3, 2014, at 3:06 AM, Loa Andersson wrote: > > Working Group, > > This is to start a two week poll on adopting > draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is no IPR disclosures against this document. > > The authors has all stated on the working group mailing > list that they are unaware of any IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends October 17, 2014. > > /Loa > > for the MPLS wg co-chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Oct 5 11:44:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A221A1ACA for ; Sun, 5 Oct 2014 11:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cIzea4bJh-u for ; Sun, 5 Oct 2014 11:44:55 -0700 (PDT) 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 7076A1A1AC9 for ; Sun, 5 Oct 2014 11:44:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKF95876; Sun, 05 Oct 2014 18:44:52 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 5 Oct 2014 19:44:50 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML702-CHM.china.huawei.com ([169.254.4.76]) with mapi id 14.03.0158.001; Sun, 5 Oct 2014 11:44:44 -0700 From: Huaimo Chen To: "Jeffrey (Zhaohui) Zhang" Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTAKcjt8kA== Date: Sun, 5 Oct 2014 18:44:43 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> In-Reply-To: <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SSgAPb9ZWGIWNjxrpwHLsg7jqz4 Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 18:44:57 -0000 Hi Jeffrey, Thanks much for your comments! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Wednesday, August 13, 2014 10:19 AM To: Huaimo Chen Cc: mpls@ietf.org Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protecti= on-01.txt Huaimo, Please see below. > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, August 10, 2014 3:59 PM > To: Jeffrey (Zhaohui) Zhang > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > protection-01.txt >=20 > Hi Jeffrey, >=20 > Thanks very much for your questions and comments! > My answers/explanations are inline below. >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Friday, August 08, 2014 3:45 PM > To: Huaimo Chen > Cc: mpls@ietf.org > Subject: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > protection-01.txt >=20 > Huaimo, >=20 > I have some questions and comments on the draft. I only started=20 > looking into this now so some of these might have been discussed=20 > before. In that case, you can just refer me to some old email in the=20 > archive for me to go through. >=20 > One big question I have is about the following: >=20 > After receiving the Path message with the EGRESS_BACKUP, the primary > egress includes the information about the primary LSP label in the > Resv message with an EGRESS_BACKUP object as UA label. When the PLR > receives the Resv message with the information about the UA label, it > includes the information in the Path message for the backup LSP to > the backup egress. Thus the primary LSP label as UA label is sent to > the backup egress from the primary egress. >=20 > When the PLR detects the failure of the primary egress, it redirects > the packets from the primary LSP into the backup LSP to backup egress > using the primary LSP label from the primary egress as an inner > label. The backup egress delivers the packets to the same > destinations as the primary egress using the backup LSP label as > context label and the inner label as UA label. >=20 > In the above text, the inner label is not service label like VPN/PWE3=20 > label. It is the transport label assigned by the primary egress and=20 > relayed by the PLR to egress. How does the backup know what to do with=20 > that transport label and the application (e.g. vpn) label that follows=20 > it? >=20 > Huaimo: The inner label here is not service label such as VPN label.=20 > It is the transport label allocated by the primary egress for the=20 > primary LSP. This part is added according to some comments. At the=20 > primary egress, the transport label may be used for some things. For=20 > example, it may be used for counting the number of packets received from = the LSP. > Thus it is better to stack the transport label for the primary LSP in=20 > the backup LSP when the primary egress fails if the label is used for=20 > some purposes. In the backup LSP, there may be three labels: the=20 > backup LSP label, the transport label for the primary LSP, and the=20 > service label such as VPN label. > At the backup egress, the backup LSP label is used as a context label,=20 > under this context, the transport label for the primary LSP and the=20 > service label are processed as upstream assigned labels. >=20 >=20 > In other places, it talks about using BGP or some other protocols to=20 > distribute service labels and that seems reasonable. I suppose the=20 > above text is not correct? >=20 > Huaimo: The above text talks about sending the transport label=20 > allocated by the primary egress for primary LSP to the backup egress as a= UA label. > There may be two UA labels in a backup LSP: one is the transport=20 > label, the other is the service label under the transport label. While the PLR can relay the transport label from the primary egress to the = backup egress, the forwarding behavior is not (at least not according to th= e spec). For example, in VPN case, the backup egress learns from the primar= y egress not just the values of VPN labels but also how to forward based on= those labels (i.e. label to prefix bindings). If there will be a separate mechanism outside the scope of this doc to be u= sed, then there is no need for the PLR to relay the label via RSVP? Huaimo: We may use a separate mechanism outside the scope of this document.= It seems that the alternative option proposed in this document may also be= used since it may have some advantages.=20 >=20 >=20 > The other big question is, compared to ingress signaling those=20 > additional flags and backup egress address via PATH messages, wouldn't=20 > it be easier for the primary egress to signal via RESV message to the=20 > PLR that it wants egress protection, and optionally specify the backup=20 > egress address? That way, the ingress and transit nodes are not=20 > bothered at all. >=20 > Huaimo: This is a good question. Currently controlling and signaling=20 > the attributes (including flags) of backup LSPs for protecting a=20 > primary LSP against link and intermediate node failures starts from=20 > the ingress of the primary LSP via PATH messages. We follow this for=20 > the egress protection. > There may be some advantages for the primary egress to signal/driven=20 > the egress protection. But there may be some disadvantages. For=20 > example, to protect a primary LSP against intermediate node and egress=20 > node failures, we need to do configurations on multiple places: one is=20 > on the ingress to configure intermediate node protection, the others=20 > are on the egresses to configure egress node protection. We can=20 > discuss on this in more details. Egress protection really has to be tied to the service so there likely to b= e service related configuration on the egress after all (and the ingress wo= uld need to learn/configure that). Using the ingress configuration for the = regular link/node protection but limit egress protection configuration and = signaling to the egress would be better. Huaimo: If we configure egress protection on egress, it seems that there ar= e more work. For example, in order to protect the egresses of a P2MP LSP, w= e need configure egress protection on every egress of the P2MP LSP. > Huaimo: It seems that some people proposed that a primary LSP set up=20 > is signaled/driven by the egress of the LSP. In this case, the egress=20 > protection signaled/driven by the egress seems a very good fit. The two topics should be separated :-) Jeffrey >=20 >=20 > I'll leave out some smaller questions/comments for now. >=20 > Thanks. > Jeffrey From nobody Sun Oct 5 20:33:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C86D1A1AFE for ; Sun, 5 Oct 2014 20:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzIdg0fBxon5 for ; Sun, 5 Oct 2014 20:33:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F5C1A1AE4 for ; Sun, 5 Oct 2014 20:33:15 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 03:32:51 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) with mapi id 15.00.1044.008; Mon, 6 Oct 2014 03:32:51 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Huaimo Chen Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTAKcjt8kAATRhAA Date: Mon, 6 Oct 2014 03:32:50 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB078; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(377454003)(199003)(51704005)(25584003)(13464003)(189002)(107046002)(99286002)(108616004)(105586002)(93886004)(85306004)(106356001)(85852003)(95666004)(110136001)(86362001)(120916001)(92566001)(99396003)(10300001)(76576001)(76482002)(77096002)(40100001)(230783001)(101416001)(122556001)(97736003)(74316001)(76176999)(20776003)(50986999)(54356999)(64706001)(66066001)(33646002)(46102003)(31966008)(80022003)(21056001)(2656002)(87936001)(4396001)(19580395003)(19580405001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EbMx4if-DQFJOHp-FwHEaz7lcxM Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 03:33:17 -0000 Huaimo, > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, October 05, 2014 2:45 PM > To: Jeffrey (Zhaohui) Zhang > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress- > protection-01.txt >=20 > Hi Jeffrey, >=20 > Thanks much for your comments! > My answers/explanations are inline below. >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, August 13, 2014 10:19 AM > To: Huaimo Chen > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress- > protection-01.txt >=20 > Huaimo, >=20 > Please see below. >=20 > > -----Original Message----- > > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > > Sent: Sunday, August 10, 2014 3:59 PM > > To: Jeffrey (Zhaohui) Zhang > > Cc: mpls@ietf.org > > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress- > > protection-01.txt > > > > Hi Jeffrey, > > > > Thanks very much for your questions and comments! > > My answers/explanations are inline below. > > > > Best Regards, > > Huaimo > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Friday, August 08, 2014 3:45 PM > > To: Huaimo Chen > > Cc: mpls@ietf.org > > Subject: Questions and comments on draft-ietf-mpls-rsvp-egress- > > protection-01.txt > > > > Huaimo, > > > > I have some questions and comments on the draft. I only started > > looking into this now so some of these might have been discussed > > before. In that case, you can just refer me to some old email in the > > archive for me to go through. > > > > One big question I have is about the following: > > > > After receiving the Path message with the EGRESS_BACKUP, the primary > > egress includes the information about the primary LSP label in the > > Resv message with an EGRESS_BACKUP object as UA label. When the PLR > > receives the Resv message with the information about the UA label, i= t > > includes the information in the Path message for the backup LSP to > > the backup egress. Thus the primary LSP label as UA label is sent t= o > > the backup egress from the primary egress. > > > > When the PLR detects the failure of the primary egress, it redirects > > the packets from the primary LSP into the backup LSP to backup egres= s > > using the primary LSP label from the primary egress as an inner > > label. The backup egress delivers the packets to the same > > destinations as the primary egress using the backup LSP label as > > context label and the inner label as UA label. > > > > In the above text, the inner label is not service label like VPN/PWE3 > > label. It is the transport label assigned by the primary egress and > > relayed by the PLR to egress. How does the backup know what to do with > > that transport label and the application (e.g. vpn) label that follows > > it? > > > > Huaimo: The inner label here is not service label such as VPN label. > > It is the transport label allocated by the primary egress for the > > primary LSP. This part is added according to some comments. At the > > primary egress, the transport label may be used for some things. For > > example, it may be used for counting the number of packets received fro= m the LSP. > > Thus it is better to stack the transport label for the primary LSP in > > the backup LSP when the primary egress fails if the label is used for > > some purposes. In the backup LSP, there may be three labels: the > > backup LSP label, the transport label for the primary LSP, and the > > service label such as VPN label. > > At the backup egress, the backup LSP label is used as a context label, > > under this context, the transport label for the primary LSP and the > > service label are processed as upstream assigned labels. > > > > > > In other places, it talks about using BGP or some other protocols to > > distribute service labels and that seems reasonable. I suppose the > > above text is not correct? > > > > Huaimo: The above text talks about sending the transport label > > allocated by the primary egress for primary LSP to the backup egress as= a UA label. > > There may be two UA labels in a backup LSP: one is the transport > > label, the other is the service label under the transport label. >=20 > While the PLR can relay the transport label from the primary egress to > the backup egress, the forwarding behavior is not (at least not > according to the spec). For example, in VPN case, the backup egress > learns from the primary egress not just the values of VPN labels but > also how to forward based on those labels (i.e. label to prefix > bindings). >=20 > If there will be a separate mechanism outside the scope of this doc to > be used, then there is no need for the PLR to relay the label via RSVP? >=20 > Huaimo: We may use a separate mechanism outside the scope of this > document. It seems that the alternative option proposed in this document > may also be used since it may have some advantages. My point is that, what's proposed in this draft can't really work, because = while the backup can learn the label relayed by the PLR, it still does not = know what to do with it. Until you have a separate document to spell out th= at separate mechanism, there is no point for this spec to relay the label. >=20 > > > > > > The other big question is, compared to ingress signaling those > > additional flags and backup egress address via PATH messages, wouldn't > > it be easier for the primary egress to signal via RESV message to the > > PLR that it wants egress protection, and optionally specify the backup > > egress address? That way, the ingress and transit nodes are not > > bothered at all. > > > > Huaimo: This is a good question. Currently controlling and signaling > > the attributes (including flags) of backup LSPs for protecting a > > primary LSP against link and intermediate node failures starts from > > the ingress of the primary LSP via PATH messages. We follow this for > > the egress protection. > > There may be some advantages for the primary egress to signal/driven > > the egress protection. But there may be some disadvantages. For > > example, to protect a primary LSP against intermediate node and egress > > node failures, we need to do configurations on multiple places: one is > > on the ingress to configure intermediate node protection, the others > > are on the egresses to configure egress node protection. We can > > discuss on this in more details. >=20 > Egress protection really has to be tied to the service so there likely > to be service related configuration on the egress after all (and the > ingress would need to learn/configure that). Using the ingress > configuration for the regular link/node protection but limit egress > protection configuration and signaling to the egress would be better. >=20 > Huaimo: If we configure egress protection on egress, it seems that there > are more work. For example, in order to protect the egresses of a P2MP > LSP, we need configure egress protection on every egress of the P2MP LSP. It's the same amount of information configured, either all on the ingress P= E or separated on all egress PEs. The latter will have much lower signaling= head. Jeffrey >=20 > > Huaimo: It seems that some people proposed that a primary LSP set up > > is signaled/driven by the egress of the LSP. In this case, the egress > > protection signaled/driven by the egress seems a very good fit. >=20 > The two topics should be separated :-) >=20 > Jeffrey >=20 > > > > > > I'll leave out some smaller questions/comments for now. > > > > Thanks. > > Jeffrey From nobody Mon Oct 6 05:56:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEB01A6F15 for ; Mon, 6 Oct 2014 05:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmhgH88cPWtt for ; Mon, 6 Oct 2014 05:56:06 -0700 (PDT) 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 9C46A1A6F13 for ; Mon, 6 Oct 2014 05:56:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNI91844; Mon, 06 Oct 2014 12:56:04 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Oct 2014 13:56:03 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 6 Oct 2014 05:55:59 -0700 From: Huaimo Chen To: "Jeffrey (Zhaohui) Zhang" Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTAKcjt8kAATRhAAABHa+6A= Date: Mon, 6 Oct 2014 12:55:58 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445CA8288@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Oatb5gPkW1FDdzEwow2n2plDhBo Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 12:56:09 -0000 Hi Jeffrey, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Sunday, October 05, 2014 11:33 PM To: Huaimo Chen Cc: mpls@ietf.org Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protecti= on-01.txt Huaimo, > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, October 05, 2014 2:45 PM > To: Jeffrey (Zhaohui) Zhang > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > protection-01.txt >=20 > Hi Jeffrey, >=20 > Thanks much for your comments! > My answers/explanations are inline below. >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, August 13, 2014 10:19 AM > To: Huaimo Chen > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > protection-01.txt >=20 > Huaimo, >=20 > Please see below. >=20 > > -----Original Message----- > > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > > Sent: Sunday, August 10, 2014 3:59 PM > > To: Jeffrey (Zhaohui) Zhang > > Cc: mpls@ietf.org > > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > > protection-01.txt > > > > Hi Jeffrey, > > > > Thanks very much for your questions and comments! > > My answers/explanations are inline below. > > > > Best Regards, > > Huaimo > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Friday, August 08, 2014 3:45 PM > > To: Huaimo Chen > > Cc: mpls@ietf.org > > Subject: Questions and comments on draft-ietf-mpls-rsvp-egress-=20 > > protection-01.txt > > > > Huaimo, > > > > I have some questions and comments on the draft. I only started=20 > > looking into this now so some of these might have been discussed=20 > > before. In that case, you can just refer me to some old email in the=20 > > archive for me to go through. > > > > One big question I have is about the following: > > > > After receiving the Path message with the EGRESS_BACKUP, the primary > > egress includes the information about the primary LSP label in the > > Resv message with an EGRESS_BACKUP object as UA label. When the PLR > > receives the Resv message with the information about the UA label, i= t > > includes the information in the Path message for the backup LSP to > > the backup egress. Thus the primary LSP label as UA label is sent t= o > > the backup egress from the primary egress. > > > > When the PLR detects the failure of the primary egress, it redirects > > the packets from the primary LSP into the backup LSP to backup egres= s > > using the primary LSP label from the primary egress as an inner > > label. The backup egress delivers the packets to the same > > destinations as the primary egress using the backup LSP label as > > context label and the inner label as UA label. > > > > In the above text, the inner label is not service label like=20 > > VPN/PWE3 label. It is the transport label assigned by the primary=20 > > egress and relayed by the PLR to egress. How does the backup know=20 > > what to do with that transport label and the application (e.g. vpn)=20 > > label that follows it? > > > > Huaimo: The inner label here is not service label such as VPN label. > > It is the transport label allocated by the primary egress for the=20 > > primary LSP. This part is added according to some comments. At the=20 > > primary egress, the transport label may be used for some things. For=20 > > example, it may be used for counting the number of packets received fro= m the LSP. > > Thus it is better to stack the transport label for the primary LSP=20 > > in the backup LSP when the primary egress fails if the label is used=20 > > for some purposes. In the backup LSP, there may be three labels: the=20 > > backup LSP label, the transport label for the primary LSP, and the=20 > > service label such as VPN label. > > At the backup egress, the backup LSP label is used as a context=20 > > label, under this context, the transport label for the primary LSP=20 > > and the service label are processed as upstream assigned labels. > > > > > > In other places, it talks about using BGP or some other protocols to=20 > > distribute service labels and that seems reasonable. I suppose the=20 > > above text is not correct? > > > > Huaimo: The above text talks about sending the transport label=20 > > allocated by the primary egress for primary LSP to the backup egress as= a UA label. > > There may be two UA labels in a backup LSP: one is the transport=20 > > label, the other is the service label under the transport label. >=20 > While the PLR can relay the transport label from the primary egress to=20 > the backup egress, the forwarding behavior is not (at least not=20 > according to the spec). For example, in VPN case, the backup egress=20 > learns from the primary egress not just the values of VPN labels but=20 > also how to forward based on those labels (i.e. label to prefix=20 > bindings). >=20 > If there will be a separate mechanism outside the scope of this doc to=20 > be used, then there is no need for the PLR to relay the label via RSVP? >=20 > Huaimo: We may use a separate mechanism outside the scope of this=20 > document. It seems that the alternative option proposed in this=20 > document may also be used since it may have some advantages. My point is that, what's proposed in this draft can't really work, because = while the backup can learn the label relayed by the PLR, it still does not = know what to do with it. Until you have a separate document to spell out th= at separate mechanism, there is no point for this spec to relay the label. Huaimo: It seems that the alternative option proposed may work. The UA labe= l with the forwarding information in TLV may be relayed to the backup egres= s. RSVP on the backup egress can pass the UA label with the information to = a separated component handling the UA label. In fact, RSVP just relays the = UA label and related information. The processing on UA label is done by the= separated component outside of RSVP. >=20 > > > > > > The other big question is, compared to ingress signaling those=20 > > additional flags and backup egress address via PATH messages,=20 > > wouldn't it be easier for the primary egress to signal via RESV=20 > > message to the PLR that it wants egress protection, and optionally=20 > > specify the backup egress address? That way, the ingress and transit=20 > > nodes are not bothered at all. > > > > Huaimo: This is a good question. Currently controlling and signaling=20 > > the attributes (including flags) of backup LSPs for protecting a=20 > > primary LSP against link and intermediate node failures starts from=20 > > the ingress of the primary LSP via PATH messages. We follow this for=20 > > the egress protection. > > There may be some advantages for the primary egress to signal/driven=20 > > the egress protection. But there may be some disadvantages. For=20 > > example, to protect a primary LSP against intermediate node and=20 > > egress node failures, we need to do configurations on multiple=20 > > places: one is on the ingress to configure intermediate node=20 > > protection, the others are on the egresses to configure egress node=20 > > protection. We can discuss on this in more details. >=20 > Egress protection really has to be tied to the service so there likely=20 > to be service related configuration on the egress after all (and the=20 > ingress would need to learn/configure that). Using the ingress=20 > configuration for the regular link/node protection but limit egress=20 > protection configuration and signaling to the egress would be better. >=20 > Huaimo: If we configure egress protection on egress, it seems that=20 > there are more work. For example, in order to protect the egresses of=20 > a P2MP LSP, we need configure egress protection on every egress of the P2= MP LSP. It's the same amount of information configured, either all on the ingress P= E or separated on all egress PEs. The latter will have much lower signaling= head. Huaimo: It seems that there are more configurations. For example, we may ne= ed to configure one-to-one protection or facility protection for protecting= the egresses of a P2MP LSP on every egress of the P2MP LSP if we limit egr= ess protection configuration to the egresses.=20 Jeffrey >=20 > > Huaimo: It seems that some people proposed that a primary LSP set up=20 > > is signaled/driven by the egress of the LSP. In this case, the=20 > > egress protection signaled/driven by the egress seems a very good fit. >=20 > The two topics should be separated :-) >=20 > Jeffrey >=20 > > > > > > I'll leave out some smaller questions/comments for now. > > > > Thanks. > > Jeffrey From nobody Mon Oct 6 06:13:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4D1A6F15 for ; Mon, 6 Oct 2014 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO-3Onnw8YlS for ; Mon, 6 Oct 2014 06:13:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9811A6F13 for ; Mon, 6 Oct 2014 06:13:10 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 13:12:46 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) with mapi id 15.00.1044.008; Mon, 6 Oct 2014 13:12:46 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Huaimo Chen Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTAKcjt8kAATRhAAABHa+6AAAhfnsA== Date: Mon, 6 Oct 2014 13:12:46 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445CA8288@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445CA8288@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB079; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(37854004)(99396003)(77096002)(31966008)(46102003)(80022003)(99286002)(105586002)(95666004)(86362001)(85306004)(66066001)(107046002)(92566001)(76576001)(93886004)(122556001)(108616004)(97736003)(64706001)(10300001)(40100001)(20776003)(120916001)(33646002)(74316001)(21056001)(4396001)(2656002)(87936001)(230783001)(101416001)(85852003)(110136001)(106356001)(76482002)(54356999)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kRf0vZaT2RAYMEvXoTR1PDiR5ZM Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:13:14 -0000 Huaimo, ... snipped ... > My point is that, what's proposed in this draft can't really work, > because while the backup can learn the label relayed by the PLR, it > still does not know what to do with it. Until you have a separate > document to spell out that separate mechanism, there is no point for > this spec to relay the label. >=20 > Huaimo: It seems that the alternative option proposed may work. The UA > label with the forwarding information in TLV may be relayed to the > backup egress. RSVP on the backup egress can pass the UA label with the > information to a separated component handling the UA label. In fact, > RSVP just relays the UA label and related information. The processing on > UA label is done by the separated component outside of RSVP. Currently the draft does not specify that forwarding information is relayed= to the backup egress. I don't see how the backup egress know what to do wh= en it receives the packets w/o additional signaling. If you do specify the = mechanisms and procedures in a separate spec on how that can be done, then = it's fine; but until you do so, it should not be mentioned here. Chances ar= e that, once you have a separate mechanism, you may not need the PLT to rel= ay any more. > It's the same amount of information configured, either all on the > ingress PE or separated on all egress PEs. The latter will have much > lower signaling head. >=20 > Huaimo: It seems that there are more configurations. For example, we may > need to configure one-to-one protection or facility protection for > protecting the egresses of a P2MP LSP on every egress of the P2MP LSP if > we limit egress protection configuration to the egresses The draft currently signals pairs of primary/egress from the ingress. That = means configuration is needed for each egress anyway (though it's on ingres= s). If you do the configuration on egress, it's still the same amount, and = you spare the transit routers from having to process the extra signaling. Jeffrey From nobody Mon Oct 6 06:37:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE51A6F39 for ; Mon, 6 Oct 2014 06:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02n7Vl_Nl86L for ; Mon, 6 Oct 2014 06:36:56 -0700 (PDT) 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 834E01A6F24 for ; Mon, 6 Oct 2014 06:36:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNI95250; Mon, 06 Oct 2014 13:36:54 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Oct 2014 14:36:54 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 6 Oct 2014 06:36:50 -0700 From: Huaimo Chen To: "Jeffrey (Zhaohui) Zhang" Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTAKcjt8kAATRhAAABHa+6AAAhfnsAAAfZ/Q Date: Mon, 6 Oct 2014 13:36:49 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445CA82D1@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445CA81A7@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445CA8288@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U6bGz-SEqdaNSIup1GuV_ZhnQ0Y Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:36:58 -0000 Hi Jeffrey, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Monday, October 06, 2014 9:13 AM To: Huaimo Chen Cc: mpls@ietf.org Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protecti= on-01.txt Huaimo, ... snipped ... > My point is that, what's proposed in this draft can't really work,=20 > because while the backup can learn the label relayed by the PLR, it=20 > still does not know what to do with it. Until you have a separate=20 > document to spell out that separate mechanism, there is no point for=20 > this spec to relay the label. >=20 > Huaimo: It seems that the alternative option proposed may work. The UA=20 > label with the forwarding information in TLV may be relayed to the=20 > backup egress. RSVP on the backup egress can pass the UA label with=20 > the information to a separated component handling the UA label. In=20 > fact, RSVP just relays the UA label and related information. The=20 > processing on UA label is done by the separated component outside of RSVP= . Currently the draft does not specify that forwarding information is relayed= to the backup egress. I don't see how the backup egress know what to do wh= en it receives the packets w/o additional signaling. If you do specify the = mechanisms and procedures in a separate spec on how that can be done, then = it's fine; but until you do so, it should not be mentioned here. Chances ar= e that, once you have a separate mechanism, you may not need the PLT to rel= ay any more. Huaimo: It seems that TLVs under the UA label are mentioned in the draft. T= hey may contain the forwarding information, which may be opaque to RSVP. =20 > It's the same amount of information configured, either all on the=20 > ingress PE or separated on all egress PEs. The latter will have much=20 > lower signaling head. >=20 > Huaimo: It seems that there are more configurations. For example, we=20 > may need to configure one-to-one protection or facility protection for=20 > protecting the egresses of a P2MP LSP on every egress of the P2MP LSP=20 > if we limit egress protection configuration to the egresses The draft currently signals pairs of primary/egress from the ingress. That = means configuration is needed for each egress anyway (though it's on ingres= s). If you do the configuration on egress, it's still the same amount, and = you spare the transit routers from having to process the extra signaling. Jeffrey From nobody Mon Oct 6 06:50:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE381A6F8D; Mon, 6 Oct 2014 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Hwrb5a_bPr; Mon, 6 Oct 2014 06:49:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA59F1A6FA3; Mon, 6 Oct 2014 06:49:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006134952.23917.27004.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 06:49:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/58Qky1rqhMv2w6guErBLjy8ihYw Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Definition of Time-to-Live TLV for LSP-Ping Mechanisms' to Proposed Standard (draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:49:57 -0000 The IESG has approved the following document: - 'Definition of Time-to-Live TLV for LSP-Ping Mechanisms' (draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/ Technical Summary LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, as it is currently defined there is no way to verify the connectivity of one or more segments of an MS-PW. This document specifies a method by which any T-PE or S-PE can verify the connectivity to any other T-PE or S-PE. This document defines a new LSP Ping TLV to support this type of connectivity verification. Working Group Summary The WG process was pretty straight-forward. The only thing even remotely close to needing to be mentioned is that the IPR poll took unreasonably long (started March 15 and ended September 18), for a poll that resulted in that "We are not aware of any IPR that relates to this document". Document Quality The Working Group chairs asked for implementation status on the working group mailing list. They received feedback on this poll and know of implementations of the draft. There have also been statements saying that vendors intend to implement this specification . The document has been reviewed through the normal WG process. No MIB Doctor, Media Type or other expert review been performed or requested. Personnel Loa Andersson is the document Shepherd. Adrian Farrel is the responsible AD. From nobody Mon Oct 6 14:55:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8761A86F9; Mon, 6 Oct 2014 14:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9hLVw1Pe1mT; Mon, 6 Oct 2014 14:54:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4E31A86E4; Mon, 6 Oct 2014 14:54:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2955518044F; Mon, 6 Oct 2014 14:54:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141006215413.2955518044F@rfc-editor.org> Date: Mon, 6 Oct 2014 14:54:13 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9uko08j_1ZRtITBluwuTuG3dbRE Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7358 on Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:54:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7358 Title: Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) Author: K. Raza, S. Boutros, L. Martini, N. Leymann Status: Standards Track Stream: IETF Date: October 2014 Mailbox: skraza@cisco.com, sboutros@cisco.com, lmartini@cisco.com, n.leymann@telekom.de Pages: 8 Characters: 15582 Updates: RFC 3212, RFC 4447, RFC 5036, RFC 5918, RFC 6388, RFC 7140 I-D Tag: draft-ietf-mpls-ldp-applicability-label-adv-03.txt URL: https://www.rfc-editor.org/rfc/rfc7358.txt The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Oct 7 09:40:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2AB1ACE4D for ; Tue, 7 Oct 2014 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1N8i3jxGpc0 for ; Tue, 7 Oct 2014 09:40:50 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (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 43B141ACE45 for ; Tue, 7 Oct 2014 09:40:48 -0700 (PDT) Received: from [65.213.193.86] (port=59274 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XbXoZ-0006CH-Md for mpls@ietf.org; Tue, 07 Oct 2014 16:40:43 +0000 From: "Shamjhana" To: References: In-Reply-To: Date: Tue, 7 Oct 2014 12:40:57 -0400 Organization: Isocore Message-ID: <006d01cfe24d$786fb660$694f2320$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01CFE22B.F15F9D00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL+6Cpm7R7g8K3N3T+Hsd7WIuqqXZnGym5Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tP7kymI3d_bv9U6Y4_w8wNCZ1gg Subject: [mpls] Cloud & Data Center, WAN and Virtualization/NFV - SDN/MPLS 2014 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:40:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006E_01CFE22B.F15F9D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Don't miss the opportunity to find out about the future of networking for service providers and large enterprise entities. Only three weeks is left to SDN/MPLS 2014 Conference. Please make sure to register at your earliest opportunity: http://www.isocore.com/sdn-mpls/attendees.php The SDN/MPLS 2014 Conference program is available at: http://www.isocore.com/sdn-mpls/ Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm Please note that the cutoff date for hotel reservations is almost a week away! After this date, the rooms may not be available for consecutive days reservations. http://www.isocore.com/sdn-mpls/hotel.htm ------=_NextPart_000_006E_01CFE22B.F15F9D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Don’t miss = the opportunity to find out about the future of networking for service = providers and large enterprise entities.

 

Only three weeks = is left to SDN/MPLS 2014 Conference. Please make sure to register = at your earliest opportunity:

 <= /span>

http://www.isocore= .com/sdn-mpls/attendees.php

 <= /span>

The SDN/MPLS 2014 = Conference program is available at: http://www.isocore.com/sdn-mpls= /
 
Tutorials (Sunday): http://www.isocore= .com/sdn-mpls/tutorials.htm
Technical sessions (Mon- = Wed): http://ww= w.isocore.com/sdn-mpls/technical_sessions.htm =

 

Please note that = the cutoff date for hotel reservations is almost a week away! After this = date, 
the rooms may not be available for consecutive days = reservations. 

http://www.is=
ocore.com/sdn-mpls/hotel.htm
------=_NextPart_000_006E_01CFE22B.F15F9D00-- From nobody Wed Oct 8 16:20:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959951A86F7; Wed, 8 Oct 2014 16:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlrGka4_M0zd; Wed, 8 Oct 2014 16:20:20 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021861A86F6; Wed, 8 Oct 2014 16:20:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D6A271BC7DB9; Wed, 8 Oct 2014 16:20:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.1.90] (107-194-85-212.lightspeed.nsvltn.sbcglobal.net [107.194.85.212]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DC19B1BC7DBA; Wed, 8 Oct 2014 16:20:18 -0700 (PDT) Message-ID: <5435C6B1.2090908@joelhalpern.com> Date: Wed, 08 Oct 2014 19:20:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "A. Jean Mahoney" , gen-art@ietf.org, "mpls@ietf.org" , Adrian Farrel , IETF discussion list References: <5435A89C.5040409@nostrum.com> In-Reply-To: <5435A89C.5040409@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UsGX8d3LoQtcD6gcEF_mZlS7MN8 Subject: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 23:20:22 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-lsp-ping-relay-reply-04 Relayed Echo Reply mechanism for LSP Ping Reviewer: Joel M. Halpern Review Date: 8-October-2014 IETF LC End Date: 13-October-2014 IESG Telechat date: (if known) Summary: This document is not ready for publication as a Proposed Standard Major issues: There is either a major technical flaw in this document, or there is a need for significantly better explanation. The following is what I was able to understand from reading the document. The procedure in the document calls for a responding or relaying LSR to search the response addresses from the top to the bottom (top being the originator of the request, bottom being visible originators). The responder then sends the reply to the first usable address it can find in the stack. Usable is variously described as "public routable" and as "routable" (in sections 4.2), the converse is described as "unroutable" in section 4.3, while section 4.4 uses "routable". If it means "routable", then this assumes that the private addresses used by one AS will not happen to also be used in another AS (which would make them routable in that domain, directing the reply to completely the wrong place. If it means "publicly routable", this would seem to fail since routers do not know whether routable addresses are public, private, or simply not martian. Minor issues: The procedures assume that border routers will know the correct address to put in the reply stack. It is not bovious that even if the router has a public address, it will get put on. The requirement stated here is that the address put on be the same one used to originate the reply. Which would seem likely to be na internal address in many cases. The procedure for setting k=0 allowing entries to be removed from the stack seems fragile. It relies on routers being able to determine that their address will not be needed for relay by the next hop. Nits/editorial comments: Some of the procedure for originating a reply is described in section 4.2 on Receiving a request, rather than in seciton 4.3 on originating the reply. (Information such as the address to put on the stack, where it goes on the stack, and the handling of the reply packet being too large all belong in 4.3.) From nobody Fri Oct 10 14:41:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398BD1A87ED; Fri, 10 Oct 2014 14:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzspg8RuxvAQ; Fri, 10 Oct 2014 14:41:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C09FB1AD421; Fri, 10 Oct 2014 14:41:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010214125.20395.24760.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 14:41:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r8SIH4SCC4GZ4th6FQNejxKwyNU Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'Requirements for MPLS-TP Shared Mesh Protection' to Informational RFC (draft-ietf-mpls-smp-requirements-09.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:41:34 -0000 The IESG has approved the following document: - 'Requirements for MPLS-TP Shared Mesh Protection' (draft-ietf-mpls-smp-requirements-09.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ Technical Summary This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. Working Group Summary The work on MPLS-TP SMP started with a number of solution drafts, some which were fairly quickly merged, but the WG failed to reach consensus to merge all solutions into a single document. The advice from the working group chairs at this point was to start with a requirement specification. The current document is the result of that process and includes authors from across the solutions drafts. The document has been well discussed in the part of the MPLS WG that is interested in MPLS-TP style protection. The only "out of the ordinary" thing that has happened is that at one point in time some of the authors told me that "the document is ready for wglc". In preparation for the wglc the shepherd started an IPR poll saying: "The authors of draft-ietf-mpls-smp-requirements have told the working group chairs that the draft is ready to be working group last called. Before starting the the wglc we need to do an IPR poll." Resulting in that one author and one contributor notified the shepherd that they did not believe the document was ready to go! Well - this was sorted out and all comments addressed. Document Quality This document is a requirement specification, and as such is not possible to implement. It has been claimed in the discussion that led up to merging solutions documents and requirement that some of the existing MPLS-TP protection implementations fulfil the requirements in this draft. The documented benefitted from an experimental English language review in the MPLS WG. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible AD From nobody Sun Oct 12 11:42:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853151A90D2 for ; Sun, 12 Oct 2014 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_lgU_1L5XMJ for ; Sun, 12 Oct 2014 11:42:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DD01A90D1 for ; Sun, 12 Oct 2014 11:42:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CIfHUW003310; Sun, 12 Oct 2014 19:41:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CIfGGL003301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 19:41:17 +0100 From: "Adrian Farrel" To: References: In-Reply-To: Date: Sun, 12 Oct 2014 19:42:47 +0100 Message-ID: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+6R3RLWxhNzQFXRc+TIr3TW5VCYgsBKQ8w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21018.001 X-TM-AS-Result: No--25.028-10.0-31-10 X-imss-scan-details: No--25.028-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFfsuBEfzzaI3BRIrj8R47F1jpJ5RePtfgYvUUv9u3VjQaT alM8C773lZJXt7iSKn1O6CI7rIh2itcUNjoF7YuV4EprSlQmFqAZskwWqoib3MRzOg7JH/NNZ1H cplu19kgkVIpcYjSb8nbXVKqcjmU6nS8klJkBZJLKl4yJoI+fGyDQvhfLY4eVcf40lLKqPGOItv q4fGcvT8Sn3Mnad3/3Baty8flE2kELAKDlCKcjvZmug812qIbzju+GX08gELDF7duWDXiFEiGZ6 VVOVYeWHdOluruBSKTCh5UkBi9iE7BAQLqGlKivBEfU2vugRF1zd7C7BtJobmCD5SM8YvVFG35v fw/rSs3WLI+pqKamrfkD9NRzvEsitEvy4aJTV6mMVQb49Y23IylayzmQ9QV0InzOyTDR1utlxSY G/Ky6D3zLb55xT9F4b0tmGTVqYTSs/r1De3um7u7KTDtx8Cggf6/Md8Lb2l8cXmBZ3mI5SYEn5M I1F+qXgNWzFHxbnWRdEyzx91EY1ffuqVRl4c9aaUe/i9AephNReWnUUdhI9aawmXRSBSppAmL/Y Mh+r1F8am4s6KmpGtHC9GfLkG2fCJNNiqQVewvBVprK8rvWX9B43gDaHridazG2pCTfDnnyv0JU fwPVyE4g51faggrkbcOkIj3HC+Hbs/05ilnempyebS/i2xjjyeUl7aCTy8jW9R0dU1eYdMlO14E 7OluCcRFRyCX4zCu1acAlnMuyVXXHdWrIeHKUYr99ImIZafihIM2VLoAF126T9TFyBLKGV96QsW 8/xRXDgGiSi1hwZ2f2QdIZiKbcveAuzzZGHSqeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ShF4uYIIPdrYzK5qjoNC9Z90o1Q Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 18:42:56 -0000 Hello, How should I read the silence on this document? Efficient spam filters? Long summer vacations? Lack of interest to continue? Do the MPLS chairs need to appoint a new editor to complete the push? Thanks, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 17 August 2014 19:22 > To: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org' > Cc: mpls@ietf.org > Subject: AD review of draft-ietf-mpls-proxy-lsp-ping > > Hello, > > Thanks for this draft. It completes another piece of the puzzle. > > I have done my normal AD review to respond to the publication request. I > didn't find any show-stoppers, but I have a number of minor issues and > questions. > > As is usual, you should feel free (you are actively encouraged!) to tell > me I am wrong or that a change does not need to be made. I await your > response either through email or with a revised I-D. > > Thanks for the work, > Adrian > > === > > Do you really need the pre-RFC5378 disclaimer? > > --- > > Please check for acronym expansions. I see: > > LSR > > --- > > A little inconsistency in "a LSP" and "an LSP". > > --- > > Section 2 would be enhanced by a figure. Something like... > > R3--R5---egress1 > / > / > ingress---R1---R2--Proxy--R6---egress2 > / \ > / \ > / R7--R8---egress3 > / \ > R4 \ > / R9--egress4 > / \ > / \ > initiator egress5 > > > Together with some explanatory text. > > --- > > In 3.2 you have > An MPLS > proxy ping reply message MAY be sent with a Return Code of , > "Proxy Ping not authorized". > > Should read > > --- > > Looking back at 4379, it is not clear to me how a legacy implementation > listening on port 3503 will react to receiving the new message type for > a proxy message. The text is phrased in terms of the ability to parse an > echo request/reply, and clearly the new message is neither of these. > > > So do you believe this is covered by 4379 section 4.4 > 1. General packet sanity is verified. If the packet is not well- > formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code > set to "Malformed echo request received" and the Subcode to zero. > You could make a case for that, although it is inside a section that > implies that the message type has already been determined and > immediately follows the text... > An LSR X that receives an MPLS echo request then processes it as > follows. > (Also compare with section 4.6). > > Anyway, you should include text on backward compatibility. > 1. The case just described > 2. The case where a targetted proxy doesn't support LSP ping at all. > > --- > > Section 3.2 > > If not, it > sets the Return Code set to "Malformed echo request received" or "TLV > not understood" (as appropriate) > > Delete "set" > Worry about "as appropriate" because it assumes that the reader will > make the right choice where you probably want to be more prescriptive. > > --- > > Section 3.2 > > If > the Reply Mode of the message header is not 1(Do not reply), an MPLS > proxy ping reply message SHOULD be sent as described below. In the > latter case, the misunderstood TLVs (only) are included in an Errored > TLVs TLV. > > "the latter case"? > > --- > > 3.2 > > If not, it sets the Return Code set to > "Malformed echo request received" and the Subcode set to zero. > > Delete "set" > > --- > > 3.2.1 has some lower case "should". Probably worth checking the whole > document for consistent 2119 usage. > > --- > > 3.2.2. > > When the Proxy LSR is a transit or bud node, downstream maps > corresponding to how the packet is transited can not be supplied > unless an ingress interface for the MPLS Echo Request is specified, > since this information is not available and since all valid output > paths are of interest, the Proxy LSR should include DS/DDMAP(s) to > describe the entire set of paths that the packet can be replicated, > like in the case where an LSP ping is initiated at the Proxy LSR. > > > Is that two sentences with "...specified. Since..."? > > > I'm not sure what purpose Section 4.1 serves. I don't like that you > have created a second (normative?) description of the message format. > > Couldn't you just say: > > The format of MPLS LSP Ping messages is defined in [RFC4379]. This > document defines two new message types as follows: > > Type Message > ---- ------- > TBA-1 MPLS proxy ping request > (Pending IANA assignment) > > TBA-2 MPLS proxy ping reply > (Pending IANA assignment) > > --- > > The security considerations say: > > If such a network also carries Internet traffic, or permits IP access > from other administrations, MPLS proxy ping message SHOULD be > discarded at those points. This can be accomplished by filtering on > source address or by filtering all MPLS ping messages on UDP port. > > I think that the mechanisms you describe here would also prohibit normal > LSP ping from transiting the network boundary. This is probably what > you intend, but I note that 4379 does not make this recommendation so > the filtering you suggest here for proxy ping would have an effect on > all LSP ping function and changes the behavior of 4379. > > The way to handle this, I think, is to paint it red. That is, say that > this is an additional filter compared to the advice in 4379, but it is > a damn fine idea. > > Alternatively, you need to step back slightly and call on the border > nodes to look into the message type field. > > --- > > It seems that proxy ping messages would be relatively easy to spoof. > This, combined with the fact that the receipt of a proxy ping causes > the proxy to retain state and to issue echo requests to the network > looks like two DoS vectors for the price of one. > > So, I think you need: > - discussion of authentication for proxy requests > - recommendation to rate limit receipt of proxy requests > - recommendation to discard "duplicate" proxy requests > > --- > > I'm not quite sure about the initiator being allowed to instruct the > proxy about which source port it must use in an echo request. > > (Incidentally, Section 3.2 doesn't restate that this has to happen > although 3.2.4.1 does restate it). > > What happens if the proxy request asks for a reserved port number to be > used? What if the port is already in use by the proxy for something > else? Why does it matter which source port the proxy uses? Why does the > proxy need to be able to control that? Why can't the proxy select its > own source port? > > --- > > Should the point from 3.2.4.2 be echoed in the Security Considerations? > > If any additional labels are > pushed onto the stack, their TTLs are set to 255. This will ensure > that the requestor will not have control over tunnels not relevant to > the FEC being tested. From nobody Sun Oct 12 11:55:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F11A7035 for ; Sun, 12 Oct 2014 11:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znkht2TjfZEX for ; Sun, 12 Oct 2014 11:55:30 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C0D1A7034 for ; Sun, 12 Oct 2014 11:55:29 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so4639237pab.40 for ; Sun, 12 Oct 2014 11:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7v+wdnsZnKxxk04B+pty3ZOwBGykPkfrBdpC2Ll2DKQ=; b=fDr3kwiSGokAwY6Dpm+XXSZkvwULlX0FC1NwDl9tR2EVZubNkrHLIaRz0/7738C3TH MeNVJWXH3CpSC2Cqldnb2drGZe3uYMHFnihXdV9KLQLZk+oW0l+p5leUjhEUn3vgsweX bCKHDtoXcaXjZnIr7l+SsFtl8fmd7cJgTXrnW+5qHxZhq1zL8/h76/pDhEPeFxW1ZhXH OA1Bzt4s2gr0ErWTw0YZj43svl449CsjIedFE1Oucjq0UmaXB/Z2Ipp0hpWmCzFi8cbQ DPm5fxQL750FMmt+aLZASSP07qvFOWuEjIvbIryKAD1rOiPGMHTOsDOYjIqZUR1ZlcMP KO2A== X-Received: by 10.66.66.42 with SMTP id c10mr18901630pat.5.1413140129586; Sun, 12 Oct 2014 11:55:29 -0700 (PDT) Received: from [10.120.180.52] ([166.170.36.192]) by mx.google.com with ESMTPSA id i16sm9101611pdk.66.2014.10.12.11.55.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 11:55:28 -0700 (PDT) References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12A405) From: Sam Aldrin Date: Sun, 12 Oct 2014 11:55:24 -0700 To: "adrian@olddog.co.uk" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/THrO-Ke0C4BPyLrHeW-5YLRw66Y Cc: "" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 18:55:32 -0000 Hi Adrian, We did discuss amongst us and I should be able to get the new revision in co= uple of days. Silence is golden in this case and definitely not the other wa= y :D. Seriously, apologize for not keeping you posted. Sam Sent from my iPhone > On Oct 12, 2014, at 11:42 AM, Adrian Farrel wrote: >=20 > Hello, >=20 > How should I read the silence on this document? >=20 > Efficient spam filters? > Long summer vacations? > Lack of interest to continue? >=20 > Do the MPLS chairs need to appoint a new editor to complete the push? >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: 17 August 2014 19:22 >> To: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org' >> Cc: mpls@ietf.org >> Subject: AD review of draft-ietf-mpls-proxy-lsp-ping >>=20 >> Hello, >>=20 >> Thanks for this draft. It completes another piece of the puzzle. >>=20 >> I have done my normal AD review to respond to the publication request. I >> didn't find any show-stoppers, but I have a number of minor issues and >> questions. >>=20 >> As is usual, you should feel free (you are actively encouraged!) to tell >> me I am wrong or that a change does not need to be made. I await your >> response either through email or with a revised I-D. >>=20 >> Thanks for the work, >> Adrian >>=20 >> =3D=3D=3D >>=20 >> Do you really need the pre-RFC5378 disclaimer? >>=20 >> --- >>=20 >> Please check for acronym expansions. I see: >>=20 >> LSR >>=20 >> --- >>=20 >> A little inconsistency in "a LSP" and "an LSP". >>=20 >> --- >>=20 >> Section 2 would be enhanced by a figure. Something like... >>=20 >> R3--R5---egress1 >> / >> / >> ingress---R1---R2--Proxy--R6---egress2 >> / \ >> / \ >> / R7--R8---egress3 >> / \ >> R4 \ >> / R9--egress4 >> / \ >> / \ >> initiator egress5 >>=20 >>=20 >> Together with some explanatory text. >>=20 >> --- >>=20 >> In 3.2 you have >> An MPLS >> proxy ping reply message MAY be sent with a Return Code of , >> "Proxy Ping not authorized". >>=20 >> Should read >>=20 >> --- >>=20 >> Looking back at 4379, it is not clear to me how a legacy implementation >> listening on port 3503 will react to receiving the new message type for >> a proxy message. The text is phrased in terms of the ability to parse an >> echo request/reply, and clearly the new message is neither of these. >>=20 >>=20 >> So do you believe this is covered by 4379 section 4.4 >> 1. General packet sanity is verified. If the packet is not well- >> formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code >> set to "Malformed echo request received" and the Subcode to zero. >> You could make a case for that, although it is inside a section that >> implies that the message type has already been determined and >> immediately follows the text... >> An LSR X that receives an MPLS echo request then processes it as >> follows. >> (Also compare with section 4.6). >>=20 >> Anyway, you should include text on backward compatibility. >> 1. The case just described >> 2. The case where a targetted proxy doesn't support LSP ping at all. >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> If not, it >> sets the Return Code set to "Malformed echo request received" or "TLV >> not understood" (as appropriate) >>=20 >> Delete "set" >> Worry about "as appropriate" because it assumes that the reader will >> make the right choice where you probably want to be more prescriptive. >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> If >> the Reply Mode of the message header is not 1(Do not reply), an MPLS >> proxy ping reply message SHOULD be sent as described below. In the >> latter case, the misunderstood TLVs (only) are included in an Errored >> TLVs TLV. >>=20 >> "the latter case"? >>=20 >> --- >>=20 >> 3.2 >>=20 >> If not, it sets the Return Code set to >> "Malformed echo request received" and the Subcode set to zero. >>=20 >> Delete "set" >>=20 >> --- >>=20 >> 3.2.1 has some lower case "should". Probably worth checking the whole >> document for consistent 2119 usage. >>=20 >> --- >>=20 >> 3.2.2. >>=20 >> When the Proxy LSR is a transit or bud node, downstream maps >> corresponding to how the packet is transited can not be supplied >> unless an ingress interface for the MPLS Echo Request is specified, >> since this information is not available and since all valid output >> paths are of interest, the Proxy LSR should include DS/DDMAP(s) to >> describe the entire set of paths that the packet can be replicated, >> like in the case where an LSP ping is initiated at the Proxy LSR. >>=20 >>=20 >> Is that two sentences with "...specified. Since..."? >>=20 >>=20 >> I'm not sure what purpose Section 4.1 serves. I don't like that you >> have created a second (normative?) description of the message format. >>=20 >> Couldn't you just say: >>=20 >> The format of MPLS LSP Ping messages is defined in [RFC4379]. This >> document defines two new message types as follows: >>=20 >> Type Message >> ---- ------- >> TBA-1 MPLS proxy ping request >> (Pending IANA assignment) >>=20 >> TBA-2 MPLS proxy ping reply >> (Pending IANA assignment) >>=20 >> --- >>=20 >> The security considerations say: >>=20 >> If such a network also carries Internet traffic, or permits IP access >> from other administrations, MPLS proxy ping message SHOULD be >> discarded at those points. This can be accomplished by filtering on >> source address or by filtering all MPLS ping messages on UDP port. >>=20 >> I think that the mechanisms you describe here would also prohibit normal >> LSP ping from transiting the network boundary. This is probably what >> you intend, but I note that 4379 does not make this recommendation so >> the filtering you suggest here for proxy ping would have an effect on >> all LSP ping function and changes the behavior of 4379. >>=20 >> The way to handle this, I think, is to paint it red. That is, say that >> this is an additional filter compared to the advice in 4379, but it is >> a damn fine idea. >>=20 >> Alternatively, you need to step back slightly and call on the border >> nodes to look into the message type field. >>=20 >> --- >>=20 >> It seems that proxy ping messages would be relatively easy to spoof. >> This, combined with the fact that the receipt of a proxy ping causes >> the proxy to retain state and to issue echo requests to the network >> looks like two DoS vectors for the price of one. >>=20 >> So, I think you need: >> - discussion of authentication for proxy requests >> - recommendation to rate limit receipt of proxy requests >> - recommendation to discard "duplicate" proxy requests >>=20 >> --- >>=20 >> I'm not quite sure about the initiator being allowed to instruct the >> proxy about which source port it must use in an echo request. >>=20 >> (Incidentally, Section 3.2 doesn't restate that this has to happen >> although 3.2.4.1 does restate it). >>=20 >> What happens if the proxy request asks for a reserved port number to be >> used? What if the port is already in use by the proxy for something >> else? Why does it matter which source port the proxy uses? Why does the >> proxy need to be able to control that? Why can't the proxy select its >> own source port? >>=20 >> --- >>=20 >> Should the point from 3.2.4.2 be echoed in the Security Considerations? >>=20 >> If any additional labels are >> pushed onto the stack, their TTLs are set to 255. This will ensure >> that the requestor will not have control over tunnels not relevant to >> the FEC being tested. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Oct 12 12:45:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC861A86F6 for ; Sun, 12 Oct 2014 12:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQZu1IBwezYo for ; Sun, 12 Oct 2014 12:45:51 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E633D1A8702 for ; Sun, 12 Oct 2014 12:45:50 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CJjmkN021755; Sun, 12 Oct 2014 20:45:48 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CJjluW021745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 20:45:48 +0100 From: "Adrian Farrel" To: Date: Sun, 12 Oct 2014 20:45:46 +0100 Message-ID: <042b01cfe655$1e29ac90$5a7d05b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/mVOct9iLm61FtSm+lbnc7JCmJ6Q== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21018.002 X-TM-AS-Result: No--4.774-10.0-31-10 X-imss-scan-details: No--4.774-10.0-31-10 X-TMASE-MatchedRID: Fd1+HyX1T/4DJrf2+hNOhXBRIrj8R47F1Ga2L87qPQLWCKzDYkqjyc8Y e3hjlZCvbdqXh5h5YmbHH37LPHLkkGResrHRY7dKW7gz/Gbgpl59LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQAXnN0DN7HnFm5PfZpRElXI0fsfrEGCE5UxMxrfF3M8av5vwaSzoLrg9/op GED7UntgkCnkA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5D5m3gL_x1a7V0vB6dljS44De74 Cc: mpls@ietf.org Subject: [mpls] Progressing draft-ietf-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 19:45:52 -0000 Hi authors, Sorry, I appear to have fumbled this document transitioning from Publication Requested to AD Review. This is particularly unfortunate as the review I have just done did not yield any issues. I will start IETF last call. Thanks for the work. Adrian From nobody Sun Oct 12 14:53:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C001A87C2 for ; Sun, 12 Oct 2014 14:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2M71ecH0cKH for ; Sun, 12 Oct 2014 14:53:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE831A87AD for ; Sun, 12 Oct 2014 14:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8435; q=dns/txt; s=iport; t=1413150788; x=1414360388; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dd9kjmDjCP9j0d9OXckRy5Z2FAHSefFDiPBkGO1pIws=; b=Q3dpRGTL9jca+c6g5PIMvuqTKtUXn1LJDIFwuN67vk3iy9qQPWPiFeU6 JE0qvI4vwLeGLuTKCrmziJmWbMnm7ZjVLUCvQDvY1fQqYkGwtpi7mqwdG IWavTWeqmXV+88GShpvE/xnf76ljHL7JQ9Mijmc7z6zLthiXqFCVS0x9e c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANP3OlStJV2Z/2dsb2JhbABbgmsjU1MFBMp1DIdLAoEGFgF9hAIBAQEEAQEBNy0HFwQCAQgRBAEBCxQJBycLFAgBCAIEARIIAYg1AQcFwwUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBQ4BoMngR4Fj1+CGoRCiD48gwqDLYlyg36Dd2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,706,1406592000"; d="scan'208";a="362474383" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 12 Oct 2014 21:53:07 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9CLr63f000709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 21:53:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sun, 12 Oct 2014 16:53:06 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Thread-Index: AQHP3N/yKiIOeV/h40KFxRIhCU+K2Zws9IjQ Date: Sun, 12 Oct 2014 21:53:05 +0000 Message-ID: References: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B854360@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B854360@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SXDRxRRpjwnYpBDJ50H1LW37fh4 Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 21:53:09 -0000 Hi Greg, I have only read through half of the document, but please find below my com= ments. =3D=3D Comments =3D=3D (1) In Section 2.1 Typically intermediate nodes should not process or modify any of the OAM configuration TLVs but simply forward them to the end-node. Should above "should not" be upper case "SHOULD NOT"? (2) In Section 2.1.1, slight rephrase. [OLD] For this specification, BFD MUST be run in either one of the two modes: [NEW] For this specification, BFD MUST run in either one of the two modes: (3) In Section 2.2, naming convention The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV of the LSP Echo request/response messages [RFC4379]. Proper name is MPLS echo request/reply as per described in Section 3 of RFC= 4379. (4) In Section 2.2, there's an inconsistency with flags Figure 1 describes 5 flags (CVLDF) while Table 1 describes 6 flags (CVFLDT)= . (5) In Section 2.2, BFD Configuration sub-TLV ... If the I flag is set, the "BFD Authentication sub-TLV" may be included. The "may" should probably be "MAY" above. (6) In Section 2.2.1 Length: indicates the length of the TLV including sub-TLVs but excluding the Type and Length field, in octets. This description seems wrong. I think what you want to say is: Length: indicates the sub-TLV length in octets, excluding the sub- type and Length fields (4). (7) In Section 2.2.1 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic continuity monitoring messages. Perhaps I missed this, but I couldn't find what goes into the PHB bits (3 b= its) and what behaviors are expected. Can you elaborate? (8) In Section 2.2.1 Integrity (I): If set BFD Authentication MUST be enabled. If the BFD Configuration sub-TLV does not include a BFD Authentication sub-TLV the authentication MUST use Keyed SHA1 with an empty pre-shared key (all 0s). What happens when receiver cannot support the requested authentication (inc= luding SHA1 w/ an empty key)? (9) In Section 2.2.1 Encapsulation Capability (G): if set, it shows the capability of encapsulating BFD messages into G-ACh channel. If both the G bit and U bit are set, configuration gives precedence to the G bit. Encapsulation Capability (U): if set, it shows the capability of encapsulating BFD messages into IP/UDP packets. If both the G bit and U bit are set, configuration gives precedence to the G bit. If neither G nor U are set, then is that considered an error case? (10) In Section 2.2.1 The BFD Configuration sub-TLV MUST include the following sub-TLVs in the LSP Echo reply message: - Local Discriminator sub-TLV; Are we missing some error cases? For example, if Bidirectional(B) bit is no= t set, then there is no need for MPLS echo reply to contain "Local Discrimi= nator sub-TLV", no? (11) In Section 2.2.1 Version: identifies the BFD protocol version. If a node does not support a specific BFD version an error must be generated: "OAM Problem/Unsupported OAM Version". I'm assuming that this error code is TBD2. However, in Section 3.2 (IANA Se= ction), the name is slightly different. | TBD2 | MPLS OAM Unsupported Functionality | This document | Additionally, I didn't see any description on where/how other error codes (= TBD3-TBD6) are to be used. I can guess, but perhaps it would be good idea t= o spell them out in relevant sections. (12) In Section 2.2.4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Auth. sub-type (103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Key ID | Reserved (0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of this TLV mandates latter 16 bits to be all zero(0)'s. However,= all authentication TLVs defined in RFC5880 and others (ex: draft-ietf-bfd-= generic-crypto-auth) use the latter 16 bits (ex: Auth Key ID) but it's depe= ndant on the Auth Type. Perhaps this sub-TLV can better be aligned. Somethi= ng like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | BFD Auth. sub-type (103) | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Auth Type | Auth Key ID | Depends on Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =3D=3D Typos =3D=3D (1) Typo in Table of Contents (and Section 2.2.8 title) s/2.2.8. Fault Managemet Signal sub-TLV/2.2.8. Fault Management Signal sub-= TLV/ (2) Typo in Section 1.1 s/MEP - Maintanence Entity Group End Point/MEP - Maintenance Entity Group E= nd Point/ (3) Typo in Section 2.2.4 s/exluding the Type/excluding the Type/ (4) Typo in Section 2.2.5 s/exluding the Type/excluding the Type/ (5) Typo in Section 3.1 s/allocation specied in that/allocation specified in that/ (6) Typo in Section 3.1 s/IANA maintians a registry/IANA maintains a registry/ (7) Typo in Section 3.1 s/IANA maintians a registry/IANA maintains a registry/ Thanks! - Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Tuesday, September 30, 2014 2:54 PM > To: mpls@ietf.org > Subject: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf= - > 07.txt >=20 > Dear All, > minor updates and bringing this work back on track. > Your comments, questions and suggestions always welcome and greatly > appreciated. >=20 > Regards, > Greg >=20 > PS. RSVP-based companion doc been in the IESG queue been prepared for > AD to review. >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, September 30, 2014 11:49 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.= txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Configuration of Pro-Active Operations, Adminis= tration, and > Maintenance (OAM) Functions for MPLS-based Transport Networks using > LSP Ping > Authors : Elisa Bellagamba > Gregory Mirsky > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt > Pages : 21 > Date : 2014-09-30 >=20 > Abstract: > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP-Ping > protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Oct 12 15:22:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0A1A87F0 for ; Sun, 12 Oct 2014 15:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPECLo4n08z2 for ; Sun, 12 Oct 2014 15:22:00 -0700 (PDT) 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 CEFEE1A9118 for ; Sun, 12 Oct 2014 15:21:59 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CMLv8s026940; Sun, 12 Oct 2014 23:21:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9CMLt8B026924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 23:21:55 +0100 From: "Adrian Farrel" To: Date: Sun, 12 Oct 2014 23:21:53 +0100 Message-ID: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/mauYYyhokKc65RvSg1yxokjWp6A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21018.003 X-TM-AS-Result: No--21.613-10.0-31-10 X-imss-scan-details: No--21.613-10.0-31-10 X-TMASE-MatchedRID: aV1vCxxKWhJpZtsObgt0hh/XcAla9LsVGSqdEmeD/nXFJnEpmt9OE97j m29XRUF16yhOH3i4eclr6gcckO+oQNuMXzh4YuvyzFOoeBdH/n1/qILR82ilmU+lUXfTsyfqsL+ 3Kv+qd5S41GGfnpzOrtBU5f4C0eNcWg3ZR7BLPu2rfZ+usyeESJ7wR6/2hZzOQQ1XgvCe7sFJ5z FoTDP8/dDdeGIFH/o8DUaNC0OqAA7l3OZM/4d1DO/1OyZjKYoh6Jj6zYvfFAQdY1owGR6BJzKgl E1ZhS7gzwxlBGkKCXC74em+5bTbSPazQK8vdF3cMN+B8zdlz9FQCOsAlaxN7914Aqe8EzF8UEAl sX5jhz8geOfO3JvG1VgqGdgzgJTB46cGvcyankaPYUYzX2Xjl35Lmbb/xUuah1FqF0jbkZUTBrT 5FMhW3SP5ldXJiVAMmeE2TJmJ5a+s7uBvvd6AmfOHbIp2eXtYlIvcAfYJnEoNht78/JfyBJrR0b rjRxFf4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IcQNZx6em9sIZn5BH_yF54cEaXU Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 22:22:03 -0000 Thank you for writing this document. I think it is an important piece of work and I will send it to IETF last call. Set out below you will find comments from my AD review. I don't think any is blocking or requires specific updates before IETF last call, but I would be glad if you would address them along the way or send me email to discuss them. Thanks for the work, Adrian === The choice of documents to reference for the different control plane sections related to RSVP-TE seemed idiosyncratic to me. For example, the GMPLS section (3.2.6) references RFC 4558, RFC 4990, and RFC 6370 all of which certainly are GMPLS documents, but there is no reference to the base GMPLS protocol documents (RFC 3471 and 3473) nor a back pointer to section 3.2.3. Similarly, the PCE section (3.2.4) [Incidentally, this has a really weird section title! Where did "controller" come from, and why is the section named after a component and not a protocol (PCEP)?] includes references to a number of protocol extensions, but neither 3.2.3 nor 3.2.6 seem to care about the detailed protocol extensions to RSVP-TE. This issue isn't in any way a show-stopper. It just makes me wonder about the precision of the survey wrt RSVP-TE given the amount of detail in some of the other sections. --- Section 3.3.3 has MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and should not be affected by operation on an IPv6-only network. Therefore this is considered out of scope for this document, but is included for completeness. This is odd! Just because MPLS-TP does not require the presence of IP, does not mean it might not be there and used. Indeed, in Section 3.2.6 you reference RFC6370 and use it to state a minor GMPLS deficiency. Yet 6370 is an MPLS-TP document! It is all about how identifiers are generated and used in MPLS-TP networks, and (as the RFC says) in documents where IP is present, the identifiers can be generated using the local IP addresses. Similarly, section 3.4.5 is a little ambitious in its claims of zero dependence on IP since identifiers play an important part in MPLS-TP OAM. This issue doesn't change the end result (although I would probably move the paragraph on 6370 from section 3.2.6 to this section. --- Throughout, you should probably refer to "MIB modules" not "MIBs" --- I am sceptical about section 3.5. Earlier in the document you have mentioned the fact that RFC 4990 explains how to use existing MIB modules with IPv6 addresses, but you don't mention that RFC here. Conversely, you do mention an individual I-D that does not (yet?) have working group support to fix a problem that it is not clear is the problem that needs to be fixed in a way that seems to me to be wrong. --- I never object to my name being spelled correctly :-) From nobody Mon Oct 13 07:49:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3421A0196; Mon, 13 Oct 2014 07:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhyMV9PgUlzk; Mon, 13 Oct 2014 07:49:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B24E71A01B0; Mon, 13 Oct 2014 07:49:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013144916.2451.26839.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 07:49:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jAssqQtHgEVw5DFjb3opqGe2Yig Cc: mpls@ietf.org Subject: [mpls] Last Call: (mLDP In-Band Signaling with Wildcards) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:49:18 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'mLDP In-Band Signaling with Wildcards' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional Multicast" trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP "Any Source Multicast" trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-wildcard-encoding/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-wildcard-encoding/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 13 08:01:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A21A020B; Mon, 13 Oct 2014 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4gQWpyzSqmM; Mon, 13 Oct 2014 08:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFC01A0195; Mon, 13 Oct 2014 08:01:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013150128.18296.93188.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 08:01:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/92NMBDl8Xf_ZR9t3DGrEV2srZLQ Cc: mpls@ietf.org Subject: [mpls] Last Call: (Gap Analysis for Operating IPv6-only MPLS Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:01:30 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Gap Analysis for Operating IPv6-only MPLS Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 13 19:45:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD341A1B24; Mon, 13 Oct 2014 19:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECA040BWtxba; Mon, 13 Oct 2014 19:45:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 816BD1A1B39; Mon, 13 Oct 2014 19:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014024501.29668.53471.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 19:45:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RiG_lUB8qsxWkBLnVuSU58zPDfU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 02:45:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MultiProtocol Label Switching (MPLS) Source Label Authors : Mach(Guoyi) Chen Xiaohu Xu Zhenbin Li Luyuan Fang Greg Mirsky Filename : draft-chen-mpls-source-label-06.txt Pages : 13 Date : 2014-10-13 Abstract: A MultiProtocol Label Switching (MPLS) label was originally defined to identify a Forwarding Equivalence Class (FEC). A packet is assigned to a specific FEC based on its network layer destination address, and optionally Class of Service. It's difficult or even impossible to derive the source identity information from the label. For some applications, source identification is a critical requirement. For example, performance monitoring, where the monitoring node needs to identify where a packet was sent from. This document introduces the concept of Source Identifier (SI) that identifies the ingress Label Switching Router (LSR) of a Label Switched Path (LSP). A SI is unique within a domain that is referred to as Source Identifier Administrative Domain (SIAD). This document also introduces the concept of Source Label (SL) that is carried in the label stack and carries the SI of the ingress LSR of an LSP. Source Label is preceded by a Source Label Indicator (SLI) when included the label stack and is not used for forwarding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-mpls-source-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-mpls-source-label-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-chen-mpls-source-label-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 20:26:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9D1A6F44 for ; Mon, 13 Oct 2014 20:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp5OG3KKBN5v for ; Mon, 13 Oct 2014 20:26:16 -0700 (PDT) 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 635C31A1B39 for ; Mon, 13 Oct 2014 20:26:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP61455; Tue, 14 Oct 2014 03:26:15 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 04:26:14 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 11:26:11 +0800 From: Mach Chen To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Thread-Index: AQHP51jzkcRN1bjWzECcQB2PqSHbXJwu6bwg Date: Tue, 14 Oct 2014 03:26:10 +0000 Message-ID: References: <20141014024501.29668.53471.idtracker@ietfa.amsl.com> In-Reply-To: <20141014024501.29668.53471.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.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Fw_B63LnxfvCYoBtuWaKdmE4PBk Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 03:26:18 -0000 Hi MPLSers,=20 We just uploaded an update that solved the online and offline comments rece= ived so far.=20 In this version, we made the following changes: 1) introducing the concept of Source Identifier that uniquely identifies an= LSR in a domain. The Source Identifier is similar to the Segment Identifie= r (SID); 2) the Source Label (SL) is not required to be unique anymore, no need to s= ignal, not used for forwarding. It is defined to carry the Source Identifie= r. The usage of SL is the same as Entropy Label, where SL carries the Sourc= e Identifier, the EL carries the Entropy. In this way, the Source Label is = completely align with the MPLS architecture and existing usage; 3) some editorial changes; Please read the draft, any comments are welcome! Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, October 14, 2014 10:45 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching Working G= roup of > the IETF. >=20 > Title : MultiProtocol Label Switching (MPLS) Source Lab= el > Authors : Mach(Guoyi) Chen > Xiaohu Xu > Zhenbin Li > Luyuan Fang > Greg Mirsky > Filename : draft-chen-mpls-source-label-06.txt > Pages : 13 > Date : 2014-10-13 >=20 > Abstract: > A MultiProtocol Label Switching (MPLS) label was originally defined > to identify a Forwarding Equivalence Class (FEC). A packet is > assigned to a specific FEC based on its network layer destination > address, and optionally Class of Service. It's difficult or even > impossible to derive the source identity information from the label. > For some applications, source identification is a critical > requirement. For example, performance monitoring, where the > monitoring node needs to identify where a packet was sent from. >=20 > This document introduces the concept of Source Identifier (SI) that > identifies the ingress Label Switching Router (LSR) of a Label > Switched Path (LSP). A SI is unique within a domain that is referred > to as Source Identifier Administrative Domain (SIAD). >=20 > This document also introduces the concept of Source Label (SL) that > is carried in the label stack and carries the SI of the ingress LSR > of an LSP. Source Label is preceded by a Source Label Indicator > (SLI) when included the label stack and is not used for forwarding. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-mpls-source-label/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-mpls-source-label-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-mpls-source-label-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 14 07:34:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CB01A88C3 for ; Tue, 14 Oct 2014 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5LeYFdPzq8F for ; Tue, 14 Oct 2014 07:34:12 -0700 (PDT) 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 AC6EB1A88DC for ; Tue, 14 Oct 2014 07:33:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN72417; Tue, 14 Oct 2014 14:33:48 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 15:33:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 22:33:39 +0800 From: Lizhenbin To: "rgandhi@cisco.com" , "tsaad@cisco.com" , "rsawaya@cisco.com" Thread-Topic: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00 Thread-Index: Ac/nu9fVvRTylE86QIawrulkA7SsOw== Date: Tue, 14 Oct 2014 14:33:39 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rn-pzfxV1P-CkAqUgDeqaT7FSfQ Cc: "mpls@ietf.org" Subject: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:34:15 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rakesh, Tarek & Robert, I just saw you proposed the draft-gandhi-mpls-te-yang-model-00. I wonder if= you are aware of the draft-chen-mpls-te-yang-cfg-00 we proposed on August = 15. From our point of view, we are not experienced enough to remind our MPL= Sers of the new draft to propose possible discussion and collaboration. I c= ompared the two drafts as follows: 1. The possible overlapped part draft-gandhi-mpls-te-yang-model-00 = draft-chen-mpls-te-yang-cfg-00 4.1. Global MPLS-TE Data Model Overview . . . . . . . . . . . . 4 = --> MPLS TE Global Configuration/RSVP-TE Global Configuration 4.2. MPLS-TE Tunnel Interface Data Model Overview . . . . . . . 6 = --> RSVP-TE Tunnel Configuration 4.3. MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . . 7 = --> RSVP-TE Tunnel Configuration 4.4. MPLS-TE Link Data Model Overview . . . . . . . . . . . . . 8 = --> MPLS TE Link Configuration/RSVP-TE Interface Configuration 2. draft-chen-mpls-te-yang-cfg-00 defines following configuration Yang beyo= nd draft-gandhi-mpls-te-yang-model-00. 3.4. Explicit Path Configuration . . . . . . . . . . . . . . . 5 3.5. P2MP TE Leaf List Configuration . . . . . . . . . . . . . 5 3.9. CSPF Configuration . . . . . . . . . . . . . . . . . . . 8 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . . 8 3. draft-chen-mpls-te-yang-cfg-00 has already defined all Yang model for th= ese listed configuration while draft-gandhi-mpls-te-yang-model-00 leaves ma= ny Yang Model definition as spaces. I think maybe you are not aware of the existing draft. If you would like to= cooperate on the MPLS TE Yang Models definition, we are very glad to discu= ss with you to try to unify these Yang models. Best Regards, Zhenbin(Robin) --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rakesh, Tarek & Robert,<= o:p>

I just saw you proposed the dra= ft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the draft-che= n-mpls-te-yang-cfg-00 we proposed on August 15. From our point of view, we = are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and collaborat= ion. I compared the two drafts as follows:

1. The possible overlapped part=

      = draft-gandhi-mpls-te-yang-model-00       = ;            &n= bsp;            = ;      draft-chen-mpls-te-yang-cfg-00

     4.1.&n= bsp; Global MPLS-TE Data Model Overview . . . . . . . . . . . .  4&nbs= p;      -->      =   MPLS TE Global Configuration/RSVP-TE Global Configuration

     4= .2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .  = 6    -->         = RSVP-TE Tunnel Configuration 

     4= .3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .  = 7      -->       =   RSVP-TE Tunnel Configuration 

     4= .4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .  = 8        -->    &= nbsp;    MPLS TE Link Configuration/RSVP-TE Interface Config= uration 

2. draft-chen-mpls-te-yang-cfg-= 00 defines following configuration Yang beyond draft-gandhi-mpls-te-yang-mo= del-00.

     3.4.&n= bsp; Explicit Path Configuration . . . . . . . . . . . . . . .   = 5

     3.5.&n= bsp; P2MP TE Leaf List Configuration . . . . . . . . . . . . .   = 5

     3.9.&n= bsp; CSPF Configuration  . . . . . . . . . . . . . . . . . . . &n= bsp; 8

     3.10. = P2MP TE Tunnel Template Configuration . . . . . . . . . .   8

3. draft-chen-mpls-te-yang-cfg-= 00 has already defined all Yang model for these listed configuration while = draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition as spa= ces.

 

I think maybe you are not aware= of the existing draft. If you would like to cooperate on the MPLS TE Yang = Models definition, we are very glad to discuss with you to try to unify the= se Yang models.

 

 

 

Best Regards,=

Zhenbin(Robin)

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09nkgeml506mbxchi_-- From nobody Tue Oct 14 08:13:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099401A88EC for ; Tue, 14 Oct 2014 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIZIAEz1uEBv for ; Tue, 14 Oct 2014 08:12:55 -0700 (PDT) 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 EE5851A87B0 for ; Tue, 14 Oct 2014 08:12:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKN75898; Tue, 14 Oct 2014 15:12:53 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 16:12:52 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 23:12:46 +0800 From: Lizhenbin To: "mpls@ietf.org" Thread-Topic: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00 Thread-Index: AQHP58FPkCgfkbkZzUCMQUZy/9OVcw== Date: Tue, 14 Oct 2014 15:12:45 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1zE6n-vqHr2qFJKjgeGUc-4tCpI Subject: [mpls] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBs?= =?gb2312?b?cy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFu?= =?gb2312?b?Zy1jZmctMDA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:13:00 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTVBMU2VyLA0KSSB3b3VsZCBsaWtlIHRvIHJlbWluZCB5b3Ugb2YgdGhlIG90aGVyIHR3byBZ YW5nIG1vZGVsIGRyYWZ0czogZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIGFuZCBkcmFm dC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLTAwLiBXZWxjb21lIGNvbW1lbnRzIGFuZCBjb2xsYWJv cmF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGVuYmluKFJvYmluKQ0KDQoNCg0KDQoNCreivP7I yzogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMaXpoZW5iaW4NCrei y83KsbzkOiAyMDE0xOoxMNTCMTTI1SAyMjozNA0KytW8/sjLOiByZ2FuZGhpQGNpc2NvLmNvbTsg dHNhYWRAY2lzY28uY29tOyByc2F3YXlhQGNpc2NvLmNvbQ0Ks63LzTogbXBsc0BpZXRmLm9yZw0K 1vfM4jogW21wbHNdIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAw IGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCg0KSGkgUmFrZXNoLCBUYXJlayAm IFJvYmVydCwNCkkganVzdCBzYXcgeW91IHByb3Bvc2VkIHRoZSBkcmFmdC1nYW5kaGktbXBscy10 ZS15YW5nLW1vZGVsLTAwLiBJIHdvbmRlciBpZiB5b3UgYXJlIGF3YXJlIG9mIHRoZSBkcmFmdC1j aGVuLW1wbHMtdGUteWFuZy1jZmctMDAgd2UgcHJvcG9zZWQgb24gQXVndXN0IDE1LiBGcm9tIG91 ciBwb2ludCBvZiB2aWV3LCB3ZSBhcmUgbm90IGV4cGVyaWVuY2VkIGVub3VnaCB0byByZW1pbmQg b3VyIE1QTFNlcnMgb2YgdGhlIG5ldyBkcmFmdCB0byBwcm9wb3NlIHBvc3NpYmxlIGRpc2N1c3Np b24gYW5kIGNvbGxhYm9yYXRpb24uIEkgY29tcGFyZWQgdGhlIHR3byBkcmFmdHMgYXMgZm9sbG93 czoNCjEuIFRoZSBwb3NzaWJsZSBvdmVybGFwcGVkIHBhcnQNCiAgICAgIGRyYWZ0LWdhbmRoaS1t cGxzLXRlLXlhbmctbW9kZWwtMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMA0KICAgICA0LjEuICBHbG9iYWwgTVBMUy1U RSBEYXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0ICAgICAgIC0t PiAgICAgICAgIE1QTFMgVEUgR2xvYmFsIENvbmZpZ3VyYXRpb24vUlNWUC1URSBHbG9iYWwgQ29u ZmlndXJhdGlvbg0KICAgICA0LjIuICBNUExTLVRFIFR1bm5lbCBJbnRlcmZhY2UgRGF0YSBNb2Rl bCBPdmVydmlldyAuIC4gLiAuIC4gLiAuICA2ICAgIC0tPiAgICAgICAgIFJTVlAtVEUgVHVubmVs IENvbmZpZ3VyYXRpb24NCiAgICAgNC4zLiAgTVBMUy1URSBUdW5uZWwgTFNQIERhdGEgTW9kZWwg T3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAgNyAgICAgIC0tPiAgICAgICAgIFJTVlAtVEUg VHVubmVsIENvbmZpZ3VyYXRpb24NCiAgICAgNC40LiAgTVBMUy1URSBMaW5rIERhdGEgTW9kZWwg T3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOCAgICAgICAgLS0+ICAgICAgICAg TVBMUyBURSBMaW5rIENvbmZpZ3VyYXRpb24vUlNWUC1URSBJbnRlcmZhY2UgQ29uZmlndXJhdGlv bg0KMi4gZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIGRlZmluZXMgZm9sbG93aW5nIGNv bmZpZ3VyYXRpb24gWWFuZyBiZXlvbmQgZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0w MC4NCiAgICAgMy40LiAgRXhwbGljaXQgUGF0aCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAzLjUuICBQMk1QIFRFIExlYWYgTGlzdCBDb25maWd1 cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAgIDMuOS4gIENTUEYgQ29u ZmlndXJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAg ICAgMy4xMC4gUDJNUCBURSBUdW5uZWwgVGVtcGxhdGUgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgOA0KMy4gZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIGhhcyBhbHJl YWR5IGRlZmluZWQgYWxsIFlhbmcgbW9kZWwgZm9yIHRoZXNlIGxpc3RlZCBjb25maWd1cmF0aW9u IHdoaWxlIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgbGVhdmVzIG1hbnkgWWFu ZyBNb2RlbCBkZWZpbml0aW9uIGFzIHNwYWNlcy4NCg0KSSB0aGluayBtYXliZSB5b3UgYXJlIG5v dCBhd2FyZSBvZiB0aGUgZXhpc3RpbmcgZHJhZnQuIElmIHlvdSB3b3VsZCBsaWtlIHRvIGNvb3Bl cmF0ZSBvbiB0aGUgTVBMUyBURSBZYW5nIE1vZGVscyBkZWZpbml0aW9uLCB3ZSBhcmUgdmVyeSBn bGFkIHRvIGRpc2N1c3Mgd2l0aCB5b3UgdG8gdHJ5IHRvIHVuaWZ5IHRoZXNlIFlhbmcgbW9kZWxz Lg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KWmhlbmJpbihSb2JpbikNCg0KDQoNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi MPLS= er,

I would= like to remind you of the other two Yang model drafts: draft-chen-mpls-te-= yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. Welcome comments and colla= boration.

&n= bsp;

Best Re= gards,

Zhenbin= (Robin)

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Lizhenbin
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA10=D4=C2= 14=C8=D5 22:34
=CA=D5=BC=FE=C8=CB: rgandhi@cisco.com; tsaad@cisco.com; rsawaya@cisco.com
=B3=AD=CB=CD: mpls@ietf.org
=D6=F7=CC=E2: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-t= e-yang-cfg-00

 

Hi Rakesh, Tarek & Robert,<= o:p>

I just saw you proposed the dra= ft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the draft-che= n-mpls-te-yang-cfg-00 we proposed on August 15. From our point of view, we = are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and collaborat= ion. I compared the two drafts as follows:

1. The possible overlapped part=

      = draft-gandhi-mpls-te-yang-model-00       = ;            &n= bsp;            = ;      draft-chen-mpls-te-yang-cfg-00

     4.1.&n= bsp; Global MPLS-TE Data Model Overview . . . . . . . . . . . .  4&nbs= p;      -->      =   MPLS TE Global Configuration/RSVP-TE Global Configuration

     4= .2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .  = 6    -->         = RSVP-TE Tunnel Configuration 

     4= .3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .  = 7      -->       =   RSVP-TE Tunnel Configuration 

     4= .4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .  = 8        -->    &= nbsp;    MPLS TE Link Configuration/RSVP-TE Interface Config= uration 

2. draft-chen-mpls-te-yang-cfg-= 00 defines following configuration Yang beyond draft-gandhi-mpls-te-yang-mo= del-00.

     3.4.&n= bsp; Explicit Path Configuration . . . . . . . . . . . . . . .   = 5

     3.5.&n= bsp; P2MP TE Leaf List Configuration . . . . . . . . . . . . .   = 5

     3.9.&n= bsp; CSPF Configuration  . . . . . . . . . . . . . . . . . . . &n= bsp; 8

     3.10. = P2MP TE Tunnel Template Configuration . . . . . . . . . .   8

3. draft-chen-mpls-te-yang-cfg-= 00 has already defined all Yang model for these listed configuration while = draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition as spa= ces.

 

I think maybe you are not aware= of the existing draft. If you would like to cooperate on the MPLS TE Yang = Models definition, we are very glad to discuss with you to try to unify the= se Yang models.

 

 

 

Best Regards,=

Zhenbin(Robin)

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36nkgeml506mbxchi_-- From nobody Tue Oct 14 08:30:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C721A8946; Tue, 14 Oct 2014 08:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caaAc4Ccu7ej; Tue, 14 Oct 2014 08:30:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D901D1A88EE; Tue, 14 Oct 2014 08:30:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: huaimo.chen@huawei.com,rtorvi@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014153037.9964.88932.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 08:30:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IFugraTe5736CrXNYYbX6a__j-8 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:30:39 -0000 Dear Huaimo Chen, Raveendra Torvi: An IPR disclosure that pertains to your Internet-Draft entitled "Extensions to RSVP-TE for LSP Ingress Local Protection" (draft-chen-mpls-p2mp-ingress- protection) was submitted to the IETF Secretariat on 2014-10-14 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2462/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-chen-mpls- p2mp-ingress-protection-11.""); The IETF Secretariat From nobody Tue Oct 14 10:26:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6DD1A90A1 for ; Tue, 14 Oct 2014 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWwH10FNslMr for ; Tue, 14 Oct 2014 10:26:47 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298F71A90A5 for ; Tue, 14 Oct 2014 10:26:37 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 34ED547CFB1F; Tue, 14 Oct 2014 17:26:34 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9EHQZc0008979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 13:26:36 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Oct 2014 13:26:35 -0400 Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.2]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 01:26:32 +0800 From: "S, Somasundaram (Somasundaram)" To: Mach Chen , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Thread-Index: AQHP51j9vgKphPoe/kGQChnaRrxZwJwuaGQAgAEIwnA= Date: Tue, 14 Oct 2014 17:26:30 +0000 Message-ID: References: <20141014024501.29668.53471.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eklpdsilG1-JLRAv8TiSj4FlZxg Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:26:51 -0000 Hi Mach, Need Couple of clarifications here.. 1: Reference to Section 4) use case G-ACH can't be used for customer traffic.. Given that RFC 6374 uses G-ACH= header how can we cite it as an example of "Passive performance measuremen= t protocol" ? I understand that Passive monitoring/measurement uses custome= r traffic for measurement.=20 2: Given that this draft paves way for passive measurement using SL/SLI, C= an you elaborate on the benefits it brings in comparison to other tools lik= e sflow/netflow that are available today...?=20 Regards Somasundaram =09 -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen Sent: Tuesday, October 14, 2014 8:56 AM To: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Hi MPLSers,=20 We just uploaded an update that solved the online and offline comments rece= ived so far.=20 In this version, we made the following changes: 1) introducing the concept of Source Identifier that uniquely identifies an= LSR in a domain. The Source Identifier is similar to the Segment Identifie= r (SID); 2) the Source Label (SL) is not required to be unique anymore, no need to s= ignal, not used for forwarding. It is defined to carry the Source Identifie= r. The usage of SL is the same as Entropy Label, where SL carries the Sourc= e Identifier, the EL carries the Entropy. In this way, the Source Label is = completely align with the MPLS architecture and existing usage; 3) some editorial changes; Please read the draft, any comments are welcome! Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, October 14, 2014 10:45 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching=20 > Working Group of the IETF. >=20 > Title : MultiProtocol Label Switching (MPLS) Source Lab= el > Authors : Mach(Guoyi) Chen > Xiaohu Xu > Zhenbin Li > Luyuan Fang > Greg Mirsky > Filename : draft-chen-mpls-source-label-06.txt > Pages : 13 > Date : 2014-10-13 >=20 > Abstract: > A MultiProtocol Label Switching (MPLS) label was originally defined > to identify a Forwarding Equivalence Class (FEC). A packet is > assigned to a specific FEC based on its network layer destination > address, and optionally Class of Service. It's difficult or even > impossible to derive the source identity information from the label. > For some applications, source identification is a critical > requirement. For example, performance monitoring, where the > monitoring node needs to identify where a packet was sent from. >=20 > This document introduces the concept of Source Identifier (SI) that > identifies the ingress Label Switching Router (LSR) of a Label > Switched Path (LSP). A SI is unique within a domain that is referred > to as Source Identifier Administrative Domain (SIAD). >=20 > This document also introduces the concept of Source Label (SL) that > is carried in the label stack and carries the SI of the ingress LSR > of an LSP. Source Label is preceded by a Source Label Indicator > (SLI) when included the label stack and is not used for forwarding. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-mpls-source-label/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-mpls-source-label-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-mpls-source-label-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 14 11:15:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD761ACCF3 for ; Tue, 14 Oct 2014 11:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqth0wQGINdH for ; Tue, 14 Oct 2014 11:15:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F271ACCEC for ; Tue, 14 Oct 2014 11:15:13 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-ae-543d10eb1410 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id ED.F3.05330.BE01D345; Tue, 14 Oct 2014 14:02:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 14:15:05 -0400 From: Gregory Mirsky To: "S, Somasundaram (Somasundaram)" , "Mach Chen" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Thread-Index: AQHP51jzELIuFZLzP0mJl7Czkf1/L5wvMY4AgADqyQD//8C+IA== Date: Tue, 14 Oct 2014 18:15:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85C9A8@eusaamb103.ericsson.se> References: <20141014024501.29668.53471.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPgu4bAdsQg4t7GC0urBW2uLV0JavF 4X0KDswerc/2snq0HHnL6rFkyU+mAOYoLpuU1JzMstQifbsEroyJb6ezF/ToVuz68om5gfGx chcjJ4eEgInE/psXWSFsMYkL99azdTFycQgJHGWUWPp+FiOEs5xRouPiNSaQKjYBI4kXG3vY QWwRgX5GiQmXokFsYQFnic99O1gg4i4SM47/Z4SwnSQ6zn0G62URUJX4eOQxWC+vgK/EsZ9v 2CEWPGCUONN9AGg1BwenQKzE62VgvYxAF30/tQasl1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4 H9QHShKTlp5jhajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPL KkaO0uLUstx0I4NNjMD4OCbBpruDcc9Ly0OMAhyMSjy8CsI2IUKsiWXFlbmHGKU5WJTEeWfV zgsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBg5N/AED++n399trMv1/J5lyq8WtN779IVU +d96p17+03JWv70ra1U2aJTHLbrYf+xfhseaL40LrS4ccDP7O3nfAff1DTf3q/84ZGz1eP60 Z5aHAld9e3qLK9ns4OYD+fr3Tt+f/Ip1jtOfqF5ukXMbl+2Z6Byl6hWgY/N7bWJCZlJv4IxP Wq+VWIozEg21mIuKEwHQIAEzcAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/y2X36ZMs7kA0JfdTZZ5zLWljs6c Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:15:16 -0000 Hi Somasundaram, thank you for your interest in this work and thoughtful questions. Please f= ind my comments in-line and tagged GIM>>. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of S, Somasundaram (Som= asundaram) Sent: Tuesday, October 14, 2014 10:27 AM To: Mach Chen; mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Hi Mach, Need Couple of clarifications here.. 1: Reference to Section 4) use case G-ACH can't be used for customer traffic.. Given that RFC 6374 uses G-ACH= header how can we cite it as an example of "Passive performance measuremen= t protocol" ? I understand that Passive monitoring/measurement uses custome= r traffic for measurement.=20 GIM>> True, customer traffic not gets encapsulated in G-ACH in most cases (= Residence Time Measurement may be one of exceptions I can recall). Yes, pas= sive measurement do not use test packets to measure performance but uses da= ta traffic. At the same time, OAM packets may be used to collect passive me= asurement statistics, e.g. as ETH-LM. 2: Given that this draft paves way for passive measurement using SL/SLI, C= an you elaborate on the benefits it brings in comparison to other tools lik= e sflow/netflow that are available today...?=20 GIM>> I can refer to draft-chen-ippm-coloring-based-ipfpm-framework that di= scusses marking data packets in non-intrusive manner in order to facilitate= passive measurements. Use of S/SLI is important, IMO, in IP/MPLS networks = in particular. Regards Somasundaram =09 -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen Sent: Tuesday, October 14, 2014 8:56 AM To: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Hi MPLSers,=20 We just uploaded an update that solved the online and offline comments rece= ived so far.=20 In this version, we made the following changes: 1) introducing the concept of Source Identifier that uniquely identifies an= LSR in a domain. The Source Identifier is similar to the Segment Identifie= r (SID); 2) the Source Label (SL) is not required to be unique anymore, no need to s= ignal, not used for forwarding. It is defined to carry the Source Identifie= r. The usage of SL is the same as Entropy Label, where SL carries the Sourc= e Identifier, the EL carries the Entropy. In this way, the Source Label is = completely align with the MPLS architecture and existing usage; 3) some editorial changes; Please read the draft, any comments are welcome! Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, October 14, 2014 10:45 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching=20 > Working Group of the IETF. >=20 > Title : MultiProtocol Label Switching (MPLS) Source Lab= el > Authors : Mach(Guoyi) Chen > Xiaohu Xu > Zhenbin Li > Luyuan Fang > Greg Mirsky > Filename : draft-chen-mpls-source-label-06.txt > Pages : 13 > Date : 2014-10-13 >=20 > Abstract: > A MultiProtocol Label Switching (MPLS) label was originally defined > to identify a Forwarding Equivalence Class (FEC). A packet is > assigned to a specific FEC based on its network layer destination > address, and optionally Class of Service. It's difficult or even > impossible to derive the source identity information from the label. > For some applications, source identification is a critical > requirement. For example, performance monitoring, where the > monitoring node needs to identify where a packet was sent from. >=20 > This document introduces the concept of Source Identifier (SI) that > identifies the ingress Label Switching Router (LSR) of a Label > Switched Path (LSP). A SI is unique within a domain that is referred > to as Source Identifier Administrative Domain (SIAD). >=20 > This document also introduces the concept of Source Label (SL) that > is carried in the label stack and carries the SI of the ingress LSR > of an LSP. Source Label is preceded by a Source Label Indicator > (SLI) when included the label stack and is not used for forwarding. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-mpls-source-label/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-mpls-source-label-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-mpls-source-label-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 14 12:37:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF81ACEEB for ; Tue, 14 Oct 2014 12:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDbq_ZAl-gkl for ; Tue, 14 Oct 2014 12:36:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:701]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFD11ACEFD for ; Tue, 14 Oct 2014 12:36:31 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 19:36:07 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 19:36:07 +0000 From: Ronald Bonica To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5+T1qcCg/R14/UmZV1nG50qHqZwv/D+w Date: Tue, 14 Oct 2014 19:36:07 +0000 Message-ID: <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> In-Reply-To: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(199003)(377424004)(189002)(15975445006)(33646002)(20776003)(77096002)(87936001)(86362001)(2656002)(76482002)(101416001)(76576001)(54356999)(92566001)(95666004)(50986999)(122556002)(74316001)(76176999)(110136001)(31966008)(105586002)(85852003)(64706001)(85306004)(106116001)(40100003)(99286002)(107886001)(4396001)(2351001)(230783001)(108616004)(66066001)(19580395003)(21056001)(19580405001)(80022003)(46102003)(97736003)(120916001)(2501002)(99396003)(15202345003)(106356001)(107046002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wBV3wohphDf58Z0CwSu8PP5MzTg Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 19:37:04 -0000 Rm9sa3MsDQoNClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0K PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDE0IDM6MjggUE0NCj4gVG86IFJvbmFsZCBC b25pY2E7IEVYVCAtIGx1aXMudG9tb3Rha2lAdmVyaXpvbi5jb207IFJhdmVlbmRyYSBUb3J2aTsN Cj4gTWljaGFlbCBDb25uOyBSYXZlZW5kcmEgVG9ydmk7IERhbnRlIFBhY2VsbGE7IFJvbmFsZCBC b25pY2E7IEVYVCAtDQo+IG1hcmsud3lnYW50QHZlcml6b24uY29tOyBFWFQgLSBsdWlzLnRvbW90 YWtpQHZlcml6b24uY29tOyBNaWNoYWVsIENvbm47DQo+IERhbnRlIFBhY2VsbGE7IEVYVCAtIG1h cmsud3lnYW50QHZlcml6b24uY29tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib25pY2EtbXBscy1zZWxmLXBpbmctMDAudHh0DQo+IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmljYSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtYm9uaWNhLW1wbHMt c2VsZi1waW5nDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCUxTUCBTZWxmLVBpbmcNCj4gRG9j dW1lbnQgZGF0ZToJMjAxNC0xMC0xNA0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K PiBQYWdlczoJCTcNCj4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZy0NCj4gMDAudHh0DQo+IFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib25pY2Et bXBscy1zZWxmLXBpbmcvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1ib25pY2EtbXBscy1zZWxmLXBpbmctMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoN Cj4gICAgVGhpcyBtZW1vIGRlc2NyaWJlcyBMU1AgU2VsZi1waW5nLiAgQW4gaW5ncmVzcyBMU1Ig Y2FuIHVzZSBMU1AgU2VsZi0NCj4gICAgcGluZyB0byB2ZXJpZnkgdGhhdCBhbiBMU1AgaXMgcmVh ZHkgdG8gY2FycnkgdHJhZmZpYy4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Oct 14 13:11:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965061ACD77 for ; Tue, 14 Oct 2014 13:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R3aBTpKuK4b for ; Tue, 14 Oct 2014 13:11:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44841ACEAE for ; Tue, 14 Oct 2014 13:11:08 -0700 (PDT) Received: from CO2PR0501MB919.namprd05.prod.outlook.com (10.141.247.22) by CO2PR0501MB917.namprd05.prod.outlook.com (10.141.247.20) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 20:11:06 +0000 Received: from CO2PR0501MB919.namprd05.prod.outlook.com ([10.141.247.22]) by CO2PR0501MB919.namprd05.prod.outlook.com ([10.141.247.22]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 20:11:07 +0000 From: Markus Jork To: Loa Andersson , Gregory Mirsky , "Kamran Raza (skraza)" , "vishwas.manral@hp.com" , Sam Aldrin , "Curtis Villamizar" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt Thread-Index: Ac/n6XkWmNN4+Q+6TC6FsQ/gAK0SyQ== Date: Tue, 14 Oct 2014 20:11:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB917; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(54356999)(85306004)(76482002)(33646002)(87936001)(108616004)(85852003)(120916001)(50986999)(230783001)(97736003)(122556002)(92566001)(86362001)(4396001)(2201001)(101416001)(2501002)(74316001)(2656002)(106356001)(66066001)(95666004)(40100003)(76576001)(99286002)(21056001)(31966008)(229853001)(20776003)(46102003)(64706001)(107046002)(99396003)(105586002)(80022003)(921003)(1121002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB917; H:CO2PR0501MB919.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/95iOm0fUcSCq_Wludmx0u7mpUH8 Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:11:22 -0000 I have been asked to review draft-kini-mpls-spring-entropy-label-01 as one = of the MPLS-RT members. The document is coherent and makes a good argument for why the entropy labe= l mechanism is useful and needed for SPRING. There are likely to be network= s for which this would be beneficial. Unfortunately, the nature of the problem and existing hardware compatibilit= y constraints don't lend themselves to very elegant solutions. The proposed= solution in section 4 pretty much screams "compromise". But the following = sections do a good job of describing the design constraints and why other s= olutions were rejected. It will be useful to keep this content in the docum= ent somewhere even in its final version. I believe the document is ready for WG adoption. Though I think there are a= couple of small problems with the examples in section 5 that should be cor= rected: 1. Up to section 5.1, the example label stack includes a label S-SvcS2 for = the service at S2. But in all the following sections, this label is dropped= from the examples. I think it's best to leave this out in all of the examp= les for brevity. 2. In section 5.3, the first example is given as . That should be 3. In section 5.4, the example is given as: "For the same Figure 1 above, if LSR P1 needs to have the EL within a depth of 4, then the source LSR S encoded label stack would be where all the ELs would typically have the same value." That is leaving out the first hop SP1 from the stack (which means the EL ha= s to move up the stack). Also, only one EL is present. So why call it EL2? -Markus From nobody Tue Oct 14 13:59:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365B1A90F8 for ; Tue, 14 Oct 2014 13:59:33 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzDFuSkKHS7b for ; Tue, 14 Oct 2014 13:59:32 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6731A0009 for ; Tue, 14 Oct 2014 13:59:31 -0700 (PDT) Received: from [216.82.253.67:7456] by server-9.bemta-7.messagelabs.com id 56/D9-03013-3BE8D345; Tue, 14 Oct 2014 20:59:31 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-6.tower-158.messagelabs.com!1413320371!12706996!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29470 invoked from network); 14 Oct 2014 20:59:31 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-6.tower-158.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Oct 2014 20:59:31 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id 00E5C2B30C; Tue, 14 Oct 2014 20:59:31 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Oct 2014 14:59:30 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 16:59:29 -0400 From: "Osborne, Eric" To: Ronald Bonica , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5+T1qcCg/R14/UmZV1nG50qHqZwv/D+wgAAVluA= Date: Tue, 14 Oct 2014 20:59:27 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF99EA5@USIDCWVEMBX08.corp.global.level3.com> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wWRjfceGB2EbnBSMTyL_WTTdbOg Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:59:33 -0000 This basically says "send an echo reply to yourself over your own LSP". Ri= ght? All the procedures in section 2 (the first 8 bullet points) seem like= implementation details. Why do you mandate the CS6 DSCP? Surely there's room for setting whatever = else I want? How likely is it that the egress LSR will receive a packet with its own sou= rce and drop it due to RPF or anti-spoofing? Strict RPF seems like it woul= d drop the packet, as does feasible; not sure about loose. If nothing else= , any changes to RPF needed to allow this should be covered in the security= section. eric -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 3:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi;=20 > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT -=20 > mark.wygant@verizon.com; EXT - luis.tomotaki@verizon.com; Michael=20 > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for=20 > draft-bonica-mpls-self-ping-00.txt >=20 >=20 > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF=20 > repository. >=20 > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 >=20 >=20 > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 14 14:20:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF8E1ACD19; Tue, 14 Oct 2014 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcRDOwBa1DE8; Tue, 14 Oct 2014 14:20:43 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684DE1A005E; Tue, 14 Oct 2014 14:20:43 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-d7-543d3c624e53 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CE.AF.05330.36C3D345; Tue, 14 Oct 2014 17:08:19 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:20:08 -0400 From: Gregory Mirsky To: Ronald Bonica , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5+T1qcCg/R14/UmZV1nG50qHqZwv/D+wgAAbKtA= Date: Tue, 14 Oct 2014 21:20:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLonSjfZxjbE4MB3JYsL2++zWdxaupLV 4sB3B4vPf7YxOrB4LFnyk8njetNVdo8vlz+zBTBHcdmkpOZklqUW6dslcGU8PdrBVtDrUnFy 4zOmBsZu6y5GTg4JAROJW9OXsEDYYhIX7q1n62Lk4hASOMoocbl3IQuEs5xR4tzVzWBVbAJG Ei829rCD2CICHhJ965rAOpgFJjFKnN+8jhUkISwQKXHz40c2iKIoicmLjkDZVhIXzr0Da2YR UJU4+OUKWD2vgK9E/5kfUKt7GSW+tvcxgSQ4BcIknn17AlbECHTf91NrwOLMAuISt57MZ4K4 W0BiyZ7zzBC2qMTLx/9YIWxFiX3909kh6vMlTjx7ywSxTFDi5MwnLBMYRWchGTULSdksJGUQ cR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66kcEmRmDcHZNg093BuOel5SFG AQ5GJR5eBWGbECHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YFyjo/XT4+10p2PHeJOajZKlOYxPZlzXevR4fqRI9sXXnbLK9mcidofU/zbZLXbjVnz0giXT Zkbldj0UmybQVPnZxszze0jqzQO34tbXSy/8ek3PYtVaEcN7Ugu/1SSfObCVpaz+6FVOa4fQ XUsFZF8lzdByX8F6QtTv8cO6Kv+aNpbT1/I371JiKc5INNRiLipOBACtsVP8nAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vi6c7LeWhA-GZlHLQ4-Pqq4jfSA Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:20:46 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ron,
thank you for bringing this work to discussion. I agree that lightweig= ht mechanism to verify LSP availability is useful and valuable tool in OAM = toolbox. Possible use of LSP Ping already been discussed in the document an= d thus I would like to reference another mechanism that authors of the Seamless Bid= irectional Forwarding Detection (BFD) Use Case document beli= eve addresses the problem stated in the Self-ping draft. Perhaps you can review and share your comments on S-BF= D Use Case document and Section 3.1 Unidirectional Forwarding Path Validati= on in particular.
 
Greatly appreciate your feedback.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt
 
Folks,
 
Please review and comment
 
           &nbs= p;             = Ron
 
 
> -----Original Message-----
> Sent: Tuesday, October 14, 2014 3:28 PM
> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi;
> Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT = -
> Conn; Dante Pacella; EXT - mark.wygant@verizon.com
> Subject: New Version Notification for
> draft-bonica-mpls-self-ping-00.txt
>
>
> A new version of I-D, draft-bonica-mpls-self-ping-00.txt
> has been successfully submitted by Ron Bonica and posted to the I= ETF
> repository.
>
> Name:         draft-bonic= a-mpls-self-ping
> Revision:     00
> Title:          = ;      LSP Self-Ping
> Document date:        2014-10-= 14
> Group:          = ;      Individual Submission
> Pages:          = ;      7
> 00.txt
>
>
> Abstract:
>    This memo describes LSP Self-ping.  An ing= ress LSR can use LSP Self-
>    ping to verify that an LSP is ready to carry tr= affic.
>
>
>
>
> Please note that it may take a couple of minutes from the time of=
> submission until the htmlized version and diff are available at t= ools.ietf.org.
>
> The IETF Secretariat
 
_______________________________________________
mpls mailing list
 
 --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_-- From nobody Tue Oct 14 14:32:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE481ACD2D; Tue, 14 Oct 2014 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.286 X-Spam-Level: X-Spam-Status: No, score=-115.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9MZpWAICcX1; Tue, 14 Oct 2014 14:32:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6981ACD19; Tue, 14 Oct 2014 14:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28622; q=dns/txt; s=iport; t=1413322372; x=1414531972; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eBnM3ecwP46UESUIqFa6z8e6bKidW39K5wmJgZBWBuY=; b=e9rSgyWKAgNjXG32w+mJXLrF4x4lPiavEBQbayPM3/0sbCKY7KlK6EjJ mXzyOoYr6ZmLSAsxnuLWAWGzZMN3NFjeRnscQA1y+M5TTIoQh8elLP0yb 85vfL0QdC3QhOWQ7ybFLswt3ga72UyFXrxDalJAKtqVLvP6fU4OE/RSUR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAC2VPVStJV2d/2dsb2JhbABbgkgjI1NYBMpJgWMBCYdNAoEXFgF9hAIBAQEDAQEBASpBCQIFBwQCAQgRBAEBCxYBBgcnCxQIAQgCBAENBQgBiCEDCQgBDMcpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF44TggEtBAYBBgODJIEeBY9fghqEQog+PIMKjR+DfoIGGIFZbIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208,217";a="363293779" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Oct 2014 21:32:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9ELWoaw022575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 21:32:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 16:32:50 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Ronald Bonica , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/S+Gv5QLnD300KRpmKZHU+QY5wwGbuw Date: Tue, 14 Oct 2014 21:32:48 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3BdLVAIdlw7-d_K-ojXnOagF3EI Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:32:56 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, I agree with Greg that a light weight mechanism to verify LSP availability = is useful, and S-BFD may be a good fit for your needs. One comment in draft-bonica-mpls-self-ping-00. [snip from draft-bonica-mpls-self-ping-00, Section 2] If the protocol messages used to establish the LSP were delivered over IPv4 [RFC0791] the probe message is an ICMPv4 [RFC0792] Echo Reply. If the protocol messages used to establish the LSP were delivered over IPv6 [RFC2460] the probe message is an ICMPv6 [RFC4443] Echo Reply. In either case, the contents of the ICMP message are as follows: o Source Address equals the address of the egress LSR o Destination Address equals the address of the ingress LSR [snip] Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,=

 <= /p>

I agree with Greg that a = light weight mechanism to verify LSP availability is useful, and S-BFD may = be a good fit for your needs.

 <= /p>

One comment in draft-boni= ca-mpls-self-ping-00.

 <= /p>

[snip from draft-bonica-m= pls-self-ping-00, Section 2]

   If the proto= col messages used to establish the LSP were delivered

   over IPv4 [R= FC0791] the probe message is an ICMPv4 [RFC0792] Echo

   Reply. = If the protocol messages used to establish the LSP were<= /p>

   delivered ov= er IPv6 [RFC2460] the probe message is an ICMPv6

   [RFC4443] Ec= ho Reply.  In either case, the contents of the ICMP<= /p>

   message are = as follows:

 <= /p>

   o  Sour= ce Address equals the address of the egress LSR

 <= /p>

   o  Dest= ination Address equals the address of the ingress LSR

[snip]<= /p>

 <= /p>

Destination address havin= g a valid IP address (i.e. address of ingress LSR) means that this probe wi= ll come back to the ingress LSR when:

- transit LSR false pops = and forwards (due to incorrect label programming)

- transit LSR false forwa= rds elsewhere and happens to terminates at some other network nodes via dif= ferent LSP (due to incorrect label programming)

 <= /p>

Certain packets over such= LSP (ex: VPN) will likely get dropped even though proposed probe reports s= uccess, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.

 <= /p>

When applied to the LDP i= ndependent mode, proposed probe will have the same “false positive= 221; issue with “end-to-end LSP not ready” case as well.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

> -----Original Message-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_-- From nobody Tue Oct 14 18:54:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242911A011F for ; Tue, 14 Oct 2014 18:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucaf72aPVOyM for ; Tue, 14 Oct 2014 18:54:09 -0700 (PDT) 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 C2D231A0119 for ; Tue, 14 Oct 2014 18:54:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ64244; Wed, 15 Oct 2014 01:54:06 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 02:54:04 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 09:53:59 +0800 From: Mach Chen To: "S, Somasundaram (Somasundaram)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt Thread-Index: AQHP51jzkcRN1bjWzECcQB2PqSHbXJwu6bwggABpcQCAAQvhoA== Date: Wed, 15 Oct 2014 01:53:58 +0000 Message-ID: References: <20141014024501.29668.53471.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/J6PHRN5ZqfddVeELQuwibiiWvx4 Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 01:54:12 -0000 Hi Somasundaram, Thanks for your thoughtful questions! Please see my reply inline... > -----Original Message----- > From: S, Somasundaram (Somasundaram) > [mailto:somasundaram.s@alcatel-lucent.com] > Sent: Wednesday, October 15, 2014 1:27 AM > To: Mach Chen; mpls@ietf.org > Subject: RE: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt >=20 > Hi Mach, > Need Couple of clarifications here.. >=20 > 1: Reference to Section 4) use case > G-ACH can't be used for customer traffic.. Given that RFC 6374 uses > G-ACH header how can we cite it as an example of "Passive performance > measurement protocol" ? I understand that Passive monitoring/measurement > uses customer traffic for measurement. In RFC6374, when do direct (passive) measurement, the GACh header is mainly= used for delimitating a flow (user traffic) to consecutive blocks and carr= ying the transmitted counters at the ingress. Then the egress can based on = the blocks to count. With the its own counted number and the counters carri= ed in the GACh header, the egress can perform the passive lost calculation. =20 >=20 > 2: Given that this draft paves way for passive measurement using SL/SLI, > Can you elaborate on the benefits it brings in comparison to other tools = like > sflow/netflow that are available today...? I am not very familiar with sflow/netflow, if I am wrong, please correct me= . In my understanding, sflow/netflow is used to collect IP traffic statisti= cs on all interfaces where netflow is enabled, and later export those stati= stics as netflow records toward at least one netflow collector - typically = a server that does the actual traffic analysis. So, normally, sflow/netflow= is not used for performance measurement. Even this, sflow/netflow can bene= fit from SL/SLI when collect and analyze MPLS traffic flows, because it als= o needs the source information to facilitate analysis.=20 Best regards, Mach >=20 > Regards > Somasundaram >=20 >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Tuesday, October 14, 2014 8:56 AM > To: mpls@ietf.org > Subject: Re: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt >=20 > Hi MPLSers, >=20 > We just uploaded an update that solved the online and offline comments > received so far. >=20 > In this version, we made the following changes: >=20 > 1) introducing the concept of Source Identifier that uniquely identifies = an LSR in a > domain. The Source Identifier is similar to the Segment Identifier (SID); >=20 > 2) the Source Label (SL) is not required to be unique anymore, no need to= signal, > not used for forwarding. It is defined to carry the Source Identifier. Th= e usage of > SL is the same as Entropy Label, where SL carries the Source Identifier, = the EL > carries the Entropy. In this way, the Source Label is completely align wi= th the > MPLS architecture and existing usage; >=20 > 3) some editorial changes; >=20 > Please read the draft, any comments are welcome! >=20 > Thanks, > Mach >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Tuesday, October 14, 2014 10:45 AM > > To: i-d-announce@ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] I-D Action: draft-chen-mpls-source-label-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Multiprotocol Label Switching > > Working Group of the IETF. > > > > Title : MultiProtocol Label Switching (MPLS) Source L= abel > > Authors : Mach(Guoyi) Chen > > Xiaohu Xu > > Zhenbin Li > > Luyuan Fang > > Greg Mirsky > > Filename : draft-chen-mpls-source-label-06.txt > > Pages : 13 > > Date : 2014-10-13 > > > > Abstract: > > A MultiProtocol Label Switching (MPLS) label was originally defined > > to identify a Forwarding Equivalence Class (FEC). A packet is > > assigned to a specific FEC based on its network layer destination > > address, and optionally Class of Service. It's difficult or even > > impossible to derive the source identity information from the label. > > For some applications, source identification is a critical > > requirement. For example, performance monitoring, where the > > monitoring node needs to identify where a packet was sent from. > > > > This document introduces the concept of Source Identifier (SI) that > > identifies the ingress Label Switching Router (LSR) of a Label > > Switched Path (LSP). A SI is unique within a domain that is referre= d > > to as Source Identifier Administrative Domain (SIAD). > > > > This document also introduces the concept of Source Label (SL) that > > is carried in the label stack and carries the SI of the ingress LSR > > of an LSP. Source Label is preceded by a Source Label Indicator > > (SLI) when included the label stack and is not used for forwarding. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-chen-mpls-source-label/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-chen-mpls-source-label-06 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-mpls-source-label-06 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 14 23:36:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4E21A0382 for ; Tue, 14 Oct 2014 23:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN3yj1LEs3A3 for ; Tue, 14 Oct 2014 23:36:47 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3601A0383 for ; Tue, 14 Oct 2014 23:36:46 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so697373pdi.19 for ; Tue, 14 Oct 2014 23:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fqNhSi6jO99s1bcqLKOWWFqcKnb65JF6FEwAjJqXFrI=; b=KCNrvdjrbJUKl4qFJNKpApjGZMoM0lMFPj7rDmquo8pGWxgg8dTV0VZ4SfRkSTEs4A sS+d6xyML8EFX1x2xC/RB21mRWcwkrqI2uPZLTVFU7zVmHaZ1IcbZ6dxF19MGjqkFVpg FPAp8ltbEKK3vSexX5pV3JqDuLKyGnTyQG/a0boJ0JEjzdxR7wTvvhiDDsEw9KdlR4Vw yVdc7iBVdf/t2Ikucy2IqWN7scxuQ1Q1WzIvZy9v7a9Nt9TzZewbLxXevyLqAKf2MGX2 nU4qHtf4xB24gqSOmA7HWjZJkHGvmmsvf9kopiVVIhIC9hUrUkhdXNk96UAXReL4u6Dh UqZA== X-Received: by 10.68.135.198 with SMTP id pu6mr10342872pbb.106.1413355006511; Tue, 14 Oct 2014 23:36:46 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id n3sm16090948pda.7.2014.10.14.23.36.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 23:36:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> Date: Tue, 14 Oct 2014 23:36:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FTEomUN7q8xlN0hRvvUhgxaAj8g Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org, mpls Subject: Re: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 06:36:49 -0000 Hi Adrian, Have incorporated most of the changes related to your comments. However, have couple of comments, which we need answers to, in order to = make necessary changes. See inline for my responses/questions. Thanks -sam On Oct 12, 2014, at 11:42 AM, Adrian Farrel wrote: > Hello, >=20 > How should I read the silence on this document? >=20 > Efficient spam filters? > Long summer vacations? > Lack of interest to continue? >=20 > Do the MPLS chairs need to appoint a new editor to complete the push? >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: 17 August 2014 19:22 >> To: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org' >> Cc: mpls@ietf.org >> Subject: AD review of draft-ietf-mpls-proxy-lsp-ping >>=20 >> Hello, >>=20 >> Thanks for this draft. It completes another piece of the puzzle. >>=20 >> I have done my normal AD review to respond to the publication = request. I >> didn't find any show-stoppers, but I have a number of minor issues = and >> questions. >>=20 >> As is usual, you should feel free (you are actively encouraged!) to = tell >> me I am wrong or that a change does not need to be made. I await your >> response either through email or with a revised I-D. >>=20 >> Thanks for the work, >> Adrian >>=20 >> =3D=3D=3D >>=20 >> Do you really need the pre-RFC5378 disclaimer? As this updates or add to RFC4379, we need that. Would you agree? >>=20 >> --- >>=20 >> Please check for acronym expansions. I see: >>=20 >> LSR %sam - Added terminology section. >>=20 >> --- >>=20 >> A little inconsistency in "a LSP" and "an LSP=94. %sam - done. >>=20 >> --- >>=20 >> Section 2 would be enhanced by a figure. Something like... >>=20 >> R3--R5---egress1 >> / >> / >> ingress---R1---R2--Proxy--R6---egress2 >> / \ >> / \ >> / R7--R8---egress3 >> / \ >> R4 \ >> / R9--egress4 >> / \ >> / \ >> initiator egress5 >>=20 >>=20 >> Together with some explanatory text. %sam - We deliberated on this and feel it will add more confusion than = helping the reader to understand. Also, it may necessitates lot of = changes to the text to reflect the use of R1, R2 etc. Would you be ok if we don=92t add this ASCII art and keep it simple? >>=20 >> --- >>=20 >> In 3.2 you have >> An MPLS >> proxy ping reply message MAY be sent with a Return Code of , >> "Proxy Ping not authorized". >>=20 >> Should read %sam - Done. Updated in other places as well. >>=20 >> --- >>=20 >> Looking back at 4379, it is not clear to me how a legacy = implementation >> listening on port 3503 will react to receiving the new message type = for >> a proxy message. The text is phrased in terms of the ability to parse = an >> echo request/reply, and clearly the new message is neither of these. >>=20 >>=20 >> So do you believe this is covered by 4379 section 4.4 >> 1. General packet sanity is verified. If the packet is not well- >> formed, LSR X SHOULD send an MPLS Echo Reply with the Return = Code >> set to "Malformed echo request received" and the Subcode to = zero. >> You could make a case for that, although it is inside a section that >> implies that the message type has already been determined and >> immediately follows the text... >> An LSR X that receives an MPLS echo request then processes it as >> follows. >> (Also compare with section 4.6). >>=20 >> Anyway, you should include text on backward compatibility. >> 1. The case just described >> 2. The case where a targetted proxy doesn't support LSP ping at all. >>=20 %sam - Added few sub-sections to be more clear and also to define = backward compatibility. >> --- >>=20 >> Section 3.2 >>=20 >> If not, it >> sets the Return Code set to "Malformed echo request received" or = "TLV >> not understood" (as appropriate) >>=20 >> Delete "set" >> Worry about "as appropriate" because it assumes that the reader will >> make the right choice where you probably want to be more = prescriptive. >>=20 %sam - done. >> --- >>=20 >> Section 3.2 >>=20 >> If >> the Reply Mode of the message header is not 1(Do not reply), an = MPLS >> proxy ping reply message SHOULD be sent as described below. In the >> latter case, the misunderstood TLVs (only) are included in an = Errored >> TLVs TLV. >>=20 >> "the latter case=94? %sam - reworded the text to remove the confusion. >>=20 >> --- >>=20 >> 3.2 >>=20 >> If not, it sets the Return Code set to >> "Malformed echo request received" and the Subcode set to zero. >>=20 >> Delete =93set" >>=20 %sam - done >> --- >>=20 >> 3.2.1 has some lower case "should". Probably worth checking the whole >> document for consistent 2119 usage. >>=20 %sam - Changed in all the places. >> --- >>=20 >> 3.2.2. >>=20 >> When the Proxy LSR is a transit or bud node, downstream maps >> corresponding to how the packet is transited can not be supplied >> unless an ingress interface for the MPLS Echo Request is specified, >> since this information is not available and since all valid output >> paths are of interest, the Proxy LSR should include DS/DDMAP(s) to >> describe the entire set of paths that the packet can be replicated, >> like in the case where an LSP ping is initiated at the Proxy LSR. >>=20 >>=20 >> Is that two sentences with "...specified. Since=85"? %sam - done. >>=20 >>=20 >> I'm not sure what purpose Section 4.1 serves. I don't like that you >> have created a second (normative?) description of the message format. >>=20 >> Couldn't you just say: >>=20 >> The format of MPLS LSP Ping messages is defined in [RFC4379]. This >> document defines two new message types as follows: >>=20 >> Type Message >> ---- ------- >> TBA-1 MPLS proxy ping request >> (Pending IANA assignment) >>=20 >> TBA-2 MPLS proxy ping reply >> (Pending IANA assignment) >>=20 %sam - Kept only relevant text and removed the RFC4379 repeat. >> --- >>=20 >> The security considerations say: >>=20 >> If such a network also carries Internet traffic, or permits IP = access >> from other administrations, MPLS proxy ping message SHOULD be >> discarded at those points. This can be accomplished by filtering = on >> source address or by filtering all MPLS ping messages on UDP port. >>=20 >> I think that the mechanisms you describe here would also prohibit = normal >> LSP ping from transiting the network boundary. This is probably what >> you intend, but I note that 4379 does not make this recommendation so >> the filtering you suggest here for proxy ping would have an effect on >> all LSP ping function and changes the behavior of 4379. >>=20 >> The way to handle this, I think, is to paint it red. That is, say = that >> this is an additional filter compared to the advice in 4379, but it = is >> a damn fine idea. >>=20 >> Alternatively, you need to step back slightly and call on the border >> nodes to look into the message type field. %sam - Adding the text. >>=20 >> --- >>=20 >> It seems that proxy ping messages would be relatively easy to spoof. >> This, combined with the fact that the receipt of a proxy ping causes >> the proxy to retain state and to issue echo requests to the network >> looks like two DoS vectors for the price of one. >>=20 >> So, I think you need: >> - discussion of authentication for proxy requests >> - recommendation to rate limit receipt of proxy requests >> - recommendation to discard "duplicate" proxy requests >>=20 %sam - Proxy do NOT maintain any state. Hence, not sure why the above = apply to proxy and not regular Echo requests. When proxy echo request = is, it (proxy LSR) merely issues a request and no state is maintained on = it. For ex: it has no way to discard duplicate requests, because is doesn=92t = maintain any state for the requests. >> --- >>=20 >> I'm not quite sure about the initiator being allowed to instruct the >> proxy about which source port it must use in an echo request. >>=20 >> (Incidentally, Section 3.2 doesn't restate that this has to happen >> although 3.2.4.1 does restate it). >>=20 >> What happens if the proxy request asks for a reserved port number to = be >> used? What if the port is already in use by the proxy for something >> else? Why does it matter which source port the proxy uses? Why does = the >> proxy need to be able to control that? Why can't the proxy select its >> own source port? %sam - I think there is some confusion here. The source port number is = not to request Proxy to use, rather to issue a request, so that the = replying router could send the reply back to the initiator at the right = port. proxy echo request does not specify what port Proxy has to use. >>=20 >> --- >>=20 >> Should the point from 3.2.4.2 be echoed in the Security = Considerations? >>=20 >> If any additional labels are >> pushed onto the stack, their TTLs are set to 255. This will ensure >> that the requestor will not have control over tunnels not relevant = to >> the FEC being tested. %sam - will add the text. thanks -sam >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 15 08:36:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D041A87ED; Wed, 15 Oct 2014 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mHZokuj7Una; Wed, 15 Oct 2014 08:36:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C615A1A8838; Wed, 15 Oct 2014 08:36:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 86D11C22C; Wed, 15 Oct 2014 11:36:54 -0400 (EDT) Date: Wed, 15 Oct 2014 11:36:54 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Message-ID: <20141015153654.GE18720@pfrc> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YgSLiztIPEjeJlv5SXNkN8n3Pl4 Cc: Ronald Bonica , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:36:55 -0000 On Tue, Oct 14, 2014 at 09:32:48PM +0000, Nobo Akiya (nobo) wrote: > Hi Ron, > > I agree with Greg that a light weight mechanism to verify LSP availability is useful, and S-BFD may be a good fit for your needs. FWIW, this discussion may also be relevant to be cc'd to lime@ietf. -- Jeff From nobody Wed Oct 15 18:13:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5111A007D for ; Wed, 15 Oct 2014 18:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6tee2QT29RT for ; Wed, 15 Oct 2014 18:13:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::724]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195D61A0062 for ; Wed, 15 Oct 2014 18:13:43 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 01:13:20 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 01:13:20 +0000 From: Ronald Bonica To: "Osborne, Eric" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/HClTXe514SEE+ZLrUCU6lhm5wx5/tw Date: Thu, 16 Oct 2014 01:13:18 +0000 Message-ID: <885935f9c50a4283882f76f12e284a39@CO1PR05MB442.namprd05.prod.outlook.com> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF99EA5@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF99EA5@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(52604005)(377424004)(51704005)(13464003)(15202345003)(40100003)(85306004)(20776003)(31966008)(106356001)(50986999)(85852003)(86362001)(107886001)(2656002)(76176999)(19580405001)(15975445006)(19580395003)(2501002)(97736003)(33646002)(76576001)(107046002)(77096002)(64706001)(101416001)(99396003)(120916001)(66066001)(21056001)(230783001)(80022003)(108616004)(92566001)(87936001)(4396001)(54356999)(46102003)(106116001)(99286002)(105586002)(76482002)(122556002)(95666004)(74316001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/odRKgJ9TyBpD4QHWP6rUGFUAA6A Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 01:13:46 -0000 Hi Eric, Thanks for reading the draft. Responses inline..... > -----Original Message----- > From: Osborne, Eric [mailto:eric.osborne@level3.com] > Sent: Tuesday, October 14, 2014 4:59 PM > To: Ronald Bonica; mpls@ietf.org > Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-se= lf- > ping-00.txt >=20 > This basically says "send an echo reply to yourself over your own LSP". = Right? [RPB]=20 Exactly! > All the procedures in section 2 (the first 8 bullet points) seem like > implementation details. [RPB]=20 Some of those implementation details are important. For example, LSP readin= ess is verified, even if Echo Reply messages don't return in the order that= they were sent. >=20 > Why do you mandate the CS6 DSCP? Surely there's room for setting > whatever else I want? [RPB]=20 Good point! For example, if your network doesn't support multiple classes o= f service, there is no reason to set the DSCP bits at all. In the next version of the draft, I will downgrade this to a recommendation= . >=20 > How likely is it that the egress LSR will receive a packet with its own s= ource > and drop it due to RPF or anti-spoofing? Strict RPF seems like it would = drop > the packet, as does feasible; not sure about loose. If nothing else, any > changes to RPF needed to allow this should be covered in the security > section. [RPB]=20 [RPB]=20 Good catch! In some scenarios, the egress LSR will drop the probe. Examples= are: - the LSP penultimate hop pops and the egress LSR enforces RPF checking - the LSP does not penultimate hop pop but the egress LSR enforces RPF chec= king *after* removing the MPLS header I will mention this in the security considerations section. Operators and/o= r implementations may have to work around this. Ron >=20 >=20 >=20 >=20 >=20 > eric >=20 >=20 >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica > Sent: Tuesday, October 14, 2014 3:36 PM > To: mpls@ietf.org > Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self- > ping-00.txt >=20 > Folks, >=20 > Please review and comment >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, October 14, 2014 3:28 PM > > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > > mark.wygant@verizon.com; EXT - luis.tomotaki@verizon.com; Michael > > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > > Subject: New Version Notification for > > draft-bonica-mpls-self-ping-00.txt > > > > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-mpls-self-ping > > Revision: 00 > > Title: LSP Self-Ping > > Document date: 2014-10-14 > > Group: Individual Submission > > Pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-s= elf- > ping- > > 00.txt > > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self= -ping/ > > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-= 00 > > > > > > Abstract: > > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > > ping to verify that an LSP is ready to carry traffic. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 15 21:32:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0225C1A0178; Wed, 15 Oct 2014 21:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oFk1LrXZ8D8; Wed, 15 Oct 2014 21:32:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF71A016F; Wed, 15 Oct 2014 21:32:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016043221.2704.48413.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 21:32:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aKrFhso_bRt5DF8q1zNTrqgYWvs Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 04:32:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Controlling State Advertisements Of Non-negotiated LDP Applications Authors : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-08.txt Pages : 15 Date : 2014-10-15 Abstract: There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ip-pw-capability-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 15 23:42:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59351A0364 for ; Wed, 15 Oct 2014 23:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysvBTnKpjLgT for ; Wed, 15 Oct 2014 23:42:47 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27FC1A0140 for ; Wed, 15 Oct 2014 23:42:46 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so2870654pad.13 for ; Wed, 15 Oct 2014 23:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sImCYQERkN6CK+CkHe1D//u8SoqT4EtWKuO/DKEKcZg=; b=HZO1cmfMEJGAOfPDl4sC5YGlaIXHbySQTO5rFNS3DFHcEIPW1F+ctJ8MxmAK/EmAG+ FbDx4oy5+uBccJQHT8je4eJrpmAJ/Hg4PEt/v4zs7mwvvK6cdiS+e0Gut+gUH8Rawaql sBS7I1IgUZcAfmFOBW3f67OdCB1OKnk5Gqk5uSE/LBPlcCO92f6y8R+X+BbOQw+BBzJV iMIkrz3iz1NWbhnEpYzwUlB9DPBYsWeHgZUg0hvc5r1xDPbyiHu9q3g+T+1TxvrFcR5D vbbPH1Jx9Nn8Bi2cE+uoMUjrtwtnPH3CQ8Vt0fEF1dgwcVz9EkxfbCluZBoPGogPhWB/ yHxw== X-Received: by 10.66.97.39 with SMTP id dx7mr17748099pab.65.1413441766612; Wed, 15 Oct 2014 23:42:46 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.102.14 with HTTP; Wed, 15 Oct 2014 23:42:16 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Wed, 15 Oct 2014 23:42:16 -0700 X-Google-Sender-Auth: hoGRJINxsUU5zw6zw_Z3rz027dc Message-ID: To: Markus Jork Content-Type: multipart/alternative; boundary=001a1133a16a68e5fb0505848e64 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rXCeYkbtt22VPYviwmGGAZ8a4Qg Cc: "vishwas.manral@hp.com" , "mpls@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" , Curtis Villamizar , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:42:48 -0000 --001a1133a16a68e5fb0505848e64 Content-Type: text/plain; charset=UTF-8 Thanks Markus for the review and comments. We will address your comments in the next rev of the draft. Sri On Tue, Oct 14, 2014 at 1:11 PM, Markus Jork wrote: > I have been asked to review draft-kini-mpls-spring-entropy-label-01 as one > of the MPLS-RT members. > > The document is coherent and makes a good argument for why the entropy > label mechanism is useful and needed for SPRING. There are likely to be > networks for which this would be beneficial. > > Unfortunately, the nature of the problem and existing hardware > compatibility constraints don't lend themselves to very elegant solutions. > The proposed solution in section 4 pretty much screams "compromise". But > the following sections do a good job of describing the design constraints > and why other solutions were rejected. It will be useful to keep this > content in the document somewhere even in its final version. > > I believe the document is ready for WG adoption. Though I think there are > a couple of small problems with the examples in section 5 that should be > corrected: > > 1. Up to section 5.1, the example label stack includes a label S-SvcS2 for > the service at S2. But in all the following sections, this label is dropped > from the examples. I think it's best to leave this out in all of the > examples for brevity. > > 2. In section 5.3, the first example is given as SS2, SD>. > That should be > > 3. In section 5.4, the example is given as: > > "For the same Figure 1 above, if LSR P1 > needs to have the EL within a depth of 4, then the source LSR S > encoded label stack would be where > all the ELs would typically have the same value." > > That is leaving out the first hop SP1 from the stack (which means the EL > has to move up the stack). Also, only one EL is present. So why call it EL2? > > -Markus > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a1133a16a68e5fb0505848e64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Markus for the review and comments. We will address= your comments in the next rev of the draft.

Sri

On Tue, Oct 1= 4, 2014 at 1:11 PM, Markus Jork <mjork@juniper.net> wrote:
I have been asked to review draft-kini-mpl= s-spring-entropy-label-01 as one of the MPLS-RT members.

The document is coherent and makes a good argument for why the entropy labe= l mechanism is useful and needed for SPRING. There are likely to be network= s for which this would be beneficial.

Unfortunately, the nature of the problem and existing hardware compatibilit= y constraints don't lend themselves to very elegant solutions. The prop= osed solution in section 4 pretty much screams "compromise". But = the following sections do a good job of describing the design constraints a= nd why other solutions were rejected. It will be useful to keep this conten= t in the document somewhere even in its final version.

I believe the document is ready for WG adoption. Though I think there are a= couple of small problems with the examples in section 5 that should be cor= rected:

1. Up to section 5.1, the example label stack includes a label S-SvcS2 for = the service at S2. But in all the following sections, this label is dropped= from the examples. I think it's best to leave this out in all of the e= xamples for brevity.

2. In section 5.3, the first example is given as <SS11, ELI, EL, S-SvcS1= , SS2, SD>.
=C2=A0 That should be <SP1, ELI, EL, SS1, S-SvcS1, SS2, SD>

3. In section 5.4, the example is given as:

=C2=A0 "For the same Figure 1 above, if LSR P1
=C2=A0 =C2=A0needs to have the EL within a depth of 4, then the source LSR = S
=C2=A0 =C2=A0encoded label stack would be <SS1, S-SvcS1, ELI, EL2, SS2, = SD> where
=C2=A0 =C2=A0all the ELs would typically have the same value."

That is leaving out the first hop SP1 from the stack (which means the EL ha= s to move up the stack). Also, only one EL is present. So why call it EL2?<= br>
-Markus

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a1133a16a68e5fb0505848e64-- From nobody Thu Oct 16 01:45:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9471A1AB6 for ; Thu, 16 Oct 2014 01:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knu_7j0b7Z7r for ; Thu, 16 Oct 2014 01:45:54 -0700 (PDT) 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 AC6341A038F for ; Thu, 16 Oct 2014 01:45:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP44729; Thu, 16 Oct 2014 08:45:52 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 09:45:51 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 16:45:48 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHB7od2a6fIukWWAhaLI28KOJwyfQYw Date: Thu, 16 Oct 2014 08:45:47 +0000 Message-ID: References: <542E752C.3020203@pi.nu> In-Reply-To: <542E752C.3020203@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UpOwMjsNzOZOIPXCdnfPgIqCdVs Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:45:56 -0000 I have read the draft, and support the adoption. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, October 03, 2014 6:07 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-raza-mpls-oam-ipv6-rao@tools.ietf.o= rg > Subject: [mpls] poll to see if we have support to make > draft-raza-mpls-oam-ipv6-rao an mpls wg doc >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). Please give a technical motivation for your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > There is no IPR disclosures against this document. >=20 > The authors has all stated on the working group mailing list that they ar= e unaware > of any IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and aware o= f IPR > that relates to this draft, the time to disclose this is now. >=20 > This poll ends October 17, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 05:49:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0071A1AA6 for ; Thu, 16 Oct 2014 05:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdWQfa6xs10S for ; Thu, 16 Oct 2014 05:49:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435B71A1B2D for ; Thu, 16 Oct 2014 05:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1297; q=dns/txt; s=iport; t=1413463742; x=1414673342; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Dy8ksu1piAl0FFJckkJ3Ub2mlp5XF/nWXwY4ES1iuRA=; b=gEGgOFobrQjSbq4p1KKuB4gmGW43Od4KhNuD65BCpalxpijiP23owbiB a7GisORDH+o3L2haM00BibPP/ZRQxqxhDjPoRy9j3VKcHczQbqAnG+ALe L7mgvWqiiBDEXX1wsAFyMzIvvX5zlNMSuBdS6IjFjKUTW+0mIRWUWBmcG 0=; X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208";a="212876904" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Oct 2014 12:49:00 +0000 Received: from [64.103.108.173] (dhcp-bdlk10-data-vlan301-64-103-108-173.cisco.com [64.103.108.173]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9GCn00I022138; Thu, 16 Oct 2014 12:49:00 GMT Message-ID: <543FBEBD.4010908@cisco.com> Date: Thu, 16 Oct 2014 13:49:01 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0MoF48MWkLT3sPg_KadUR9uegpI Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 12:49:28 -0000 Ross You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft. It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements. In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly. In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces. I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource. As such I think the IPR poll, and the imminent intention to adopt is premature. - Stewart From nobody Thu Oct 16 06:34:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F71A1BE8 for ; Thu, 16 Oct 2014 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HmLlPw3KpNs for ; Thu, 16 Oct 2014 06:34:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B1D1A1BE6 for ; Thu, 16 Oct 2014 06:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41710; q=dns/txt; s=iport; t=1413466470; x=1414676070; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QeYOEg6CufnTW1yBb5y/ngf61GL5TRh5yUK62JcvKSE=; b=I03SzuBWDJPk1sc9hddXSUutojwEaHpLHBd72e6Z+ZZWF/Lt2w/J+jle JgDP3DuTpSRg0SOvxphBZfuW4gsyCOnxrJW5VySID1ZmqtU8NWfs2Bgd6 4Tdh1e4eVmmFS9IfpRLEKo6P/teo044X4Vo/QaYup9E/t3Pwk24pZaI8j s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFACDJP1StJV2d/2dsb2JhbABbgkhGgS+DAtBoAht6FgF9hAIBAQEEJwZcAgEGAhEDAQIhAQYFAgIwFAYDCAIEARKIPphZnEkIlRoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2IUPAoXAYJzgVgBBJF/i1iBMI1UhxiCNIFDbIEHQYECAQEB X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208,217";a="363586472" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2014 13:34:04 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9GDY314020172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 13:34:03 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:34:03 -0500 From: "Tarek Saad (tsaad)" To: Lizhenbin , "mpls@ietf.org" Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6ICBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUt?= =?gb2312?B?eWFuZy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2Zn?= =?gb2312?Q?-00?= Thread-Index: AQHP58Feg2ZeYdbA6kixioRl3kAWoZwyzP2A Date: Thu, 16 Oct 2014 13:34:02 +0000 Message-ID: References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.250.160] Content-Type: multipart/alternative; boundary="_000_D06540F0142AF3tsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jJESaKcq1DmyPXxrTSjlnj582A4 Subject: Re: [mpls] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBs?= =?gb2312?b?cy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFu?= =?gb2312?b?Zy1jZmctMDA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:34:33 -0000 --_000_D06540F0142AF3tsaadciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQoNClRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZSB0byB0aGUgZHJhZnQuIFdlIGhh ZCBhIGxvb2sgYXQgaXQuIFdlIGFyZSBwcm9wb3NpbmcgYSBzbGlnaHRseSBkaWZmZXJlbnQgbW9k ZWwgdGhhdCBpbnRyb2R1Y2VzIGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gY29uZmlndXJhdGlv biwgb3BlcmF0aW9uYWwgKHN0YXRlKSwgUlBDIChleGVjdXRpb25hbCksIGFuZCBub3RpZmljYXRp b25zIGZvciBNUExTLVRFIHR1bm5lbHMsIGxzcHMsIGxpbmtzLCBhbmQgZ2xvYmFsIGRhdGE6DQoN Cg0KbW9kdWxlOiBtcGxzLXRlDQoNCiAgICstLXJ3IHR1bm5lbHMtY2ZnIQ0KDQogICArLS1ydyBs c3BzLWNmZyENCg0KICAgKy0tcncgbGlua3MtY2ZnIQ0KDQogICArLS1ydyBnbG9iYWwtY2ZnIQ0K DQogICArLS1ybyB0dW5uZWxzLW9wZXINCg0KICAgKy0tcm8gbHNwcy1vcGVyDQoNCiAgICstLXJv IGxpbmtzLW9wZXINCg0KICAgKy0tcm8gZ2xvYmFsLW9wZXINCg0KcnBjczoNCg0KICAgKy0tLXgg dHVubmVscy1ycGMNCg0KICAgKy0tLXggbHNwcy1ycGMNCg0KICAgKy0tLXggZ2xvYmFsLXJwYw0K DQogICArLS0teCBsaW5rcy1ycGMNCg0Kbm90aWZpY2F0aW9uczoNCg0KICAgKy0tLW4gdHVubmVs cy1ub3RpZg0KDQogICArLS0tbiBsc3BzLW5vdGlmDQoNCiAgICstLS1uIGxpbmtzLW5vdGlmDQoN CiAgICstLS1uIGdsb2JhbC1ub3RpZg0KDQpXZSBhbHNvIGhhdmUgYSBkZXRhaWxlZCBZQU5HIG1v ZGVsIGluLXRoZS13b3JrcyAoYXMgcGVyIHRoZSBhYm92ZSkgYW5kIHdloa9yZSBwbGFubmluZyB0 byBpbmNsdWRlIGluIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgZHJhZnQuIEZvciBleGFtcGxlLCB0 aGUgdHVubmVscyBZQU5HIG1vZGVsIGxvb2tzIHNvbWV0aGluZyBsaWtlIGJlbG93Lg0KDQpBcyBm b3IgY29sbGFib3JhdGlvbiwgeWVzLCB3ZSBhcmUgd2lsbGluZyB0byBjb25zb2xpZGF0ZSBvdXIg ZWZmb3J0cyB3aXRoIHlvdSB0byBwcm9kdWNlIHRoZSBJRVRGIE1QTFMtVEUgWWFuZyBtb2RlbC4N Cg0KDQptb2R1bGU6IG1wbHMtdGUNCg0KICAgKy0tcncgdHVubmVscy1jZmchDQoNCiAgIHwgICst LXJ3IHR1bm5lbCogW25hbWUgdHlwZV0NCg0KICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAg ICAgICAgICAgc3RyaW5nDQoNCiAgIHwgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAg IHR1bm5lbC10eXBlDQoNCiAgIHwgICAgICstLXJ3IHR1bm5lbC1pZD8gICAgICAgICAgICAgIHVp bnQxNg0KDQogICB8ICAgICArLS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICAgICBzdHJpbmcNCg0K ICAgfCAgICAgKy0tcncgZGVzdGluYXRpb24qIFthZGRyZXNzXQ0KDQogICB8ICAgICB8ICArLS1y dyBhZGRyZXNzICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgfCAgKy0tcncgcGF0 aC1vcHRpb24qIFtpbmRleF0NCg0KICAgfCAgICAgfCAgICAgKy0tcncgaW5kZXggICAgICAgICAg ICAgdWludDgNCg0KICAgfCAgICAgfCAgICAgKy0tcncgKHR5cGUpPw0KDQogICB8ICAgICB8ICAg ICB8ICArLS06KGR5bmFtaWMpDQoNCiAgIHwgICAgIHwgICAgIHwgIHwgICstLXJ3IGR5bmFtaWMN Cg0KICAgfCAgICAgfCAgICAgfCAgKy0tOihleHBsaWNpdCkNCg0KICAgfCAgICAgfCAgICAgfCAg ICAgKy0tcncgZXhwbGljaXQNCg0KICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcncgZXhwbGlj aXQtaG9wbGlzdCogW2luZGV4XQ0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAgICArLS1ydyBp bmRleCAgICAgICAgICAgICAgICAgICB1aW50OA0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAg ICArLS1ydyBleHBsaWNpdC1ob3AtYWRkcmVzcz8gICBob3AtYWRkcmVzcy10eXBlDQoNCiAgIHwg ICAgIHwgICAgIHwgICAgICAgICAgICstLXJ3IGV4cGxpY2l0LWhvcC1hY3Rpb24/ICAgIGhvcC1h Y3Rpb24tdHlwZQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBpZ3AtY29uc3RyYWludA0KDQogICB8 ICAgICB8ICAgICB8ICArLS1ydyBpZ3A/ICAgICAgICAgIGVudW1lcmF0aW9uDQoNCiAgIHwgICAg IHwgICAgIHwgICstLXJ3IGFyZWEtbGV2ZWw/ICAgdWludDMyDQoNCiAgIHwgICAgIHwgICAgICst LXJ3IHZlcmJhdGltPyAgICAgICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgICAgKy0tcncgbG9j a2Rvd24/ICAgICAgICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1ydyBsc3AtY2ZnKiBbaW5kZXhd DQoNCiAgIHwgICAgIHwgICstLXJ3IGluZGV4ICAgICAgICAgICAgIGxlYWZyZWYNCg0KICAgfCAg ICAgfCAgKy0tcncgc291cmNlPyAgICAgICAgICAgaW5ldDppcC1hZGRyZXNzDQoNCiAgIHwgICAg IHwgICstLXJ3IGZhc3QtcmVyb3V0ZT8gICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgKy0tcncg cmVjb3JkLXJvdXRlPyAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICArLS1ydyBzaWduYWxlZC1u YW1lPyAgICBzdHJpbmcNCg0KICAgfCAgICAgfCAgKy0tcncgcHJpb3JpdHkNCg0KICAgfCAgICAg fCAgfCAgKy0tcncgc2V0dXA/ICAgdWludDgNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9sZD8g ICAgdWludDgNCg0KICAgfCAgICAgfCAgKy0tcncgYWZmaW5pdHkNCg0KICAgfCAgICAgfCAgfCAg Ky0tcncgY29uc3RyYWludHMqIFthY3Rpb25dDQoNCiAgIHwgICAgIHwgIHwgICAgICstLXJ3IGFj dGlvbiAgICAgICAgYWZmaW5pdHktYWN0aW9uLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgICAgKy0t cncgY29uc3RyYWludA0KDQogICB8ICAgICB8ICB8ICAgICAgICArLS1ydyBhZmZpbml0eS1saXN0 KiBbbmFtZV0NCg0KICAgfCAgICAgfCAgfCAgICAgICAgICAgKy0tcncgbmFtZSAgICBzdHJpbmcN Cg0KICAgfCAgICAgfCAgKy0tcncgcGF0aC1zZWxlY3Rpb24NCg0KICAgfCAgICAgfCAgfCAgKy0t cncgY29zdC1saW1pdD8gICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9wLWxpbWl0 PyAgICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgbWV0cmljPyAgICAgICBwYXRoLW1l dHJpYy10eXBlDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IHRpZWJyZWFrZXI/ICAgcGF0aC10aWVi cmVha2VyLXR5cGUNCg0KICAgfCAgICAgfCAgKy0tcncgYmZkDQoNCiAgIHwgICAgIHwgIHwgICst LXJ3IHR5cGU/ICAgICAgICAgICAgICAgYmZkLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgKy0tcncg YnJpbmd1cC10aW1lb3V0PyAgICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZGFtcGVu aW5nPyAgICAgICAgICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZW5jYXAtbW9kZT8g ICAgICAgICBiZmQtZW5jYXAtbW9kZS10eXBlDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZhc3Qt ZGV0ZWN0PyAgICAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBsc3AtcGluZw0K DQogICB8ICAgICB8ICB8ICB8ICArLS1ydyBkaXNhYmxlPyAgICBib29sZWFuDQoNCiAgIHwgICAg IHwgIHwgIHwgICstLXJ3IGludGVydmFsPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1y dyBtaW5pbXVtLWludGVydmFsPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBtdWx0 aXBsaWVyPyAgICAgICAgIHVpbnQzMg0KDQogICB8ICAgICB8ICArLS1ydyBsb2dnaW5nLWV2ZW50 KiBbZXZlbnRdDQoNCiAgIHwgICAgIHwgICAgICstLXJ3IGV2ZW50ICAgIGxvZ2dpbmctZXZlbnQt dHlwZQ0KDQogICB8ICAgICArLS1ydyAocG9saWN5LXJvdXRpbmcpPw0KDQogICB8ICAgICB8ICAr LS06KGZvcndhcmRpbmctY2xhc3MpDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZvcndhcmRpbmct Y2xhc3MNCg0KICAgfCAgICAgfCAgfCAgICAgKy0tcncgY2xhc3M/ICAgdWludDgNCg0KICAgfCAg ICAgfCAgKy0tOihmb3J3YXJkaW5nLWdyb3VwKQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBmb3J3 YXJkaW5nLWdyb3VwDQoNCiAgIHwgICAgIHwgICAgICAgICstLXJ3IGNsYXNzZXMqICAgdWludDgN Cg0KICAgfCAgICAgKy0tcncgYXV0by1iYW5kd2lkdGgNCg0KICAgfCAgICAgfCAgKy0tcncgb3Zl cmZsb3ctdGhyZXNob2xkPyAgICB1aW50MzINCg0KICAgfCAgICAgfCAgKy0tcncgb3ZlcmZsb3ct bGltaXQ/ICAgICAgICB1aW50OA0KDQogICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctdGhyZXNo b2xkPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctbGltaXQ/ICAgICAg IHVpbnQ4DQoNCiAgIHwgICAgIHwgICstLXJ3IGNvbGxlY3Qtb25seT8gICAgICAgICAgYm9vbGVh bg0KDQogICB8ICAgICArLS1ydyAoYW5ub3VuY2UtYXMpPw0KDQogICB8ICAgICB8ICArLS06KGF1 dG9yb3V0ZSkNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgYXV0b3JvdXRlIQ0KDQogICB8ICAgICB8 ICB8ICAgICArLS1ydyBpbmNsdWRlLWlwdjYtdW5pY2FzdD8gICBib29sZWFuDQoNCiAgIHwgICAg IHwgIHwgICAgICstLXJ3IChtZXRyaWMtdHlwZSk/DQoNCiAgIHwgICAgIHwgIHwgICAgICAgICst LToobWV0cmljKQ0KDQogICB8ICAgICB8ICB8ICAgICAgICB8ICArLS1ydyBtZXRyaWM/ICAgICAg ICAgICAgICAgICB1aW50OA0KDQogICB8ICAgICB8ICB8ICAgICAgICArLS06KHJlbGF0aXZlLW1l dHJpYykNCg0KICAgfCAgICAgfCAgfCAgICAgICAgfCAgKy0tcncgcmVsYXRpdmUtbWV0cmljPyAg ICAgICAgdWludDgNCg0KICAgfCAgICAgfCAgfCAgICAgICAgKy0tOihhYnNvbHV0ZS1tZXRyaWMp DQoNCiAgIHwgICAgIHwgIHwgICAgICAgICAgICstLXJ3IGFic29sdXRlLW1ldHJpYz8gICAgICAg IHVpbnQ4DQoNCiAgIHwgICAgIHwgICstLTooZm9yd2FyZGluZy1hZGphY2VuY3kpDQoNCiAgIHwg ICAgIHwgICAgICstLXJ3IGZvcndhcmRpbmctYWRqYWNlbmN5IQ0KDQogICB8ICAgICB8ICAgICAg ICArLS1ydyBob2xkdGltZT8gICAgICAgICAgICAgICB1aW50MzINCg0KICAgfCAgICAgfCAgICAg ICAgKy0tcncgaW5jbHVkZS1pcHY2LXVuaWNhc3Q/ICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1y dyBiYWNrdXAtYmFuZHdpZHRoPyAgICAgICB1aW50MzINCg0KICAgfCAgICAgKy0tcncgbG9hZC1z aGFyZT8gICAgICAgICAgICAgdWludDMyDQoNCiAgIHwgICAgICstLXJ3IGJpZGlyZWN0aW9uYWwN Cg0KICAgfCAgICAgICAgKy0tcncgYXNzb2NpYXRpb24NCg0KICAgfCAgICAgICAgICAgKy0tcncg aWQ/ICAgICAgICAgICAgICB1aW50MzINCg0KICAgfCAgICAgICAgICAgKy0tcncgc291cmNlPyAg ICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgZ2xvYmFsLXNv dXJjZT8gICBpbmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgdHlwZT8gICAg ICAgICAgICBiaWRpci1hc3NvY2lhdGlvbi10eXBlDQoNCiAgICstLXJ3IGdsb2JhbC1jZmchDQoN ClJlZ2FyZHMsDQpUYXJlaw0KDQpGcm9tOiBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29t PG1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDE0 LCAyMDE0IGF0IDExOjEyIEFNDQpUbzogIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbXBs c10gtPC4tDogUmVnYXJkaW5nIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgYW5k IGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMA0KDQpIaSBNUExTZXIsDQpJIHdvdWxkIGxp a2UgdG8gcmVtaW5kIHlvdSBvZiB0aGUgb3RoZXIgdHdvIFlhbmcgbW9kZWwgZHJhZnRzOiBkcmFm dC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDAgYW5kIGRyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1v YW0tMDAuIFdlbGNvbWUgY29tbWVudHMgYW5kIGNvbGxhYm9yYXRpb24uDQoNCkJlc3QgUmVnYXJk cywNClpoZW5iaW4oUm9iaW4pDQoNCg0KDQoNCg0Kt6K8/sjLOiBtcGxzIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIExpemhlbmJpbg0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIxNMjV IDIyOjM0DQrK1bz+yMs6IHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT47IHRzYWFkQGNpc2NvLmNvbTxtYWlsdG86dHNhYWRAY2lzY28uY29tPjsgcnNhd2F5YUBjaXNj by5jb208bWFpbHRvOnJzYXdheWFAY2lzY28uY29tPg0Ks63LzTogbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCtb3zOI6IFttcGxzXSBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1w bHMtdGUteWFuZy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwDQoN CkhpIFJha2VzaCwgVGFyZWsgJiBSb2JlcnQsDQpJIGp1c3Qgc2F3IHlvdSBwcm9wb3NlZCB0aGUg ZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0wMC4gSSB3b25kZXIgaWYgeW91IGFyZSBh d2FyZSBvZiB0aGUgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIHdlIHByb3Bvc2VkIG9u IEF1Z3VzdCAxNS4gRnJvbSBvdXIgcG9pbnQgb2Ygdmlldywgd2UgYXJlIG5vdCBleHBlcmllbmNl ZCBlbm91Z2ggdG8gcmVtaW5kIG91ciBNUExTZXJzIG9mIHRoZSBuZXcgZHJhZnQgdG8gcHJvcG9z ZSBwb3NzaWJsZSBkaXNjdXNzaW9uIGFuZCBjb2xsYWJvcmF0aW9uLiBJIGNvbXBhcmVkIHRoZSB0 d28gZHJhZnRzIGFzIGZvbGxvd3M6DQoxLiBUaGUgcG9zc2libGUgb3ZlcmxhcHBlZCBwYXJ0DQog ICAgICBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCiAgICAg NC4xLiAgR2xvYmFsIE1QTFMtVEUgRGF0YSBNb2RlbCBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNCAgICAgICAtLT4gICAgICAgICBNUExTIFRFIEdsb2JhbCBDb25maWd1cmF0aW9u L1JTVlAtVEUgR2xvYmFsIENvbmZpZ3VyYXRpb24NCiAgICAgNC4yLiAgTVBMUy1URSBUdW5uZWwg SW50ZXJmYWNlIERhdGEgTW9kZWwgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAgNiAgICAtLT4gICAg ICAgICBSU1ZQLVRFIFR1bm5lbCBDb25maWd1cmF0aW9uDQogICAgIDQuMy4gIE1QTFMtVEUgVHVu bmVsIExTUCBEYXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcgICAgICAt LT4gICAgICAgICBSU1ZQLVRFIFR1bm5lbCBDb25maWd1cmF0aW9uDQogICAgIDQuNC4gIE1QTFMt VEUgTGluayBEYXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgg ICAgICAgIC0tPiAgICAgICAgIE1QTFMgVEUgTGluayBDb25maWd1cmF0aW9uL1JTVlAtVEUgSW50 ZXJmYWNlIENvbmZpZ3VyYXRpb24NCjIuIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBk ZWZpbmVzIGZvbGxvd2luZyBjb25maWd1cmF0aW9uIFlhbmcgYmV5b25kIGRyYWZ0LWdhbmRoaS1t cGxzLXRlLXlhbmctbW9kZWwtMDAuDQogICAgIDMuNC4gIEV4cGxpY2l0IFBhdGggQ29uZmlndXJh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgMy41LiAgUDJNUCBU RSBMZWFmIExpc3QgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0K ICAgICAzLjkuICBDU1BGIENvbmZpZ3VyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA4DQogICAgIDMuMTAuIFAyTVAgVEUgVHVubmVsIFRlbXBsYXRlIENvbmZp Z3VyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCjMuIGRyYWZ0LWNoZW4tbXBscy10ZS15 YW5nLWNmZy0wMCBoYXMgYWxyZWFkeSBkZWZpbmVkIGFsbCBZYW5nIG1vZGVsIGZvciB0aGVzZSBs aXN0ZWQgY29uZmlndXJhdGlvbiB3aGlsZSBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVs LTAwIGxlYXZlcyBtYW55IFlhbmcgTW9kZWwgZGVmaW5pdGlvbiBhcyBzcGFjZXMuDQoNCkkgdGhp bmsgbWF5YmUgeW91IGFyZSBub3QgYXdhcmUgb2YgdGhlIGV4aXN0aW5nIGRyYWZ0LiBJZiB5b3Ug d291bGQgbGlrZSB0byBjb29wZXJhdGUgb24gdGhlIE1QTFMgVEUgWWFuZyBNb2RlbHMgZGVmaW5p dGlvbiwgd2UgYXJlIHZlcnkgZ2xhZCB0byBkaXNjdXNzIHdpdGggeW91IHRvIHRyeSB0byB1bmlm eSB0aGVzZSBZYW5nIG1vZGVscy4NCg0KDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4p DQoNCg0KDQo= --_000_D06540F0142AF3tsaadciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <8736EB9F69F7C648A7469F271C515887@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Robin,

Thanks for the reference to the draft. We had a look at it. We are pro= posing a slightly different model that introduces clear delineation between= configuration, operational (state), RPC (executional), and notifications f= or MPLS-TE tunnels, lsps, links, and global data:

modu= le: mpls-te

&nbs= p;  +--rw tunnels-cfg!

&nbs= p;  +--rw lsps-cfg!

&nbs= p;  +--rw links-cfg!

&nbs= p;  +--rw global-cfg!

&nbs= p;  +--ro tunnels-oper

&nbs= p;  +--ro lsps-oper

&nbs= p;  +--ro links-oper

&nbs= p;  +--ro global-oper

rpcs= :

&nbs= p;  +---x tunnels-rpc    

&nbs= p;  +---x lsps-rpc       

&nbs= p;  +---x global-rpc     

&nbs= p;  +---x links-rpc      

noti= fications:

&nbs= p;  +---n tunnels-notif    

&nbs= p;  +---n lsps-notif       

&nbs= p;  +---n links-notif      

&nbs= p;  +---n global-notif 


We also have a detailed YANG model in-the-works (as per the above) and we= =A1=AFre planning to include in the next update of the draft. For example, = the tunnels YANG model looks something like below.

As for collaboration, yes, we are willing to consolidate our efforts w= ith you to produce the IETF MPLS-TE Yang model.

modu= le: mpls-te

&nbs= p;  +--rw tunnels-cfg!

&nbs= p;  |  +--rw tunnel* [name type]

&nbs= p;  |     +--rw name          &= nbsp;         string

&nbs= p;  |     +--rw type          &= nbsp;         tunnel-type

&nbs= p;  |     +--rw tunnel-id?        &n= bsp;     uint16

&nbs= p;  |     +--rw description?        =     string

&nbs= p;  |     +--rw destination* [address]

&nbs= p;  |     |  +--rw address      &nbs= p; inet:ip-address

&nbs= p;  |     |  +--rw path-option* [index]

&nbs= p;  |     |     +--rw index     &nbs= p;       uint8

&nbs= p;  |     |     +--rw (type)?

&nbs= p;  |     |     |  +--:(dynamic)

&nbs= p;  |     |     |  |  +--rw dynamic<= /p>

&nbs= p;  |     |     |  +--:(explicit)

&nbs= p;  |     |     |     +--rw explicit=

&nbs= p;  |     |     |        += --rw explicit-hoplist* [index]

&nbs= p;  |     |     |         &nbs= p; +--rw index                 =   uint8

&nbs= p;  |     |     |         &nbs= p; +--rw explicit-hop-address?   hop-address-type

&nbs= p;  |     |     |         &nbs= p; +--rw explicit-hop-action?    hop-action-type

&nbs= p;  |     |     +--rw igp-constraint

&nbs= p;  |     |     |  +--rw igp?   = ;       enumeration

&nbs= p;  |     |     |  +--rw area-level? &nbs= p; uint32

&nbs= p;  |     |     +--rw verbatim?     =     boolean

&nbs= p;  |     |     +--rw lockdown?     =     boolean

&nbs= p;  |     +--rw lsp-cfg* [index]

&nbs= p;  |     |  +--rw index        = ;     leafref

&nbs= p;  |     |  +--rw source?       &nb= sp;   inet:ip-address

&nbs= p;  |     |  +--rw fast-reroute?     bool= ean

&nbs= p;  |     |  +--rw record-route?     bool= ean

&nbs= p;  |     |  +--rw signaled-name?    stri= ng

&nbs= p;  |     |  +--rw priority

&nbs= p;  |     |  |  +--rw setup?   uint8

&nbs= p;  |     |  |  +--rw hold?    uint8=

&nbs= p;  |     |  +--rw affinity

&nbs= p;  |     |  |  +--rw constraints* [action]

&nbs= p;  |     |  |     +--rw action  &nb= sp;     affinity-action-type

&nbs= p;  |     |  |     +--rw constraint

&nbs= p;  |     |  |        +--rw aff= inity-list* [name]

&nbs= p;  |     |  |           += --rw name    string

&nbs= p;  |     |  +--rw path-selection

&nbs= p;  |     |  |  +--rw cost-limit?   uint3= 2

&nbs= p;  |     |  |  +--rw hop-limit?    = uint32

&nbs= p;  |     |  |  +--rw metric?     &n= bsp; path-metric-type

&nbs= p;  |     |  |  +--rw tiebreaker?   path-= tiebreaker-type

&nbs= p;  |     |  +--rw bfd

&nbs= p;  |     |  |  +--rw type?     &nbs= p;         bfd-type

&nbs= p;  |     |  |  +--rw bringup-timeout?  &= nbsp; uint32

&nbs= p;  |     |  |  +--rw dampening?    =       uint32

&nbs= p;  |     |  |  +--rw encap-mode?    = ;     bfd-encap-mode-type

&nbs= p;  |     |  |  +--rw fast-detect?   = ;     boolean

&nbs= p;  |     |  |  +--rw lsp-ping

&nbs= p;  |     |  |  |  +--rw disable?  &= nbsp; boolean

&nbs= p;  |     |  |  |  +--rw interval?  = uint32

&nbs= p;  |     |  |  +--rw minimum-interval?  = uint32

&nbs= p;  |     |  |  +--rw multiplier?    = ;     uint32

&nbs= p;  |     |  +--rw logging-event* [event]

&nbs= p;  |     |     +--rw event    loggi= ng-event-type

&nbs= p;  |     +--rw (policy-routing)?

&nbs= p;  |     |  +--:(forwarding-class)

&nbs= p;  |     |  |  +--rw forwarding-class

&nbs= p;  |     |  |     +--rw class?   ui= nt8

&nbs= p;  |     |  +--:(forwarding-group)

&nbs= p;  |     |     +--rw forwarding-group

&nbs= p;  |     |        +--rw classes* &n= bsp; uint8

&nbs= p;  |     +--rw auto-bandwidth

&nbs= p;  |     |  +--rw overflow-threshold?   = uint32

&nbs= p;  |     |  +--rw overflow-limit?    &nb= sp;   uint8

&nbs= p;  |     |  +--rw underflow-threshold?   uint= 32

&nbs= p;  |     |  +--rw underflow-limit?     &= nbsp; uint8

&nbs= p;  |     |  +--rw collect-only?     = ;     boolean

&nbs= p;  |     +--rw (announce-as)?

&nbs= p;  |     |  +--:(autoroute)

&nbs= p;  |     |  |  +--rw autoroute!

&nbs= p;  |     |  |     +--rw include-ipv6-uni= cast?   boolean

&nbs= p;  |     |  |     +--rw (metric-type)?

&nbs= p;  |     |  |        +--:(metr= ic)

&nbs= p;  |     |  |        |  += --rw metric?                 uint8<= /p>

&nbs= p;  |     |  |        +--:(rela= tive-metric)

&nbs= p;  |     |  |        |  += --rw relative-metric?        uint8

&nbs= p;  |     |  |        +--:(abso= lute-metric)

&nbs= p;  |     |  |           += --rw absolute-metric?        uint8

&nbs= p;  |     |  +--:(forwarding-adjacency)

&nbs= p;  |     |     +--rw forwarding-adjacency!

&nbs= p;  |     |        +--rw holdtime? &= nbsp;             uint32

&nbs= p;  |     |        +--rw include-ipv= 6-unicast?   boolean

&nbs= p;  |     +--rw backup-bandwidth?       u= int32

&nbs= p;  |     +--rw load-share?         =     uint32

&nbs= p;  |     +--rw bidirectional

&nbs= p;  |        +--rw association

&nbs= p;  |           +--rw id?    &n= bsp;         uint32

&nbs= p;  |           +--rw source?   = ;       inet:ip-address

&nbs= p;  |           +--rw global-source? &nbs= p; inet:ip-address

&nbs= p;  |           +--rw type?    =         bidir-association-type

&nbs= p;  +--rw global-cfg!


Regards,
Tarek

From: Lizhenbin <lizhenbin@huawei.com>
Date: Tuesday, October 14, 2014 at = 11:12 AM
To: "mpls@ietf.org" <mpls@i= etf.org>
Subject: [mpls] =B4=F0=B8=B4: Regar= ding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00<= br>

Hi MPLS= er,

I would= like to remind you of the other two Yang model drafts: draft-chen-mpls-te-= yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. Welcome comments and colla= boration.

&n= bsp;

Best Re= gards,

Zhenbin= (Robin)

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: mpls [mailto:m= pls-bounces@ietf.org] =B4=FA=B1=ED = Lizhenbin
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA10=D4=C2= 14=C8=D5 22:34
=CA=D5=BC=FE=C8=CB: rgandhi@cisco.com; tsaad@cisco.com; rsawaya@cisco.com
=B3=AD=CB=CD: mpls@ietf.org
=D6=F7=CC=E2: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-t= e-yang-cfg-00

 

Hi Rakesh, Tarek & Robert,<= o:p>

I just saw you proposed the dra= ft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the draft-che= n-mpls-te-yang-cfg-00 we proposed on August 15. From our point of view, we = are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and collaborat= ion. I compared the two drafts as follows:

1. The possible overlapped part=

      = draft-gandhi-mpls-te-yang-model-00       = ;            &n= bsp;            = ;      draft-chen-mpls-te-yang-cfg-00

     4.1.&n= bsp; Global MPLS-TE Data Model Overview . . . . . . . . . . . .  4&nbs= p;      -->      =   MPLS TE Global Configuration/RSVP-TE Global Configuration

     4= .2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .  = 6    -->         = RSVP-TE Tunnel Configuration 

     4= .3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .  = 7      -->       =   RSVP-TE Tunnel Configuration 

     4= .4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .  = 8        -->    &= nbsp;    MPLS TE Link Configuration/RSVP-TE Interface Config= uration 

2. draft-chen-mpls-te-yang-cfg-= 00 defines following configuration Yang beyond draft-gandhi-mpls-te-yang-mo= del-00.

     3.4.&n= bsp; Explicit Path Configuration . . . . . . . . . . . . . . .   = 5

     3.5.&n= bsp; P2MP TE Leaf List Configuration . . . . . . . . . . . . .   = 5

     3.9.&n= bsp; CSPF Configuration  . . . . . . . . . . . . . . . . . . . &n= bsp; 8

     3.10. = P2MP TE Tunnel Template Configuration . . . . . . . . . .   8

3. draft-chen-mpls-te-yang-cfg-= 00 has already defined all Yang model for these listed configuration while = draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition as spa= ces.

 

I think maybe you are not aware= of the existing draft. If you would like to cooperate on the MPLS TE Yang = Models definition, we are very glad to discuss with you to try to unify the= se Yang models.

 

 

 

Best Regards,=

Zhenbin(Robin)

 

 

 --_000_D06540F0142AF3tsaadciscocom_-- From nobody Thu Oct 16 08:24:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B571A1BDD for ; Thu, 16 Oct 2014 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-KBz4YODx8c for ; Thu, 16 Oct 2014 08:24:16 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (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 3E1211A1BC0 for ; Thu, 16 Oct 2014 08:24:16 -0700 (PDT) Received: from [65.213.193.25] (port=51250 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XemuQ-0005ry-9u for mpls@ietf.org; Thu, 16 Oct 2014 15:24:10 +0000 From: "Shamjhana" To: Date: Thu, 16 Oct 2014 11:23:58 -0400 Organization: Isocore Message-ID: <001301cfe955$356a61d0$a03f2570$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01CFE933.AE5A4870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/pVTTXrvfxGZ3BQpekT2Ta2rI4rw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tpq-4Nhn718_BmUdUgvOAIuoC5c Subject: [mpls] Cloud & Data Center, WAN and Virtualization/NFV - SDN/MPLS 2014 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:24:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01CFE933.AE5A4870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Only a few days is left to SDN/MPLS 2014 Conference. Come and learn about the future of networking. Register now at: http://www.isocore.com/sdn-mpls/attendees.php The SDN/MPLS 2014 Conference program is available at: http://www.isocore.com/sdn-mpls/ Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm You can make your hotel reservation based on room availability at: http://www.isocore.com/sdn-mpls/hotel.htm Thank you! ------=_NextPart_000_0014_01CFE933.AE5A4870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Only a few days =  is left to SDN/MPLS 2014 Conference. Come and  learn = about the future of networking.  Register now at: http://www.isocor= e.com/sdn-mpls/attendees.php

 

The SDN/MPLS 2014 = Conference program is available at:http://www.isocore.com/sdn-mpls/Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm 
Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions= .htm

 

You can make your = hotel reservation based on room availability at:  http://www.isocore.com/sdn-mpls/hotel.htm

Thank = you!

 =

------=_NextPart_000_0014_01CFE933.AE5A4870-- From nobody Thu Oct 16 09:34:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8A71A876A for ; Thu, 16 Oct 2014 09:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLY-YGL-kwaf for ; Thu, 16 Oct 2014 09:34:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FF61A876D for ; Thu, 16 Oct 2014 09:34:02 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-3a-543f99b1d0fb Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F1.C0.25146.1B99F345; Thu, 16 Oct 2014 12:10:57 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 12:33:53 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6A///4KUA= Date: Thu, 16 Oct 2014 16:33:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: <543FBEBD.4010908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiO7GmfYhBitnylnM2TqRxeL7pSUs FreWrmS1+LviCovFuadzGB1YPab83sjqsWTJTyaP601X2T2+XP7MFsASxWWTkpqTWZZapG+X wJVxcvZz1oLJIhW//s9lamBcI9DFyMEhIWAisXuRdRcjJ5ApJnHh3nq2LkYuDiGBo4wSz//P hHKWM0p8//2IBaSKTcBI4sXGHnaQhIjAFUaJ/f9WsoMkmAVsJe48ucYIYgsD2dNn3QWzRQTs JI4uPskGYVtJ3Pn0DqyeRUBVYsrlPnaQK3gFfCXe73ABCQsJlEi8fXsRrJxTQFNi599fYHsZ ga77fmoNE8QqcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtpLEpKXnWCHqdSQW7P7EBmFrSyxb +BqsnldAUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25kuIkRGFfHJNgcdzAu +GR5iFGAg1GJh3eBmn2IEGtiWXFl7iFGaQ4WJXFezep5wUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYPVv/fd/uIzoro33mlpnifasNlj5KSlPUDRI/ZO115mzko03SARPyvn2aer3uYb9k 4JQnuwQOSZ68eXul85+YLoZbn3Wm7j9UbnVCxtz7FU+07bMERYXkeS9ffJrjar+TP5bhqd3y 7z+ZandeMf2y1m16neHhPIM5TiGn2f+17d+/W+Ffcsn5p0osxRmJhlrMRcWJAA2mkFKMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WxNW27LJS8kprlTD3243IjftR3A Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:34:04 -0000 Hi Stewart, thank you for your interest in the proposal, detailed and thought provoking= comments. Please find my notes in-lined and tagged GIM>>. Regards, Greg -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Thursday, October 16, 2014 5:49 AM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Ross You state that you are starting an IPR poll with a view to determining whet= her this draft is ready for adoption as a WG draft. It is my view that it is premature to adopt a solution draft such as this w= ithout first achieving a common understanding of all the requirements. In this particular case, the solution on the table will require a hardware = re-spin and will consume a precious 0..15 reserved label which is something= that we should not do lightly. GIM>> With creation of the Extended Special Purpose Label space SLI (Source= Label Indicator) may well come be allocated from that space, not from orig= inal 0...15. Though I agree, we must be considerate and thorough when alloc= ating (extended) special purpose label, any label. In addition I am not convinced that the full set of requirements are taken = into account in the proposed design. For example the solution only proposes= to identify the source LSR, whereas it seems likely that a finer granulari= ty of flow identification will be needed in practice. Additionally in the o= nly use case cited (performance monitoring) it seems likely that accounting= demarcation will be be needed to allow for different delays of the ECMP pa= ths and the distribution of packets across multiple receiver interfaces. GIM>> I believe that purpose of SL in OAM is not to uniquely identify parti= cular flow but only identify maintenance point, whether as source of OAM te= st packets in case of active measurements, or OAM observation point in case= of passive measurements. True MEP ID, as in RFC 6428, may be used but SL i= s viewed by authors as lighter, more generic method that is applicable not = only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment R= outing with MPLS dataplane. I think that we need to backup the process and start by agreeing the set of= requirements before we embark on a design which will be expensive in MPLS = protocol and implementation resource. As such I think the IPR poll, and the imminent intention to adopt is prema= ture. - Stewart From nobody Thu Oct 16 10:06:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06FA1A0275 for ; Thu, 16 Oct 2014 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XBs1DD68LDT for ; Thu, 16 Oct 2014 10:06:36 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949C01A0276 for ; Thu, 16 Oct 2014 10:06:34 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id cm18so2630048qab.20 for ; Thu, 16 Oct 2014 10:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wwAblvRMMWLB72ZAxfwo+mq3qdWGDlQ42nFEOaOjzOg=; b=lc1q2B5750RCB45FjYU94Wm6kbmWJwXs319LxrRBkw7Pip6lXcP7ChNIdC3WhjQvtu XDI7XUf4g5UGKcZYd8KVa+EKI7KBSRV804xTVuLoEteWXTTBeU4IZZ7wLCahlR1N2eGj vk9/OihTzc+c3Vjx3otOWybBEdRAO+25I/oeo7WmBL0Zu9YOyUgpOeHIbmy7wuOb3nNP Us9zATf3URh6WvYvYEgp44TjZTBXM9tM6Gd5rvJV2L+6huaBBdeAxOhFVILd2uaJMUmf zUs7K64hsFNpXzVF2ECgkVLSHSIGuuV+0xh91+OQm8KxVt0HQ30KhM25IIwr3a403/Sy 5/3g== X-Received: by 10.229.212.5 with SMTP id gq5mr4114429qcb.25.1413479193638; Thu, 16 Oct 2014 10:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.147 with HTTP; Thu, 16 Oct 2014 10:06:13 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> From: "Andrew G. Malis" Date: Thu, 16 Oct 2014 19:06:13 +0200 Message-ID: To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a113378183bfcc905058d45bb Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/i-9jQ2sHJHwpz4mdWtAtkh9LZBs Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:06:38 -0000 --001a113378183bfcc905058d45bb Content-Type: text/plain; charset=UTF-8 Stewart, To add to Greg's response, in a vacuum, I would agree with your email. Howver, there has already been considerable discussion on the mpls list of real operational issues that this draft addresses, such as packet loss in mobile backhaul networks using mp-to-p MPLS. This will allow both the ability to measure loss ratios and also to generate traffic matrices to see if judicial TE would improve things. Perhaps this could be added to the draft, but the draft isn't being written as an academic excercse, but to address networks issues. Cheers, Andy On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky wrote: > Hi Stewart, > thank you for your interest in the proposal, detailed and thought > provoking comments. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org; > draft-chen-mpls-source-label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Ross > > You state that you are starting an IPR poll with a view to determining > whether this draft is ready for adoption as a WG draft. > > It is my view that it is premature to adopt a solution draft such as this > without first achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardware > re-spin and will consume a precious 0..15 reserved label which is something > that we should not do lightly. > GIM>> With creation of the Extended Special Purpose Label space SLI > (Source Label Indicator) may well come be allocated from that space, not > from original 0...15. Though I agree, we must be considerate and thorough > when allocating (extended) special purpose label, any label. > > In addition I am not convinced that the full set of requirements are taken > into account in the proposed design. For example the solution only proposes > to identify the source LSR, whereas it seems likely that a finer > granularity of flow identification will be needed in practice. Additionally > in the only use case cited (performance monitoring) it seems likely that > accounting demarcation will be be needed to allow for different delays of > the ECMP paths and the distribution of packets across multiple receiver > interfaces. > GIM>> I believe that purpose of SL in OAM is not to uniquely identify > particular flow but only identify maintenance point, whether as source of > OAM test packets in case of active measurements, or OAM observation point > in case of passive measurements. True MEP ID, as in RFC 6428, may be used > but SL is viewed by authors as lighter, more generic method that is > applicable not only to MPLS-TP but to other MPLS networks, including > IP/MPLS and Segment Routing with MPLS dataplane. > > I think that we need to backup the process and start by agreeing the set > of requirements before we embark on a design which will be expensive in > MPLS protocol and implementation resource. > > As such I think the IPR poll, and the imminent intention to adopt is > premature. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113378183bfcc905058d45bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

To add to Greg's response,= in a vacuum, I would agree with your email. Howver, there has already been= considerable discussion on the mpls list of real operational issues that t= his draft addresses, such as packet loss in mobile backhaul networks using = mp-to-p MPLS. This will allow both the ability to measure loss ratios and a= lso to generate traffic matrices to see if judicial TE would improve things= . Perhaps this could be added to the draft, but the draft isn't being w= ritten as an academic excercse, but to address networks issues.
<= br>
Cheers,
Andy


On Thu, Oct 16, 2014 at 6:3= 3 PM, Gregory Mirsky <gregory.mirsky@ericsson.com>= wrote:
Hi Stewart,
thank you for your interest in the proposal, detailed and thought provoking= comments. Please find my notes in-lined and tagged GIM>>.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg

-----Original Message-----
From: Stewart Bryant [mailto:stbryant= @cisco.com]
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; mpls@ietf.org; draft-chen-mpls-so= urce-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.or= g
Subject: Re: [mpls] IPR poll for draft-chen-mpls-so= urce-label

Ross

You state that you are starting an IPR poll with a view to determining whet= her this draft is ready for adoption as a WG draft.

It is my view that it is premature to adopt a solution draft such as this w= ithout first achieving a common understanding of all the requirements.
In this particular case, the solution on the table will require a hardware = re-spin and will consume a precious 0..15 reserved label which is something= that we should not do lightly.
GIM>> With creation of the Extended Special Purpose Label spac= e SLI (Source Label Indicator) may well come be allocated from that space, = not from original 0...15. Though I agree, we must be considerate and thorou= gh when allocating (extended) special purpose label, any label.

In addition I am not convinced that the full set of requirements are taken = into account in the proposed design. For example the solution only proposes= to identify the source LSR, whereas it seems likely that a finer granulari= ty of flow identification will be needed in practice. Additionally in the o= nly use case cited (performance monitoring) it seems likely that accounting= demarcation will be be needed to allow for different delays of the ECMP pa= ths and the distribution of packets across multiple receiver interfaces. GIM>> I believe that purpose of SL in OAM is not to uniquely i= dentify particular flow but only identify maintenance point, whether as sou= rce of OAM test packets in case of active measurements, or OAM observation = point in case of passive measurements. True MEP ID, as in RFC 6428, may be = used but SL is viewed by authors as lighter, more generic method that is ap= plicable not only to MPLS-TP but to other MPLS networks, including IP/MPLS = and Segment Routing with MPLS dataplane.

I think that we need to backup the process and start by agreeing the set of= requirements before we embark on a design which will be expensive in MPLS = protocol and implementation resource.

As such I think the IPR poll, and the=C2=A0 imminent intention to adopt is = premature.

- Stewart


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a113378183bfcc905058d45bb-- From nobody Thu Oct 16 11:17:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6546F1A011E; Thu, 16 Oct 2014 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1VTgjwCD_RB; Thu, 16 Oct 2014 11:16:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BC51A011D; Thu, 16 Oct 2014 11:16:53 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 18:16:30 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 18:16:30 +0000 From: Ronald Bonica To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/Sz532BBBssAEmtAXBon3Z/HZwzBFYw Date: Thu, 16 Oct 2014 18:16:29 +0000 Message-ID: <95c3da24b7e7438a9044c037b0920781@CO1PR05MB442.namprd05.prod.outlook.com> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(199003)(377454003)(52604005)(377424004)(13464003)(189002)(86362001)(87936001)(77096002)(20776003)(99286002)(106116001)(76482002)(85306004)(19617315012)(33646002)(15975445006)(95666004)(54356999)(50986999)(76176999)(105586002)(85852003)(122556002)(74316001)(40100003)(31966008)(92566001)(19625215002)(108616004)(230783001)(120916001)(101416001)(19580395003)(66066001)(21056001)(19580405001)(80022003)(46102003)(4396001)(97736003)(76576001)(64706001)(19609705001)(15202345003)(2656002)(99396003)(107046002)(106356001)(2501002)(16236675004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qlf_6iHJZY9NbJPLHvhpxeGnNTY Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:16:57 -0000 --_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for reviewing the document! One drawback of the approach outlined in draft-ietf-bfd-seamless-use-case i= s that it requires the egress LSR to implement new BFD procedures. By contr= ast, LSP Self-ping does not impose any new requirements upon the egress. Ron From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: draft-ietf-bfd-seamless-use-case@tools.ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

Thanks for reviewing the = document!

 <= /p>

One drawback of the appro= ach outlined in draft-ietf-bfd-seamless-use-case is that it requires the eg= ress LSR to implement new BFD procedures. By contrast, LSP Self-ping does not impose any new requirements upon the egress.=

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Ron

 <= /p>

 <= /p>

From: Gregor= y Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: draft-ietf-bfd-seamless-use-case@tools.ietf.org; rtg-bfd@ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

> -----Original Message-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_-- From nobody Thu Oct 16 11:19:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D51A1A32; Thu, 16 Oct 2014 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC8OT-ROK8gV; Thu, 16 Oct 2014 11:19:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACA11A0199; Thu, 16 Oct 2014 11:19:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9GIJE7W021852; Thu, 16 Oct 2014 19:19:14 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9GIJCk8021842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 19:19:13 +0100 From: "Adrian Farrel" To: "'CCAMP'" , , Date: Thu, 16 Oct 2014 19:19:08 +0100 Message-ID: <028e01cfe96d$ae0b58c0$0a220a40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/pbaw1aHsTHPmgROqdF3p2VsF9QA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21032.002 X-TM-AS-Result: No--4.904-10.0-31-10 X-imss-scan-details: No--4.904-10.0-31-10 X-TMASE-MatchedRID: +zq3ScDhdVz243bLvnYxneLdprnA5EQRz5hzQnUnsHZA9Ad+70NukwaT alM8C773f5Vqqfad4pvUWPjkMGeZuEj+bWNtFbsn2Hdvv/MGE3V9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62Slph5Erpfp880NeRFKdoAXdDgke9UroWa3BQLMX8eahc1zb 8qMsqVNO6pgZ0FbrwakU7Q86IOG58YSeH4gETaLLp6OACFzbL56Hq9RCTLxvsstHmcXeW1eBVSG W4LjW40FYnPSoXfG8ckhYHVA/r8kw== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HDvXJ4fgfo83rbcn9Fw2tTmsk_c Cc: routing-discussion@ietf.org Subject: [mpls] Progress with forming TEAS working group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:19:21 -0000 All, We have been working on a first draft of a charter for TEAS to split out "Traffic Engineering" from the current CCAMP and MPLS working groups. This will also necessitate new charters for CCAMP and MPLS, and a tiny tweak to PCE. Our plan is to get something with some rough agreement from the chairs of the various working groups and then to put it out for discussion. I hope that we will be able to assign some time in Honolulu to discuss any contentious issues that arise. However, note that the current working groups will meet a normal in Hawaii. Adrian and Alia From nobody Thu Oct 16 11:26:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55601A70FE for ; Thu, 16 Oct 2014 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OqI_ocKyAH5 for ; Thu, 16 Oct 2014 11:26:35 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0161A011E for ; Thu, 16 Oct 2014 11:26:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,733,1406617200"; d="scan'208";a="48620615" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 16 Oct 2014 12:46:31 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Oct 2014 11:26:38 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 11:26:30 -0700 From: Shahram Davari To: "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkA= Date: Thu, 16 Oct 2014 18:26:29 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: <543FBEBD.4010908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/odRdRTzKjpFk8tyhJmJ8dhM-q8g Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:26:37 -0000 Hi, I agree with Stewart. I am not convinced such a label is required. This dra= ft adds multiple labels to the label stack (makes the label stack much larg= er than it already is) and requires a respin of chips due to its special la= bel handling in the data-plane. An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM fr= om RFC6374. So until a solid argument is put forward that existing solutions (ILM in RF= C 6374) or possible other solutions not requiring HW change are not adequat= e, I think it is premature To adopt this draft.=20 Thanks Shahram -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, October 16, 2014 5:49 AM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Ross You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft. It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements. In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly. In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces. I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource. As such I think the IPR poll, and the imminent intention to adopt is premature. - Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 11:38:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1491E1A0199 for ; Thu, 16 Oct 2014 11:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0k26pykx2Bu for ; Thu, 16 Oct 2014 11:37:55 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id BE3901A011E for ; Thu, 16 Oct 2014 11:37:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,733,1406617200"; d="scan'208";a="48232446" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 16 Oct 2014 11:40:50 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Oct 2014 11:37:52 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 11:37:50 -0700 From: Shahram Davari To: "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoA== Date: Thu, 16 Oct 2014 18:37:49 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hwbys3zsyZCQFGJKy7iGmLWoqc4 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:37:58 -0000 Hi, This is similar to the Traffic Engineering argument. If a service provider = wants to use MPL S and do traffic Engineering then they should use P2P RSVP= -TE LSPs, otherwise then can use MP2MP LDP LSPs.=20 Similarly in this case, if a service provider wants to use MPL S and do Dir= ect Loss Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise = they can use MP2MP LDP LSPs. Thanks Shahram -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Thursday, October 16, 2014 11:26 AM To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; draft-chen-mpls-source-= label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Hi, I agree with Stewart. I am not convinced such a label is required. This dra= ft adds multiple labels to the label stack (makes the label stack much larg= er than it already is) and requires a respin of chips due to its special la= bel handling in the data-plane. An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM fr= om RFC6374. So until a solid argument is put forward that existing solutions (ILM in RF= C 6374) or possible other solutions not requiring HW change are not adequat= e, I think it is premature To adopt this draft.=20 Thanks Shahram -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, October 16, 2014 5:49 AM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Ross You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft. It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements. In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly. In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces. I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource. As such I think the IPR poll, and the imminent intention to adopt is premature. - Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 11:44:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9D21A86ED; Thu, 16 Oct 2014 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8uLRwENJTPi; Thu, 16 Oct 2014 11:44:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077B71A6FED; Thu, 16 Oct 2014 11:44:12 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 18:44:10 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 18:44:10 +0000 From: Ronald Bonica To: "Nobo Akiya (nobo)" , Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/Zqa6/0YZx/ZEumjY2jQZiJtJwzEBjA Date: Thu, 16 Oct 2014 18:44:10 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(41574002)(189002)(377454003)(52604005)(51704005)(377424004)(13464003)(85852003)(40100003)(20776003)(85306004)(93886004)(15202345003)(106356001)(50986999)(76576001)(86362001)(31966008)(19617315012)(2656002)(19625215002)(76176999)(19580395003)(15975445006)(16236675004)(19580405001)(19609705001)(2501002)(97736003)(33646002)(107046002)(99396003)(77096002)(64706001)(101416001)(120916001)(66066001)(21056001)(230783001)(80022003)(108616004)(46102003)(54356999)(4396001)(87936001)(92566001)(106116001)(105586002)(76482002)(122556002)(99286002)(74316001)(95666004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8maZkOz2FzBjZqMAuGAQurTkths Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:44:18 -0000 --_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Thanks for reviewing this document. Comments inline..... Ron Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. [RPB] LSP Self-ping is an extremely lightweight mechanism that verifies the avail= ability of the data plane. It does not verify that the LSP follows the ERO,= or even that it terminates on the correct egress LSR. In the rare cases when the LSP has been programmed incorrectly, it is appro= priate to invoke heavier-weight diagnostic tools. When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. [RPB] True. LSP Self-ping is not applicable for LDP independent mode. Ron Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-= case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nobo,

 <= /p>

Thanks for reviewing this= document. Comments inline…..

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Ron

 <= /p>

 <= /p>

 = ;

Destinatio= n address having a valid IP address (i.e. address of ingress LSR) means tha= t this probe will come back to the ingress LSR when:

- transit = LSR false pops and forwards (due to incorrect label programming)=

- transit = LSR false forwards elsewhere and happens to terminates at some other networ= k nodes via different LSP (due to incorrect label programming)

 = ;

Certain pa= ckets over such LSP (ex: VPN) will likely get dropped even though proposed = probe reports success, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.=

 

[RPB= ]

LSP = Self-ping is an extremely lightweight mechanism that verifies the availabil= ity of the data plane. It does not verify that the LSP follows the ERO, or even that it terminates on the correct egress LSR.<= /span>

 

In t= he rare cases when the LSP has been programmed incorrectly, it is appropria= te to invoke heavier-weight diagnostic tools.

 = ;

 = ;

When appli= ed to the LDP independent mode, proposed probe will have the same “fa= lse positive” issue with “end-to-end LSP not ready” case = as well.

 

 

[RPB= ]

True= . LSP Self-ping is not applicable for LDP independent mode.

 

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 = ;

 = ;

Thanks!

 = ;

-Nobo=

 = ;

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing t= his work to discussion. I agree that lightweight mechanism to verify LSP av= ailability is useful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would li= ke to reference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 =

Greatly appreciate your = feedback.

 =

    =     Regards,

    =             Greg

 =

-----Original Message---= --
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 =

Folks,=

 =

Please review and commen= t

 =

    =             &nb= sp;        Ron

 =

 =

> -----Original Messa= ge-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, Octo= ber 14, 2014 3:28 PM

> To: Ronald Bonica; = EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Ravee= ndra Torvi; Dante Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella= ; EXT - mark.wygant@verizon.com=

> Subject: New Versio= n Notification for

> draft-bonica-mpls-s= elf-ping-00.txt

>

>

> A new version of I-= D, draft-bonica-mpls-self-ping-00.txt

> has been successful= ly submitted by Ron Bonica and posted to the IETF

> repository.

>

> Name:  &n= bsp;      draft-bonica-mpls-self-ping

> Revision: &nbs= p;   00

> Title:  &= nbsp;           &nbs= p; LSP Self-Ping

> Document date: = ;       2014-10-14

> Group:  &= nbsp;           &nbs= p; Individual Submission

> Pages:  &= nbsp;           &nbs= p; 7

> 00.txt

>

>

> Abstract:

>    T= his memo describes LSP Self-ping.  An ingress LSR can use LSP Self-

>    p= ing to verify that an LSP is ready to carry traffic.

>

>

>

>

> Please note that it= may take a couple of minutes from the time of

> submission until th= e htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretaria= t

 =

________________________= _______________________

mpls mailing list

 =

--_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_-- From nobody Thu Oct 16 12:18:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AFD1A882E for ; Thu, 16 Oct 2014 12:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.05 X-Spam-Level: **** X-Spam-Status: No, score=4.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow8Ko8ov7FpU for ; Thu, 16 Oct 2014 12:18:08 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.195]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBE51A8827 for ; Thu, 16 Oct 2014 12:18:07 -0700 (PDT) Received: from [216.82.242.147:6747] by server-3.bemta-8.messagelabs.com id C8/A3-01183-EE910445; Thu, 16 Oct 2014 19:18:06 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-13.tower-95.messagelabs.com!1413487085!30362438!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20766 invoked from network); 16 Oct 2014 19:18:05 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-13.tower-95.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Oct 2014 19:18:05 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 0DC9F1F8F8; Thu, 16 Oct 2014 19:18:05 +0000 (GMT) Received: from USIDCWVEHT04.corp.global.level3.com (10.1.196.124) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 16 Oct 2014 13:18:04 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT04.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 13:18:04 -0600 From: "Osborne, Eric" To: "Tarek Saad (tsaad)" , Lizhenbin , "mpls@ietf.org" Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6ICBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUt?= =?gb2312?B?eWFuZy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2Zn?= =?gb2312?Q?-00?= Thread-Index: AQHP58FeZIbQv9djREeRA2f1MRZyjpwzIMQA///4guA= Date: Thu, 16 Oct 2014 19:18:03 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.207] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717USIDCWVEMBX08corp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qCpNcGBzzM5M70fvV38FU1dgYmE Subject: Re: [mpls] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBs?= =?gb2312?b?cy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFu?= =?gb2312?b?Zy1jZmctMDA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:18:12 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717USIDCWVEMBX08corp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBsb29rZWQgYXQgYm90aCBkb2N1bWVudHMuICBUaGV5IGJvdGggaGF2ZSBzb21lIGdvb2QgYW5k IHNvbWUgYmFkLiAgVGhlIGhhcmRlc3QgcGFydCBpbiByZWNvbmNpbGluZyB0aGVtIHdpbGwgYmUg dGhhdCB0aGV5IGJvdGggaGF2ZSBhIHZlcnkgdmVuZG9yLXNwZWNpZmljIHZpZXcgb2YgdGhlIHdv cmxkLiAgVGhpcyBpcyBubyBzdXJwcmlzZSBnaXZlbiB0aGUgbmF0dXJlIG9mIHRoZSB0ZWNobm9s b2d5LCBhbmQgSSBkb26hr3QgdGhpbmsgaXShr3MgdW5pcXVlIHRvIFRFLiAgQkdQIHdpbGwgYmUg YXQgbGVhc3QgYXMgaGFyZCB0byBzb3J0IG91dC4NCg0KSSB0aGluayB3ZSBuZWVkIHRvIGNsZWFy bHkgZGVsaW5lYXRlIGJldHdlZW4gc3RhbmRhcmQgZmVhdHVyZXMsIGNvbW1vbiBmZWF0dXJlcywg YW5kIHZlbmRvci1zcGVjaWZpYyBvbmVzLiAgU3RhbmRhcmQgZmVhdHVyZXMgbWlnaHQgYmUgc2Nv cGVkIHRvIGFueXRoaW5nIHRoYXQgaXMgYm90aCBzaWduYWxlZCBhbmQgUkZDoa9kLCBlLmcuLCBb MzIwOSwgNDQyMCwgNDg3NSwgNTcxMiwgNzMwOF0uDQoNCkNvbW1vbiBhcmUgdGhpbmdzIHRoYXQg bWF5IGhhdmUgZGlmZmVyZW50IG5hbWVzIGFuZCB3aGljaCBhcmVuoa90IHNpZ25hbGVkLCBidXQg d2hpY2ggYXJlIGluIHVzZSBpbiBtYW55L21vc3QvYWxsIGltcGxlbWVudGF0aW9ucyCoQyB0aGlu Z3MgbGlrZSB3aGF0IG9uZSB2ZW5kb3IgY2FsbHMgoa5hdXRvcm91dGUgYW5ub3VuY2WhryBhbmQg YW5vdGhlciBjYWxscyChrmlncCBzaG9ydGN1dHOhry4gIEZpbmQgYSBjb21tb24gbmFtZSwgb3Ig YSB3YXkgdG8gdXNlIGJvdGgsIGFuZCBidWlsZCBhIG1vZGVsIGZvciB0aGUgc3Vic2V0IG9mIHRo aW5ncyB0aGF0IGlzIG1vc3QgY29tbW9uIGFjcm9zcyB2ZW5kb3JzLiAgVGhpcyBpcyBhIGJpdCBv ZiBhIHF1YWdtaXJlIHNpbmNlIGRpZmZlcmVudCB2ZW5kb3JzIHdpbGwgaGF2ZSBkaWZmZXJlbnQg YXBwcm9hY2hlcyB0byBtYW55IGRldGFpbHMgb2YgY29tbW9uIGZlYXR1cmVzLCBhbmQgaXQgbWF5 IGJlIHRoZSBtb3N0IGRpZmZpY3VsdCBwYXJ0IG9mIHRoaXMgd2hvbGUgZXhlcmNpc2UuDQoNClZl bmRvci1zcGVjaWZpYyB0aGluZ3MgYXJlIGp1c3QgdGhhdCCoQyB0aGluZ3MgaW1wbGVtZW50ZWQg aW4gYSBwYXJ0aWN1bGFyIHdheSBieSBvbmx5IG9uZSB2ZW5kb3IuICBBbiBleGFtcGxlIGZyb20g Um9iZXJ0LCBSYWtlc2ggYW5kIFRhcmVroa9zIGRvY3VtZW50IG1pZ2h0IGJlIGF0dHJpYnV0ZS1z ZXRzLCB3aGljaCBtYXkgbm90IGhhdmUgYW4gb2J2aW91cyBwYXJhbGxlbCBpbiBvdGhlciB2ZW5k b3Jzoa8gZ2Vhci4gIElmIG5vdGhpbmcgZWxzZSB0aGVyZSBuZWVkcyB0byBiZSBzb21lcGxhY2Ug YSB2ZW5kb3IgY2FuIGFwcGVuZCBpdHMgb3duIHByb3ByaWV0YXJ5IG1vZGVscy4NCg0KSW4gdGhl IGVuZCBpdCBtYXkgYmUgbW9yZSBwcm9kdWN0aXZlIHRvIGRvIGl0IHRoaXMgd2F5IKhDIHN0YXJ0 aW5nIHdpdGggYSBtaW5pbXVtIHNldCBvZiBvYnZpb3VseSBjb21tb24gZmVhdHVyZXMgYW5kIHdv cmtpbmcgdXAgqEMgdGhhbiB0cnlpbmcgdG8gcmVjb25jaWxlIHR3byBmdWxseSBiYWtlZCBtb2Rl bHMgd2l0aCB2ZXJ5IGRpZmZlcmVudCB2aWV3cyBvZiB0aGUgd29ybGQuDQoNCg0KDQoNCg0KZXJp Yw0KDQoNCg0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgVGFyZWsgU2FhZCAodHNhYWQpDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNiwg MjAxNCA5OjM0IEFNDQpUbzogTGl6aGVuYmluOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21wbHNdILTwuLQ6IFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAw IGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCg0KSGkgUm9iaW4sDQoNClRoYW5r cyBmb3IgdGhlIHJlZmVyZW5jZSB0byB0aGUgZHJhZnQuIFdlIGhhZCBhIGxvb2sgYXQgaXQuIFdl IGFyZSBwcm9wb3NpbmcgYSBzbGlnaHRseSBkaWZmZXJlbnQgbW9kZWwgdGhhdCBpbnRyb2R1Y2Vz IGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gY29uZmlndXJhdGlvbiwgb3BlcmF0aW9uYWwgKHN0 YXRlKSwgUlBDIChleGVjdXRpb25hbCksIGFuZCBub3RpZmljYXRpb25zIGZvciBNUExTLVRFIHR1 bm5lbHMsIGxzcHMsIGxpbmtzLCBhbmQgZ2xvYmFsIGRhdGE6DQoNCg0KbW9kdWxlOiBtcGxzLXRl DQoNCiAgICstLXJ3IHR1bm5lbHMtY2ZnIQ0KDQogICArLS1ydyBsc3BzLWNmZyENCg0KICAgKy0t cncgbGlua3MtY2ZnIQ0KDQogICArLS1ydyBnbG9iYWwtY2ZnIQ0KDQogICArLS1ybyB0dW5uZWxz LW9wZXINCg0KICAgKy0tcm8gbHNwcy1vcGVyDQoNCiAgICstLXJvIGxpbmtzLW9wZXINCg0KICAg Ky0tcm8gZ2xvYmFsLW9wZXINCg0KcnBjczoNCg0KICAgKy0tLXggdHVubmVscy1ycGMNCg0KICAg Ky0tLXggbHNwcy1ycGMNCg0KICAgKy0tLXggZ2xvYmFsLXJwYw0KDQogICArLS0teCBsaW5rcy1y cGMNCg0Kbm90aWZpY2F0aW9uczoNCg0KICAgKy0tLW4gdHVubmVscy1ub3RpZg0KDQogICArLS0t biBsc3BzLW5vdGlmDQoNCiAgICstLS1uIGxpbmtzLW5vdGlmDQoNCiAgICstLS1uIGdsb2JhbC1u b3RpZg0KDQpXZSBhbHNvIGhhdmUgYSBkZXRhaWxlZCBZQU5HIG1vZGVsIGluLXRoZS13b3JrcyAo YXMgcGVyIHRoZSBhYm92ZSkgYW5kIHdloa9yZSBwbGFubmluZyB0byBpbmNsdWRlIGluIHRoZSBu ZXh0IHVwZGF0ZSBvZiB0aGUgZHJhZnQuIEZvciBleGFtcGxlLCB0aGUgdHVubmVscyBZQU5HIG1v ZGVsIGxvb2tzIHNvbWV0aGluZyBsaWtlIGJlbG93Lg0KDQpBcyBmb3IgY29sbGFib3JhdGlvbiwg eWVzLCB3ZSBhcmUgd2lsbGluZyB0byBjb25zb2xpZGF0ZSBvdXIgZWZmb3J0cyB3aXRoIHlvdSB0 byBwcm9kdWNlIHRoZSBJRVRGIE1QTFMtVEUgWWFuZyBtb2RlbC4NCg0KDQptb2R1bGU6IG1wbHMt dGUNCg0KICAgKy0tcncgdHVubmVscy1jZmchDQoNCiAgIHwgICstLXJ3IHR1bm5lbCogW25hbWUg dHlwZV0NCg0KICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQoN CiAgIHwgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgIHR1bm5lbC10eXBlDQoNCiAg IHwgICAgICstLXJ3IHR1bm5lbC1pZD8gICAgICAgICAgICAgIHVpbnQxNg0KDQogICB8ICAgICAr LS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICAgICBzdHJpbmcNCg0KICAgfCAgICAgKy0tcncgZGVz dGluYXRpb24qIFthZGRyZXNzXQ0KDQogICB8ICAgICB8ICArLS1ydyBhZGRyZXNzICAgICAgICBp bmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgfCAgKy0tcncgcGF0aC1vcHRpb24qIFtpbmRleF0N Cg0KICAgfCAgICAgfCAgICAgKy0tcncgaW5kZXggICAgICAgICAgICAgdWludDgNCg0KICAgfCAg ICAgfCAgICAgKy0tcncgKHR5cGUpPw0KDQogICB8ICAgICB8ICAgICB8ICArLS06KGR5bmFtaWMp DQoNCiAgIHwgICAgIHwgICAgIHwgIHwgICstLXJ3IGR5bmFtaWMNCg0KICAgfCAgICAgfCAgICAg fCAgKy0tOihleHBsaWNpdCkNCg0KICAgfCAgICAgfCAgICAgfCAgICAgKy0tcncgZXhwbGljaXQN Cg0KICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcncgZXhwbGljaXQtaG9wbGlzdCogW2luZGV4 XQ0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAgICArLS1ydyBpbmRleCAgICAgICAgICAgICAg ICAgICB1aW50OA0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAgICArLS1ydyBleHBsaWNpdC1o b3AtYWRkcmVzcz8gICBob3AtYWRkcmVzcy10eXBlDQoNCiAgIHwgICAgIHwgICAgIHwgICAgICAg ICAgICstLXJ3IGV4cGxpY2l0LWhvcC1hY3Rpb24/ICAgIGhvcC1hY3Rpb24tdHlwZQ0KDQogICB8 ICAgICB8ICAgICArLS1ydyBpZ3AtY29uc3RyYWludA0KDQogICB8ICAgICB8ICAgICB8ICArLS1y dyBpZ3A/ICAgICAgICAgIGVudW1lcmF0aW9uDQoNCiAgIHwgICAgIHwgICAgIHwgICstLXJ3IGFy ZWEtbGV2ZWw/ICAgdWludDMyDQoNCiAgIHwgICAgIHwgICAgICstLXJ3IHZlcmJhdGltPyAgICAg ICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgICAgKy0tcncgbG9ja2Rvd24/ICAgICAgICAgYm9v bGVhbg0KDQogICB8ICAgICArLS1ydyBsc3AtY2ZnKiBbaW5kZXhdDQoNCiAgIHwgICAgIHwgICst LXJ3IGluZGV4ICAgICAgICAgICAgIGxlYWZyZWYNCg0KICAgfCAgICAgfCAgKy0tcncgc291cmNl PyAgICAgICAgICAgaW5ldDppcC1hZGRyZXNzDQoNCiAgIHwgICAgIHwgICstLXJ3IGZhc3QtcmVy b3V0ZT8gICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgKy0tcncgcmVjb3JkLXJvdXRlPyAgICAg Ym9vbGVhbg0KDQogICB8ICAgICB8ICArLS1ydyBzaWduYWxlZC1uYW1lPyAgICBzdHJpbmcNCg0K ICAgfCAgICAgfCAgKy0tcncgcHJpb3JpdHkNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgc2V0dXA/ ICAgdWludDgNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9sZD8gICAgdWludDgNCg0KICAgfCAg ICAgfCAgKy0tcncgYWZmaW5pdHkNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgY29uc3RyYWludHMq IFthY3Rpb25dDQoNCiAgIHwgICAgIHwgIHwgICAgICstLXJ3IGFjdGlvbiAgICAgICAgYWZmaW5p dHktYWN0aW9uLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgICAgKy0tcncgY29uc3RyYWludA0KDQog ICB8ICAgICB8ICB8ICAgICAgICArLS1ydyBhZmZpbml0eS1saXN0KiBbbmFtZV0NCg0KICAgfCAg ICAgfCAgfCAgICAgICAgICAgKy0tcncgbmFtZSAgICBzdHJpbmcNCg0KICAgfCAgICAgfCAgKy0t cncgcGF0aC1zZWxlY3Rpb24NCg0KICAgfCAgICAgfCAgfCAgKy0tcncgY29zdC1saW1pdD8gICB1 aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9wLWxpbWl0PyAgICB1aW50MzINCg0KICAg fCAgICAgfCAgfCAgKy0tcncgbWV0cmljPyAgICAgICBwYXRoLW1ldHJpYy10eXBlDQoNCiAgIHwg ICAgIHwgIHwgICstLXJ3IHRpZWJyZWFrZXI/ICAgcGF0aC10aWVicmVha2VyLXR5cGUNCg0KICAg fCAgICAgfCAgKy0tcncgYmZkDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IHR5cGU/ICAgICAgICAg ICAgICAgYmZkLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgYnJpbmd1cC10aW1lb3V0PyAg ICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZGFtcGVuaW5nPyAgICAgICAgICB1aW50 MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZW5jYXAtbW9kZT8gICAgICAgICBiZmQtZW5jYXAt bW9kZS10eXBlDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZhc3QtZGV0ZWN0PyAgICAgICAgYm9v bGVhbg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBsc3AtcGluZw0KDQogICB8ICAgICB8ICB8ICB8 ICArLS1ydyBkaXNhYmxlPyAgICBib29sZWFuDQoNCiAgIHwgICAgIHwgIHwgIHwgICstLXJ3IGlu dGVydmFsPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBtaW5pbXVtLWludGVydmFs PyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBtdWx0aXBsaWVyPyAgICAgICAgIHVp bnQzMg0KDQogICB8ICAgICB8ICArLS1ydyBsb2dnaW5nLWV2ZW50KiBbZXZlbnRdDQoNCiAgIHwg ICAgIHwgICAgICstLXJ3IGV2ZW50ICAgIGxvZ2dpbmctZXZlbnQtdHlwZQ0KDQogICB8ICAgICAr LS1ydyAocG9saWN5LXJvdXRpbmcpPw0KDQogICB8ICAgICB8ICArLS06KGZvcndhcmRpbmctY2xh c3MpDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZvcndhcmRpbmctY2xhc3MNCg0KICAgfCAgICAg fCAgfCAgICAgKy0tcncgY2xhc3M/ICAgdWludDgNCg0KICAgfCAgICAgfCAgKy0tOihmb3J3YXJk aW5nLWdyb3VwKQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBmb3J3YXJkaW5nLWdyb3VwDQoNCiAg IHwgICAgIHwgICAgICAgICstLXJ3IGNsYXNzZXMqICAgdWludDgNCg0KICAgfCAgICAgKy0tcncg YXV0by1iYW5kd2lkdGgNCg0KICAgfCAgICAgfCAgKy0tcncgb3ZlcmZsb3ctdGhyZXNob2xkPyAg ICB1aW50MzINCg0KICAgfCAgICAgfCAgKy0tcncgb3ZlcmZsb3ctbGltaXQ/ICAgICAgICB1aW50 OA0KDQogICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctdGhyZXNob2xkPyAgIHVpbnQzMg0KDQog ICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctbGltaXQ/ICAgICAgIHVpbnQ4DQoNCiAgIHwgICAg IHwgICstLXJ3IGNvbGxlY3Qtb25seT8gICAgICAgICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1y dyAoYW5ub3VuY2UtYXMpPw0KDQogICB8ICAgICB8ICArLS06KGF1dG9yb3V0ZSkNCg0KICAgfCAg ICAgfCAgfCAgKy0tcncgYXV0b3JvdXRlIQ0KDQogICB8ICAgICB8ICB8ICAgICArLS1ydyBpbmNs dWRlLWlwdjYtdW5pY2FzdD8gICBib29sZWFuDQoNCiAgIHwgICAgIHwgIHwgICAgICstLXJ3ICht ZXRyaWMtdHlwZSk/DQoNCiAgIHwgICAgIHwgIHwgICAgICAgICstLToobWV0cmljKQ0KDQogICB8 ICAgICB8ICB8ICAgICAgICB8ICArLS1ydyBtZXRyaWM/ICAgICAgICAgICAgICAgICB1aW50OA0K DQogICB8ICAgICB8ICB8ICAgICAgICArLS06KHJlbGF0aXZlLW1ldHJpYykNCg0KICAgfCAgICAg fCAgfCAgICAgICAgfCAgKy0tcncgcmVsYXRpdmUtbWV0cmljPyAgICAgICAgdWludDgNCg0KICAg fCAgICAgfCAgfCAgICAgICAgKy0tOihhYnNvbHV0ZS1tZXRyaWMpDQoNCiAgIHwgICAgIHwgIHwg ICAgICAgICAgICstLXJ3IGFic29sdXRlLW1ldHJpYz8gICAgICAgIHVpbnQ4DQoNCiAgIHwgICAg IHwgICstLTooZm9yd2FyZGluZy1hZGphY2VuY3kpDQoNCiAgIHwgICAgIHwgICAgICstLXJ3IGZv cndhcmRpbmctYWRqYWNlbmN5IQ0KDQogICB8ICAgICB8ICAgICAgICArLS1ydyBob2xkdGltZT8g ICAgICAgICAgICAgICB1aW50MzINCg0KICAgfCAgICAgfCAgICAgICAgKy0tcncgaW5jbHVkZS1p cHY2LXVuaWNhc3Q/ICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1ydyBiYWNrdXAtYmFuZHdpZHRo PyAgICAgICB1aW50MzINCg0KICAgfCAgICAgKy0tcncgbG9hZC1zaGFyZT8gICAgICAgICAgICAg dWludDMyDQoNCiAgIHwgICAgICstLXJ3IGJpZGlyZWN0aW9uYWwNCg0KICAgfCAgICAgICAgKy0t cncgYXNzb2NpYXRpb24NCg0KICAgfCAgICAgICAgICAgKy0tcncgaWQ/ICAgICAgICAgICAgICB1 aW50MzINCg0KICAgfCAgICAgICAgICAgKy0tcncgc291cmNlPyAgICAgICAgICBpbmV0OmlwLWFk ZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgZ2xvYmFsLXNvdXJjZT8gICBpbmV0OmlwLWFk ZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICBiaWRpci1hc3Nv Y2lhdGlvbi10eXBlDQoNCiAgICstLXJ3IGdsb2JhbC1jZmchDQoNClJlZ2FyZHMsDQpUYXJlaw0K DQpGcm9tOiBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPG1haWx0bzpsaXpoZW5iaW5A aHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDE0IGF0IDExOjEyIEFN DQpUbzogIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbXBsc10gtPC4tDogUmVnYXJkaW5n IGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgYW5kIGRyYWZ0LWNoZW4tbXBscy10 ZS15YW5nLWNmZy0wMA0KDQpIaSBNUExTZXIsDQpJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHlvdSBv ZiB0aGUgb3RoZXIgdHdvIFlhbmcgbW9kZWwgZHJhZnRzOiBkcmFmdC1jaGVuLW1wbHMtdGUteWFu Zy1jZmctMDAgYW5kIGRyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1vYW0tMDAuIFdlbGNvbWUgY29t bWVudHMgYW5kIGNvbGxhYm9yYXRpb24uDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4p DQoNCg0KDQoNCg0Kt6K8/sjLOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIExpemhlbmJpbg0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIxNMjVIDIyOjM0DQrK1bz+yMs6IHJn YW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT47IHRzYWFkQGNpc2NvLmNv bTxtYWlsdG86dHNhYWRAY2lzY28uY29tPjsgcnNhd2F5YUBjaXNjby5jb208bWFpbHRvOnJzYXdh eWFAY2lzY28uY29tPg0Ks63LzTogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Ctb3zOI6IFttcGxzXSBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0w MCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwDQoNCkhpIFJha2VzaCwgVGFyZWsg JiBSb2JlcnQsDQpJIGp1c3Qgc2F3IHlvdSBwcm9wb3NlZCB0aGUgZHJhZnQtZ2FuZGhpLW1wbHMt dGUteWFuZy1tb2RlbC0wMC4gSSB3b25kZXIgaWYgeW91IGFyZSBhd2FyZSBvZiB0aGUgZHJhZnQt Y2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIHdlIHByb3Bvc2VkIG9uIEF1Z3VzdCAxNS4gRnJvbSBv dXIgcG9pbnQgb2Ygdmlldywgd2UgYXJlIG5vdCBleHBlcmllbmNlZCBlbm91Z2ggdG8gcmVtaW5k IG91ciBNUExTZXJzIG9mIHRoZSBuZXcgZHJhZnQgdG8gcHJvcG9zZSBwb3NzaWJsZSBkaXNjdXNz aW9uIGFuZCBjb2xsYWJvcmF0aW9uLiBJIGNvbXBhcmVkIHRoZSB0d28gZHJhZnRzIGFzIGZvbGxv d3M6DQoxLiBUaGUgcG9zc2libGUgb3ZlcmxhcHBlZCBwYXJ0DQogICAgICBkcmFmdC1nYW5kaGkt bXBscy10ZS15YW5nLW1vZGVsLTAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCiAgICAgNC4xLiAgR2xvYmFsIE1QTFMt VEUgRGF0YSBNb2RlbCBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNCAgICAgICAt LT4gICAgICAgICBNUExTIFRFIEdsb2JhbCBDb25maWd1cmF0aW9uL1JTVlAtVEUgR2xvYmFsIENv bmZpZ3VyYXRpb24NCiAgICAgNC4yLiAgTVBMUy1URSBUdW5uZWwgSW50ZXJmYWNlIERhdGEgTW9k ZWwgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAgNiAgICAtLT4gICAgICAgICBSU1ZQLVRFIFR1bm5l bCBDb25maWd1cmF0aW9uDQogICAgIDQuMy4gIE1QTFMtVEUgVHVubmVsIExTUCBEYXRhIE1vZGVs IE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcgICAgICAtLT4gICAgICAgICBSU1ZQLVRF IFR1bm5lbCBDb25maWd1cmF0aW9uDQogICAgIDQuNC4gIE1QTFMtVEUgTGluayBEYXRhIE1vZGVs IE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDggICAgICAgIC0tPiAgICAgICAg IE1QTFMgVEUgTGluayBDb25maWd1cmF0aW9uL1JTVlAtVEUgSW50ZXJmYWNlIENvbmZpZ3VyYXRp b24NCjIuIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBkZWZpbmVzIGZvbGxvd2luZyBj b25maWd1cmF0aW9uIFlhbmcgYmV5b25kIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwt MDAuDQogICAgIDMuNC4gIEV4cGxpY2l0IFBhdGggQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgMy41LiAgUDJNUCBURSBMZWFmIExpc3QgQ29uZmln dXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAzLjkuICBDU1BGIENv bmZpZ3VyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQog ICAgIDMuMTAuIFAyTVAgVEUgVHVubmVsIFRlbXBsYXRlIENvbmZpZ3VyYXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDgNCjMuIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBoYXMgYWxy ZWFkeSBkZWZpbmVkIGFsbCBZYW5nIG1vZGVsIGZvciB0aGVzZSBsaXN0ZWQgY29uZmlndXJhdGlv biB3aGlsZSBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGxlYXZlcyBtYW55IFlh bmcgTW9kZWwgZGVmaW5pdGlvbiBhcyBzcGFjZXMuDQoNCkkgdGhpbmsgbWF5YmUgeW91IGFyZSBu b3QgYXdhcmUgb2YgdGhlIGV4aXN0aW5nIGRyYWZ0LiBJZiB5b3Ugd291bGQgbGlrZSB0byBjb29w ZXJhdGUgb24gdGhlIE1QTFMgVEUgWWFuZyBNb2RlbHMgZGVmaW5pdGlvbiwgd2UgYXJlIHZlcnkg Z2xhZCB0byBkaXNjdXNzIHdpdGggeW91IHRvIHRyeSB0byB1bmlmeSB0aGVzZSBZYW5nIG1vZGVs cy4NCg0KDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4pDQoNCg0KDQo= --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717USIDCWVEMBX08corp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I looked at both documents.  They both have some= good and some bad.  The hardest part in reconciling them will be that= they both have a very vendor-specific view of the world.  This is no surprise given the nature of the technology, a= nd I don=A1=AFt think it=A1=AFs unique to TE.  BGP will be at least as= hard to sort out.

 

I think we need to clearly delineate between standard= features, common features, and vendor-specific ones.  Standard featur= es might be scoped to anything that is both signaled and RFC=A1=AFd, e.g., [3209, 4420, 4875, 5712, 7308]. =

 

Common are things that may have different names and w= hich aren=A1=AFt signaled, but which are in use in many/most/all implementa= tions =A8C things like what one vendor calls =A1=AEautoroute announce=A1=AF and another calls =A1=AEigp shortcuts=A1=AF= .  Find a common name, or a way to use both, and build a model for the= subset of things that is most common across vendors.  This is a bit o= f a quagmire since different vendors will have different approaches to many details of common features, and it may be the most difficult part = of this whole exercise.

 

Vendor-specific things are just that =A8C things impl= emented in a particular way by only one vendor.  An example from Rober= t, Rakesh and Tarek=A1=AFs document might be attribute-sets, which may not have an obvious parallel in other vendors=A1=AF gear.  = If nothing else there needs to be someplace a vendor can append its own pro= prietary models.

 

In the end it may be more productive to do it this wa= y =A8C starting with a minimum set of obviouly common features and working = up =A8C than trying to reconcile two fully baked models with very different views of the world.

 

 

 

 

 

eric

 

 

 

 

From: = mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Thursday, October 16, 2014 9:34 AM
To: Lizhenbin; mpls@ietf.org
Subject: Re: [mpls] =B4=F0=B8=B4: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-ya= ng-cfg-00

 =

Hi Robin,

 =

Thanks for the reference= to the draft. We had a look at it. We are proposing a slightly different m= odel that introduces clear delineation between configuration, operational (= state), RPC (executional), and notifications for MPLS-TE tunnels, lsps, links, and global data:

 =

module= : mpls-te

 =   +--rw tunnels-cfg!

 =   +--rw lsps-cfg!

 =   +--rw links-cfg!

 =   +--rw global-cfg!

 =   +--ro tunnels-oper

 =   +--ro lsps-oper

 =   +--ro links-oper

 =   +--ro global-oper

rpcs:<= o:p>

 =   +---x tunnels-rpc    

 =   +---x lsps-rpc       

 =   +---x global-rpc     

 =   +---x links-rpc      

notifi= cations:

 =   +---n tunnels-notif    

 =   +---n lsps-notif       

 =   +---n links-notif      

 =   +---n global-notif 

 =

We also have a detailed = YANG model in-the-works (as per the above) and we=A1=AFre planning to inclu= de in the next update of the draft. For example, the tunnels YANG model loo= ks something like below.

 =

As for collaboration, ye= s, we are willing to consolidate our efforts with you to produce the IETF M= PLS-TE Yang model.

 =

module= : mpls-te

 =   +--rw tunnels-cfg!

 =   |  +--rw tunnel* [name type]

 =   |     +--rw name          &nb= sp;         string

 =   |     +--rw type          &nb= sp;         tunnel-type

 =   |     +--rw tunnel-id?        &nbs= p;     uint16

 =   |     +--rw description?        &n= bsp;   string

 =   |     +--rw destination* [address]

 =   |     |  +--rw address       = inet:ip-address

 =   |     |  +--rw path-option* [index]

 =   |     |     +--rw index      =       uint8

 =   |     |     +--rw (type)?<= /p>

 =   |     |     |  +--:(dynamic)=

 =   |     |     |  |  +--rw dynamic

 =   |     |     |  +--:(explicit)

 =   |     |     |     +--rw explicit

 =   |     |     |        +--= rw explicit-hoplist* [index]

 =   |     |     |          = +--rw index                 &n= bsp; uint8

 =   |     |     |          = +--rw explicit-hop-address?   hop-address-type<= /p>

 =   |     |     |          = +--rw explicit-hop-action?    hop-action-type

 =   |     |     +--rw igp-constraint<= /span>

 =   |     |     |  +--rw igp?    =       enumeration

 =   |     |     |  +--rw area-level?  = uint32

 =   |     |     +--rw verbatim?     &n= bsp;   boolean

 =   |     |     +--rw lockdown?     &n= bsp;   boolean

 =   |     +--rw lsp-cfg* [index]

 =   |     |  +--rw index         =     leafref

 =   |     |  +--rw source?        = ;   inet:ip-address

 =   |     |  +--rw fast-reroute?     boolea= n

 =   |     |  +--rw record-route?     boolea= n

 =   |     |  +--rw signaled-name?    string=

 =   |     |  +--rw priority

 =   |     |  |  +--rw setup?   uint8

 =   |     |  |  +--rw hold?    uint8

 =   |     |  +--rw affinity

 =   |     |  |  +--rw constraints* [action]=

 =   |     |  |     +--rw action   = ;     affinity-action-type

 =   |     |  |     +--rw constraint

 =   |     |  |        +--rw affin= ity-list* [name]

 =   |     |  |           +--= rw name    string

 =   |     |  +--rw path-selection

 =   |     |  |  +--rw cost-limit?   uint32<= o:p>

 =   |     |  |  +--rw hop-limit?    ui= nt32

 =   |     |  |  +--rw metric?     &nbs= p; path-metric-type

 =   |     |  |  +--rw tiebreaker?   path-ti= ebreaker-type

 =   |     |  +--rw bfd

 =   |     |  |  +--rw type?      =         bfd-type

 =   |     |  |  +--rw bringup-timeout?  &nb= sp; uint32

 =   |     |  |  +--rw dampening?    &n= bsp;     uint32

 =   |     |  |  +--rw encap-mode?     =     bfd-encap-mode-type

 =   |     |  |  +--rw fast-detect?    =     boolean

 =   |     |  |  +--rw lsp-ping=

 =   |     |  |  |  +--rw disable?  &nb= sp; boolean

 =   |     |  |  |  +--rw interval?   u= int32

 =   |     |  |  +--rw minimum-interval?   u= int32

 =   |     |  |  +--rw multiplier?     =     uint32

 =   |     |  +--rw logging-event* [event]<= /span>

 =   |     |     +--rw event    logging= -event-type

 =   |     +--rw (policy-routing)?

 =   |     |  +--:(forwarding-class)=

 =   |     |  |  +--rw forwarding-class

 =   |     |  |     +--rw class?   uint= 8

 =   |     |  +--:(forwarding-group)=

 =   |     |     +--rw forwarding-group

 =   |     |        +--rw classes* &nbs= p; uint8

 =   |     +--rw auto-bandwidth

 =   |     |  +--rw overflow-threshold?    u= int32

 =   |     |  +--rw overflow-limit?     = ;   uint8

 =   |     |  +--rw underflow-threshold?   uint32=

 =   |     |  +--rw underflow-limit?     &nb= sp; uint8

 =   |     |  +--rw collect-only?      =     boolean

 =   |     +--rw (announce-as)?

 =   |     |  +--:(autoroute)

 =   |     |  |  +--rw autoroute!

 =   |     |  |     +--rw include-ipv6-unica= st?   boolean

 =   |     |  |     +--rw (metric-type)?

 =   |     |  |        +--:(metric= )

 =   |     |  |        |  +--= rw metric?                 uint8

 =   |     |  |        +--:(relati= ve-metric)

 =   |     |  |        |  +--= rw relative-metric?        uint8

 =   |     |  |        +--:(absolu= te-metric)

 =   |     |  |           +--= rw absolute-metric?        uint8

 =   |     |  +--:(forwarding-adjacency)

 =   |     |     +--rw forwarding-adjacency!=

 =   |     |        +--rw holdtime? &nb= sp;             uint32

 =   |     |        +--rw include-ipv6-= unicast?   boolean

 =   |     +--rw backup-bandwidth?       uin= t32

 =   |     +--rw load-share?         &n= bsp;   uint32

 =   |     +--rw bidirectional

 =   |        +--rw association=

 =   |           +--rw id?    &nbs= p;         uint32

 =   |           +--rw source?    =       inet:ip-address

 =   |           +--rw global-source?  = inet:ip-address

 =   |           +--rw type?    &n= bsp;       bidir-association-type

 =   +--rw global-cfg!

 =

Regards,

Tarek<= /p>

 =

From= : Lizhenbin <lizhenbin@huawei.com>
Date: Tuesday, October 14, 2014 at 11:12 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: [mpls] =B4=F0=B8=B4: Regarding draft-gandhi-mpls-te-yang-model-00 and d= raft-chen-mpls-te-yang-cfg-00

 =

Hi MPLSer,

I would like to remind= you of the other two Yang model drafts: draft-chen-mpls-te-yang-cfg-00 and= draft-zhang-mpls-tp-yang-oam-00. Welcome comments and collaboration.

 

Best Regards,

Zhenbin(Robin)<= span style=3D"color:black">

 

 

 

 

 

=B7= =A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.or= g] =B4=FA=B1=ED Lizhenbin
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C214=C8=D5 22:34
=CA=D5=BC=FE=C8=CB: rgandhi@cisco.com; tsaad@cisco.com; rsawaya@cisco.com
=B3=AD=CB=CD: mpls@ietf.org
=D6=F7=CC=E2: [mpls] Regarding draft-gan= dhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

 

Hi Rakesh, Tarek & R= obert,

I just saw you proposed = the draft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the dr= aft-chen-mpls-te-yang-cfg-00 we proposed on August 15. From our point of vi= ew, we are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and col= laboration. I compared the two drafts as follows:

1. The possible overlapp= ed part

    =   draft-gandhi-mpls-te-yang-model-00     &nbs= p;            &= nbsp;           &nbs= p;       draft-chen-mpls-te-yang-cfg-00<= /o:p>

    = 4.1.  Global MPLS-TE Data Model Overview . . . . . . . . . . . . = ; 4       -->     = ;    MPLS TE Global Configuration/RSVP-TE Global Configurati= on

    =  4.2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .=   6    -->        = ; RSVP-TE Tunnel Configuration 

    =  4.3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .=   7      -->     =     RSVP-TE Tunnel Configuration 

    =  4.4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .=   8        -->   =       MPLS TE Link Configuration/RSVP-TE Interface= Configuration 

2. draft-chen-mpls-te-ya= ng-cfg-00 defines following configuration Yang beyond draft-gandhi-mpls-te-= yang-model-00.

    = 3.4.  Explicit Path Configuration . . . . . . . . . . . . . . . =   5

    = 3.5.  P2MP TE Leaf List Configuration . . . . . . . . . . . . . =   5

    = 3.9.  CSPF Configuration  . . . . . . . . . . . . . . . . . . .&= nbsp;  8

    = 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . .  = ; 8

3. draft-chen-mpls-te-ya= ng-cfg-00 has already defined all Yang model for these listed configuration= while draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition= as spaces.

 =

I think maybe you are no= t aware of the existing draft. If you would like to cooperate on the MPLS T= E Yang Models definition, we are very glad to discuss with you to try to un= ify these Yang models.

 =

 =

 =

Best Regards,=

Zhenbin(Robin)

 

 =

--_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717USIDCWVEMBX08corp_-- From nobody Thu Oct 16 12:25:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065811A8860 for ; Thu, 16 Oct 2014 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d6Ic0jOd0Hi for ; Thu, 16 Oct 2014 12:25:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF0D1A8861 for ; Thu, 16 Oct 2014 12:25:05 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB617.namprd05.prod.outlook.com (10.141.198.139) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 19:25:04 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 19:25:02 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 19:25:02 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/Xpwyy8CAgABpwqA= Date: Thu, 16 Oct 2014 19:25:02 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: <543FBEBD.4010908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB636;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51444003)(189002)(199003)(13464003)(377454003)(101416001)(230783001)(74316001)(110136001)(120916001)(46102003)(80022003)(85306004)(99396003)(108616004)(64706001)(76576001)(87936001)(20776003)(66066001)(4396001)(106356001)(2501002)(122556002)(33646002)(85852003)(106116001)(105586002)(2351001)(107046002)(95666004)(40100003)(50986999)(76482002)(31966008)(97736003)(92566001)(86362001)(21056001)(2656002)(76176999)(99286002)(19580395003)(19580405001)(54356999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB617; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AnCl39Dg8ko3uuN4KyBlNzQhwuo Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:25:08 -0000 MPLS working group; There have been a number of comments, both public and private, about whethe= r or not source labels are needed and/or worth the cost of implementing thi= s approach. It is clear that we need a discussion in public on the MPLS ema= il list of this issue. In principle this discussion could occur either befo= re or as part of the call for adoption. However, due to the strong interest= of several folks to focus on this issue, and the possibility that the outc= ome of this discussion might motivate changes to the document, I think that= we should have this discussion prior to the call for adoption.=20 I would like to therefore encourage MPLS participants to reply to Stewart's= email (and the few replies that have already occurred) and to continue thi= s discussion. The requirements and use cases for source labels, whether sou= rce labels are needed, what the cost of implementation would be, and altern= atives to satisfy the same use cases, are all explicitly topics that should= be considered (as well as any other issues that people feel is important i= n determining whether the MPLS WG should work on source labels).=20 In the hope of coming to a timely consensus, I would encourage people who h= ave opinions on this issue to respond within two weeks (by Friday October 3= 1).=20 Thanks, Ross -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Thursday, October 16, 2014 8:49 AM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Ross You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft. It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements. In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly. In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces. I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource. As such I think the IPR poll, and the imminent intention to adopt is premature. - Stewart From nobody Thu Oct 16 17:33:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E508D1A9061 for ; Thu, 16 Oct 2014 17:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSomyIxRlI1D for ; Thu, 16 Oct 2014 17:33:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440821A9045 for ; Thu, 16 Oct 2014 17:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2791; q=dns/txt; s=iport; t=1413506018; x=1414715618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kp4kXd/3yADjq3sp+YTegBYpMMu/s+fD+0jJq6H4G+A=; b=RbxlRucCdNdE6T7AOv+ur3R77oIgFNMm+Ugg6NdbCR18IkBpOZvvDJ9r zN/e63iF97bRtwSZgJFdDpdBtL04q6NuDQ+MJB39FGunKmvMhRCBF99ii 2ed0GOtKKOZr/XeYKyTil1QSLB3IQsIjsp1cySHYKq/Yna1I4NZG77rhI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAE5jQFStJV2d/2dsb2JhbABRCoJrI1NczBYKh00CgREWAX2EAgEBAQQBAQE3NAsMBAIBCBEEAQELCwkJBycLFAkIAgQBDQUIE4gjAQzLUwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj2IPBCcxBwYEgyOBHgWPY4IcoXSDd2yBBkKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,735,1406592000"; d="scan'208";a="363967728" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 17 Oct 2014 00:33:37 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9H0XbpV000895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 00:33:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 19:33:37 -0500 From: "Nobo Akiya (nobo)" To: "Stewart Bryant (stbryant)" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzH5KAgABrv8A= Date: Fri, 17 Oct 2014 00:33:37 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: <543FBEBD.4010908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8IgsQ7YnY1GlBapSCk3KNWKTIuk Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:33:40 -0000 Kudos to the authors of draft-chen-mpls-source-label for coming up with an = interesting solution. However, I agree with Stewart. The Introduction only specifies that "perfor= mance monitoring" is the only concrete requirement for this solution. From = "performance monitoring" perspective, the proposed only provides a solution= to limited [1] LSP types (and UHP/PHP of them) and [2] granularity of meas= urements.=20 For example, let's say node A has X number of Segment Routing steered path = to node B. Even assuming that measurement is to be taken per steered path b= asis, there needs to be X number of labels for node B to keep statistics on= . The number of required labels can increase quite fast with increasing num= ber of devices x number of paths x level of measurement granularity. I think it is a good idea to take a step back and discuss the problem scope= . Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > (stbryant) > Sent: Thursday, October 16, 2014 8:49 AM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source- > label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Ross >=20 > You state that you are starting an IPR poll with a view to determining > whether this draft is ready for adoption as a WG draft. >=20 > It is my view that it is premature to adopt a solution draft such as this > without first achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardwar= e re- > spin and will consume a precious 0..15 reserved label which is something > that we should not do lightly. >=20 > In addition I am not convinced that the full set of requirements are take= n > into account in the proposed design. For example the solution only > proposes to identify the source LSR, whereas it seems likely that a finer > granularity of flow identification will be needed in practice. Additional= ly in > the only use case cited (performance monitoring) it seems likely that > accounting demarcation will be be needed to allow for different delays of > the ECMP paths and the distribution of packets across multiple receiver > interfaces. >=20 > I think that we need to backup the process and start by agreeing the set = of > requirements before we embark on a design which will be expensive in > MPLS protocol and implementation resource. >=20 > As such I think the IPR poll, and the imminent intention to adopt is > premature. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 18:22:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78F61A1BB5; Thu, 16 Oct 2014 18:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwS8vJvnu2I5; Thu, 16 Oct 2014 18:22:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69901A1BA4; Thu, 16 Oct 2014 18:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36798; q=dns/txt; s=iport; t=1413508954; x=1414718554; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UuyHF9kCyaHvMRiNw0Q940Y59FmqF0AbdBUUIJtsPyU=; b=WC93kCdhZ6hDhPA/EwkgehsQppNvnVacRyu2KDC6OT53cM8KT4+MOGLX hP5Wdc25YmQZOPzGSl+w3jF35Wqr0LcJjuG5Mr9b4+LiFgLq7YZfwzFfh AnpKk8IBS0mgaarNBUb/GyQzArtCUZbXZ8QDcAFDUBmAtltoHJ017VAQ/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABduQFStJA2D/2dsb2JhbABbgkgjI1NcyjKBZAEJh00CgRIWAX2EAgEBAQMBAQEBKkEJAgUHBAIBCA4DBAEBCxYBBgcnCxQIAQgCBAENBQgBiCEDCQgBDMtTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF44ZggMtBAYBBgODJIEeBY9jghyERohCPIMKjSiDfoIGGIFZbIEIJByBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,735,1406592000"; d="scan'208,217"; a="87735706" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 17 Oct 2014 01:22:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9H1MXMl031672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 01:22:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 20:22:32 -0500 From: "Nobo Akiya (nobo)" To: Ronald Bonica , Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/S+Gv5QLnD300KRpmKZHU+QY5wwGbuwgANMhQCAAA+ykA== Date: Fri, 17 Oct 2014 01:22:32 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.22] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/28mUCtl7bzODe934Q3ldjHhIGTQ Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:22:39 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Thanks for your response. Please see in-line with [NOBO]. From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: Thursday, October 16, 2014 2:44 PM To: Nobo Akiya (nobo); Gregory Mirsky; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Nobo, Thanks for reviewing this document. Comments inline..... Ron Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. [RPB] LSP Self-ping is an extremely lightweight mechanism that verifies the avail= ability of the data plane. It does not verify that the LSP follows the ERO,= or even that it terminates on the correct egress LSR. [NOBO] "verifies the availability of the data plane" depends on which data = plane you are referring to. The proposed verifies the IP data plane from so= me nodes to self, which some node could the egress LSR. The proposed does n= ot verify the availability of the LSP (i.e. MPLS data plane), which I belie= ve is the verification that the proposal is trying to provide. In Section 3: [snip] By contrast, LSP Self-ping does not consume any control plane resources at the egress LSR, and relies solely on the data plane of the egress LSR, making it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs. [snip] It might be beneficial to clarify above text that the proposed attempts to = check the LSP readiness but has limitations as described previously. In the rare cases when the LSP has been programmed incorrectly, it is appro= priate to invoke heavier-weight diagnostic tools. [NOBO] It is also those "rare cases" that causes some of the biggest issue= s in networks. If something similar (i.e. light weight and quick) can be do= ne truly in-band to catch even those "rare cases", then I think that will b= e a good mechanism to [also] pursue. Thanks! -Nobo When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. [RPB] True. LSP Self-ping is not applicable for LDP independent mode. Ron Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-= case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

Thanks for your response. Please see in-line with [NOBO]= .

 <= /p>

From: Ronald Bonica [mailto:rbonica@juniper.net]
Sent: Thursday, October 16, 2014 2:44 PM
To: Nobo Akiya (nobo); Gregory Mirsky; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Nobo,

 = ;

Thanks for= reviewing this document. Comments inline…..

 = ;

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Ron

 = ;

 = ;

 <= /p>

Destination address havin= g a valid IP address (i.e. address of ingress LSR) means that this probe wi= ll come back to the ingress LSR when:

- transit LSR false pops = and forwards (due to incorrect label programming)

- transit LSR false forwa= rds elsewhere and happens to terminates at some other network nodes via dif= ferent LSP (due to incorrect label programming)

 <= /p>

Certain packets over such= LSP (ex: VPN) will likely get dropped even though proposed probe reports s= uccess, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.

 

[RPB]

LSP Self-ping is an= extremely lightweight mechanism that verifies the availability of the data= plane. It does not verify that the LSP follows the ERO, or even that it terminates on the correct egress LSR.

 

[NOBO] “verifies the availability of the data plan= e” depends on which data plane you are referring to. The proposed ver= ifies the IP data plane from some nodes to self, which some node could the egress LSR. The proposed does not verify the availability of the LSP (= i.e. MPLS data plane), which I believe is the verification that the proposa= l is trying to provide.

 

In Section 3:

 

[snip]

   By contrast, LSP Self-ping does not consume a= ny control plane

   resources at the egress LSR, and relies solel= y on the data plane of

   the egress LSR, making it more suitable as a = tool for checking LSP

   readiness when dealing with a large number of= LSPs.

[snip]

 

It might be beneficial to clarify above text that the pr= oposed attempts to check the LSP readiness but has limitations as described= previously.

 

In the rare cases w= hen the LSP has been programmed incorrectly, it is appropriate to invoke he= avier-weight diagnostic tools.

 <= /p>

[NOBO]  It is also those “rare cases” t= hat causes some of the biggest issues in networks. If something similar (i.= e. light weight and quick) can be done truly in-band to catch even those “rare cases”, then I think that will be a good mechanism to [a= lso] pursue.

 

Thanks!

 

-Nobo

 <= /p>

When applied to the LDP i= ndependent mode, proposed probe will have the same “false positive= 221; issue with “end-to-end LSP not ready” case as well.

 

 

[RPB]

True. LSP Self-ping= is not applicable for LDP independent mode.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Ron=

 <= /p>

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Rtg-bfd [= mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

> -----Original Message-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_-- From nobody Thu Oct 16 19:08:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3A1A8820 for ; Thu, 16 Oct 2014 19:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXCAiCvAWZVB for ; Thu, 16 Oct 2014 19:08:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135CA1A9040 for ; Thu, 16 Oct 2014 19:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1462; q=dns/txt; s=iport; t=1413511685; x=1414721285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nn4tUiovZoyukng+F4ywiEPqjEIjEYL3XcuCAHAcQWo=; b=eZT8WZMYCwMhH+HctGKBNSmxkgwfZiEHE3kvWOMwJXyFDej5ooeqcnsc +kWOTbmF5ktrqBpxXNo4sYPMgnGou4jnPAnFjLCgfnkcpdMYpqpQ7s6XP ZKNielLmAztfbGgBgom3NUuTDxrs9y3EPfaaWg43v+Bvymenw7PnikaaT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOd4QFStJA2F/2dsb2JhbABbgw6BL9NtAoEUFgFyC4QDAQEEOjEDCw4CAgEIGAoUEBsXJQIEDgUIiDbLQwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEj2cRAR8xB4MtgR4Fj2OCHI0Ig0aNKIN+gjSBQ2yBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,735,1406592000"; d="scan'208";a="87747347" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 17 Oct 2014 02:08:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9H283UN024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 02:08:03 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.105]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 21:08:03 -0500 From: "Siva Sivabalan (msiva)" To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHBpZkBi75kT0K9jxl/yFthaJwzlDeAgAALoLA= Date: Fri, 17 Oct 2014 02:08:02 +0000 Message-ID: References: <542E752C.3020203@pi.nu> <543F820F.5000607@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5pszmW4P0eaaAdKE4j5dUA49C58 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:08:10 -0000 Support. -Siva On 2014-10-16, 4:30 AM, "Loa Andersson" wrote: >Folks, > >This adoption poll ends tomorrow - so far I have seen no responses to=20 >the poll. > >I don't want a number of mails "Support - as co-author!" But it would=20 >be good if you could encourage people to respond to the poll. > >/Loa > >On 2014-10-03 12:06, Loa Andersson wrote: >> Working Group, >> >> This is to start a two week poll on adopting >> draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >> >> Please send your comments (support/not support) to the mpls working=20 >> group mailing list (mpls@ietf.org). Please give a technical=20 >> motivation for your support/not support, especially if you think that=20 >> the document should not be adopted as a working group document. >> >> There is no IPR disclosures against this document. >> >> The authors has all stated on the working group mailing list that=20 >> they are unaware of any IPR claims against this draft. >> >> However if you are on the the mpls working group mailing list and=20 >> aware of IPR that relates to this draft, the time to disclose this is=20 >> now. >> >> This poll ends October 17, 2014. >> >> /Loa >> >> for the MPLS wg co-chairs > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 16 19:33:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C251A8830 for ; Thu, 16 Oct 2014 19:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdUEX87DAxgY for ; Thu, 16 Oct 2014 19:33:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5C31A1BA4 for ; Thu, 16 Oct 2014 19:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1413513235; x=1414722835; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FA3H9UZJprYU/0Wp/RxfhFwS+LylLmA6yt6Zxq4sl1w=; b=PDMh2RsLhXu/V4GTRaHJYYoZr/yebNV+5enoo+u5LEyp861ek/nRkSAk DMfoJlBSUoG6bNpZF+BC+LTrPa61jCv8pi8/lc2R/PwLp9fWPvmJl8Wx+ urJ4w0PsaYtvHDeAh/tqGAVBN6/FStsjeQ22S8X9y/wyojrqbkdGXy9VU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADl/QFStJA2J/2dsb2JhbABbgw5TXMwWCodNAoEUFgFyC4QDAQEEAQEBNzEDCw4EAQgYHisMCyUCBA4FiD4NyyMBAQEBAQEBAQEBAQEBAQEBAQEBARQEBI9nEQFQB4RLBY9jghyLWIEwg0aNKIN+gjSBQ2yBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,735,1406592000"; d="scan'208";a="363996050" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2014 02:33:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9H2XsFZ026734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 02:33:54 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 21:33:54 -0500 From: "Rakesh Gandhi (rgandhi)" To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHBJANV1vL/pkiBLF8l8T4Gb5wzlDeAgAALoLCAABiaAA== Date: Fri, 17 Oct 2014 02:33:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.247.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AD94CA994E7E04E9A4E6378D75A6E23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Mrznl_vw9tBxPEa8_rchpTKmfP0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:33:57 -0000 Support. Thanks, Rakesh >> >>On 2014-10-03 12:06, Loa Andersson wrote: >>> Working Group, >>> >>> This is to start a two week poll on adopting >>> draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >>> >>> Please send your comments (support/not support) to the mpls working >>> group mailing list (mpls@ietf.org). Please give a technical >>> motivation for your support/not support, especially if you think that >>> the document should not be adopted as a working group document. >>> >>> There is no IPR disclosures against this document. >>> >>> The authors has all stated on the working group mailing list that >>> they are unaware of any IPR claims against this draft. >>> >>> However if you are on the the mpls working group mailing list and >>> aware of IPR that relates to this draft, the time to disclose this is >>> now. >>> >>> This poll ends October 17, 2014. >>> >>> /Loa >>> >>> for the MPLS wg co-chairs >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 19:41:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888661A9087 for ; Thu, 16 Oct 2014 19:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6gJJGx_xeUR for ; Thu, 16 Oct 2014 19:41:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F051A9028 for ; Thu, 16 Oct 2014 19:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4197; q=dns/txt; s=iport; t=1413513715; x=1414723315; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=W3q9n96K0KkthURe+2TBpk4oSz+i6lWyyKkHCVm2ruc=; b=WdlGgl6oz4jG16xCTcd08R6LggnDTGjs4mxVU7kxTeT3EznSzEPdhHFW zHpNoKnIkZ+aRpAi6glRyTqzMVhrX640M8VMEi09ek1JOxx7VEt0kWUKd VtYVhoFgPGMvfKF7q55Z665a8LU69lwGCm5ie/YGeWXAuRuECPjUpDmRB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABaBQFStJV2a/2dsb2JhbABbgw6BL9NtgRYWAX2ECQxtEgGBACcEAQ0FG4gjyzQBAQEBAQEBAwEBAQEBARyQTYRSBZF/i1iBMJBug36CNIFDbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,736,1406592000"; d="scan'208";a="363777227" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2014 02:41:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9H2fr9q012240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 02:41:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 21:41:53 -0500 From: "Kamran Raza (skraza)" To: "draft-kini-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , Loa Andersson Thread-Topic: My review comments [Re: MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt] Thread-Index: AQHP6bPocOqLv2SsbUuoaPWxTLW0ug== Date: Fri, 17 Oct 2014 02:41:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.246.166] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YVCgZRwkRbfqZIp9LavYLGs7NwQ Cc: "vishwas.manral@hp.com" , "mpls@ietf.org" , Curtis Villamizar Subject: [mpls] My review comments [Re: MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:41:57 -0000 I have reviewed the draft and here are my comments: - I have found this document useful as it puts forward a good case of use of EL in SR, as well as suggest EL procedures/algo for use in SR networks. - I have found some sections (introductory + solution) that require some cleanup / clarifications as per my per-section comments [ see below ]. - I believe that once author respin the rev that take care of cleanup/re-org as per review comments, this document could be adopted as a WG doc.=20 Following are my per-section detailed comments: =20 Section 1: Introduction: Although reader could infer the problem statement by reading other text in this section, IMO, this section needs to state the problem statement explicitly and clearly. For example, the last para talks about =B3A recommended solution=B2 without stating the problem explicitly. Section 3: In the Service chaining use case, it is easy to confuse as a reader/writer amongst =B3S=B2 (the LSR) vs =B3S1=B2 (Svc) vs =B3S2=B2 (Svc). The example = is further complicated as you are using notion SN to denote where =B3S=B2 is used as n= ode Segment Id of LSR-N. All this makes the description of label stack cluttered with too many Ss. I suggest using LSR I/E (or A/B) for src and dest LSRs, N1/N2 instead of S1/S2 service LSRs, F1 and F2 for respective service functions, and keep using SN for SID of node N. This means your example of becomes . =20 Section 4: - The title of this section is =B3Recommended EL Solution for SPRING=B2 .. Should it not be renamed something like =B3EL Procedures in SPRING=B2 ? - EL insertion algorithm needs to be bulletized or written in more readable form (Flowchart?). Section 5:=20 - As per my comment regarding section 4 title, the title needs renaming from =B3Options considered=B2 to something like =B3Discarded options for EL= in SPRING=B2 ?=20 - I am not sure but should this section be moved to Appendix ? - Or, should we not swap section 4 and 5 ? =8B i.e. first list all the options and why they were rejected, followed by the recommended one. =20 Section 8. Security considerations: - The section is empty and needs some contents. At minimum, it needs to state TBD to be addressed in later revisions. Thanks. =8B Kamran On 2014-10-14, 4:11 PM, "Markus Jork" wrote: >I have been asked to review draft-kini-mpls-spring-entropy-label-01 as >one of the MPLS-RT members. >=20 >The document is coherent and makes a good argument for why the entropy >label mechanism is useful and needed for SPRING. There are likely to be >networks for which this would be beneficial. > >Unfortunately, the nature of the problem and existing hardware >compatibility constraints don't lend themselves to very elegant >solutions. The proposed solution in section 4 pretty much screams >"compromise". But the following sections do a good job of describing the >design constraints and why other solutions were rejected. It will be >useful to keep this content in the document somewhere even in its final >version. > >I believe the document is ready for WG adoption. Though I think there are >a couple of small problems with the examples in section 5 that should be >corrected: > >1. Up to section 5.1, the example label stack includes a label S-SvcS2 >for the service at S2. But in all the following sections, this label is >dropped from the examples. I think it's best to leave this out in all of >the examples for brevity. > >2. In section 5.3, the first example is given as SS2, SD>. > That should be > >3. In section 5.4, the example is given as: > > "For the same Figure 1 above, if LSR P1 > needs to have the EL within a depth of 4, then the source LSR S > encoded label stack would be where > all the ELs would typically have the same value." > >That is leaving out the first hop SP1 from the stack (which means the EL >has to move up the stack). Also, only one EL is present. So why call it >EL2? > >-Markus > From nobody Thu Oct 16 19:42:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347C21A908D for ; Thu, 16 Oct 2014 19:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siC5XWG0hqPJ for ; Thu, 16 Oct 2014 19:42:38 -0700 (PDT) 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 E36F71A908F for ; Thu, 16 Oct 2014 19:42:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNS81990; Fri, 17 Oct 2014 02:42:30 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Oct 2014 03:42:29 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.123]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 17 Oct 2014 10:42:23 +0800 From: Vero Zheng To: Sam Aldrin , Loa Andersson Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHAiPdkRQ5xqkSYvkgYlvEZPpwejAgAgBUdanA= Date: Fri, 17 Oct 2014 02:42:23 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8D2445@SZXEMA504-MBS.china.huawei.com> References: <542E752C.3020203@pi.nu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hG0lZe7gTnPRNEBmq6FmEed6xxE Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:42:41 -0000 I agree with Sam this draft fills the missing piece in IPv6 LSP Ping. Support the adoption. Cheers, Vero > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Saturday, October 04, 2014 8:13 AM > To: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-raza-mpls-oam-ipv6-rao@tools.ietf.org > Subject: Re: [mpls] poll to see if we have support to make > draft-raza-mpls-oam-ipv6-rao an mpls wg doc >=20 > Support!! > It fills the missing piece in IPv6 support. >=20 > Sam >=20 > Sent from my iPhone >=20 > > On Oct 3, 2014, at 3:06 AM, Loa Andersson wrote: > > > > Working Group, > > > > This is to start a two week poll on adopting > > draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working > > group mailing list (mpls@ietf.org). Please give a technical motivation > > for your support/not support, especially if you think that the > > document should not be adopted as a working group document. > > > > There is no IPR disclosures against this document. > > > > The authors has all stated on the working group mailing list that they > > are unaware of any IPR claims against this draft. > > > > However if you are on the the mpls working group mailing list and > > aware of IPR that relates to this draft, the time to disclose this is > > now. > > > > This poll ends October 17, 2014. > > > > /Loa > > > > for the MPLS wg co-chairs > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 16 19:44:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D201A9087 for ; Thu, 16 Oct 2014 19:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXI4Hj4ZIN1W for ; Thu, 16 Oct 2014 19:44:14 -0700 (PDT) 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 AEE811A9028 for ; Thu, 16 Oct 2014 19:44:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNS82092; Fri, 17 Oct 2014 02:44:12 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Oct 2014 03:44:11 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 17 Oct 2014 10:44:07 +0800 From: Mach Chen To: "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgAFXHGA= Date: Fri, 17 Oct 2014 02:44:07 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: <543FBEBD.4010908@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lcGjE_8C5DH-f5IvvQ_-aJtjPKA Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 02:44:16 -0000 Hi Stewart, Thanks for raising this discussion! Please see my replies inline... > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 16, 2014 8:49 PM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.o= rg > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Ross >=20 > You state that you are starting an IPR poll with a view to determining wh= ether this > draft is ready for adoption as a WG draft. >=20 > It is my view that it is premature to adopt a solution draft such as this= without first > achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardwar= e re-spin > and will consume a precious 0..15 reserved label which is something that = we > should not do lightly. As Greg pointed out, Extended Special Purpose (ESP) label is also applicabl= e. I will let the WG to decide whether this solution deserves a 0..15 reser= ved label or an ESP label. No hardware re-spin is a good thing, but I don't think hardware re-spin is = a hurdle for accepting a solution in IETF. I always believe "no pain no gai= n".=20 >=20 > In addition I am not convinced that the full set of requirements are take= n into > account in the proposed design. For example the solution only proposes to > identify the source LSR, whereas it seems likely that a finer granularity= of flow > identification will be needed in practice. Additionally in the only use c= ase cited The solution does allow multiple Source Identifiers to be allocated and cor= related to an LSR, hence it could provide a finer granularity of flow ident= ification when needed. =20 > (performance monitoring) it seems likely that accounting demarcation will= be be > needed to allow for different delays of the ECMP paths and the distributi= on of > packets across multiple receiver interfaces. This document is talking about how to do source identification, accounting = demarcation is out of the scope although it is another important thing for = passive performance measurement, you may refer to: http://tools.ietf.org/ht= ml/draft-chen-ippm-coloring-based-ipfpm-framework-02, it proposed a way to = do accounting demarcation even with ECMP paths. >=20 > I think that we need to backup the process and start by agreeing the set = of > requirements before we embark on a design which will be expensive in MPLS > protocol and implementation resource. Given that RFC6374 is there, I think that the WG has made the agreement on = passive performance measurement.=20 And for MP2P and MP2MP based LSP, it's obviously that source identification= is needed when do passive performance measurement. So, IMHO, the requireme= nt is clear and straightforward. Best regards, Mach >=20 > As such I think the IPR poll, and the imminent intention to adopt is pre= mature. >=20 > - Stewart >=20 From nobody Thu Oct 16 20:10:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C221A9088 for ; Thu, 16 Oct 2014 20:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKaYoW5pEQbB for ; Thu, 16 Oct 2014 20:10:45 -0700 (PDT) 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 EACF51A1B65 for ; Thu, 16 Oct 2014 20:10:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNS84162; Fri, 17 Oct 2014 03:10:42 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Oct 2014 04:10:41 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Fri, 17 Oct 2014 11:10:34 +0800 From: Mach Chen To: Shahram Davari , "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgABeSoCAAAMqgIABEYJQ Date: Fri, 17 Oct 2014 03:10:33 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FGNQGJVm17KSb8RppAAmboPUVgg Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 03:10:52 -0000 HI Shahram, > Similarly in this case, if a service provider wants to use MPL S and do D= irect Loss > Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they ca= n > use MP2MP LDP LSPs. If I was a service provider, I will not buy this logic. It just like someon= e's son is not good at math, then you suggest him to replace the son with s= omeone else who is good at math :-) Best regards, Mach > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Friday, October 17, 2014 2:38 AM > To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > draft-chen-mpls-source-label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Hi, >=20 > This is similar to the Traffic Engineering argument. If a service provide= r wants to > use MPL S and do traffic Engineering then they should use P2P RSVP-TE LSP= s, > otherwise then can use MP2MP LDP LSPs. >=20 > Similarly in this case, if a service provider wants to use MPL S and do D= irect Loss > Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they ca= n > use MP2MP LDP LSPs. >=20 > Thanks > Shahram >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > Sent: Thursday, October 16, 2014 11:26 AM > To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > draft-chen-mpls-source-label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Hi, >=20 > I agree with Stewart. I am not convinced such a label is required. This d= raft adds > multiple labels to the label stack (makes the label stack much larger tha= n it > already is) and requires a respin of chips due to its special label handl= ing in the > data-plane. >=20 > An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM > from RFC6374. >=20 > So until a solid argument is put forward that existing solutions (ILM in = RFC 6374) > or possible other solutions not requiring HW change are not adequate, I t= hink it is > premature To adopt this draft. >=20 >=20 > Thanks > Shahram >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.o= rg > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Ross >=20 > You state that you are starting an IPR poll with a view to determining wh= ether this > draft is ready for adoption as a WG draft. >=20 > It is my view that it is premature to adopt a solution draft such as this= without first > achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardwar= e re-spin > and will consume a precious 0..15 reserved label which is something that = we > should not do lightly. >=20 > In addition I am not convinced that the full set of requirements are take= n into > account in the proposed design. For example the solution only proposes to > identify the source LSR, whereas it seems likely that a finer granularity= of flow > identification will be needed in practice. Additionally in the only use c= ase cited > (performance monitoring) it seems likely that accounting demarcation will= be be > needed to allow for different delays of the ECMP paths and the distributi= on of > packets across multiple receiver interfaces. >=20 > I think that we need to backup the process and start by agreeing the set = of > requirements before we embark on a design which will be expensive in MPLS > protocol and implementation resource. >=20 > As such I think the IPR poll, and the imminent intention to adopt is pre= mature. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 00:29:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D61A90FB for ; Fri, 17 Oct 2014 00:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4zFfUx2tbq5 for ; Fri, 17 Oct 2014 00:28:57 -0700 (PDT) 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 2F1381A90EE for ; Fri, 17 Oct 2014 00:28:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNT01408; Fri, 17 Oct 2014 07:28:55 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Oct 2014 08:28:54 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 17 Oct 2014 15:28:51 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "Stewart Bryant (stbryant)" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgADE3YCAALNMYA== Date: Fri, 17 Oct 2014 07:28:50 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lKN7BDEOOjCxK-KCy2KEqx7Cdvc Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 07:29:00 -0000 Hi Nobo, Thanks for your comments! Please see my replies inline... > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Friday, October 17, 2014 8:34 AM > To: Stewart Bryant (stbryant); Ross Callon; mpls@ietf.org; > draft-chen-mpls-source-label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Kudos to the authors of draft-chen-mpls-source-label for coming up with a= n > interesting solution. Thanks for your "kudos" :-) >=20 > However, I agree with Stewart. The Introduction only specifies that > "performance monitoring" is the only concrete requirement for this soluti= on. > From "performance monitoring" perspective, the proposed only provides a > solution to limited [1] LSP types (and UHP/PHP of them) and [2] granulari= ty of > measurements. The solution is intended to solve an existing real problem. We do not expec= t the solution that could apply to any scenario and solve future occur issu= es, although it may have the potentiality. This is also the tradition of IE= TF. >=20 > For example, let's say node A has X number of Segment Routing steered pat= h to > node B. Even assuming that measurement is to be taken per steered path ba= sis, > there needs to be X number of labels for node B to keep statistics on. Th= e > number of required labels can increase quite fast with increasing number = of > devices x number of paths x level of measurement granularity. Regarding the granularity, the Source Identifier (SI) is very similar to th= e situation of BFD discriminator (DISC). I think you would agree that the S= I and DISC themselves are not the issue. The crux is that how many flows/BF= D sessions you want to monitor/enable, and the hardware resource(e.g., time= rs) is the critical constraint.=20 Best regards, Mach >=20 > I think it is a good idea to take a step back and discuss the problem sco= pe. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > (stbryant) > > Sent: Thursday, October 16, 2014 8:49 AM > > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source- > > label@tools.ietf.org > > Cc: mpls-chairs@tools.ietf.org > > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > > Ross > > > > You state that you are starting an IPR poll with a view to determining > > whether this draft is ready for adoption as a WG draft. > > > > It is my view that it is premature to adopt a solution draft such as > > this without first achieving a common understanding of all the requirem= ents. > > In this particular case, the solution on the table will require a > > hardware re- spin and will consume a precious 0..15 reserved label > > which is something that we should not do lightly. > > > > In addition I am not convinced that the full set of requirements are > > taken into account in the proposed design. For example the solution > > only proposes to identify the source LSR, whereas it seems likely that > > a finer granularity of flow identification will be needed in practice. > > Additionally in the only use case cited (performance monitoring) it > > seems likely that accounting demarcation will be be needed to allow > > for different delays of the ECMP paths and the distribution of packets > > across multiple receiver interfaces. > > > > I think that we need to backup the process and start by agreeing the > > set of requirements before we embark on a design which will be > > expensive in MPLS protocol and implementation resource. > > > > As such I think the IPR poll, and the imminent intention to adopt is > > premature. > > > > - Stewart > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 03:15:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD01AC3BB for ; Fri, 17 Oct 2014 03:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObzFsTtkQxdD for ; Fri, 17 Oct 2014 03:15:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830A31AC3B6 for ; Fri, 17 Oct 2014 03:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14066; q=dns/txt; s=iport; t=1413540926; x=1414750526; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=E+eDmW6QizxeBJ1Bf37+5YJ9Tc/9W+a6dlJ07IxqMP4=; b=ZszjfyLAkMf5E/u43/bTqbTLQBDiQrJL6Y/UWiKDGNiOgUeThOLZDp18 kQc4WFmo1VWghDgKY1I1fcEjwdpPJhKk1ENxAJ1d5JFBvEwIuodBYjzg3 9RL5oJA9sTk8e96IWh7Ee9CvWG9WXC0Of+lzGIIGsoBmNPu6ZRn/oTeax c=; X-IronPort-AV: E=Sophos;i="5.04,738,1406592000"; d="scan'208,217";a="209887051" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Oct 2014 10:15:24 +0000 Received: from [10.61.163.179] ([10.61.163.179]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9HAFNFd029545; Fri, 17 Oct 2014 10:15:24 GMT Message-ID: <5440EC3D.2000902@cisco.com> Date: Fri, 17 Oct 2014 11:15:25 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrew G. Malis" , Gregory Mirsky References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504070902030407060603" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xSnicTIvG3GPvsOKxppct_InK-c Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 10:15:30 -0000 This is a multi-part message in MIME format. --------------090504070902030407060603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andy As urgent as you might feel the requirement, jumping to a solution without properly understanding the requirement just costs everyone time and money and at the end of the day may not deliver anything of use to the customer. If you have ECMP, which many networks do, and you have multiple core facing line cards at the egress you need other information besides the SA. Now you can declare this out of scope if the requirements say it is not needed. However whilst that may be the case for MW it is certainly needed in the core. Why do we assume that SA-DA measurement granularity is sufficient? Will you never be required to report on a finer granularity than that? Why do we need do this by introducing SA? Why not do it with some destination based approach? Why do we need to have the reserved labels, why not have a new FEC for delivery which always includes an SA as the next label? MW usually deploys systems that have highly restricted imposition capability, can we really afford to introduce three labels as Greg suggests? If you want to generate a traffic matrix, why would you not do this with IPFIX? Are there any other methods that can leverage control plane capabilities without the need to spin new h/w which would be required by the proposed dataplane change. - Stewart On 16/10/2014 18:06, Andrew G. Malis wrote: > Stewart, > > To add to Greg's response, in a vacuum, I would agree with your email. > Howver, there has already been considerable discussion on the mpls > list of real operational issues that this draft addresses, such as > packet loss in mobile backhaul networks using mp-to-p MPLS. This will > allow both the ability to measure loss ratios and also to generate > traffic matrices to see if judicial TE would improve things. Perhaps > this could be added to the draft, but the draft isn't being written as > an academic excercse, but to address networks issues. > > Cheers, > Andy > > > On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky > > wrote: > > Hi Stewart, > thank you for your interest in the proposal, detailed and thought > provoking comments. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com > ] > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org ; > draft-chen-mpls-source-label@tools.ietf.org > > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Ross > > You state that you are starting an IPR poll with a view to > determining whether this draft is ready for adoption as a WG draft. > > It is my view that it is premature to adopt a solution draft such > as this without first achieving a common understanding of all the > requirements. > In this particular case, the solution on the table will require a > hardware re-spin and will consume a precious 0..15 reserved label > which is something that we should not do lightly. > GIM>> With creation of the Extended Special Purpose Label space > SLI (Source Label Indicator) may well come be allocated from that > space, not from original 0...15. Though I agree, we must be > considerate and thorough when allocating (extended) special > purpose label, any label. > > In addition I am not convinced that the full set of requirements > are taken into account in the proposed design. For example the > solution only proposes to identify the source LSR, whereas it > seems likely that a finer granularity of flow identification will > be needed in practice. Additionally in the only use case cited > (performance monitoring) it seems likely that accounting > demarcation will be be needed to allow for different delays of the > ECMP paths and the distribution of packets across multiple > receiver interfaces. > GIM>> I believe that purpose of SL in OAM is not to uniquely > identify particular flow but only identify maintenance point, > whether as source of OAM test packets in case of active > measurements, or OAM observation point in case of passive > measurements. True MEP ID, as in RFC 6428, may be used but SL is > viewed by authors as lighter, more generic method that is > applicable not only to MPLS-TP but to other MPLS networks, > including IP/MPLS and Segment Routing with MPLS dataplane. > > I think that we need to backup the process and start by agreeing > the set of requirements before we embark on a design which will be > expensive in MPLS protocol and implementation resource. > > As such I think the IPR poll, and the imminent intention to adopt > is premature. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090504070902030407060603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Andy

As urgent as you might feel the requirement, jumping to a solution without properly understanding the requirement just costs everyone time and money and at the end of the day may not deliver anything of use to the customer.

If you have ECMP, which many networks do, and you have multiple core facing line cards at the egress you need other information besides the SA. Now you can declare this out of scope if the requirements say it is not needed. However whilst that may be the case for MW it is certainly needed in the core.

Why do we assume that SA-DA measurement granularity is sufficient? Will you never be required to report on a finer granularity than that?

Why do we need do this by introducing SA? Why not do it with some destination based approach?

Why do we need to have the reserved labels, why not have a new FEC for delivery which always includes an SA as the next label?

MW usually deploys systems that have highly restricted imposition capability, can we really afford to introduce three labels as Greg suggests?

If you want to generate a traffic matrix, why would you not do this with IPFIX? Are there any other methods that can leverage control plane capabilities without the need to spin new h/w which would be required by the proposed dataplane change.

- Stewart


On 16/10/2014 18:06, Andrew G. Malis wrote:
Stewart,

To add to Greg's response, in a vacuum, I would agree with your email. Howver, there has already been considerable discussion on the mpls list of real operational issues that this draft addresses, such as packet loss in mobile backhaul networks using mp-to-p MPLS. This will allow both the ability to measure loss ratios and also to generate traffic matrices to see if judicial TE would improve things. Perhaps this could be added to the draft, but the draft isn't being written as an academic excercse, but to address networks issues.

Cheers,
Andy


On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
Hi Stewart,
thank you for your interest in the proposal, detailed and thought provoking comments. Please find my notes in-lined and tagged GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft.

It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements.
In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly.
GIM>> With creation of the Extended Special Purpose Label space SLI (Source Label Indicator) may well come be allocated from that space, not from original 0...15. Though I agree, we must be considerate and thorough when allocating (extended) special purpose label, any label.

In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces.
GIM>> I believe that purpose of SL in OAM is not to uniquely identify particular flow but only identify maintenance point, whether as source of OAM test packets in case of active measurements, or OAM observation point in case of passive measurements. True MEP ID, as in RFC 6428, may be used but SL is viewed by authors as lighter, more generic method that is applicable not only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment Routing with MPLS dataplane.

I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource.

As such I think the IPR poll, and the  imminent intention to adopt is premature.

- Stewart


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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090504070902030407060603-- From nobody Fri Oct 17 03:21:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DE21AC3C1 for ; Fri, 17 Oct 2014 03:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjNDr8HcAw3G for ; Fri, 17 Oct 2014 03:21:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45471AC3C0 for ; Fri, 17 Oct 2014 03:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2973; q=dns/txt; s=iport; t=1413541293; x=1414750893; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1OdIdsv3SCd2VlV3KbOUN5S/EP9qToxJua4D012U2+c=; b=b0q4MEbheY2oAiVJ0NXS1z2wPOTmZkYtwyDuUbJWv5pMXtSiEk47xjlY DpOgkn/Yk1xtAP3DIc66d7if+/DSjhGaEuuhthJABhJZIZ6aFIk7CQKZR Leij7+P5pWA0b4Lz0vA3ZGOMDOLEYgKV82x3IlfkXhuVKLipVQ8gnMPAA c=; X-IronPort-AV: E=Sophos;i="5.04,738,1406592000"; d="scan'208";a="209892622" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Oct 2014 10:21:31 +0000 Received: from [10.61.163.179] ([10.61.163.179]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9HALTMW011962; Fri, 17 Oct 2014 10:21:30 GMT Message-ID: <5440EDAB.1010800@cisco.com> Date: Fri, 17 Oct 2014 11:21:31 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Jx7krF97BSeW9j7vrP-gagIGqpg Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 10:21:34 -0000 On 16/10/2014 17:33, Gregory Mirsky wrote: > Hi Stewart, > thank you for your interest in the proposal, detailed and thought provoking comments. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Ross > > You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft. > > It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly. > GIM>> With creation of the Extended Special Purpose Label space SLI (Source Label Indicator) may well come be allocated from that space, not from original 0...15. Though I agree, we must be considerate and thorough when allocating (extended) special purpose label, any label. SB> This adds three labels to the stack. Are we sure that the edge boxes can afford to do this? > > In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces. > GIM>> I believe that purpose of SL in OAM is not to uniquely identify particular flow but only identify maintenance point, whether as source of OAM test packets in case of active measurements, or OAM observation point in case of passive measurements. True MEP ID, as in RFC 6428, may be used but SL is viewed by authors as lighter, more generic method that is applicable not only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment Routing with MPLS dataplane. SB> SL on it's own is not sufficient to cope with ECMP. SB> Why do we need reserved labels? Why not a new FEC with dual labels? Stewart > > I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource. > > As such I think the IPR poll, and the imminent intention to adopt is premature. > > - Stewart > > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Oct 17 03:34:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C131AC3C0 for ; Fri, 17 Oct 2014 03:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRbi1EaPhiaK for ; Fri, 17 Oct 2014 03:34:41 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E546E1AC3CA for ; Fri, 17 Oct 2014 03:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3721; q=dns/txt; s=iport; t=1413542081; x=1414751681; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rlQE10i2uYbFSW69gqefFRhq9or3lAmWZszyaIrixWo=; b=V185+ly6eWKiTpaer7Zm7tGArXPpd5awISz20hpUbe7i8YBBH/wZTUPP lqSUA9Nx9RBbCglotyBx6S1aWInaIzwBUGGIKXxE+q8BwSkSP15RctKdS 6MaMIyQbFNLECNHlkEladpZDK++3FA3r9dvVQ0pyacbWIodFcU/+uUa3t s=; X-IronPort-AV: E=Sophos;i="5.04,738,1406592000"; d="scan'208";a="209935622" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Oct 2014 10:34:39 +0000 Received: from [10.61.163.179] ([10.61.163.179]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9HAYdxW003390; Fri, 17 Oct 2014 10:34:39 GMT Message-ID: <5440F0C0.4000400@cisco.com> Date: Fri, 17 Oct 2014 11:34:40 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mach Chen , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8nMF64bMWa7Nug46B3T17JXM4zI Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 10:34:43 -0000 On 17/10/2014 03:44, Mach Chen wrote: > Hi Stewart, > > Thanks for raising this discussion! > > Please see my replies inline... > >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Thursday, October 16, 2014 8:49 PM >> To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Ross >> >> You state that you are starting an IPR poll with a view to determining whether this >> draft is ready for adoption as a WG draft. >> >> It is my view that it is premature to adopt a solution draft such as this without first >> achieving a common understanding of all the requirements. >> In this particular case, the solution on the table will require a hardware re-spin >> and will consume a precious 0..15 reserved label which is something that we >> should not do lightly. > As Greg pointed out, Extended Special Purpose (ESP) label is also applicable. I will let the WG to decide whether this solution deserves a 0..15 reserved label or an ESP label. > > No hardware re-spin is a good thing, but I don't think hardware re-spin is a hurdle for accepting a solution in IETF. I always believe "no pain no gain". Setting aside the fact that SL on its work is insufficient in an ECMP case, and that a lot can be done with multiple delivery labels, a new FEC would mean that you did not need any reserved labels. >> In addition I am not convinced that the full set of requirements are taken into >> account in the proposed design. For example the solution only proposes to >> identify the source LSR, whereas it seems likely that a finer granularity of flow >> identification will be needed in practice. Additionally in the only use case cited > The solution does allow multiple Source Identifiers to be allocated and correlated to an LSR, hence it could provide a finer granularity of flow identification when needed. I agree you could have a source block, you could also have an additional label. > >> (performance monitoring) it seems likely that accounting demarcation will be be >> needed to allow for different delays of the ECMP paths and the distribution of >> packets across multiple receiver interfaces. > This document is talking about how to do source identification, accounting demarcation is out of the scope although it is another important thing for passive performance measurement, you may refer to: http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework-02, it proposed a way to do accounting demarcation even with ECMP paths. Indeed, but the question is whether we need one solution or two. > >> I think that we need to backup the process and start by agreeing the set of >> requirements before we embark on a design which will be expensive in MPLS >> protocol and implementation resource. > Given that RFC6374 is there, I think that the WG has made the agreement on passive performance measurement. > > And for MP2P and MP2MP based LSP, it's obviously that source identification is needed when do passive performance measurement. So, IMHO, the requirement is clear and straightforward. The requirement to do the measurement is there, but I remain unconvinced that the full set of requirements for the solution is on the table, nor am I yet convinced that the solution you propose is optimum. - Stewart > > Best regards, > Mach > >> As such I think the IPR poll, and the imminent intention to adopt is premature. >> >> - Stewart >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Oct 17 03:49:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E5B1AC3CC for ; Fri, 17 Oct 2014 03:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSB2zMbu3Y5y for ; Fri, 17 Oct 2014 03:49:17 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B70D1AC3C9 for ; Fri, 17 Oct 2014 03:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4782; q=dns/txt; s=iport; t=1413542957; x=1414752557; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8ML1fwy1b+NWS2IA349aBoxKmr/FTNFono3qfS72l5M=; b=A8UKPkmgcaTv2gBD6LDhC0Ms3paWhEgekVVuIf3T7gapDJp3BLF/fCM6 20LA5vlbTFOXihbzQdQ9c7+vDA0j8MU4YfJ2BWm7twy5zu+r0mTIoHFix 4jhS417xKfHFW3QmbBD5csilfJkmMTARjijOjJC9QrZh6LztSzivWXHIJ g=; X-IronPort-AV: E=Sophos;i="5.04,738,1406592000"; d="scan'208";a="209916899" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Oct 2014 10:49:15 +0000 Received: from [10.61.163.179] ([10.61.163.179]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9HAnFWV031952; Fri, 17 Oct 2014 10:49:15 GMT Message-ID: <5440F42C.1090401@cisco.com> Date: Fri, 17 Oct 2014 11:49:16 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mach Chen , Shahram Davari , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sjzhL405geJ_ZKciWGDpTgFgQgo Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 10:49:19 -0000 On 17/10/2014 04:10, Mach Chen wrote: > HI Shahram, > >> Similarly in this case, if a service provider wants to use MPL S and do Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they can >> use MP2MP LDP LSPs. > If I was a service provider, I will not buy this logic. It just like someone's son is not good at math, then you suggest him to replace the son with someone else who is good at math :-) Your opinion would depend on whether you were the son, a more capable child competing for the school/job, the parent, the parent of another child, the teacher, the maths quiz team captain, the admissions tutor, the employer..... Solutions meet requirements in a context, and the proposal is that we start by building a common understanding of the requirements before we jump to a solution. - Stewart > > Best regards, > Mach > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Hi, >> >> This is similar to the Traffic Engineering argument. If a service provider wants to >> use MPL S and do traffic Engineering then they should use P2P RSVP-TE LSPs, >> otherwise then can use MP2MP LDP LSPs. >> >> Similarly in this case, if a service provider wants to use MPL S and do Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they can >> use MP2MP LDP LSPs. >> >> Thanks >> Shahram >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Hi, >> >> I agree with Stewart. I am not convinced such a label is required. This draft adds >> multiple labels to the label stack (makes the label stack much larger than it >> already is) and requires a respin of chips due to its special label handling in the >> data-plane. >> >> An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM >> from RFC6374. >> >> So until a solid argument is put forward that existing solutions (ILM in RFC 6374) >> or possible other solutions not requiring HW change are not adequate, I think it is >> premature To adopt this draft. >> >> >> Thanks >> Shahram >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Ross >> >> You state that you are starting an IPR poll with a view to determining whether this >> draft is ready for adoption as a WG draft. >> >> It is my view that it is premature to adopt a solution draft such as this without first >> achieving a common understanding of all the requirements. >> In this particular case, the solution on the table will require a hardware re-spin >> and will consume a precious 0..15 reserved label which is something that we >> should not do lightly. >> >> In addition I am not convinced that the full set of requirements are taken into >> account in the proposed design. For example the solution only proposes to >> identify the source LSR, whereas it seems likely that a finer granularity of flow >> identification will be needed in practice. Additionally in the only use case cited >> (performance monitoring) it seems likely that accounting demarcation will be be >> needed to allow for different delays of the ECMP paths and the distribution of >> packets across multiple receiver interfaces. >> >> I think that we need to backup the process and start by agreeing the set of >> requirements before we embark on a design which will be expensive in MPLS >> protocol and implementation resource. >> >> As such I think the IPR poll, and the imminent intention to adopt is premature. >> >> - Stewart >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Oct 17 06:05:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2556C1ACD84 for ; Fri, 17 Oct 2014 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq5N_lzog8bT for ; Fri, 17 Oct 2014 06:05:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637A71ACD88 for ; Fri, 17 Oct 2014 06:05:53 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ea-5440ba5ed5d9 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 67.C2.25146.E5AB0445; Fri, 17 Oct 2014 08:42:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 09:05:46 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6A///4KUCAAXD2gP//6Y8w Date: Fri, 17 Oct 2014 13:05:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FA02@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> <5440EDAB.1010800@cisco.com> In-Reply-To: <5440EDAB.1010800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiG78LocQgxuN3BZztk5ksfh+aQmL xa2lK1kt/q64wmJx7ukcRgdWjym/N7J6LFnyk8njetNVdo8vlz+zBbBEcdmkpOZklqUW6dsl cGVsPXaYqeC2TMXM5Y0sDYzTxbsYOTgkBEwklu/K7GLkBDLFJC7cW88GYgsJHGWUmLJPu4uR C8hezihx5/ZRRpAEm4CRxIuNPewgCRGBK4wS+/+tZAdJMAvYStx5cg2sSBjInj7rLpgtImAn cXTxSTYI201i5sSHYDaLgKrEy3PHwGxeAV+JzztvMEFsu84ocfHICSaQ6zgFNCUaH1iD1DAC Xff91BomiF3iEreezGeCuFpAYsme88wQtqjEy8f/WCFsJYmPv+dD3aYjsWD3JzYIW1ti2cLX zBB7BSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgXF1TILNcQfjgk+W hxgFOBiVeHgXsDuECLEmlhVX5h5ilOZgURLn1ayeFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD UwoYJTtk/KRbXGQCEz3ftffafNF61HgsMURcfcMG7xMPV7Pcj+1XDXi84oaW389jfXNDnN+n fsm5sGDnzQtFPyINp0VFnmrqehvG9WaXVw6TpXeU7nGbTd0e/m2ijWrrHVYt9Tpbu1Vtn3/U ikeneiqOz7A9/2v+g7bI6JtsIcXXN23+em7HhlZeJZbijERDLeai4kQAY0EiL4wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gLqJTMfvxrkj_EBK8oTEkgIxp70 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:05:56 -0000 Hi Stewart, I recall that the question of SLI/SL impact on MPLS label stack depth was d= iscussed, probably in London. Yes, some nodes would not be able to support SLI/SL and thus would not adve= rtise SLC. I think that is no different from how ELI/EL and ELC case been h= andled. Regards, Greg -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Friday, October 17, 2014 3:22 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org; draft-chen-mpls-source-labe= l@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label On 16/10/2014 17:33, Gregory Mirsky wrote: > Hi Stewart, > thank you for your interest in the proposal, detailed and thought provoki= ng comments. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.o= rg > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Ross > > You state that you are starting an IPR poll with a view to determining wh= ether this draft is ready for adoption as a WG draft. > > It is my view that it is premature to adopt a solution draft such as this= without first achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardwar= e re-spin and will consume a precious 0..15 reserved label which is somethi= ng that we should not do lightly. > GIM>> With creation of the Extended Special Purpose Label space SLI (Sour= ce Label Indicator) may well come be allocated from that space, not from or= iginal 0...15. Though I agree, we must be considerate and thorough when all= ocating (extended) special purpose label, any label. SB> This adds three labels to the stack. Are we sure that the edge boxes=20 can afford to do this? > > In addition I am not convinced that the full set of requirements are take= n into account in the proposed design. For example the solution only propos= es to identify the source LSR, whereas it seems likely that a finer granula= rity of flow identification will be needed in practice. Additionally in the= only use case cited (performance monitoring) it seems likely that accounti= ng demarcation will be be needed to allow for different delays of the ECMP = paths and the distribution of packets across multiple receiver interfaces. > GIM>> I believe that purpose of SL in OAM is not to uniquely identify par= ticular flow but only identify maintenance point, whether as source of OAM = test packets in case of active measurements, or OAM observation point in ca= se of passive measurements. True MEP ID, as in RFC 6428, may be used but SL= is viewed by authors as lighter, more generic method that is applicable no= t only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment= Routing with MPLS dataplane. SB> SL on it's own is not sufficient to cope with ECMP. SB> Why do we need reserved labels? Why not a new FEC with dual labels? Stewart > > I think that we need to backup the process and start by agreeing the set = of requirements before we embark on a design which will be expensive in MPL= S protocol and implementation resource. > > As such I think the IPR poll, and the imminent intention to adopt is pre= mature. > > - Stewart > > > . > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Oct 17 06:35:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525B1ACDCD for ; Fri, 17 Oct 2014 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqjHhyruU8dl for ; Fri, 17 Oct 2014 06:35:50 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE1B1ACDC5 for ; Fri, 17 Oct 2014 06:35:50 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-44-5440c3d232a2 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.2E.05330.2D3C0445; Fri, 17 Oct 2014 09:22:58 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 09:35:48 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , "Andrew G. Malis" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6A///4KUCAAE+0gIABH46A///zMDA= Date: Fri, 17 Oct 2014 13:35:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FA93@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> <5440EC3D.2000902@cisco.com> In-Reply-To: <5440EC3D.2000902@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B85FA93eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyuXRPrO6lww4hBp826Ficfn6KzWLO1oks Ft8vLWGxuLV0JavF3xVXWCzOPZ3D6MDmMeX3RlaPnbPusnssWfKTyeN601V2jy+XP7MFsEZx 2aSk5mSWpRbp2yVwZfSs+8xcsGUXY8XH2dsZGxj3bGXsYuTgkBAwkVj4V7uLkRPIFJO4cG89 WxcjF4eQwFFGid65J5ggnOWMEtsO3mIGqWITMJJ4sbGHHcQWEQiTeLlrNjNIEbPAE0aJudvX gBUJC9hKTJ91lxGiyE7i6OKTbBC2n8SK+ffAalgEVCV2f+sHs3kFfCXunbvFDrFtHpPEjo2v wDZwCmhKLGiYDzaIEei+76fWMIHYzALiEreezGeCuFtAYsme88wQtqjEy8f/WCFsJYmPv+ez Q9TnS5x4fYgJYpmgxMmZT1gmMIrOQjJqFpKyWUjKZgFDiRnojPW79CFKFCWmdD9kh7A1JFrn zGVHFl/AyL6KkaO0OLUsN93IYBMjMEKPSbDp7mDc89LyEKMAB6MSD+8CdocQIdbEsuLK3EOM 0hwsSuK8s2rnBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgtM76MdWz1jB6Ta/Hf6dvTzPt d+lbm36tj+S6l23Vyhw8O/T9G1du7xlHnS0ytaMvXSzZELPCW0Eju0hrsVjda+7bX9N2rm9Y IfWy6/qeG4uOLFCzOtitcz9/W/zT2ZJut43m3nl8MHfWcV6pVO1Kvxszpl6tnF/xKuAIQ6Zc 0NGv3J0PhGRTlFiKMxINtZiLihMBHFeItbECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xShRGE3swOFS0PP328qHBIKx3TI Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:35:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B85FA93eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3Rld2FydCwNCklmIHRoZSBjYXNlIGlzIHdoZW4gRUNNUCBzZWdtZW50IGlzIGF0IHRoZSB2 ZXJ5IGluZ3Jlc3MgTFNSLCBhdCB0aGUgc291cmNlLCB0aGVuLCBJ4oCZZCBhc3N1bWUsIEVMSS9F TCB3aWxsIGJlIHVzZWQgYW5kIHRodXMgZWdyZXNzIGNhbiB1c2UgaXQgaW4gY29tYmluYXRpb24g d2l0aCBTTEkvU0wgdG8gaWRlbnRpZnkgdGhlIGFjdHVhbCBjb21wb25lbnQgb2YgdGhlIEVDTVAg c2VnbWVudCB0aGF0IGJlZW4gdHJhdmVyc2VkLg0KVHJ1ZSwgdGhhdCB3b3VsZCBhZGQgZXZlbiBt b3JlIGxhYmVscyB0byB0aGUgc3RhY2sgYnV0IGlmIGNlcnRhaW50eSwgYWJzb2x1dGUgY2VydGFp bnR5IGlzIHRoZSBwcmVlbWluZW50IHJlcXVpcmVtZW50LCB0aGVuIG9uZSB3aWxsIGFjY2VwdCB0 aGUgc29sdXRpb24uDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IFN0ZXdhcnQgQnJ5YW50IFttYWlsdG86c3Ri cnlhbnRAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDE3LCAyMDE0IDM6MTUgQU0N ClRvOiBBbmRyZXcgRy4gTWFsaXM7IEdyZWdvcnkgTWlyc2t5DQpDYzogUm9zcyBDYWxsb247IG1w bHNAaWV0Zi5vcmc7IGRyYWZ0LWNoZW4tbXBscy1zb3VyY2UtbGFiZWxAdG9vbHMuaWV0Zi5vcmc7 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIElQUiBwb2xs IGZvciBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsDQoNCkFuZHkNCg0KQXMgdXJnZW50IGFz IHlvdSBtaWdodCBmZWVsIHRoZSByZXF1aXJlbWVudCwganVtcGluZyB0byBhIHNvbHV0aW9uIHdp dGhvdXQgcHJvcGVybHkgdW5kZXJzdGFuZGluZyB0aGUgcmVxdWlyZW1lbnQganVzdCBjb3N0cyBl dmVyeW9uZSB0aW1lIGFuZCBtb25leSBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgZGF5IG1heSBub3Qg ZGVsaXZlciBhbnl0aGluZyBvZiB1c2UgdG8gdGhlIGN1c3RvbWVyLg0KDQpJZiB5b3UgaGF2ZSBF Q01QLCB3aGljaCBtYW55IG5ldHdvcmtzIGRvLCBhbmQgeW91IGhhdmUgbXVsdGlwbGUgY29yZSBm YWNpbmcgbGluZSBjYXJkcyBhdCB0aGUgZWdyZXNzIHlvdSBuZWVkIG90aGVyIGluZm9ybWF0aW9u IGJlc2lkZXMgdGhlIFNBLiBOb3cgeW91IGNhbiBkZWNsYXJlIHRoaXMgb3V0IG9mIHNjb3BlIGlm IHRoZSByZXF1aXJlbWVudHMgc2F5IGl0IGlzIG5vdCBuZWVkZWQuIEhvd2V2ZXIgd2hpbHN0IHRo YXQgbWF5IGJlIHRoZSBjYXNlIGZvciBNVyBpdCBpcyBjZXJ0YWlubHkgbmVlZGVkIGluIHRoZSBj b3JlLg0KDQpXaHkgZG8gd2UgYXNzdW1lIHRoYXQgU0EtREEgbWVhc3VyZW1lbnQgZ3JhbnVsYXJp dHkgaXMgc3VmZmljaWVudD8gV2lsbCB5b3UgbmV2ZXIgYmUgcmVxdWlyZWQgdG8gcmVwb3J0IG9u IGEgZmluZXIgZ3JhbnVsYXJpdHkgdGhhbiB0aGF0Pw0KDQpXaHkgZG8gd2UgbmVlZCBkbyB0aGlz IGJ5IGludHJvZHVjaW5nIFNBPyBXaHkgbm90IGRvIGl0IHdpdGggc29tZSBkZXN0aW5hdGlvbiBi YXNlZCBhcHByb2FjaD8NCg0KV2h5IGRvIHdlIG5lZWQgdG8gaGF2ZSB0aGUgcmVzZXJ2ZWQgbGFi ZWxzLCB3aHkgbm90IGhhdmUgYSBuZXcgRkVDIGZvciBkZWxpdmVyeSB3aGljaCBhbHdheXMgaW5j bHVkZXMgYW4gU0EgYXMgdGhlIG5leHQgbGFiZWw/DQoNCk1XIHVzdWFsbHkgZGVwbG95cyBzeXN0 ZW1zIHRoYXQgaGF2ZSBoaWdobHkgcmVzdHJpY3RlZCBpbXBvc2l0aW9uIGNhcGFiaWxpdHksIGNh biB3ZSByZWFsbHkgYWZmb3JkIHRvIGludHJvZHVjZSB0aHJlZSBsYWJlbHMgYXMgR3JlZyBzdWdn ZXN0cz8NCg0KSWYgeW91IHdhbnQgdG8gZ2VuZXJhdGUgYSB0cmFmZmljIG1hdHJpeCwgd2h5IHdv dWxkIHlvdSBub3QgZG8gdGhpcyB3aXRoIElQRklYPyBBcmUgdGhlcmUgYW55IG90aGVyIG1ldGhv ZHMgdGhhdCBjYW4gbGV2ZXJhZ2UgY29udHJvbCBwbGFuZSBjYXBhYmlsaXRpZXMgd2l0aG91dCB0 aGUgbmVlZCB0byBzcGluIG5ldyBoL3cgd2hpY2ggd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHBy b3Bvc2VkIGRhdGFwbGFuZSBjaGFuZ2UuDQoNCi0gU3Rld2FydA0KDQoNCk9uIDE2LzEwLzIwMTQg MTg6MDYsIEFuZHJldyBHLiBNYWxpcyB3cm90ZToNClN0ZXdhcnQsDQoNClRvIGFkZCB0byBHcmVn J3MgcmVzcG9uc2UsIGluIGEgdmFjdXVtLCBJIHdvdWxkIGFncmVlIHdpdGggeW91ciBlbWFpbC4g SG93dmVyLCB0aGVyZSBoYXMgYWxyZWFkeSBiZWVuIGNvbnNpZGVyYWJsZSBkaXNjdXNzaW9uIG9u IHRoZSBtcGxzIGxpc3Qgb2YgcmVhbCBvcGVyYXRpb25hbCBpc3N1ZXMgdGhhdCB0aGlzIGRyYWZ0 IGFkZHJlc3Nlcywgc3VjaCBhcyBwYWNrZXQgbG9zcyBpbiBtb2JpbGUgYmFja2hhdWwgbmV0d29y a3MgdXNpbmcgbXAtdG8tcCBNUExTLiBUaGlzIHdpbGwgYWxsb3cgYm90aCB0aGUgYWJpbGl0eSB0 byBtZWFzdXJlIGxvc3MgcmF0aW9zIGFuZCBhbHNvIHRvIGdlbmVyYXRlIHRyYWZmaWMgbWF0cmlj ZXMgdG8gc2VlIGlmIGp1ZGljaWFsIFRFIHdvdWxkIGltcHJvdmUgdGhpbmdzLiBQZXJoYXBzIHRo aXMgY291bGQgYmUgYWRkZWQgdG8gdGhlIGRyYWZ0LCBidXQgdGhlIGRyYWZ0IGlzbid0IGJlaW5n IHdyaXR0ZW4gYXMgYW4gYWNhZGVtaWMgZXhjZXJjc2UsIGJ1dCB0byBhZGRyZXNzIG5ldHdvcmtz IGlzc3Vlcy4NCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIFRodSwgT2N0IDE2LCAyMDE0IGF0IDY6 MzMgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRv OmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgU3Rld2FydCwNCnRoYW5r IHlvdSBmb3IgeW91ciBpbnRlcmVzdCBpbiB0aGUgcHJvcG9zYWwsIGRldGFpbGVkIGFuZCB0aG91 Z2h0IHByb3Zva2luZyBjb21tZW50cy4gUGxlYXNlIGZpbmQgbXkgbm90ZXMgaW4tbGluZWQgYW5k IHRhZ2dlZCBHSU0+Pi4NCg0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgIEdyZWcN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXdhcnQgQnJ5YW50IFttYWls dG86c3RicnlhbnRAY2lzY28uY29tPG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+XQ0KU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTYsIDIwMTQgNTo0OSBBTQ0KVG86IFJvc3MgQ2FsbG9uOyBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1s YWJlbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJlbEB0 b29scy5pZXRmLm9yZz4NCkNjOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIElQUiBwb2xsIGZv ciBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsDQoNClJvc3MNCg0KWW91IHN0YXRlIHRoYXQg eW91IGFyZSBzdGFydGluZyBhbiBJUFIgcG9sbCB3aXRoIGEgdmlldyB0byBkZXRlcm1pbmluZyB3 aGV0aGVyIHRoaXMgZHJhZnQgaXMgcmVhZHkgZm9yIGFkb3B0aW9uIGFzIGEgV0cgZHJhZnQuDQoN Ckl0IGlzIG15IHZpZXcgdGhhdCBpdCBpcyBwcmVtYXR1cmUgdG8gYWRvcHQgYSBzb2x1dGlvbiBk cmFmdCBzdWNoIGFzIHRoaXMgd2l0aG91dCBmaXJzdCBhY2hpZXZpbmcgYSBjb21tb24gdW5kZXJz dGFuZGluZyBvZiBhbGwgdGhlIHJlcXVpcmVtZW50cy4NCkluIHRoaXMgcGFydGljdWxhciBjYXNl LCB0aGUgc29sdXRpb24gb24gdGhlIHRhYmxlIHdpbGwgcmVxdWlyZSBhIGhhcmR3YXJlIHJlLXNw aW4gYW5kIHdpbGwgY29uc3VtZSBhIHByZWNpb3VzIDAuLjE1IHJlc2VydmVkIGxhYmVsIHdoaWNo IGlzIHNvbWV0aGluZyB0aGF0IHdlIHNob3VsZCBub3QgZG8gbGlnaHRseS4NCkdJTT4+IFdpdGgg Y3JlYXRpb24gb2YgdGhlIEV4dGVuZGVkIFNwZWNpYWwgUHVycG9zZSBMYWJlbCBzcGFjZSBTTEkg KFNvdXJjZSBMYWJlbCBJbmRpY2F0b3IpIG1heSB3ZWxsIGNvbWUgYmUgYWxsb2NhdGVkIGZyb20g dGhhdCBzcGFjZSwgbm90IGZyb20gb3JpZ2luYWwgMC4uLjE1LiBUaG91Z2ggSSBhZ3JlZSwgd2Ug bXVzdCBiZSBjb25zaWRlcmF0ZSBhbmQgdGhvcm91Z2ggd2hlbiBhbGxvY2F0aW5nIChleHRlbmRl ZCkgc3BlY2lhbCBwdXJwb3NlIGxhYmVsLCBhbnkgbGFiZWwuDQoNCkluIGFkZGl0aW9uIEkgYW0g bm90IGNvbnZpbmNlZCB0aGF0IHRoZSBmdWxsIHNldCBvZiByZXF1aXJlbWVudHMgYXJlIHRha2Vu IGludG8gYWNjb3VudCBpbiB0aGUgcHJvcG9zZWQgZGVzaWduLiBGb3IgZXhhbXBsZSB0aGUgc29s dXRpb24gb25seSBwcm9wb3NlcyB0byBpZGVudGlmeSB0aGUgc291cmNlIExTUiwgd2hlcmVhcyBp dCBzZWVtcyBsaWtlbHkgdGhhdCBhIGZpbmVyIGdyYW51bGFyaXR5IG9mIGZsb3cgaWRlbnRpZmlj YXRpb24gd2lsbCBiZSBuZWVkZWQgaW4gcHJhY3RpY2UuIEFkZGl0aW9uYWxseSBpbiB0aGUgb25s eSB1c2UgY2FzZSBjaXRlZCAocGVyZm9ybWFuY2UgbW9uaXRvcmluZykgaXQgc2VlbXMgbGlrZWx5 IHRoYXQgYWNjb3VudGluZyBkZW1hcmNhdGlvbiB3aWxsIGJlIGJlIG5lZWRlZCB0byBhbGxvdyBm b3IgZGlmZmVyZW50IGRlbGF5cyBvZiB0aGUgRUNNUCBwYXRocyBhbmQgdGhlIGRpc3RyaWJ1dGlv biBvZiBwYWNrZXRzIGFjcm9zcyBtdWx0aXBsZSByZWNlaXZlciBpbnRlcmZhY2VzLg0KR0lNPj4g SSBiZWxpZXZlIHRoYXQgcHVycG9zZSBvZiBTTCBpbiBPQU0gaXMgbm90IHRvIHVuaXF1ZWx5IGlk ZW50aWZ5IHBhcnRpY3VsYXIgZmxvdyBidXQgb25seSBpZGVudGlmeSBtYWludGVuYW5jZSBwb2lu dCwgd2hldGhlciBhcyBzb3VyY2Ugb2YgT0FNIHRlc3QgcGFja2V0cyBpbiBjYXNlIG9mIGFjdGl2 ZSBtZWFzdXJlbWVudHMsIG9yIE9BTSBvYnNlcnZhdGlvbiBwb2ludCBpbiBjYXNlIG9mIHBhc3Np dmUgbWVhc3VyZW1lbnRzLiBUcnVlIE1FUCBJRCwgYXMgaW4gUkZDIDY0MjgsIG1heSBiZSB1c2Vk IGJ1dCBTTCBpcyB2aWV3ZWQgYnkgYXV0aG9ycyBhcyBsaWdodGVyLCBtb3JlIGdlbmVyaWMgbWV0 aG9kIHRoYXQgaXMgYXBwbGljYWJsZSBub3Qgb25seSB0byBNUExTLVRQIGJ1dCB0byBvdGhlciBN UExTIG5ldHdvcmtzLCBpbmNsdWRpbmcgSVAvTVBMUyBhbmQgU2VnbWVudCBSb3V0aW5nIHdpdGgg TVBMUyBkYXRhcGxhbmUuDQoNCkkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGJhY2t1cCB0aGUgcHJv Y2VzcyBhbmQgc3RhcnQgYnkgYWdyZWVpbmcgdGhlIHNldCBvZiByZXF1aXJlbWVudHMgYmVmb3Jl IHdlIGVtYmFyayBvbiBhIGRlc2lnbiB3aGljaCB3aWxsIGJlIGV4cGVuc2l2ZSBpbiBNUExTIHBy b3RvY29sIGFuZCBpbXBsZW1lbnRhdGlvbiByZXNvdXJjZS4NCg0KQXMgc3VjaCBJIHRoaW5rIHRo ZSBJUFIgcG9sbCwgYW5kIHRoZSAgaW1taW5lbnQgaW50ZW50aW9uIHRvIGFkb3B0IGlzIHByZW1h dHVyZS4NCg0KLSBTdGV3YXJ0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQoNCg0KDQoNCg0KLS0NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoN Cg0KDQoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdh bC9jcmkvaW5kZXguaHRtbA0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B85FA93eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTdGV3YXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JZiB0aGUgY2FzZSBpcyB3aGVuIEVDTVAgc2VnbWVudCBpcyBhdCB0aGUgdmVyeSBp bmdyZXNzIExTUiwgYXQgdGhlIHNvdXJjZSwgdGhlbiwgSeKAmWQgYXNzdW1lLCBFTEkvRUwgd2ls bCBiZSB1c2VkIGFuZCB0aHVzIGVncmVzcyBjYW4gdXNlIGl0IGluIGNvbWJpbmF0aW9uDQogd2l0 aCBTTEkvU0wgdG8gaWRlbnRpZnkgdGhlIGFjdHVhbCBjb21wb25lbnQgb2YgdGhlIEVDTVAgc2Vn bWVudCB0aGF0IGJlZW4gdHJhdmVyc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U cnVlLCB0aGF0IHdvdWxkIGFkZCBldmVuIG1vcmUgbGFiZWxzIHRvIHRoZSBzdGFjayBidXQgaWYg Y2VydGFpbnR5LCBhYnNvbHV0ZSBjZXJ0YWludHkgaXMgdGhlIHByZWVtaW5lbnQgcmVxdWlyZW1l bnQsIHRoZW4gb25lIHdpbGwgYWNjZXB0IHRoZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0YnJ5YW50 QGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMTcsIDIwMTQg MzoxNSBBTTxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEcuIE1hbGlzOyBHcmVnb3J5IE1pcnNreTxi cj4NCjxiPkNjOjwvYj4gUm9zcyBDYWxsb247IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWNoZW4tbXBs cy1zb3VyY2UtbGFiZWxAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gSVBSIHBvbGwgZm9yIGRyYWZ0LWNoZW4t bXBscy1zb3VyY2UtbGFiZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5keTxicj4NCjxicj4NCkFzIHVyZ2VudCBhcyB5b3UgbWlnaHQgZmVl bCB0aGUgcmVxdWlyZW1lbnQsIGp1bXBpbmcgdG8gYSBzb2x1dGlvbiB3aXRob3V0IHByb3Blcmx5 IHVuZGVyc3RhbmRpbmcgdGhlIHJlcXVpcmVtZW50IGp1c3QgY29zdHMgZXZlcnlvbmUgdGltZSBh bmQgbW9uZXkgYW5kIGF0IHRoZSBlbmQgb2YgdGhlIGRheSBtYXkgbm90IGRlbGl2ZXIgYW55dGhp bmcgb2YgdXNlIHRvIHRoZSBjdXN0b21lci48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSBFQ01QLCB3 aGljaCBtYW55IG5ldHdvcmtzIGRvLCBhbmQgeW91IGhhdmUgbXVsdGlwbGUgY29yZSBmYWNpbmcg bGluZSBjYXJkcyBhdCB0aGUgZWdyZXNzIHlvdSBuZWVkIG90aGVyIGluZm9ybWF0aW9uIGJlc2lk ZXMgdGhlIFNBLiBOb3cgeW91IGNhbiBkZWNsYXJlIHRoaXMgb3V0IG9mIHNjb3BlIGlmIHRoZSBy ZXF1aXJlbWVudHMgc2F5IGl0IGlzIG5vdCBuZWVkZWQuIEhvd2V2ZXIgd2hpbHN0IHRoYXQgbWF5 IGJlIHRoZSBjYXNlDQogZm9yIE1XIGl0IGlzIGNlcnRhaW5seSBuZWVkZWQgaW4gdGhlIGNvcmUu PGJyPg0KPGJyPg0KV2h5IGRvIHdlIGFzc3VtZSB0aGF0IFNBLURBIG1lYXN1cmVtZW50IGdyYW51 bGFyaXR5IGlzIHN1ZmZpY2llbnQ/IFdpbGwgeW91IG5ldmVyIGJlIHJlcXVpcmVkIHRvIHJlcG9y dCBvbiBhIGZpbmVyIGdyYW51bGFyaXR5IHRoYW4gdGhhdD88YnI+DQo8YnI+DQpXaHkgZG8gd2Ug bmVlZCBkbyB0aGlzIGJ5IGludHJvZHVjaW5nIFNBPyBXaHkgbm90IGRvIGl0IHdpdGggc29tZSBk ZXN0aW5hdGlvbiBiYXNlZCBhcHByb2FjaD88YnI+DQo8YnI+DQpXaHkgZG8gd2UgbmVlZCB0byBo YXZlIHRoZSByZXNlcnZlZCBsYWJlbHMsIHdoeSBub3QgaGF2ZSBhIG5ldyBGRUMgZm9yIGRlbGl2 ZXJ5IHdoaWNoIGFsd2F5cyBpbmNsdWRlcyBhbiBTQSBhcyB0aGUgbmV4dCBsYWJlbD88YnI+DQo8 YnI+DQpNVyB1c3VhbGx5IGRlcGxveXMgc3lzdGVtcyB0aGF0IGhhdmUgaGlnaGx5IHJlc3RyaWN0 ZWQgaW1wb3NpdGlvbiBjYXBhYmlsaXR5LCBjYW4gd2UgcmVhbGx5IGFmZm9yZCB0byBpbnRyb2R1 Y2UgdGhyZWUgbGFiZWxzIGFzIEdyZWcgc3VnZ2VzdHM/PGJyPg0KPGJyPg0KSWYgeW91IHdhbnQg dG8gZ2VuZXJhdGUgYSB0cmFmZmljIG1hdHJpeCwgd2h5IHdvdWxkIHlvdSBub3QgZG8gdGhpcyB3 aXRoIElQRklYPyBBcmUgdGhlcmUgYW55IG90aGVyIG1ldGhvZHMgdGhhdCBjYW4gbGV2ZXJhZ2Ug Y29udHJvbCBwbGFuZSBjYXBhYmlsaXRpZXMgd2l0aG91dCB0aGUgbmVlZCB0byBzcGluIG5ldyBo L3cgd2hpY2ggd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHByb3Bvc2VkIGRhdGFwbGFuZSBjaGFu Z2UuPGJyPg0KPGJyPg0KLSBTdGV3YXJ0PGJyPg0KPGJyPg0KPGJyPg0KT24gMTYvMTAvMjAxNCAx ODowNiwgQW5kcmV3IEcuIE1hbGlzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGV3YXJ0LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFkZCB0byBHcmVnJ3MgcmVzcG9uc2UsIGluIGEg dmFjdXVtLCBJIHdvdWxkIGFncmVlIHdpdGggeW91ciBlbWFpbC4gSG93dmVyLCB0aGVyZSBoYXMg YWxyZWFkeSBiZWVuIGNvbnNpZGVyYWJsZSBkaXNjdXNzaW9uIG9uIHRoZSBtcGxzIGxpc3Qgb2Yg cmVhbCBvcGVyYXRpb25hbCBpc3N1ZXMgdGhhdCB0aGlzIGRyYWZ0IGFkZHJlc3Nlcywgc3VjaCBh cyBwYWNrZXQgbG9zcyBpbiBtb2JpbGUgYmFja2hhdWwNCiBuZXR3b3JrcyB1c2luZyBtcC10by1w IE1QTFMuIFRoaXMgd2lsbCBhbGxvdyBib3RoIHRoZSBhYmlsaXR5IHRvIG1lYXN1cmUgbG9zcyBy YXRpb3MgYW5kIGFsc28gdG8gZ2VuZXJhdGUgdHJhZmZpYyBtYXRyaWNlcyB0byBzZWUgaWYganVk aWNpYWwgVEUgd291bGQgaW1wcm92ZSB0aGluZ3MuIFBlcmhhcHMgdGhpcyBjb3VsZCBiZSBhZGRl ZCB0byB0aGUgZHJhZnQsIGJ1dCB0aGUgZHJhZnQgaXNuJ3QgYmVpbmcgd3JpdHRlbiBhcyBhbiBh Y2FkZW1pYw0KIGV4Y2VyY3NlLCBidXQgdG8gYWRkcmVzcyBuZXR3b3JrcyBpc3N1ZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIE9jdCAxNiwgMjAxNCBhdCA2OjMzIFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3Rld2FydCw8YnI+DQp0aGFuayB5b3UgZm9yIHlvdXIg aW50ZXJlc3QgaW4gdGhlIHByb3Bvc2FsLCBkZXRhaWxlZCBhbmQgdGhvdWdodCBwcm92b2tpbmcg Y29tbWVudHMuIFBsZWFzZSBmaW5kIG15IG5vdGVzIGluLWxpbmVkIGFuZCB0YWdnZWQgR0lNJmd0 OyZndDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlZ2FyZHMsPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBHcmVnPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBT dGV3YXJ0IEJyeWFudCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdGJyeWFudEBjaXNjby5jb20i PnN0YnJ5YW50QGNpc2NvLmNvbTwvYT5dPGJyPg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTYs IDIwMTQgNTo0OSBBTTxicj4NClRvOiBSb3NzIENhbGxvbjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtY2hlbi1t cGxzLXNvdXJjZS1sYWJlbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1jaGVuLW1wbHMtc291cmNl LWxhYmVsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4N ClN1YmplY3Q6IFJlOiBbbXBsc10gSVBSIHBvbGwgZm9yIGRyYWZ0LWNoZW4tbXBscy1zb3VyY2Ut bGFiZWw8YnI+DQo8YnI+DQpSb3NzPGJyPg0KPGJyPg0KWW91IHN0YXRlIHRoYXQgeW91IGFyZSBz dGFydGluZyBhbiBJUFIgcG9sbCB3aXRoIGEgdmlldyB0byBkZXRlcm1pbmluZyB3aGV0aGVyIHRo aXMgZHJhZnQgaXMgcmVhZHkgZm9yIGFkb3B0aW9uIGFzIGEgV0cgZHJhZnQuPGJyPg0KPGJyPg0K SXQgaXMgbXkgdmlldyB0aGF0IGl0IGlzIHByZW1hdHVyZSB0byBhZG9wdCBhIHNvbHV0aW9uIGRy YWZ0IHN1Y2ggYXMgdGhpcyB3aXRob3V0IGZpcnN0IGFjaGlldmluZyBhIGNvbW1vbiB1bmRlcnN0 YW5kaW5nIG9mIGFsbCB0aGUgcmVxdWlyZW1lbnRzLjxicj4NCkluIHRoaXMgcGFydGljdWxhciBj YXNlLCB0aGUgc29sdXRpb24gb24gdGhlIHRhYmxlIHdpbGwgcmVxdWlyZSBhIGhhcmR3YXJlIHJl LXNwaW4gYW5kIHdpbGwgY29uc3VtZSBhIHByZWNpb3VzIDAuLjE1IHJlc2VydmVkIGxhYmVsIHdo aWNoIGlzIHNvbWV0aGluZyB0aGF0IHdlIHNob3VsZCBub3QgZG8gbGlnaHRseS48YnI+DQpHSU0m Z3Q7Jmd0OyBXaXRoIGNyZWF0aW9uIG9mIHRoZSBFeHRlbmRlZCBTcGVjaWFsIFB1cnBvc2UgTGFi ZWwgc3BhY2UgU0xJIChTb3VyY2UgTGFiZWwgSW5kaWNhdG9yKSBtYXkgd2VsbCBjb21lIGJlIGFs bG9jYXRlZCBmcm9tIHRoYXQgc3BhY2UsIG5vdCBmcm9tIG9yaWdpbmFsIDAuLi4xNS4gVGhvdWdo IEkgYWdyZWUsIHdlIG11c3QgYmUgY29uc2lkZXJhdGUgYW5kIHRob3JvdWdoIHdoZW4gYWxsb2Nh dGluZyAoZXh0ZW5kZWQpIHNwZWNpYWwgcHVycG9zZQ0KIGxhYmVsLCBhbnkgbGFiZWwuPGJyPg0K PGJyPg0KSW4gYWRkaXRpb24gSSBhbSBub3QgY29udmluY2VkIHRoYXQgdGhlIGZ1bGwgc2V0IG9m IHJlcXVpcmVtZW50cyBhcmUgdGFrZW4gaW50byBhY2NvdW50IGluIHRoZSBwcm9wb3NlZCBkZXNp Z24uIEZvciBleGFtcGxlIHRoZSBzb2x1dGlvbiBvbmx5IHByb3Bvc2VzIHRvIGlkZW50aWZ5IHRo ZSBzb3VyY2UgTFNSLCB3aGVyZWFzIGl0IHNlZW1zIGxpa2VseSB0aGF0IGEgZmluZXIgZ3JhbnVs YXJpdHkgb2YgZmxvdyBpZGVudGlmaWNhdGlvbiB3aWxsIGJlDQogbmVlZGVkIGluIHByYWN0aWNl LiBBZGRpdGlvbmFsbHkgaW4gdGhlIG9ubHkgdXNlIGNhc2UgY2l0ZWQgKHBlcmZvcm1hbmNlIG1v bml0b3JpbmcpIGl0IHNlZW1zIGxpa2VseSB0aGF0IGFjY291bnRpbmcgZGVtYXJjYXRpb24gd2ls bCBiZSBiZSBuZWVkZWQgdG8gYWxsb3cgZm9yIGRpZmZlcmVudCBkZWxheXMgb2YgdGhlIEVDTVAg cGF0aHMgYW5kIHRoZSBkaXN0cmlidXRpb24gb2YgcGFja2V0cyBhY3Jvc3MgbXVsdGlwbGUgcmVj ZWl2ZXIgaW50ZXJmYWNlcy48YnI+DQpHSU0mZ3Q7Jmd0OyBJIGJlbGlldmUgdGhhdCBwdXJwb3Nl IG9mIFNMIGluIE9BTSBpcyBub3QgdG8gdW5pcXVlbHkgaWRlbnRpZnkgcGFydGljdWxhciBmbG93 IGJ1dCBvbmx5IGlkZW50aWZ5IG1haW50ZW5hbmNlIHBvaW50LCB3aGV0aGVyIGFzIHNvdXJjZSBv ZiBPQU0gdGVzdCBwYWNrZXRzIGluIGNhc2Ugb2YgYWN0aXZlIG1lYXN1cmVtZW50cywgb3IgT0FN IG9ic2VydmF0aW9uIHBvaW50IGluIGNhc2Ugb2YgcGFzc2l2ZSBtZWFzdXJlbWVudHMuIFRydWUg TUVQDQogSUQsIGFzIGluIFJGQyA2NDI4LCBtYXkgYmUgdXNlZCBidXQgU0wgaXMgdmlld2VkIGJ5 IGF1dGhvcnMgYXMgbGlnaHRlciwgbW9yZSBnZW5lcmljIG1ldGhvZCB0aGF0IGlzIGFwcGxpY2Fi bGUgbm90IG9ubHkgdG8gTVBMUy1UUCBidXQgdG8gb3RoZXIgTVBMUyBuZXR3b3JrcywgaW5jbHVk aW5nIElQL01QTFMgYW5kIFNlZ21lbnQgUm91dGluZyB3aXRoIE1QTFMgZGF0YXBsYW5lLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHRo aW5rIHRoYXQgd2UgbmVlZCB0byBiYWNrdXAgdGhlIHByb2Nlc3MgYW5kIHN0YXJ0IGJ5IGFncmVl aW5nIHRoZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGJlZm9yZSB3ZSBlbWJhcmsgb24gYSBkZXNpZ24g d2hpY2ggd2lsbCBiZSBleHBlbnNpdmUgaW4gTVBMUyBwcm90b2NvbCBhbmQgaW1wbGVtZW50YXRp b24gcmVzb3VyY2UuPGJyPg0KPGJyPg0KQXMgc3VjaCBJIHRoaW5rIHRoZSBJUFIgcG9sbCwgYW5k IHRoZSZuYnNwOyBpbW1pbmVudCBpbnRlbnRpb24gdG8gYWRvcHQgaXMgcHJlbWF0dXJlLjxicj4N Cjxicj4NCi0gU3Rld2FydDxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86 PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2Fs L2NyaS9pbmRleC5odG1sIj5odHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVz aW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B85FA93eusaamb103erics_-- From nobody Fri Oct 17 06:59:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45001ACE10 for ; Fri, 17 Oct 2014 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRD4QdeyzhyD for ; Fri, 17 Oct 2014 06:59:49 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BF11ACE09 for ; Fri, 17 Oct 2014 06:59:49 -0700 (PDT) Received: from [192.168.0.110] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5C87F180131A; Fri, 17 Oct 2014 15:59:46 +0200 (CEST) Message-ID: <544120D1.6000303@pi.nu> Date: Fri, 17 Oct 2014 15:59:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/El-A7mn7uoT93kDYqy2irApD4fs Cc: "mpls-chairs@tools.ietf.org" , draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:59:51 -0000 Working Group, We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. The outcome is such that we anticipate a poll for working group adoption after the authors have updated the draft. Before we do poll to see if we have consensus to accept the document as a working group document we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are one IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 17 07:02:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5451A1A1D for ; Fri, 17 Oct 2014 07:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEMOuiMPxASy for ; Fri, 17 Oct 2014 07:02:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6815D1A0123 for ; Fri, 17 Oct 2014 07:02:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2DA4528653C0; Fri, 17 Oct 2014 14:02:25 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9HE2D9w016304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 16:02:26 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 16:02:17 +0200 From: "Henderickx, Wim (Wim)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: AQHP6hKmRMRAlr9AJkCkH81Bwlqtdpw0UcqA Date: Fri, 17 Oct 2014 14:02:17 +0000 Message-ID: References: <544120D1.6000303@pi.nu> In-Reply-To: <544120D1.6000303@pi.nu> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AA431D67A071A4CBA802ED125A5801D@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cLNcOf2K_5G7CJrkeuQ1r-erI2Q Cc: "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:02:33 -0000 I am not aware of IPR related to this draft On 17/10/14 15:59, "Loa Andersson" wrote: >Working Group, > >We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. > >The outcome is such that we anticipate a poll for working group adoption >after the authors have updated the draft. > >Before we do poll to see if we have consensus to accept the document >as a working group document we want to do an IPR poll on the document. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- >label? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are one IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >(as MPLS WG co-chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 07:19:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB231A0055 for ; Fri, 17 Oct 2014 07:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-0CoTa8i-Ex for ; Fri, 17 Oct 2014 07:19:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8F11A001A for ; Fri, 17 Oct 2014 07:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22996; q=dns/txt; s=iport; t=1413555565; x=1414765165; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=57kyyx7hGfdw06f77mqWD49oOXnTBkRbGv0giUUAigE=; b=QBBIeoDP6u8k2OWEfYjGV6JMjBgNUeuoQOroUFkFYoWx/UFdqOZ/9aUn MX8WhfCqZW8OjFimI+IyRj9LOvlWM9eeatoeTAO21jBfY7ZVHrRxgudUp xNgKeh7PzPlZWotzOTkfFFwosKEDQ4Jhjgd9gMr/auhTJNM5krZBa4UhG Y=; X-IronPort-AV: E=Sophos;i="5.04,739,1406592000"; d="scan'208,217";a="214857243" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Oct 2014 14:19:23 +0000 Received: from [10.61.163.179] ([10.61.163.179]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9HEJMv1002691; Fri, 17 Oct 2014 14:19:22 GMT Message-ID: <5441256A.8030809@cisco.com> Date: Fri, 17 Oct 2014 15:19:22 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gregory Mirsky , "Andrew G. Malis" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85F1F3@eusaamb103.ericsson.se> <5440EC3D.2000902@cisco.com> <7347100B5761DC41A166AC17F22DF1121B85FA93@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85FA93@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------060603090400080200010900" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RsPjoi4bvt9mmwLY05So0PVFvqY Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:19:29 -0000 This is a multi-part message in MIME format. --------------060603090400080200010900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Greg, the interesting ECMP case is where it occurs at the egress and results in delivery to multiple line cards. However where ever it happens to get flow discontinuity that needs to be reconciled. In modern networks packet loss is so low that close to absolute certainty is surely the only case of interest? Or are you aiming this at a very course granularity of loss, in which case that needs to be made very clear early on the draft. Stewart On 17/10/2014 14:35, Gregory Mirsky wrote: > > Hi Stewart, > > If the case is when ECMP segment is at the very ingress LSR, at the > source, then, I’d assume, ELI/EL will be used and thus egress can use > it in combination with SLI/SL to identify the actual component of the > ECMP segment that been traversed. > > True, that would add even more labels to the stack but if certainty, > absolute certainty is the preeminent requirement, then one will accept > the solution. > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Friday, October 17, 2014 3:15 AM > *To:* Andrew G. Malis; Gregory Mirsky > *Cc:* Ross Callon; mpls@ietf.org; > draft-chen-mpls-source-label@tools.ietf.org; mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Andy > > As urgent as you might feel the requirement, jumping to a solution > without properly understanding the requirement just costs everyone > time and money and at the end of the day may not deliver anything of > use to the customer. > > If you have ECMP, which many networks do, and you have multiple core > facing line cards at the egress you need other information besides the > SA. Now you can declare this out of scope if the requirements say it > is not needed. However whilst that may be the case for MW it is > certainly needed in the core. > > Why do we assume that SA-DA measurement granularity is sufficient? > Will you never be required to report on a finer granularity than that? > > Why do we need do this by introducing SA? Why not do it with some > destination based approach? > > Why do we need to have the reserved labels, why not have a new FEC for > delivery which always includes an SA as the next label? > > MW usually deploys systems that have highly restricted imposition > capability, can we really afford to introduce three labels as Greg > suggests? > > If you want to generate a traffic matrix, why would you not do this > with IPFIX? Are there any other methods that can leverage control > plane capabilities without the need to spin new h/w which would be > required by the proposed dataplane change. > > - Stewart > > > On 16/10/2014 18:06, Andrew G. Malis wrote: > > Stewart, > > To add to Greg's response, in a vacuum, I would agree with your > email. Howver, there has already been considerable discussion on > the mpls list of real operational issues that this draft > addresses, such as packet loss in mobile backhaul networks using > mp-to-p MPLS. This will allow both the ability to measure loss > ratios and also to generate traffic matrices to see if judicial TE > would improve things. Perhaps this could be added to the draft, > but the draft isn't being written as an academic excercse, but to > address networks issues. > > Cheers, > > Andy > > On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky > > > wrote: > > Hi Stewart, > thank you for your interest in the proposal, detailed and thought > provoking comments. Please find my notes in-lined and tagged GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com > ] > Sent: Thursday, October 16, 2014 5:49 AM > To: Ross Callon; mpls@ietf.org ; > draft-chen-mpls-source-label@tools.ietf.org > > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > Ross > > You state that you are starting an IPR poll with a view to > determining whether this draft is ready for adoption as a WG draft. > > It is my view that it is premature to adopt a solution draft such > as this without first achieving a common understanding of all the > requirements. > In this particular case, the solution on the table will require a > hardware re-spin and will consume a precious 0..15 reserved label > which is something that we should not do lightly. > GIM>> With creation of the Extended Special Purpose Label space > SLI (Source Label Indicator) may well come be allocated from that > space, not from original 0...15. Though I agree, we must be > considerate and thorough when allocating (extended) special > purpose label, any label. > > In addition I am not convinced that the full set of requirements > are taken into account in the proposed design. For example the > solution only proposes to identify the source LSR, whereas it > seems likely that a finer granularity of flow identification will > be needed in practice. Additionally in the only use case cited > (performance monitoring) it seems likely that accounting > demarcation will be be needed to allow for different delays of the > ECMP paths and the distribution of packets across multiple > receiver interfaces. > GIM>> I believe that purpose of SL in OAM is not to uniquely > identify particular flow but only identify maintenance point, > whether as source of OAM test packets in case of active > measurements, or OAM observation point in case of passive > measurements. True MEP ID, as in RFC 6428, may be used but SL is > viewed by authors as lighter, more generic method that is > applicable not only to MPLS-TP but to other MPLS networks, > including IP/MPLS and Segment Routing with MPLS dataplane. > > > I think that we need to backup the process and start by agreeing > the set of requirements before we embark on a design which will be > expensive in MPLS protocol and implementation resource. > > As such I think the IPR poll, and the imminent intention to adopt > is premature. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------060603090400080200010900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Greg, the interesting ECMP case is where it occurs at the egress and results
in delivery to multiple line cards. However where ever it happens to get
flow discontinuity that needs to be reconciled.

In modern networks packet loss is so low that close to absolute certainty
is surely the only case of interest?

Or are you aiming this at a very course granularity of loss, in which case
that needs to be made very clear early on the draft.

Stewart

On 17/10/2014 14:35, Gregory Mirsky wrote:

Hi Stewart,

If the case is when ECMP segment is at the very ingress LSR, at the source, then, I’d assume, ELI/EL will be used and thus egress can use it in combination with SLI/SL to identify the actual component of the ECMP segment that been traversed.

True, that would add even more labels to the stack but if certainty, absolute certainty is the preeminent requirement, then one will accept the solution.

 

                Regards,

                                Greg

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, October 17, 2014 3:15 AM
To: Andrew G. Malis; Gregory Mirsky
Cc: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

 

Andy

As urgent as you might feel the requirement, jumping to a solution without properly understanding the requirement just costs everyone time and money and at the end of the day may not deliver anything of use to the customer.

If you have ECMP, which many networks do, and you have multiple core facing line cards at the egress you need other information besides the SA. Now you can declare this out of scope if the requirements say it is not needed. However whilst that may be the case for MW it is certainly needed in the core.

Why do we assume that SA-DA measurement granularity is sufficient? Will you never be required to report on a finer granularity than that?

Why do we need do this by introducing SA? Why not do it with some destination based approach?

Why do we need to have the reserved labels, why not have a new FEC for delivery which always includes an SA as the next label?

MW usually deploys systems that have highly restricted imposition capability, can we really afford to introduce three labels as Greg suggests?

If you want to generate a traffic matrix, why would you not do this with IPFIX? Are there any other methods that can leverage control plane capabilities without the need to spin new h/w which would be required by the proposed dataplane change.

- Stewart


On 16/10/2014 18:06, Andrew G. Malis wrote:

Stewart,

 

To add to Greg's response, in a vacuum, I would agree with your email. Howver, there has already been considerable discussion on the mpls list of real operational issues that this draft addresses, such as packet loss in mobile backhaul networks using mp-to-p MPLS. This will allow both the ability to measure loss ratios and also to generate traffic matrices to see if judicial TE would improve things. Perhaps this could be added to the draft, but the draft isn't being written as an academic excercse, but to address networks issues.

 

Cheers,

Andy

 

 

On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Stewart,
thank you for your interest in the proposal, detailed and thought provoking comments. Please find my notes in-lined and tagged GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft.

It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements.
In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly.
GIM>> With creation of the Extended Special Purpose Label space SLI (Source Label Indicator) may well come be allocated from that space, not from original 0...15. Though I agree, we must be considerate and thorough when allocating (extended) special purpose label, any label.

In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces.
GIM>> I believe that purpose of SL in OAM is not to uniquely identify particular flow but only identify maintenance point, whether as source of OAM test packets in case of active measurements, or OAM observation point in case of passive measurements. True MEP ID, as in RFC 6428, may be used but SL is viewed by authors as lighter, more generic method that is applicable not only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment Routing with MPLS dataplane.


I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource.

As such I think the IPR poll, and the  imminent intention to adopt is premature.

- Stewart


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

 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------060603090400080200010900-- From nobody Fri Oct 17 07:34:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411D41A0079 for ; Fri, 17 Oct 2014 07:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWO3G_hO7Grc for ; Fri, 17 Oct 2014 07:32:51 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103C81A0047 for ; Fri, 17 Oct 2014 07:32:50 -0700 (PDT) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 17 Oct 2014 15:32:52 +0100 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.139]) by E07HT04-UKBR.domain1.systemhost.net ([193.113.197.162]) with mapi; Fri, 17 Oct 2014 15:32:54 +0100 From: To: , Date: Fri, 17 Oct 2014 15:32:48 +0100 Thread-Topic: IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: Ac/qFzzes6EbAWO0QrSQcdN42yYvYA== Message-ID: In-Reply-To: <544120D1.6000303@pi.nu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ws5aLWOqf0EYO3yXLAKTvEd05cg X-Mailman-Approved-At: Fri, 17 Oct 2014 07:34:06 -0700 Cc: mpls-chairs@tools.ietf.org, draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:32:53 -0000 Hi Loa, [17/10/2014 14:59, "Loa Andersson" ] >Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- >label? I=B9m not aware of any IPR other than the existing Huawei disclosure. Kind regards, r. From nobody Fri Oct 17 07:39:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7B1A010C for ; Fri, 17 Oct 2014 07:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SWYAjE_618e for ; Fri, 17 Oct 2014 07:39:30 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 535EF1A001B for ; Fri, 17 Oct 2014 07:39:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,739,1406617200"; d="scan'208";a="48697276" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 17 Oct 2014 08:59:51 -0700 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 07:39:32 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 07:39:30 -0700 From: Shahram Davari To: Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABLJSg= Date: Fri, 17 Oct 2014 14:39:30 +0000 Message-ID: <3FC3510F-D7BB-4445-B08F-94C4134BA94D@broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ky-DaopL__HjlDut_lJ0LF6W3co Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:39:32 -0000 Hi This is a funny example that does not represent my alternative solution. My example is solid as applies to TE case today and SPs are buying it. Othe= rwise why no SP has ever proposed to add TE to MP2P LSPs ? Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and do = Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they c= an >> use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like some= one's son is not good at math, then you suggest him to replace the son with= someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service provid= er wants to >> use MPL S and do traffic Engineering then they should use P2P RSVP-TE LS= Ps, >> otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and do = Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they c= an >> use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required. This = draft adds >> multiple labels to the label stack (makes the label stack much larger th= an it >> already is) and requires a respin of chips due to its special label hand= ling in the >> data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM >> from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM in= RFC 6374) >> or possible other solutions not requiring HW change are not adequate, I = think it is >> premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.= org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to determining w= hether this >> draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as thi= s without first >> achieving a common understanding of all the requirements. >> In this particular case, the solution on the table will require a hardwa= re re-spin >> and will consume a precious 0..15 reserved label which is something that= we >> should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are tak= en into >> account in the proposed design. For example the solution only proposes t= o >> identify the source LSR, whereas it seems likely that a finer granularit= y of flow >> identification will be needed in practice. Additionally in the only use = case cited >> (performance monitoring) it seems likely that accounting demarcation wil= l be be >> needed to allow for different delays of the ECMP paths and the distribut= ion of >> packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the set= of >> requirements before we embark on a design which will be expensive in MPL= S >> protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 08:19:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565551A0047 for ; Fri, 17 Oct 2014 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HVVTlHuJCzt for ; Fri, 17 Oct 2014 08:19:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF7E1A1A17 for ; Fri, 17 Oct 2014 08:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2250; q=dns/txt; s=iport; t=1413559170; x=1414768770; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vV846wyiMakrR8s7PMIwLYFf64QwYR9mcAtJ2L7PBBU=; b=eP8bRMrEupgriYks419Lb05FYRDSXm9e/r6ko/2g7UcqJaFxu7ANrKU9 SV7BKHHaO5nJc6FGG2NTJnJ6Q6POI0cGVFHVB5qBtJjG7j5cNDcOgorja 8nzt4XFsq1oZD4pQRcgNxR9FlU1DJ26wyNCcggGJwQxIDeTCDJGF4vrDI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFADAzQVStJA2E/2dsb2JhbABbgw5TWATMOAqHTgKBEBYBfYQCAQEBBAEBAWgDCwwCBAEIEQMBAQEoIgwLFAkIAgQBDQWIPw3McgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI9nEQFQBwaERQWSAItZgTCDRo0og36CNIFDbIEPOYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,739,1406592000"; d="scan'208";a="87925712" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 17 Oct 2014 15:19:29 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9HFJT42021671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 15:19:29 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.138]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 10:19:29 -0500 From: "Zafar Ali (zali)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHBJ1nSYjgapEiCQNDJEg+ITpwy0RaAgAG+V4A= Date: Fri, 17 Oct 2014 15:19:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.243.65] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8224C125F96BC34383C9F65C5B416DA7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uT_f_fNbIeHweOVgbEqtivFiqwk Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:19:49 -0000 Support!=20 Thanks Regards =8A Zafar -----Original Message----- From: Mach Chen Date: Thursday, October 16, 2014 4:45 AM To: Loa Andersson , "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc > > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Friday, October 03, 2014 6:07 PM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; >>draft-raza-mpls-oam-ipv6-rao@tools.ietf.org >> Subject: [mpls] poll to see if we have support to make >> draft-raza-mpls-oam-ipv6-rao an mpls wg doc >>=20 >> Working Group, >>=20 >> This is to start a two week poll on adopting >> draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >>=20 >> Please send your comments (support/not support) to the mpls working >>group >> mailing list (mpls@ietf.org). Please give a technical motivation for >>your >> support/not support, especially if you think that the document should >>not be >> adopted as a working group document. >>=20 >> There is no IPR disclosures against this document. >>=20 >> The authors has all stated on the working group mailing list that they >>are unaware >> of any IPR claims against this draft. >>=20 >> However if you are on the the mpls working group mailing list and aware >>of IPR >> that relates to this draft, the time to disclose this is now. >>=20 >> This poll ends October 17, 2014. >>=20 >> /Loa >>=20 >> for the MPLS wg co-chairs >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 08:45:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB961A1B70 for ; Fri, 17 Oct 2014 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chr4OEyz5_gp for ; Fri, 17 Oct 2014 08:45:40 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 36E401A1AB0 for ; Fri, 17 Oct 2014 08:45:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,739,1406617200"; d="scan'208";a="48318592" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 17 Oct 2014 08:48:47 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 08:45:42 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 08:45:41 -0700 From: Shahram Davari To: Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXc= Date: Fri, 17 Oct 2014 15:45:40 +0000 Message-ID: <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pct4akSa8y5QTFBnYJjVrxjc-es Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:45:42 -0000 Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and do = Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they c= an >> use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like some= one's son is not good at math, then you suggest him to replace the son with= someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service provid= er wants to >> use MPL S and do traffic Engineering then they should use P2P RSVP-TE LS= Ps, >> otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and do = Direct Loss >> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they c= an >> use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required. This = draft adds >> multiple labels to the label stack (makes the label stack much larger th= an it >> already is) and requires a respin of chips due to its special label hand= ling in the >> data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM >> from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM in= RFC 6374) >> or possible other solutions not requiring HW change are not adequate, I = think it is >> premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.= org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to determining w= hether this >> draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as thi= s without first >> achieving a common understanding of all the requirements. >> In this particular case, the solution on the table will require a hardwa= re re-spin >> and will consume a precious 0..15 reserved label which is something that= we >> should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are tak= en into >> account in the proposed design. For example the solution only proposes t= o >> identify the source LSR, whereas it seems likely that a finer granularit= y of flow >> identification will be needed in practice. Additionally in the only use = case cited >> (performance monitoring) it seems likely that accounting demarcation wil= l be be >> needed to allow for different delays of the ECMP paths and the distribut= ion of >> packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the set= of >> requirements before we embark on a design which will be expensive in MPL= S >> protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:14:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889671A002F for ; Fri, 17 Oct 2014 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fouQoRg57AeG for ; Fri, 17 Oct 2014 11:14:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3232E1A004B for ; Fri, 17 Oct 2014 11:14:46 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-c1-5441052ec2e9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.5E.05330.E2501445; Fri, 17 Oct 2014 14:01:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 14:14:44 -0400 From: Gregory Mirsky To: Shahram Davari , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6AgABeSoCAAAMrgIAAj0GAgADS+gD//+UAUA== Date: Fri, 17 Oct 2014 18:14:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> In-Reply-To: <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonQVef1THE4PEVPov1vZ4Wc7ZOZLG4 sFbY4vulJSwWt5auZLX4u+IKiwObx6z7Z9k8Wo68ZfVYsuQnk8f1pqvsHl8uf2YLYI3isklJ zcksSy3St0vgylj//j57wVmDilOTrRsYH6p3MXJySAiYSLR9usMIYYtJXLi3nq2LkYtDSOAo o8TiPWsZIZzljBKT755jB6liEzCSeLGxB8wWEfCSeHzgPStIEbPAE6COaffBEsICthLTZ91l hCiykzi6+CQbhB0mMefFErA4i4CqxJe9+5i7GDk4eAV8JT5PsodYNpFZ4s+KI6wgNZwCDhKf tn0A62UEOu/7qTVMIDazgLjErSfzmSDOFpBYsuc8M4QtKvHy8T9WCFtJYtLSc6wQ9ToSC3Z/ YoOwtSWWLXwNVs8rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIy0 YxJsujsY97y0PMQowMGoxMO7gN0hRIg1say4MvcQozQHi5I476zaecFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGLeV96lsT5rN8dlU/YVjTF6me0gzD3OOYluRYM6BAF45ObeID4oO3Jkd x7mc78/MfsIr9qXt0cXee0KO7dedAvf/KnzLKL21RGhPg0LUm/JHm9K8A1L5cpdEVud5Ltj0 5vxBp3fFLz8GmZZVcNcIHdl18XmRZ8RlYetryoXqel4bJrncsrRVYinOSDTUYi4qTgQAkG/8 BpUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VUiFdzVGerWxfcEhWR6flIsR1ls Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:14:48 -0000 Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance=20 >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:23:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1319B1A00AF for ; Fri, 17 Oct 2014 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKoPEUFBV0nH for ; Fri, 17 Oct 2014 11:22:52 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id AC3591A01F0 for ; Fri, 17 Oct 2014 11:22:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="48486992" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Oct 2014 11:44:43 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 11:22:47 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 11:22:46 -0700 From: Shahram Davari To: Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXeAAJ7+gP//jHiA Date: Fri, 17 Oct 2014 18:22:44 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EvDLl8x6hxokPMpwF9rJwI6JA4Y Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:23:02 -0000 Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance=20 >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:23:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3411A0195 for ; Fri, 17 Oct 2014 11:23:52 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIhowmbDJMG4 for ; Fri, 17 Oct 2014 11:23:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFFB1A01A8 for ; Fri, 17 Oct 2014 11:23:50 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-bf-544104e648aa Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F0.B4.25146.6E401445; Fri, 17 Oct 2014 14:00:39 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 14:23:48 -0400 From: Uma Chunduri To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP3vHCCa7MKf0gt0KX5wGtVz4e3Jw0sQ5Q Date: Fri, 17 Oct 2014 18:23:47 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F3CB456@eusaamb105.ericsson.se> References: <542E752C.3020203@pi.nu> In-Reply-To: <542E752C.3020203@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXSPt+5zFscQg7OnmC32zOlnsfg3dw6z xfdLS1gsbi1dyerA4rFkyU8mj1nT29g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVceXOZOaCW9wV qw7eZWtgnM/ZxcjJISFgIrH53RlGCFtM4sK99WxdjFwcQgJHGSXON3SwQzjLGSWalmxlBali E9CT+Dj1JzuILSJgJ7Hx1T9GkCJmgXmMEk+mzgdLCAtkSPy9cIEFoihTYv6878wQtpHE69c9 bCA2i4CqxKZz65hAbF4BX4lHRzqAbA6gbSoSP+/Wg4Q5gUo+7OkGG8MIdN33U2vAypkFxCVu PZnPBHG1gMSSPeeZIWxRiZeP/7FC2IoS+/qns0PU60gs2P2JDcLWlli28DUzxFpBiZMzn7BM YBSbhWTsLCQts5C0zELSsoCRZRUjR2lxalluupHhJkZgFB2TYHPcwbjgk+UhRgEORiUe3gXs DiFCrIllxZW5hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBc7nJo86Wk iowZj+K6Fm+uy76j1XGhn/2FS5jQ3O50B7ulpdV7786tYj77LeSmcNfPjwcv2cs9PbEmam3W h1zeP8InReUN62OfO60663e3v3zOqd9PVvQVHX/tlTjxrv7dpQc+xFSvUJt++KOEpdh1frcT Bnu2HLPb9LJGoPavsKlI6uGJs2QWKrEUZyQaajEXFScCAIbNfmGDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ebEM_W0nKh9LAIzRZZ5JU_fB1b0 Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:23:52 -0000 Support. -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, October 03, 2014 3:07 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-raza-mpls-oam-ipv6-rao@tools.ietf.org Subject: [mpls] poll to see if we have support to make draft-raza-mpls-oam-= ipv6-rao an mpls wg doc Working Group, This is to start a two week poll on adopting draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There is no IPR disclosures against this document. The authors has all stated on the working group mailing list that they are = unaware of any IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends October 17, 2014. /Loa for the MPLS wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:25:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09661A03A0 for ; Fri, 17 Oct 2014 11:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAAe8lUlLDXh for ; Fri, 17 Oct 2014 11:25:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7631A039C for ; Fri, 17 Oct 2014 11:25:50 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-4d-5441055ff9e3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.D4.25146.F5501445; Fri, 17 Oct 2014 14:02:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 14:25:36 -0400 From: Gregory Mirsky To: Shahram Davari , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6AgABeSoCAAAMrgIAAj0GAgADS+gD//+UAUIAARuMA//+9EXA= Date: Fri, 17 Oct 2014 18:25:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonRDee1THEYOlFA4v1vZ4Wc7ZOZLG4 sFbY4vulJSwWt5auZLX4u+IKiwObx6z7Z9k8Wo68ZfVYsuQnk8f1pqvsHl8uf2YLYI3isklJ zcksSy3St0vgyjh9+SJLwSeLiksLO1gaGK/qdTFyckgImEgcu7ePBcIWk7hwbz1bFyMXh5DA UUaJOdNOM4MkhASWM0rceiwDYrMJGEm82NjDDmKLCHhJPD7wnhWkgVngCaPE4mn3wRLCArYS 02fdZYQospM4uvgkG4SdJLHiSj8TiM0ioCrRc+IrmM0r4Ctx5twkqM2LWCR2tO8Ha+YUCJdY eOAQWBEj0HnfT60Bs5kFxCVuPZnPBHG2gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsT G4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCPDTYzAWDsm wea4g3HBJ8tDjAIcjEo8vAvYHUKEWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8q zUktPsTIxMEp1cA423tVjv+2wO8OQSzdnXw7PfcIhx288zlP24aRc/2zHRPibNUDls6w+ft7 TUlsA197Z0iM7KudgrGrex+se1edFSqunDOJZTJD+4XnbB55n/qrL3040JWy+X9t8karvYoM sktMvyRf1Zll/zRKMuXNyqaTfM8tDvLM6ZbZsUcn1Fi7q8+HpU6JpTgj0VCLuag4EQC2WAvd lgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iEUln8mOFyP70u4_j6RYCjSxm00 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:25:53 -0000 Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:34:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7F31A19F4 for ; Fri, 17 Oct 2014 11:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl4Bf0YP6TtS for ; Fri, 17 Oct 2014 11:34:55 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2E1A19F7 for ; Fri, 17 Oct 2014 11:34:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="48488109" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Oct 2014 11:56:54 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 11:34:56 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 11:34:55 -0700 From: Shahram Davari To: Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXeAAJ7+gP//jHiAgAB2kYD//4yoQA== Date: Fri, 17 Oct 2014 18:34:54 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WftbZNzdTADx6RlRpEwL-W9oAhE Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:34:57 -0000 Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:35:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184611A1A36 for ; Fri, 17 Oct 2014 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lULDWBgKmFd5 for ; Fri, 17 Oct 2014 11:35:45 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2831A1A1B for ; Fri, 17 Oct 2014 11:35:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="48488175" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Oct 2014 11:57:45 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 11:35:47 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 11:35:47 -0700 From: Shahram Davari To: Shahram Davari , Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXeAAJ7+gP//jHiAgAB2kYD//4yoQAAAGSUw Date: Fri, 17 Oct 2014 18:35:45 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D5492C@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_09hnVnXdCmR0j6GuiaHYHcpKVM Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:35:51 -0000 Also why ILM is not acceptable? Thx SD -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 11:35 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:39:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28E1A19EA for ; Fri, 17 Oct 2014 11:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP-Z5HNdo5h0 for ; Fri, 17 Oct 2014 11:39:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B001A0024 for ; Fri, 17 Oct 2014 11:39:02 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-54-54410877c08d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.85.25146.77801445; Fri, 17 Oct 2014 14:15:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 14:39:01 -0400 From: Gregory Mirsky To: Shahram Davari , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6AgABeSoCAAAMrgIAAj0GAgADS+gD//+UAUIAARuMA//+9EXCAAEZVAP//vSRw Date: Fri, 17 Oct 2014 18:39:00 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FD28@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLrHT7ecwzHE4MUjaYv1vZ4Wc7ZOZLG4 sFbY4vulJSwWt5auZLX4u+IKiwObx6z7Z9k8Wo68ZfVYsuQnk8f1pqvsHl8uf2YLYI3isklJ zcksSy3St0vgynj2sJ2l4JRTxbGeOcwNjK/Muhg5OSQETCQamhpYIWwxiQv31rOB2EICRxkl 1v1L62LkArKXM0pcu9LKDpJgEzCSeLGxB8wWEfCSeHzgPStIEbPAE0aJxdPugyWEBWwlps+6 ywhRZCdxdPFJNgg7T+L+j/lgNSwCqhKfXy0Gaubg4BXwlXj4zRhi2WZWidfbHoPVcAqES5z+ 1AlmMwJd9/3UGiYQm1lAXOLWk/lMEFcLSCzZc54ZwhaVePn4H9Q3ShKTlp5jhajXkViw+xMb hK0tsWzha7B6XgFBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUjR2lxalluupHhJkZgpB2T YHPcwbjgk+UhRgEORiUe3gXsDiFCrIllxZW5hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamBcnOW8rpwzN9Tx7puaeSuFD26SO+7OGV3X8fvIvpMJe3b1KZQ+rH2onXmD f4rceaYsjZe5H+K7zE46PtVKeuQ7bzfnHC8lbtYzL8t+9DdG5XJP9C+y3qNYd/8Q44rXtql7 Tj2JeKcocXNf5AQ1l/0XxM/G3vTZdtx+c5OhxJlVk7MnWOawzEtUYinOSDTUYi4qTgQARG3e GZUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Cg4nULP1KSxF1hntIIykP3Xe6xc Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:39:05 -0000 Hi Shahram, thank you for pointing this. We will review references and update the docum= ent with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, draft-kumar-spr= ing-sr-oam-requirement, and draft-ashwood-nvo3-oam-requirements, if any is = missing. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:35 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:41:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB751A0277 for ; Fri, 17 Oct 2014 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I49bvczqLCXG for ; Fri, 17 Oct 2014 11:41:52 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9791A19EA for ; Fri, 17 Oct 2014 11:41:52 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5B725180006E; Fri, 17 Oct 2014 20:41:51 +0200 (CEST) Message-ID: <544162EF.1070806@pi.nu> Date: Fri, 17 Oct 2014 20:41:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <544120D1.6000303@pi.nu> In-Reply-To: <544120D1.6000303@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0IUmw8IGbjs5PxvqlqZSS7vjs5s Cc: "mpls-chairs@tools.ietf.org" , draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:41:54 -0000 Folks, I have been made aware of that I have there is a mistake in this IPR poll. I wrote that there is one IPR disclosed against this document, that is not correct. There are no IPRs disclosed against the document. The authors that have responded that they are not aware of IPRs, will not have to re-state this. /Loa On 2014-10-17 15:59, Loa Andersson wrote: > Working Group, > > We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. > > The outcome is such that we anticipate a poll for working group adoption > after the authors have updated the draft. > > Before we do poll to see if we have consensus to accept the document > as a working group document we want to do an IPR poll on the document. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- > label? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are one IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 17 11:52:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8B1A1A05 for ; Fri, 17 Oct 2014 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4PNOTcIQFy3 for ; Fri, 17 Oct 2014 11:52:31 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 520D61A028A for ; Fri, 17 Oct 2014 11:52:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="48338487" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 17 Oct 2014 11:55:27 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 11:52:22 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 11:52:20 -0700 From: Shahram Davari To: Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXeAAJ7+gP//jHiAgAB2kYD//4yoQAAO4wMAAA6UumA= Date: Fri, 17 Oct 2014 18:52:18 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D549CB@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FD28@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85FD28@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7H_j9srNCQl399y5Jcf6iX34GdE Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:52:33 -0000 Hi Greg, draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a fram= ework and not requirements. I believe the EVPN OAM has much more requiremen= ts than just adding a Source label. You have to consider the Load balancin= g at multiple points, aliasing, Multi-homing, etc. This requires much more discussion and a thorough requirements analysis bef= ore coming to a quick rush solution such a source-label. Thanks Shahram=20 -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, October 17, 2014 11:39 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, thank you for pointing this. We will review references and update the docum= ent with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, draft-kumar-spr= ing-sr-oam-requirement, and draft-ashwood-nvo3-oam-requirements, if any is = missing. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:35 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:58:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59251A1B15 for ; Fri, 17 Oct 2014 11:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY8tl9zKfZ-N for ; Fri, 17 Oct 2014 11:58:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16411A0069 for ; Fri, 17 Oct 2014 11:58:42 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-78-54410d13bcb4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AF.B6.25146.31D01445; Fri, 17 Oct 2014 14:35:31 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 14:58:41 -0400 From: Gregory Mirsky To: Shahram Davari , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzDs6AgABeSoCAAAMrgIAAj0GAgADS+gD//+UAUIAARuMA//+9EXCAAEZVAP//vSRwAAj3GQAACD+ZQA== Date: Fri, 17 Oct 2014 18:58:41 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85FD9D@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FD28@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D549CB@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D549CB@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLrHW1eY1zHEYOE3eYv1vZ4Wc7ZOZLG4 sFbY4vulJSwWt5auZLX4u+IKiwObx6z7Z9k8Wo68ZfVYsuQnk8f1pqvsHl8uf2YLYI3isklJ zcksSy3St0vgyph39jJ7wSrfis7b15gaGJ/bdzFyckgImEisfLaUCcIWk7hwbz1bFyMXh5DA UUaJvTcOskM4yxkl5u5/xwJSxSZgJPFiYw87iC0i4CXx+MB7VpAiZoEnjBKLp90HSwgL2EpM n3WXEaLITuLo4pNsEHadRMO76WDrWARUJWacm84MYvMK+EqsWXYfavURNollB6aAbeMUCJfo a3sINpQR6L7vp9aANTMLiEvcejIf6m4BiSV7zjND2KISLx//Y4WwlSQmLT3HClGvI7Fg9yc2 CFtbYtnC11CLBSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgdF2TILN cQfjgk+WhxgFOBiVeHgXsDuECLEmlhVX5h5ilOZgURLn1ayeFywkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBcfqPuWLGU8R31tfdCDN/7ru6dI/VQf1Xh3f/fDJd9rfS5CWNd19/aX7Jn3tq pXS3gkKZZYCf+5vJnBpPjdTvih2qExCzzvfxz7LrcxFh8OKNub1fljNP6ULQ7ftcM/l+pRnH OFXJHJrak3ZSZn5g3r47/KwmS5PaWDIWnNPx6u7Pup52WtFfiaU4I9FQi7moOBEA3aPsGJcC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FLGsYN6wcpYkEnJ3lr_vRoYlAbU Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:58:45 -0000 Hi Shahram, I'll check with the authors of the EVPN OAM document on their plans. I agree, there are many other interesting problems to solve. And we're not = claiming that SLI/SL is solving all of them. Some, perhaps, but not all. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:52 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a fram= ework and not requirements. I believe the EVPN OAM has much more requiremen= ts than just adding a Source label. You have to consider the Load balancin= g at multiple points, aliasing, Multi-homing, etc. This requires much more discussion and a thorough requirements analysis bef= ore coming to a quick rush solution such a source-label. Thanks Shahram=20 -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:39 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, thank you for pointing this. We will review references and update the docum= ent with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, draft-kumar-spr= ing-sr-oam-requirement, and draft-ashwood-nvo3-oam-requirements, if any is = missing. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, October 17, 2014 11:35 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 11:59:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D531A1AD2 for ; Fri, 17 Oct 2014 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7VdtK1bjH6G for ; Fri, 17 Oct 2014 11:59:32 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFB11A0069 for ; Fri, 17 Oct 2014 11:59:31 -0700 (PDT) Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 17 Oct 2014 19:59:32 +0100 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.139]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Fri, 17 Oct 2014 19:59:34 +0100 From: To: , , Date: Fri, 17 Oct 2014 19:59:27 +0100 Thread-Topic: IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: Ac/qPHypppfDsuS8TA6oMtCeqL8Hlg== Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/je0LTRYWlNAAM20oN4y029chvsE Cc: mpls-chairs@tools.ietf.org, draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:59:35 -0000 SGkgTVBMUyBXRywgTG9hLA0KDQpbMTcvMTAvMjAxNCAxNTozMiwgIlNoYWtpcixSSixSb2IsVE5F RjQgUiIgPHJvYi5zaGFraXJAYnQuY29tPl0NCg0KPkmp9m0gbm90IGF3YXJlIG9mIGFueSBJUFIg b3RoZXIgdGhhbiB0aGUgZXhpc3RpbmcgSHVhd2VpIGRpc2Nsb3N1cmUuDQoNCkhhdmluZyBiZWVu IGNvcnJlY3RlZCB0aGF0IHRoaXMgSVBSIGlzIG5vdCBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuIEkg YW0gbm90DQphd2FyZSBvZiBhbnkgSVBSIHdoaWNoIGlzIHJlbGV2YW50IHRvIHRoaXMgZG9jdW1l bnQuDQoNClRoYW5rcyENCnIuDQoNCg== From nobody Fri Oct 17 12:04:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304BE1A1B39 for ; Fri, 17 Oct 2014 12:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf0Nbkh54zjY for ; Fri, 17 Oct 2014 12:04:07 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 113DC1A1B64 for ; Fri, 17 Oct 2014 12:04:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="48339139" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 17 Oct 2014 12:07:12 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 17 Oct 2014 12:04:08 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 12:04:05 -0700 From: Shahram Davari To: Shahram Davari , Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzQRmA///lxkCAAATBoIABBi+AgABdoXeAAJ7+gP//jHiAgAB2kYD//4yoQAAO4wMAAA6UumAAHI6pgA== Date: Fri, 17 Oct 2014 19:04:05 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D54A88@SJEXCHMB12.corp.ad.broadcom.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831D52D4E@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831D52E00@SJEXCHMB12.corp.ad.broadcom.com>, <1046DA44-8E3E-4DD4-AA8C-64E391839647@broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCB3@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54894@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FCE8@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D54919@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B85FD28@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D549CB@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D549CB@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sew-Hn2iXmAF2BPSkl-aOiE1fDA Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 19:04:10 -0000 Hi Greg, I suggest you talk to your co-authors since Mach Chen just wrote this in re= sponse to Nobo: > However, I agree with Stewart. The Introduction only specifies that > "performance monitoring" is the only concrete requirement for this soluti= on. > From "performance monitoring" perspective, the proposed only provides a > solution to limited [1] LSP types (and UHP/PHP of them) and [2] granulari= ty of > measurements. Mach: The solution is intended to solve an existing real problem. We do not= expect the solution that could apply to any scenario and solve future occu= r issues, although it may have the potentiality. This is also the tradition= of IETF. SD> First of all Mach says this is an existing real problem. Therefore I wo= uld conclude he is not solving the EVPN LM. Secondly he says this is not a= generalized solution for future (aka EVPN). So just use the LSP+PW counti= ng and it will solve your problem quickly and without any respin of HW. No = standard is even required, just information RFC.=20 Thanks Shahram -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 11:52 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a fram= ework and not requirements. I believe the EVPN OAM has much more requiremen= ts than just adding a Source label. You have to consider the Load balancin= g at multiple points, aliasing, Multi-homing, etc. This requires much more discussion and a thorough requirements analysis bef= ore coming to a quick rush solution such a source-label. Thanks Shahram=20 -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, October 17, 2014 11:39 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, thank you for pointing this. We will review references and update the docum= ent with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, draft-kumar-spr= ing-sr-oam-requirement, and draft-ashwood-nvo3-oam-requirements, if any is = missing. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, October 17, 2014 11:35 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg I think you are jumping too far. The draft only mentions RFC5036 and RFC436= 4 as requirements and not EVPN. Are you adding new requirements on the fly? We will solve the EVPN LM when the time comes. (LSP+PW) label counting can= be done today without any HW change. Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:26 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, and if this is EVPN and no PW exist? Are you going to offer piecemeal solut= ions or look for more generic mechanism? I do believe that SLI/SL, though m= ay cause some pain, is useful and generic solution to the real problem. Regards, Greg=20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, October 17, 2014 11:23 AM To: Gregory Mirsky; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Greg, How about using a combination of (LSP label + PW Label) to uniquely identif= y the source of the LSP?=20 Thanks Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 17, 2014 11:15 AM To: Shahram Davari; Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label Hi Shahram, using characteristic information from IP or Ethernet layer to measure MPLS = performance? That would be another layer violation, would it not? And what = if your payload is neither IP, nor Ethernet, just of academic argument sake= ? IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.= 1731. And in both cases none relies on another layer addressing information= . I think that what you're suggesting is not the right way, even if custome= rs are buying it for the time being. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Friday, October 17, 2014 8:46 AM To: Mach Chen Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -source-label@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label Let me give you a proper example instead. This is like adding a custom made motor to your son's bike since he wants t= o get to school faster. While a better solution is just give him a motorcyc= le or car instead of inventing something new.=20 The solution to DLM already exists.=20 You might say this is optional but as we know vendors have to implement opt= ions too. I think the 3 extra labels this solution adds to solve a problem that can b= e solved using other methods is by itself a show stopper. As Stewart said we need another 2-3 labels for the EL.=20 Another possible way of doing this is by just using SIP from the encapsulat= ed IP header or SA from the encapsulated Ethernet header. Regards, Shahram > On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >=20 > HI Shahram, >=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >=20 > If I was a service provider, I will not buy this logic. It just like=20 > someone's son is not good at math, then you suggest him to replace the=20 > son with someone else who is good at math :-) >=20 >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, October 17, 2014 2:38 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> This is similar to the Traffic Engineering argument. If a service=20 >> provider wants to use MPL S and do traffic Engineering then they=20 >> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>=20 >> Similarly in this case, if a service provider wants to use MPL S and=20 >> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE=20 >> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, October 16, 2014 11:26 AM >> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;=20 >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Hi, >>=20 >> I agree with Stewart. I am not convinced such a label is required.=20 >> This draft adds multiple labels to the label stack (makes the label=20 >> stack much larger than it already is) and requires a respin of chips=20 >> due to its special label handling in the data-plane. >>=20 >> An alternative solution for MP2MP or MP2P Loss Measurement is to use=20 >> ILM from RFC6374. >>=20 >> So until a solid argument is put forward that existing solutions (ILM=20 >> in RFC 6374) or possible other solutions not requiring HW change are=20 >> not adequate, I think it is premature To adopt this draft. >>=20 >>=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, October 16, 2014 5:49 AM >> To: Ross Callon; mpls@ietf.org; >> draft-chen-mpls-source-label@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Ross >>=20 >> You state that you are starting an IPR poll with a view to=20 >> determining whether this draft is ready for adoption as a WG draft. >>=20 >> It is my view that it is premature to adopt a solution draft such as=20 >> this without first achieving a common understanding of all the requireme= nts. >> In this particular case, the solution on the table will require a=20 >> hardware re-spin and will consume a precious 0..15 reserved label=20 >> which is something that we should not do lightly. >>=20 >> In addition I am not convinced that the full set of requirements are=20 >> taken into account in the proposed design. For example the solution=20 >> only proposes to identify the source LSR, whereas it seems likely=20 >> that a finer granularity of flow identification will be needed in=20 >> practice. Additionally in the only use case cited (performance >> monitoring) it seems likely that accounting demarcation will be be=20 >> needed to allow for different delays of the ECMP paths and the distribut= ion of packets across multiple receiver interfaces. >>=20 >> I think that we need to backup the process and start by agreeing the=20 >> set of requirements before we embark on a design which will be=20 >> expensive in MPLS protocol and implementation resource. >>=20 >> As such I think the IPR poll, and the imminent intention to adopt is pr= emature. >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 13:33:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40BE1A6F7D for ; Fri, 17 Oct 2014 13:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pegp8ZSVdMLK for ; Fri, 17 Oct 2014 13:33:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23461A1BED for ; Fri, 17 Oct 2014 13:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11454; q=dns/txt; s=iport; t=1413578009; x=1414787609; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Hrr38q9GgrDtzFsizcsBmvryBnYbWDifeOq7ruvVyWk=; b=SKdlzGV+vBEY9Kldr0VtKITZumwTbOjV2Qnj5vuk+9uEioz/EeD9+Wav oaXx8dbgXLad9hhYo9eUAZhIT8mO4ahLLsVzAEdb87s6SHVQBgSk4cX95 /PytYMi6D0buJX75LFMVW6yGFt/XFhFXAI/nrSLdLChas6HNLibVvfhmo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAFB8QVStJA2N/2dsb2JhbABRCoMOU1gEzDMKh04CgRQWAX2EAgEBAQQBAQE3NAsMBgEIEQQBAQEVCQkuCxQJCAIEAQ0FG4gkDc4PAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKT4UTDwRYBwYEhEEFkgCLWYEwjVaDG4QEg3dsgQZCgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,741,1406592000"; d="scan'208";a="88014702" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 17 Oct 2014 20:33:28 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9HKXSbS029804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 20:33:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 15:33:28 -0500 From: "George Swallow (swallow)" To: Shahram Davari , Gregory Mirsky , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwzH5KAgABeSYCAAAMrgIAAj0KAgADS+gCAACmlgIAAAj0AgAAAzICAAAKaAIAAASYAgAADtwCAAANLgP//1eeA Date: Fri, 17 Oct 2014 20:33:27 +0000 Message-ID: In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D54A88@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.98.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <3170030971C4964D89B42E209580854C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NweQbITUSjuZayChvCitlAcm9b0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:33:32 -0000 Folks - We need a clear set of requirements! This is a huge change to MPLS. We certainly do not want to do it to meet a narrow set of requirements. We need to clearly articulate what we need in the way of loss/delay measurement. Then we need to explore possible solutions. If a solution can be found that does not have a major hardware impact, then we should adopt that. =20 George On 10/17/14 3:04 PM, "Shahram Davari" wrote: >Hi Greg, > >I suggest you talk to your co-authors since Mach Chen just wrote this in >response to Nobo: > >> However, I agree with Stewart. The Introduction only specifies that >> "performance monitoring" is the only concrete requirement for this >>solution. >> From "performance monitoring" perspective, the proposed only provides a >> solution to limited [1] LSP types (and UHP/PHP of them) and [2] >>granularity of >> measurements. > >Mach: The solution is intended to solve an existing real problem. We do >not expect the solution that could apply to any scenario and solve future >occur issues, although it may have the potentiality. This is also the >tradition of IETF. > > >SD> First of all Mach says this is an existing real problem. Therefore I >would conclude he is not solving the EVPN LM. Secondly he says this is >not a generalized solution for future (aka EVPN). So just use the LSP+PW >counting and it will solve your problem quickly and without any respin of >HW. No standard is even required, just information RFC. > >Thanks >Shahram > >-----Original Message----- >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >Sent: Friday, October 17, 2014 11:52 AM >To: Gregory Mirsky; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Greg, > >draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a >framework and not requirements. I believe the EVPN OAM has much more >requirements than just adding a Source label. You have to consider the >Load balancing at multiple points, aliasing, Multi-homing, etc. > >This requires much more discussion and a thorough requirements analysis >before coming to a quick rush solution such a source-label. > > >Thanks >Shahram=20 > >-----Original Message----- >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >Sent: Friday, October 17, 2014 11:39 AM >To: Shahram Davari; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Shahram, >thank you for pointing this. We will review references and update the >document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, >draft-kumar-spring-sr-oam-requirement, and >draft-ashwood-nvo3-oam-requirements, if any is missing. > > Regards, > Greg > >-----Original Message----- >From: Shahram Davari [mailto:davari@broadcom.com] >Sent: Friday, October 17, 2014 11:35 AM >To: Gregory Mirsky; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Greg > >I think you are jumping too far. The draft only mentions RFC5036 and >RFC4364 as requirements and not EVPN. Are you adding new requirements on >the fly? >We will solve the EVPN LM when the time comes. (LSP+PW) label counting >can be done today without any HW change. > >Thanks >Shahram > >-----Original Message----- >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >Sent: Friday, October 17, 2014 11:26 AM >To: Shahram Davari; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Shahram, >and if this is EVPN and no PW exist? Are you going to offer piecemeal >solutions or look for more generic mechanism? I do believe that SLI/SL, >though may cause some pain, is useful and generic solution to the real >problem. > > Regards, > Greg=20 > >-----Original Message----- >From: Shahram Davari [mailto:davari@broadcom.com] >Sent: Friday, October 17, 2014 11:23 AM >To: Gregory Mirsky; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Greg, > >How about using a combination of (LSP label + PW Label) to uniquely >identify the source of the LSP? > >Thanks >Shahram > >-----Original Message----- >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >Sent: Friday, October 17, 2014 11:15 AM >To: Shahram Davari; Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >Hi Shahram, >using characteristic information from IP or Ethernet layer to measure >MPLS performance? That would be another layer violation, would it not? >And what if your payload is neither IP, nor Ethernet, just of academic >argument sake? >IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - >Y.1731. And in both cases none relies on another layer addressing >information. I think that what you're suggesting is not the right way, >even if customers are buying it for the time being. > > Regards, > Greg > >-----Original Message----- >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >Sent: Friday, October 17, 2014 8:46 AM >To: Mach Chen >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >draft-chen-mpls-source-label@tools.ietf.org >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >Let me give you a proper example instead. > >This is like adding a custom made motor to your son's bike since he wants >to get to school faster. While a better solution is just give him a >motorcycle or car instead of inventing something new. > >The solution to DLM already exists. > >You might say this is optional but as we know vendors have to implement >options too. > >I think the 3 extra labels this solution adds to solve a problem that can >be solved using other methods is by itself a show stopper. > >As Stewart said we need another 2-3 labels for the EL. > >Another possible way of doing this is by just using SIP from the >encapsulated IP header or SA from the encapsulated Ethernet header. > >Regards, >Shahram > > >> On Oct 16, 2014, at 8:10 PM, "Mach Chen" wrote: >>=20 >> HI Shahram, >>=20 >>> Similarly in this case, if a service provider wants to use MPL S and >>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE >>> LSPs, otherwise they can use MP2MP LDP LSPs. >>=20 >> If I was a service provider, I will not buy this logic. It just like >> someone's son is not good at math, then you suggest him to replace the >> son with someone else who is good at math :-) >>=20 >>=20 >> Best regards, >> Mach >>=20 >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Friday, October 17, 2014 2:38 AM >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Cc: mpls-chairs@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi, >>>=20 >>> This is similar to the Traffic Engineering argument. If a service >>> provider wants to use MPL S and do traffic Engineering then they >>> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>>=20 >>> Similarly in this case, if a service provider wants to use MPL S and >>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE >>> LSPs, otherwise they can use MP2MP LDP LSPs. >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >>> Sent: Thursday, October 16, 2014 11:26 AM >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Cc: mpls-chairs@tools.ietf.org >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi, >>>=20 >>> I agree with Stewart. I am not convinced such a label is required. >>> This draft adds multiple labels to the label stack (makes the label >>> stack much larger than it already is) and requires a respin of chips >>> due to its special label handling in the data-plane. >>>=20 >>> An alternative solution for MP2MP or MP2P Loss Measurement is to use >>> ILM from RFC6374. >>>=20 >>> So until a solid argument is put forward that existing solutions (ILM >>> in RFC 6374) or possible other solutions not requiring HW change are >>> not adequate, I think it is premature To adopt this draft. >>>=20 >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >>> Sent: Thursday, October 16, 2014 5:49 AM >>> To: Ross Callon; mpls@ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Cc: mpls-chairs@tools.ietf.org >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Ross >>>=20 >>> You state that you are starting an IPR poll with a view to >>> determining whether this draft is ready for adoption as a WG draft. >>>=20 >>> It is my view that it is premature to adopt a solution draft such as >>> this without first achieving a common understanding of all the >>>requirements. >>> In this particular case, the solution on the table will require a >>> hardware re-spin and will consume a precious 0..15 reserved label >>> which is something that we should not do lightly. >>>=20 >>> In addition I am not convinced that the full set of requirements are >>> taken into account in the proposed design. For example the solution >>> only proposes to identify the source LSR, whereas it seems likely >>> that a finer granularity of flow identification will be needed in >>> practice. Additionally in the only use case cited (performance >>> monitoring) it seems likely that accounting demarcation will be be >>> needed to allow for different delays of the ECMP paths and the >>>distribution of packets across multiple receiver interfaces. >>>=20 >>> I think that we need to backup the process and start by agreeing the >>> set of requirements before we embark on a design which will be >>> expensive in MPLS protocol and implementation resource. >>>=20 >>> As such I think the IPR poll, and the imminent intention to adopt is >>>premature. >>>=20 >>> - Stewart >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 14:10:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A071A6FF5 for ; Fri, 17 Oct 2014 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1Z-UMbdDnQ5 for ; Fri, 17 Oct 2014 14:09:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6691A702B for ; Fri, 17 Oct 2014 14:09:41 -0700 (PDT) Received: from BLUPR05MB627.namprd05.prod.outlook.com (10.141.204.150) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 21:09:40 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB627.namprd05.prod.outlook.com (10.141.204.150) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 21:09:38 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 21:09:38 +0000 From: John E Drake To: "George Swallow (swallow)" , Shahram Davari , Gregory Mirsky , "Mach Chen" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/Xpwyy8CAgABeSoCAAAMqgIAAj0KAgADS+gCAACmlgIAAAj0AgAAAzICAAAKbAIAAASUAgAADtwCAAANLgIAAGPiAgAAFsUA= Date: Fri, 17 Oct 2014 21:09:38 +0000 Message-ID: <71d98852b32040f3bcc7fc2542885386@BLUPR05MB562.namprd05.prod.outlook.com> References: <4A6CE49E6084B141B15C0713B8993F2831D54A88@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB627;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(199003)(377454003)(51704005)(51444003)(76104003)(24454002)(189002)(13464003)(37854004)(87936001)(19580405001)(50986999)(46102003)(85852003)(76576001)(92566001)(15975445006)(19580395003)(85306004)(4396001)(108616004)(54356999)(2656002)(74316001)(76176999)(80022003)(230783001)(40100003)(86362001)(101416001)(97736003)(95666004)(99286002)(122556002)(76482002)(99396003)(120916001)(33646002)(20776003)(21056001)(106356001)(106116001)(105586002)(66066001)(64706001)(107046002)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB627; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Z0TvDsncU_rRExuZ7tgfO3DJIOI Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:09:49 -0000 X-List-Received-Date: Fri, 17 Oct 2014 21:09:49 -0000 George, >From the draft: "For some applications, source identification is a critical requirement. F= or example, performance monitoring, the monitoring nodes need to identify w= here packets were sent from and then can count the packets according to som= e constraints." What do you think could possibly be added to make this list of requirements= either more clear or more complete 8->? It should also be blindingly obvi= ous to the informed participant that to address this very complete set of r= equirements the use of global source labels is the solution that immediatel= y springs to mind even thought it is completely at odds w/ the MPLS archite= cture. "This isn't right. This isn't even wrong." -- Wolfgang Pauli Is it possible euthanize to an I-D? Yours Irrespectively, John > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow > (swallow) > Sent: Friday, October 17, 2014 1:33 PM > To: Shahram Davari; Gregory Mirsky; Mach Chen > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mp= ls- > source-label@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Folks - >=20 > We need a clear set of requirements! This is a huge change to MPLS. We > certainly do not want to do it to meet a narrow set of requirements. We = need > to clearly articulate what we need in the way of loss/delay measurement. > Then we need to explore possible solutions. If a solution can be found t= hat > does not have a major hardware impact, then we should adopt that. >=20 > George >=20 > On 10/17/14 3:04 PM, "Shahram Davari" wrote: >=20 > >Hi Greg, > > > >I suggest you talk to your co-authors since Mach Chen just wrote this > >in response to Nobo: > > > >> However, I agree with Stewart. The Introduction only specifies that > >>"performance monitoring" is the only concrete requirement for this > >>solution. > >> From "performance monitoring" perspective, the proposed only provides > >>a solution to limited [1] LSP types (and UHP/PHP of them) and [2] > >>granularity of measurements. > > > >Mach: The solution is intended to solve an existing real problem. We do > >not expect the solution that could apply to any scenario and solve > >future occur issues, although it may have the potentiality. This is > >also the tradition of IETF. > > > > > >SD> First of all Mach says this is an existing real problem. Therefore > >SD> I > >would conclude he is not solving the EVPN LM. Secondly he says this is > >not a generalized solution for future (aka EVPN). So just use the > >LSP+PW counting and it will solve your problem quickly and without any > >respin of HW. No standard is even required, just information RFC. > > > >Thanks > >Shahram > > > >-----Original Message----- > >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > >Sent: Friday, October 17, 2014 11:52 AM > >To: Gregory Mirsky; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Greg, > > > >draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a > >framework and not requirements. I believe the EVPN OAM has much more > >requirements than just adding a Source label. You have to consider the > >Load balancing at multiple points, aliasing, Multi-homing, etc. > > > >This requires much more discussion and a thorough requirements analysis > >before coming to a quick rush solution such a source-label. > > > > > >Thanks > >Shahram > > > >-----Original Message----- > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >Sent: Friday, October 17, 2014 11:39 AM > >To: Shahram Davari; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Shahram, > >thank you for pointing this. We will review references and update the > >document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, > >draft-kumar-spring-sr-oam-requirement, and > >draft-ashwood-nvo3-oam-requirements, if any is missing. > > > > Regards, > > Greg > > > >-----Original Message----- > >From: Shahram Davari [mailto:davari@broadcom.com] > >Sent: Friday, October 17, 2014 11:35 AM > >To: Gregory Mirsky; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Greg > > > >I think you are jumping too far. The draft only mentions RFC5036 and > >RFC4364 as requirements and not EVPN. Are you adding new requirements > >on the fly? > >We will solve the EVPN LM when the time comes. (LSP+PW) label counting > >can be done today without any HW change. > > > >Thanks > >Shahram > > > >-----Original Message----- > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >Sent: Friday, October 17, 2014 11:26 AM > >To: Shahram Davari; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Shahram, > >and if this is EVPN and no PW exist? Are you going to offer piecemeal > >solutions or look for more generic mechanism? I do believe that SLI/SL, > >though may cause some pain, is useful and generic solution to the real > >problem. > > > > Regards, > > Greg > > > >-----Original Message----- > >From: Shahram Davari [mailto:davari@broadcom.com] > >Sent: Friday, October 17, 2014 11:23 AM > >To: Gregory Mirsky; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Greg, > > > >How about using a combination of (LSP label + PW Label) to uniquely > >identify the source of the LSP? > > > >Thanks > >Shahram > > > >-----Original Message----- > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >Sent: Friday, October 17, 2014 11:15 AM > >To: Shahram Davari; Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Hi Shahram, > >using characteristic information from IP or Ethernet layer to measure > >MPLS performance? That would be another layer violation, would it not? > >And what if your payload is neither IP, nor Ethernet, just of academic > >argument sake? > >IP has IP PM with OWAMP/TWAMP as active measurement protocol. > Ethernet > >- Y.1731. And in both cases none relies on another layer addressing > >information. I think that what you're suggesting is not the right way, > >even if customers are buying it for the time being. > > > > Regards, > > Greg > > > >-----Original Message----- > >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > >Sent: Friday, October 17, 2014 8:46 AM > >To: Mach Chen > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > >draft-chen-mpls-source-label@tools.ietf.org > >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > >Let me give you a proper example instead. > > > >This is like adding a custom made motor to your son's bike since he > >wants to get to school faster. While a better solution is just give him > >a motorcycle or car instead of inventing something new. > > > >The solution to DLM already exists. > > > >You might say this is optional but as we know vendors have to implement > >options too. > > > >I think the 3 extra labels this solution adds to solve a problem that > >can be solved using other methods is by itself a show stopper. > > > >As Stewart said we need another 2-3 labels for the EL. > > > >Another possible way of doing this is by just using SIP from the > >encapsulated IP header or SA from the encapsulated Ethernet header. > > > >Regards, > >Shahram > > > > > >> On Oct 16, 2014, at 8:10 PM, "Mach Chen" > wrote: > >> > >> HI Shahram, > >> > >>> Similarly in this case, if a service provider wants to use MPL S and > >>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE > >>> LSPs, otherwise they can use MP2MP LDP LSPs. > >> > >> If I was a service provider, I will not buy this logic. It just like > >> someone's son is not good at math, then you suggest him to replace > >> the son with someone else who is good at math :-) > >> > >> > >> Best regards, > >> Mach > >> > >>> -----Original Message----- > >>> From: Shahram Davari [mailto:davari@broadcom.com] > >>> Sent: Friday, October 17, 2014 2:38 AM > >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > >>> draft-chen-mpls-source-label@tools.ietf.org > >>> Cc: mpls-chairs@tools.ietf.org > >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > >>> > >>> Hi, > >>> > >>> This is similar to the Traffic Engineering argument. If a service > >>> provider wants to use MPL S and do traffic Engineering then they > >>> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. > >>> > >>> Similarly in this case, if a service provider wants to use MPL S and > >>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE > >>> LSPs, otherwise they can use MP2MP LDP LSPs. > >>> > >>> Thanks > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram > >>> Davari > >>> Sent: Thursday, October 16, 2014 11:26 AM > >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > >>> draft-chen-mpls-source-label@tools.ietf.org > >>> Cc: mpls-chairs@tools.ietf.org > >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >>> > >>> Hi, > >>> > >>> I agree with Stewart. I am not convinced such a label is required. > >>> This draft adds multiple labels to the label stack (makes the label > >>> stack much larger than it already is) and requires a respin of chips > >>> due to its special label handling in the data-plane. > >>> > >>> An alternative solution for MP2MP or MP2P Loss Measurement is to use > >>> ILM from RFC6374. > >>> > >>> So until a solid argument is put forward that existing solutions > >>> (ILM in RFC 6374) or possible other solutions not requiring HW > >>> change are not adequate, I think it is premature To adopt this draft. > >>> > >>> > >>> Thanks > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart > >>> Bryant > >>> Sent: Thursday, October 16, 2014 5:49 AM > >>> To: Ross Callon; mpls@ietf.org; > >>> draft-chen-mpls-source-label@tools.ietf.org > >>> Cc: mpls-chairs@tools.ietf.org > >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >>> > >>> Ross > >>> > >>> You state that you are starting an IPR poll with a view to > >>> determining whether this draft is ready for adoption as a WG draft. > >>> > >>> It is my view that it is premature to adopt a solution draft such as > >>>this without first achieving a common understanding of all the > >>>requirements. > >>> In this particular case, the solution on the table will require a > >>>hardware re-spin and will consume a precious 0..15 reserved label > >>>which is something that we should not do lightly. > >>> > >>> In addition I am not convinced that the full set of requirements are > >>>taken into account in the proposed design. For example the solution > >>>only proposes to identify the source LSR, whereas it seems likely > >>>that a finer granularity of flow identification will be needed in > >>>practice. Additionally in the only use case cited (performance > >>> monitoring) it seems likely that accounting demarcation will be be > >>>needed to allow for different delays of the ECMP paths and the > >>>distribution of packets across multiple receiver interfaces. > >>> > >>> I think that we need to backup the process and start by agreeing the > >>> set of requirements before we embark on a design which will be > >>> expensive in MPLS protocol and implementation resource. > >>> > >>> As such I think the IPR poll, and the imminent intention to adopt > >>>is premature. > >>> > >>> - Stewart > >>> > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 14:11:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37EB1A701D for ; Fri, 17 Oct 2014 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IVx0mvx0vO0 for ; Fri, 17 Oct 2014 14:11:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4446B1A701C for ; Fri, 17 Oct 2014 14:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5666; q=dns/txt; s=iport; t=1413580303; x=1414789903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nS5i5V5dM+kecComjKH2x7ghrp2GA+1vwFOXsPW/Yt0=; b=cdRv24EWXO0dsko1M6o8ZvhnoJ2D4o8QzOMQi1yLR5vEPTOpjJmY0Ot2 N7jqS6GTvqMS7bEyYo4cl44wHK0/rPOr9Oipf6uL6I0QCb0F06z5tGTbG MXf52lIFjUL1MBZ34VEOcXBhjixCaQYB0HEWccEMkjdS42wsP31TZQ8Fc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPuEQVStJA2K/2dsb2JhbABRCoJrI1NYBMw4CodOAoEUFgF9hAIBAQEDAQEBARodNAsFBwQCAQgOAwQBARYJCQcnCxQJCAIEDgUbiBwIAQzOCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj2IJBgsBHTMHBgSDI4EeBY9kghyLWZYlg3dsgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,741,1406592000"; d="scan'208";a="364239416" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2014 21:11:42 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9HLBgxJ028975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 21:11:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 16:11:42 -0500 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+l2b155pZvakGO4uRCWsmh1pwzbxUAgAGwIAA= Date: Fri, 17 Oct 2014 21:11:41 +0000 Message-ID: <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.230.29] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S8HoLwoaHA5FrjlhqgfGS0objDc Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:11:47 -0000 Hi Ross, Since you are asking, let me share a couple of high level thoughts. As already mentioned, the document only lists PM as the application that ne= eds source labels. Based on that, this draft adds a Source Label Indicator = and a Source Label, without really analyzing the use cases and requirements= for PM. IOW, this draft provides one solution but it is not clear if that = is solving the right problem in the context of PM. For example, what happen= s when PHP? What happens if a finer granularity than the source node is nee= ded? Basically, two or three labels are added to the label stack, and some serio= us forwarding (and HW) requirements. It also lists some constraining contro= l plane requirements (e.g., extending LDP signaling on a per-FEC basis!, ex= tending BGP, and extending IGPs). It also requires per-domain unique identi= fiers. Given this dramatic set of extensions and strong requirements, it se= ems prudent to me to better understand the problem space of PM gaps before = adopting a solution. The document also seems to contradict itself in parts. First it says that a= "Source Identifier (SI) identifies the ingress Label Switching Router (LSR= ) of a Label Switched Path (LSP)", but then the definition breaks with text= like "Each node in a domain MUST be allocated one or more unique SIs" and = "For most of the use cases, one SI per LSR would be sufficient. But for so= me cases, there may be need for more than one SIs." Many of the RFC 2119 requirements also seem to be self-contradicting -- for= example, "An ingress LSR MUST make sure that the egress LSR is able to pro= cess the {SLI;SL} pair (or trio!)", and "an egress LSR SHOULD signal its ca= pability to process SL".=20 I had mentioned to the authors privately (and on list as well if I remember= correctly) in rev -00 that the unique label requirement coupled with distr= ibution of those assignments and the addition of 2-3 labels all seemed far = from insignificant changes, making the need to understand the scope of the = problem more important. It seemed to me as this is "what other {indicator; = label} can we invent similar to {ELI; EL}" draft. I have not seen the discussion of the problem space on the list, other than= "needed for PM". I hope these comments are useful. Thanks, Carlos. On Oct 16, 2014, at 8:25 PM, Ross Callon wrote: > MPLS working group; >=20 > There have been a number of comments, both public and private, about whet= her or not source labels are needed and/or worth the cost of implementing t= his approach. It is clear that we need a discussion in public on the MPLS e= mail list of this issue. In principle this discussion could occur either be= fore or as part of the call for adoption. However, due to the strong intere= st of several folks to focus on this issue, and the possibility that the ou= tcome of this discussion might motivate changes to the document, I think th= at we should have this discussion prior to the call for adoption.=20 >=20 > I would like to therefore encourage MPLS participants to reply to Stewart= 's email (and the few replies that have already occurred) and to continue t= his discussion. The requirements and use cases for source labels, whether s= ource labels are needed, what the cost of implementation would be, and alte= rnatives to satisfy the same use cases, are all explicitly topics that shou= ld be considered (as well as any other issues that people feel is important= in determining whether the MPLS WG should work on source labels).=20 >=20 > In the hope of coming to a timely consensus, I would encourage people who= have opinions on this issue to respond within two weeks (by Friday October= 31).=20 >=20 > Thanks, Ross >=20 >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: Thursday, October 16, 2014 8:49 AM > To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.o= rg > Cc: mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Ross >=20 > You state that you are starting an IPR poll with a view > to determining whether this draft is ready for adoption as a WG draft. >=20 > It is my view that it is premature to adopt a solution draft such as this > without first achieving a common understanding of all the requirements. > In this particular case, the solution on the table will require a hardwar= e > re-spin and will consume a precious 0..15 reserved label which > is something that we should not do lightly. >=20 > In addition I am not convinced that the full set of requirements > are taken into account in the proposed design. For example > the solution only proposes to identify the source LSR, whereas > it seems likely that a finer granularity of flow identification will be > needed in practice. Additionally in the only use case cited > (performance monitoring) it seems likely that accounting > demarcation will be be needed to allow for different delays > of the ECMP paths and the distribution of packets across > multiple receiver interfaces. >=20 > I think that we need to backup the process and start by agreeing > the set of requirements before we embark on a design which will > be expensive in MPLS protocol and implementation resource. >=20 > As such I think the IPR poll, and the imminent intention to adopt > is premature. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 14:43:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477FC1A86DE for ; Fri, 17 Oct 2014 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 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, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Ejs4TNkN-l for ; Fri, 17 Oct 2014 14:43:37 -0700 (PDT) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6287A1A86DD for ; Fri, 17 Oct 2014 14:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413582216; bh=qT3pk+d3qOlujARlOexsjn67HHpvueHwoBWdEObfAUo=; h=Subject:References:From:In-Reply-To:Date:Cc:To:From:Subject; b=OrrnWwBrbcjDe/MFsUNi7Ir8kwjqfGcFug7VcTJaQOdcR1TpzYSGxoCTvhd3diB2sHIE9sCNPXcOjOHjnOscTjFOowEdvvZ16BeB+cpq+XavXP5EP1NSHevCPLU3G271J8PyIuJPy/tOX433pgCFWAEunIUpeKrzPt+eo758hem1U3o+jjNfnx2Hnxn/Rieuo3FwTcaRlxhhBBjSFGqV5GbbJ7yF6Pe7fhMkcTWatpR7YzkIVUqEx+JcUlK4PmL/XCrIW+7Q4amF/RoZ6TAxS5cwtzerO02jgAHMdP7F4CWCo4LNjJDBCk6hewq8h9RZrZBBYQAjNLqruYJ7y3IhQg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=UO3bh9MGAcRaAg2gNk8lG0Iyv0QQSn7CTbm2Cu7JJ8TiOJTs7gJ3LMJCDywF8JkriOOkeeZqVUHeafdiQkXyRsvBpRaK9G44LLilVNOWIgZf1skcFfV2DSvDrz189s9mU0nD6f+d+Sh4oimKarDI6ptTORIho6fNY1R1T0qWiQX018d097y9HULMXnBznUwaIIYQIn5g66nv0cT55JZzmj6AcgYRiY12bDo/S57z/4tZDd0QzgXrVUFdyxR7XlR1H2mwl3Y0VhUqNnxSX+EqW3XqP8gFAy6ue0a41k3DhowOS/lLJqmOkp3xLkcxOCl5bZ7+grWXHz2JRzZlbkChRA==; Received: from [98.139.215.141] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2014 21:43:36 -0000 Received: from [98.139.211.195] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2014 21:43:36 -0000 Received: from [127.0.0.1] by smtp204.mail.bf1.yahoo.com with NNFMP; 17 Oct 2014 21:43:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1413582216; bh=qT3pk+d3qOlujARlOexsjn67HHpvueHwoBWdEObfAUo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Content-Type:Content-Transfer-Encoding:Subject:References:From:Mime-Version:In-Reply-To:Message-Id:Date:Cc:To:X-Mailer; b=3gwoyYn8NTkyEUw/SsyJFEUXVVAPveJf75annwF4bmZglY29mEi9CxDZwpw3SCnZEORGffjviaub7FdvkiUi2iTBDiDJbLaYBPn8LSDNCrSnoDkCLGgWDRZvk3n1SuHKgoWbW3KOWqFoKKw3T/iu587Nfb2iwP6mzi8V71psKj4= X-Yahoo-Newman-Id: 464264.52699.bm@smtp204.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: h8.VeuEVM1ldSevQlwT_I.2Bs3t8gIOK0ect4yvleo3T_xz QEnKcP0RACQcCS0mxvGdp7_PlBamGxKJ04RX4l1h7_Amq0RrE4svSAWtJXYN bQEoBH6_njkLdtiuBI5fk7C6mIpZTpzI5ZagGZPGwucNp50si2D7zgDhg7Oh DVMNonQ54sojvVxYEdQTGCfldUW6Vl7Aea4s0yCwQiRqxYCdQWcUHNNPRA4A OS2jubcCwzescwytI72SlrnGpz_OlfGsLpW8BneBDb.pHhpAlQCzfKPKZurt GNcuAdCsIJjUY8YqcfZ4gj7eY1aARERw73bb1pUSG0n9fX84MlQFKtCz388B Af5YA7YP58TEzRcqq_QGWsNHl3oGGqQzyhVnolBkMK2w.c0dtLXRt6ivjffL hlBvuCq2fDrH3YdmiZZuwfvejFm_a8l0nC6D_oMH6TnflgzhW817IgJx96UT sOxW5GVW9YJ_djeJrGcAtfiJRaM.6RrYNRu1WIC3nmZBH2fDXinIn3CgEi0k AncWxh_KhY4F_k5KjaLfj98DWbe1265YlLA-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <4A6CE49E6084B141B15C0713B8993F2831D54A88@SJEXCHMB12.corp.ad.broadcom.com> <71d98852b32040f3bcc7fc2542885386@BLUPR05MB562.namprd05.prod.outlook.com> From: "S. Davari" Mime-Version: 1.0 (1.0) In-Reply-To: <71d98852b32040f3bcc7fc2542885386@BLUPR05MB562.namprd05.prod.outlook.com> Message-Id: Date: Fri, 17 Oct 2014 14:39:59 -0700 To: John E Drake X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gkBieP9ag-B6vZZO-wbrxKvTqlo Cc: "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:43:40 -0000 Many things can be added, for example is ECMP support required? What is the r= equired granularity of the required PM? Is EVPN support required? Why can't o= ther methods such as ILM be used? Etc. Engineers shouldn't just focus on the first obvious solution that come to mi= nd no matter what is the cost. Regards, Shahram > On Oct 17, 2014, at 2:09 PM, John E Drake wrote: >=20 > George, >=20 >> =46rom the draft: >=20 > "For some applications, source identification is a critical requirement. = For example, performance monitoring, the monitoring nodes need to identify w= here packets were sent from and then can count the packets according to some= constraints." >=20 > What do you think could possibly be added to make this list of requirement= s either more clear or more complete 8->? It should also be blindingly obvi= ous to the informed participant that to address this very complete set of re= quirements the use of global source labels is the solution that immediately s= prings to mind even thought it is completely at odds w/ the MPLS architectur= e. "This isn't right. This isn't even wrong." -- Wolfgang Pauli >=20 > Is it possible euthanize to an I-D? >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow >> (swallow) >> Sent: Friday, October 17, 2014 1:33 PM >> To: Shahram Davari; Gregory Mirsky; Mach Chen >> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mp= ls- >> source-label@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Folks - >>=20 >> We need a clear set of requirements! This is a huge change to MPLS. We >> certainly do not want to do it to meet a narrow set of requirements. We n= eed >> to clearly articulate what we need in the way of loss/delay measurement. >> Then we need to explore possible solutions. If a solution can be found t= hat >> does not have a major hardware impact, then we should adopt that. >>=20 >> George >>=20 >>> On 10/17/14 3:04 PM, "Shahram Davari" wrote: >>>=20 >>> Hi Greg, >>>=20 >>> I suggest you talk to your co-authors since Mach Chen just wrote this >>> in response to Nobo: >>>=20 >>>> However, I agree with Stewart. The Introduction only specifies that >>>> "performance monitoring" is the only concrete requirement for this >>>> solution. >>>> =46rom "performance monitoring" perspective, the proposed only provides= >>>> a solution to limited [1] LSP types (and UHP/PHP of them) and [2] >>>> granularity of measurements. >>>=20 >>> Mach: The solution is intended to solve an existing real problem. We do >>> not expect the solution that could apply to any scenario and solve >>> future occur issues, although it may have the potentiality. This is >>> also the tradition of IETF. >>>=20 >>>=20 >>> SD> First of all Mach says this is an existing real problem. Therefore >>> SD> I >>> would conclude he is not solving the EVPN LM. Secondly he says this is >>> not a generalized solution for future (aka EVPN). So just use the >>> LSP+PW counting and it will solve your problem quickly and without any >>> respin of HW. No standard is even required, just information RFC. >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >>> Sent: Friday, October 17, 2014 11:52 AM >>> To: Gregory Mirsky; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Greg, >>>=20 >>> draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a >>> framework and not requirements. I believe the EVPN OAM has much more >>> requirements than just adding a Source label. You have to consider the >>> Load balancing at multiple points, aliasing, Multi-homing, etc. >>>=20 >>> This requires much more discussion and a thorough requirements analysis >>> before coming to a quick rush solution such a source-label. >>>=20 >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: Friday, October 17, 2014 11:39 AM >>> To: Shahram Davari; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Shahram, >>> thank you for pointing this. We will review references and update the >>> document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, >>> draft-kumar-spring-sr-oam-requirement, and >>> draft-ashwood-nvo3-oam-requirements, if any is missing. >>>=20 >>> Regards, >>> Greg >>>=20 >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Friday, October 17, 2014 11:35 AM >>> To: Gregory Mirsky; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Greg >>>=20 >>> I think you are jumping too far. The draft only mentions RFC5036 and >>> RFC4364 as requirements and not EVPN. Are you adding new requirements >>> on the fly? >>> We will solve the EVPN LM when the time comes. (LSP+PW) label counting >>> can be done today without any HW change. >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: Friday, October 17, 2014 11:26 AM >>> To: Shahram Davari; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Shahram, >>> and if this is EVPN and no PW exist? Are you going to offer piecemeal >>> solutions or look for more generic mechanism? I do believe that SLI/SL, >>> though may cause some pain, is useful and generic solution to the real >>> problem. >>>=20 >>> Regards, >>> Greg >>>=20 >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Friday, October 17, 2014 11:23 AM >>> To: Gregory Mirsky; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Greg, >>>=20 >>> How about using a combination of (LSP label + PW Label) to uniquely >>> identify the source of the LSP? >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: Friday, October 17, 2014 11:15 AM >>> To: Shahram Davari; Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Hi Shahram, >>> using characteristic information from IP or Ethernet layer to measure >>> MPLS performance? That would be another layer violation, would it not? >>> And what if your payload is neither IP, nor Ethernet, just of academic >>> argument sake? >>> IP has IP PM with OWAMP/TWAMP as active measurement protocol. >> Ethernet >>> - Y.1731. And in both cases none relies on another layer addressing >>> information. I think that what you're suggesting is not the right way, >>> even if customers are buying it for the time being. >>>=20 >>> Regards, >>> Greg >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >>> Sent: Friday, October 17, 2014 8:46 AM >>> To: Mach Chen >>> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-chen-mpls-source-label@tools.ietf.org >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>=20 >>> Let me give you a proper example instead. >>>=20 >>> This is like adding a custom made motor to your son's bike since he >>> wants to get to school faster. While a better solution is just give him >>> a motorcycle or car instead of inventing something new. >>>=20 >>> The solution to DLM already exists. >>>=20 >>> You might say this is optional but as we know vendors have to implement >>> options too. >>>=20 >>> I think the 3 extra labels this solution adds to solve a problem that >>> can be solved using other methods is by itself a show stopper. >>>=20 >>> As Stewart said we need another 2-3 labels for the EL. >>>=20 >>> Another possible way of doing this is by just using SIP from the >>> encapsulated IP header or SA from the encapsulated Ethernet header. >>>=20 >>> Regards, >>> Shahram >>>=20 >>>=20 >>>> On Oct 16, 2014, at 8:10 PM, "Mach Chen" >> wrote: >>>>=20 >>>> HI Shahram, >>>>=20 >>>>> Similarly in this case, if a service provider wants to use MPL S and >>>>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE >>>>> LSPs, otherwise they can use MP2MP LDP LSPs. >>>>=20 >>>> If I was a service provider, I will not buy this logic. It just like >>>> someone's son is not good at math, then you suggest him to replace >>>> the son with someone else who is good at math :-) >>>>=20 >>>>=20 >>>> Best regards, >>>> Mach >>>>=20 >>>>> -----Original Message----- >>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>> Sent: Friday, October 17, 2014 2:38 AM >>>>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >>>>> draft-chen-mpls-source-label@tools.ietf.org >>>>> Cc: mpls-chairs@tools.ietf.org >>>>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> This is similar to the Traffic Engineering argument. If a service >>>>> provider wants to use MPL S and do traffic Engineering then they >>>>> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. >>>>>=20 >>>>> Similarly in this case, if a service provider wants to use MPL S and >>>>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE >>>>> LSPs, otherwise they can use MP2MP LDP LSPs. >>>>>=20 >>>>> Thanks >>>>> Shahram >>>>>=20 >>>>> -----Original Message----- >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram >>>>> Davari >>>>> Sent: Thursday, October 16, 2014 11:26 AM >>>>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; >>>>> draft-chen-mpls-source-label@tools.ietf.org >>>>> Cc: mpls-chairs@tools.ietf.org >>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I agree with Stewart. I am not convinced such a label is required. >>>>> This draft adds multiple labels to the label stack (makes the label >>>>> stack much larger than it already is) and requires a respin of chips >>>>> due to its special label handling in the data-plane. >>>>>=20 >>>>> An alternative solution for MP2MP or MP2P Loss Measurement is to use >>>>> ILM from RFC6374. >>>>>=20 >>>>> So until a solid argument is put forward that existing solutions >>>>> (ILM in RFC 6374) or possible other solutions not requiring HW >>>>> change are not adequate, I think it is premature To adopt this draft. >>>>>=20 >>>>>=20 >>>>> Thanks >>>>> Shahram >>>>>=20 >>>>> -----Original Message----- >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart >>>>> Bryant >>>>> Sent: Thursday, October 16, 2014 5:49 AM >>>>> To: Ross Callon; mpls@ietf.org; >>>>> draft-chen-mpls-source-label@tools.ietf.org >>>>> Cc: mpls-chairs@tools.ietf.org >>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>=20 >>>>> Ross >>>>>=20 >>>>> You state that you are starting an IPR poll with a view to >>>>> determining whether this draft is ready for adoption as a WG draft. >>>>>=20 >>>>> It is my view that it is premature to adopt a solution draft such as >>>>> this without first achieving a common understanding of all the >>>>> requirements. >>>>> In this particular case, the solution on the table will require a >>>>> hardware re-spin and will consume a precious 0..15 reserved label >>>>> which is something that we should not do lightly. >>>>>=20 >>>>> In addition I am not convinced that the full set of requirements are >>>>> taken into account in the proposed design. For example the solution >>>>> only proposes to identify the source LSR, whereas it seems likely >>>>> that a finer granularity of flow identification will be needed in >>>>> practice. Additionally in the only use case cited (performance >>>>> monitoring) it seems likely that accounting demarcation will be be >>>>> needed to allow for different delays of the ECMP paths and the >>>>> distribution of packets across multiple receiver interfaces. >>>>>=20 >>>>> I think that we need to backup the process and start by agreeing the >>>>> set of requirements before we embark on a design which will be >>>>> expensive in MPLS protocol and implementation resource. >>>>>=20 >>>>> As such I think the IPR poll, and the imminent intention to adopt >>>>> is premature. >>>>>=20 >>>>> - Stewart >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 15:19:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538981A1B95 for ; Fri, 17 Oct 2014 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up0CT8BTGnYh for ; Fri, 17 Oct 2014 15:19:27 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 E9F9A1A1A1E for ; Fri, 17 Oct 2014 15:19:26 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B55425758C5C2; Fri, 17 Oct 2014 22:19:22 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s9HMJOrw008286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 18:19:25 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.79]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 18:19:24 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX4OkhgWsQGIUeAKGjjOVb0U5v0ZR+AgDvz/2A= Date: Fri, 17 Oct 2014 22:19:23 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9Y3S0GYH9LDRIRppqbKfOm8YzSI Cc: "Ross Callon \(rcallon@juniper.net\)" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:19:29 -0000 Dear all, This is a follow-up to the action below from the MPLS-RT review of this dra= ft. Instead of defining a new reply mode as proposed in Section 3.1 of the draf= t, I suggested to relax the rule in RFC 7110 such that if the echo request = includes reply mode 5 "Reply via Specified Path" and the Reply Path TLV was= not included, the responder node will interpret this as an implicit reques= t to reply via the reverse direction of the tested LSP.=20 This approach would address the requirement that the sender be able of requ= esting the reply via the reverse path of an LSP without having to include a= n additional TLV. I appreciate comments on this proposal. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) > Sent: Saturday, September 06, 2014 9:59 AM > To: mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net) > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e-00.txt >=20 > Thank you Ross and the WG. >=20 > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as draft-ie= tf-mpls- > lsp-ping-reply-mode-simple-00. >=20 > Authors would like the WG help to discuss and close off on these two aspe= cts: >=20 > - From Bruno Decraene: Reply Mode for SPRING and applicability of this > document. > o There's already a thread for this. > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > o Mustapha or myself will start a thread on this topic later. >=20 > Once above are close off, then we will roll out -01 that includes: >=20 > - Conclusion from the two aspects above. > - A comment received from Tarek Saad. > - Comments received from Lou Berger (will reply to the review comments > from Lou soon) >=20 > URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-p= ing-reply-mode- > simple-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping= -reply-mode- > simple/ > Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply= -mode-simple-00 >=20 > Thanks! >=20 > -Nobo, on behalf of authors >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Saturday, September 06, 2014 3:41 AM > > To: i-d-announce@ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > 00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Multiprotocol Label Switching > > Working Group of the IETF. > > > > Title : Label Switched Path (LSP) Ping/Traceroute Rep= ly Mode > > Simplification > > Authors : Nobo Akiya > > George Swallow > > Carlos Pignataro > > Loa Andersson > > Mach(Guoyi) Chen > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > Pages : 11 > > Date : 2014-09-05 > > > > Abstract: > > The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) > > Ping and Traceroute use the Reply Mode field to signal the method to > > be used in the MPLS echo reply. This document adds one value to the > > Reply Mode field to indicate reverse LSP. This document also adds a= n > > optional TLV which can carry ordered list of Reply Mode values. > > > > This document updates RFC4379. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode- > > simple/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple- > > 00 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 17 15:20:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD01A1BAC for ; Fri, 17 Oct 2014 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqCne82N_BoV for ; Fri, 17 Oct 2014 15:20:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1201A1B95 for ; Fri, 17 Oct 2014 15:20:24 -0700 (PDT) Received: from [172.29.35.196] (66.129.241.12) by DM2PR0501MB1101.namprd05.prod.outlook.com (25.160.245.11) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 17 Oct 2014 22:20:01 +0000 Message-ID: <5441960B.7040305@juniper.net> Date: Fri, 17 Oct 2014 18:19:55 -0400 From: Eric Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , Ross Callon References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> In-Reply-To: <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR01CA031.prod.exchangelabs.com (25.160.23.21) To DM2PR0501MB1101.namprd05.prod.outlook.com (25.160.245.11) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1101; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(189002)(107046002)(4396001)(95666004)(83506001)(23746002)(87976001)(120916001)(99396003)(54356999)(77096002)(92726001)(92566001)(87266999)(65816999)(40100003)(64126003)(50986999)(21056001)(76176999)(85852003)(1941001)(122386002)(86362001)(80316001)(59896002)(230783001)(20776003)(66066001)(101416001)(31966008)(105586002)(46102003)(47776003)(76482002)(102836001)(106356001)(42186005)(33656002)(50466002)(36756003)(65956001)(97736003)(80022003)(93886004)(85306004)(65806001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1101; H:[172.29.35.196]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nXyOYnj-ePDHfN2GqedsIhh6Rao Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:20:27 -0000 Carlos> Basically, two or three labels are added to the label stack, Actually, that's two or three labels per LSP. A packet may be going through a nested set of LSPs, which each label in the stack representing one of those LSPs. Each LSP may have its own source label. Since a source label is likely to require three label stack entries, the number of labels in the stack could be quadrupled. And for what? Carlos> the document only lists PM as the application that needs source labels. There doesn't seem to be general agreement that this is a compelling use case. Certainly not compelling enough to justify the complexity and the overhead that it brings. Carlos> What happens if a finer granularity than the source node is needed? This is inevitable. How long before folks are complaining "we can't run our network unless the egress LSR can determine the ingress interface for each packet". This could lead to thousands of source label values for each ingress LSR. And what will happen when someone decides that the granularity needs to be per-subscriber, not merely per-interface? And it's not just "finer granularity" we have to worry about. What if someone decides that an ingress LSR needs to convey an arbitrary amount of "meta-data" about an LSP to the egress LSR. Will the label stack become a set of labels alternating with meta-data containers? Do we really want to put stuff that doesn't affect the packet forwarding into the label stack? Where will we draw the line? I don't think the authors really intend the mechanism to be generalized in this manner. They're probably thinking "But we only intend for this to be deployed in a very simple case, where packets are being tunneled, where the ingress LSR knows who the egress LSR is, where they're in the same administrative domain, etc. etc. You're really exaggerating the negatives." But the proposed mechanisms do lend themselves to abuse or this sort. Once we start putting stuff in the label stack that isn't used for forwarding, how will we know when to stop? Carlos> Given this dramatic set of extensions and strong requirements, it seems prudent to me to better understand the problem space of PM gaps before adopting a solution. I agree. I think Stewart has made a good case that further analysis is needed. The problem isn't that there is no use for source labels, the problem is that the mechanism seems to bring a lot of problems with it. Is this really the only solution? And if so, is it so important to be able to do PM that we should be willing to take on all these problems? I also think the proposed LDP and BGP extensions are problematic, but those issues are really of secondary importance right now. So I don't support the adoption of this draft. From nobody Fri Oct 17 16:17:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1CB1A8748 for ; Fri, 17 Oct 2014 16:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQCRKal8E3Re for ; Fri, 17 Oct 2014 16:17:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00D41A6FF1 for ; Fri, 17 Oct 2014 16:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79618; q=dns/txt; s=iport; t=1413587868; x=1414797468; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=E805qKGNG5Zy8TT+FEKI8GjvV0IsXNHc42nsRJJw7i8=; b=P6tcGjKCUoxDs+oxzCCBb8zvtSxt77Yube8295gfUGguPX5W9Vi55yun hIPYDh45Dd28lSo9B73KfpzO5IkPgtDnE1EpGgdy8aV1MB9a3HgACDC4R lGcSSCdTibP4ooaYcGYGJE5vlpj5H96TO/+IJ0iL0vJ7Tj6w20pFwCiCH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAIeiQVStJV2R/2dsb2JhbABbgkhGU1gEgwLRDwIbdRYBfYQCAQEBBCMEBkwSAQYCEQMBAQEhAQYDAgQwFAYDCAIEAQ0FiD+dCJxPlGkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2IUMwkKEQYBgneBVAEEkgCLWYEwjVaDG4QEgjSBQ2yBB0GBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,742,1406592000"; d="scan'208,217";a="364216758" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2014 23:17:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9HNHkXD029097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 23:17:46 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 18:17:46 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Osborne, Eric" , "Tarek Saad (tsaad)" , Lizhenbin , "mpls@ietf.org" Thread-Topic: =?utf-8?B?W21wbHNdIOetlOWkjTogIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBscy10?= =?utf-8?B?ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1j?= =?utf-8?Q?fg-00?= Thread-Index: AQHP58Fh2hQnWaba40WbbB/wI7IbjJwzEAAAgABgHoCAAZI7gA== Date: Fri, 17 Oct 2014 23:17:45 +0000 Message-ID: In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.244.194] Content-Type: multipart/alternative; boundary="_000_D0671B3F3F283rgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w2aiuDeS96gRTYS3kmlq0AoV1q4 Cc: "Robert Sawaya \(rsawaya\)" Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAgUmVnYXJkaW5nIGRyYWZ0LWdhbmRoaS1tcGxz?= =?utf-8?q?-te-yang-model-00_and_draft-chen-mpls-te-yang-cfg-00?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:17:53 -0000 --_000_D0671B3F3F283rgandhiciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBFcmljLA0KDQpXZSBkZWZpbml0ZWx5IGFncmVlIHdpdGggeW91ciBmZWVkYmFjay4gV2Ug YWxyZWFkeSByZWFsaXplIHRoYXQgc3RhbmRhcmRpemluZyBhbnkgWUFORyBtb2RlbCBoYXMgdG8g YmUgYXMgZ2VuZXJpYyBhcyBwb3NzaWJsZS4NClRoaXMgaXMgd2h5IHdlIGFyZSB0cnlpbmcgdG8g ZGV0YWNoIG91cnNlbHZlcyBmcm9tIGFueSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIGluY2x1 ZGluZyBvdXJzLg0KV2Ugd2FudCB0byBjb3ZlciB0aGUgVEUgYXNwZWN0cyBmcm9tIGxvZ2ljYWwg cG9pbnQgb2Ygdmlldy4gV2UgYXJlIGFsc28gYWltaW5nIHRvIGNvdmVyIHRoZSBzdGFuZGFyZHMg aW4gdGVybXMgb2YgdGhlIG1vZGVsIGNvbnRlbnRzIGFuZCBuYW1pbmcuDQpNb3Jlb3Zlciwgd2Ug dHJ5IHRvIGhhdmUgbW9kZWxzIHRoYXQgaW5jb3Jwb3JhdGUgc29tZSBvZiB0aGUgb3RoZXIgdmVu ZG9ycyAgc3Ryb25nIHBvaW50cyBldmVuIGlmIHRoZXkgYXJlIG5vdCBwcmVzZW50IGluIG91ciBp bXBsZW1lbnRhdGlvbi4NCg0KV2Ugc3RhcnRlZCB0YWxraW5nIHRvIHRoZSBhdXRob3JzIG9mIGRy YWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBhbmQgd2UgYXJlIGxvb2tpbmcgdG8gY29ubmVj dCB3aXRoIG90aGVyIHZlbmRvcnMgYXMgd2VsbCB0byBqb2luIHRoZSBlZmZvcnQuDQoNClJlZ2Fy ZHMNClJvYmVydCwgUmFrZXNoIGFuZCBUYXJlaw0KDQoNCkZyb206IDxPc2Jvcm5lPiwgRXJpYyA8 ZXJpYy5vc2Jvcm5lQGxldmVsMy5jb208bWFpbHRvOmVyaWMub3Nib3JuZUBsZXZlbDMuY29tPj4N CkRhdGU6IFRodXJzZGF5LCAxNiBPY3RvYmVyLCAyMDE0IDM6MTggUE0NClRvOiAiVGFyZWsgU2Fh ZCAodHNhYWQpIiA8dHNhYWRAY2lzY28uY29tPG1haWx0bzp0c2FhZEBjaXNjby5jb20+PiwgTGl6 aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+ PiwgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW21wbHNdIOetlOWkjTogUmVnYXJk aW5nIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgYW5kIGRyYWZ0LWNoZW4tbXBs cy10ZS15YW5nLWNmZy0wMA0KDQpJIGxvb2tlZCBhdCBib3RoIGRvY3VtZW50cy4gIFRoZXkgYm90 aCBoYXZlIHNvbWUgZ29vZCBhbmQgc29tZSBiYWQuICBUaGUgaGFyZGVzdCBwYXJ0IGluIHJlY29u Y2lsaW5nIHRoZW0gd2lsbCBiZSB0aGF0IHRoZXkgYm90aCBoYXZlIGEgdmVyeSB2ZW5kb3Itc3Bl Y2lmaWMgdmlldyBvZiB0aGUgd29ybGQuICBUaGlzIGlzIG5vIHN1cnByaXNlIGdpdmVuIHRoZSBu YXR1cmUgb2YgdGhlIHRlY2hub2xvZ3ksIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIHVuaXF1 ZSB0byBURS4gIEJHUCB3aWxsIGJlIGF0IGxlYXN0IGFzIGhhcmQgdG8gc29ydCBvdXQuDQoNCkkg dGhpbmsgd2UgbmVlZCB0byBjbGVhcmx5IGRlbGluZWF0ZSBiZXR3ZWVuIHN0YW5kYXJkIGZlYXR1 cmVzLCBjb21tb24gZmVhdHVyZXMsIGFuZCB2ZW5kb3Itc3BlY2lmaWMgb25lcy4gIFN0YW5kYXJk IGZlYXR1cmVzIG1pZ2h0IGJlIHNjb3BlZCB0byBhbnl0aGluZyB0aGF0IGlzIGJvdGggc2lnbmFs ZWQgYW5kIFJGQ+KAmWQsIGUuZy4sIFszMjA5LCA0NDIwLCA0ODc1LCA1NzEyLCA3MzA4XS4NCg0K Q29tbW9uIGFyZSB0aGluZ3MgdGhhdCBtYXkgaGF2ZSBkaWZmZXJlbnQgbmFtZXMgYW5kIHdoaWNo IGFyZW7igJl0IHNpZ25hbGVkLCBidXQgd2hpY2ggYXJlIGluIHVzZSBpbiBtYW55L21vc3QvYWxs IGltcGxlbWVudGF0aW9ucyDigJMgdGhpbmdzIGxpa2Ugd2hhdCBvbmUgdmVuZG9yIGNhbGxzIOKA mGF1dG9yb3V0ZSBhbm5vdW5jZeKAmSBhbmQgYW5vdGhlciBjYWxscyDigJhpZ3Agc2hvcnRjdXRz 4oCZLiAgRmluZCBhIGNvbW1vbiBuYW1lLCBvciBhIHdheSB0byB1c2UgYm90aCwgYW5kIGJ1aWxk IGEgbW9kZWwgZm9yIHRoZSBzdWJzZXQgb2YgdGhpbmdzIHRoYXQgaXMgbW9zdCBjb21tb24gYWNy b3NzIHZlbmRvcnMuICBUaGlzIGlzIGEgYml0IG9mIGEgcXVhZ21pcmUgc2luY2UgZGlmZmVyZW50 IHZlbmRvcnMgd2lsbCBoYXZlIGRpZmZlcmVudCBhcHByb2FjaGVzIHRvIG1hbnkgZGV0YWlscyBv ZiBjb21tb24gZmVhdHVyZXMsIGFuZCBpdCBtYXkgYmUgdGhlIG1vc3QgZGlmZmljdWx0IHBhcnQg b2YgdGhpcyB3aG9sZSBleGVyY2lzZS4NCg0KVmVuZG9yLXNwZWNpZmljIHRoaW5ncyBhcmUganVz dCB0aGF0IOKAkyB0aGluZ3MgaW1wbGVtZW50ZWQgaW4gYSBwYXJ0aWN1bGFyIHdheSBieSBvbmx5 IG9uZSB2ZW5kb3IuICBBbiBleGFtcGxlIGZyb20gUm9iZXJ0LCBSYWtlc2ggYW5kIFRhcmVr4oCZ cyBkb2N1bWVudCBtaWdodCBiZSBhdHRyaWJ1dGUtc2V0cywgd2hpY2ggbWF5IG5vdCBoYXZlIGFu IG9idmlvdXMgcGFyYWxsZWwgaW4gb3RoZXIgdmVuZG9yc+KAmSBnZWFyLiAgSWYgbm90aGluZyBl bHNlIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWVwbGFjZSBhIHZlbmRvciBjYW4gYXBwZW5kIGl0cyBv d24gcHJvcHJpZXRhcnkgbW9kZWxzLg0KDQpJbiB0aGUgZW5kIGl0IG1heSBiZSBtb3JlIHByb2R1 Y3RpdmUgdG8gZG8gaXQgdGhpcyB3YXkg4oCTIHN0YXJ0aW5nIHdpdGggYSBtaW5pbXVtIHNldCBv ZiBvYnZpb3VseSBjb21tb24gZmVhdHVyZXMgYW5kIHdvcmtpbmcgdXAg4oCTIHRoYW4gdHJ5aW5n IHRvIHJlY29uY2lsZSB0d28gZnVsbHkgYmFrZWQgbW9kZWxzIHdpdGggdmVyeSBkaWZmZXJlbnQg dmlld3Mgb2YgdGhlIHdvcmxkLg0KDQoNCg0KDQoNCmVyaWMNCg0KDQoNCg0KRnJvbTogbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRhcmVrIFNhYWQgKHRz YWFkKQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTYsIDIwMTQgOTozNCBBTQ0KVG86IExpemhl bmJpbjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb bXBsc10g562U5aSNOiBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0w MCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwDQoNCkhpIFJvYmluLA0KDQpUaGFu a3MgZm9yIHRoZSByZWZlcmVuY2UgdG8gdGhlIGRyYWZ0LiBXZSBoYWQgYSBsb29rIGF0IGl0LiBX ZSBhcmUgcHJvcG9zaW5nIGEgc2xpZ2h0bHkgZGlmZmVyZW50IG1vZGVsIHRoYXQgaW50cm9kdWNl cyBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVuIGNvbmZpZ3VyYXRpb24sIG9wZXJhdGlvbmFsIChz dGF0ZSksIFJQQyAoZXhlY3V0aW9uYWwpLCBhbmQgbm90aWZpY2F0aW9ucyBmb3IgTVBMUy1URSB0 dW5uZWxzLCBsc3BzLCBsaW5rcywgYW5kIGdsb2JhbCBkYXRhOg0KDQoNCm1vZHVsZTogbXBscy10 ZQ0KDQogICArLS1ydyB0dW5uZWxzLWNmZyENCg0KICAgKy0tcncgbHNwcy1jZmchDQoNCiAgICst LXJ3IGxpbmtzLWNmZyENCg0KICAgKy0tcncgZ2xvYmFsLWNmZyENCg0KICAgKy0tcm8gdHVubmVs cy1vcGVyDQoNCiAgICstLXJvIGxzcHMtb3Blcg0KDQogICArLS1ybyBsaW5rcy1vcGVyDQoNCiAg ICstLXJvIGdsb2JhbC1vcGVyDQoNCnJwY3M6DQoNCiAgICstLS14IHR1bm5lbHMtcnBjDQoNCiAg ICstLS14IGxzcHMtcnBjDQoNCiAgICstLS14IGdsb2JhbC1ycGMNCg0KICAgKy0tLXggbGlua3Mt cnBjDQoNCm5vdGlmaWNhdGlvbnM6DQoNCiAgICstLS1uIHR1bm5lbHMtbm90aWYNCg0KICAgKy0t LW4gbHNwcy1ub3RpZg0KDQogICArLS0tbiBsaW5rcy1ub3RpZg0KDQogICArLS0tbiBnbG9iYWwt bm90aWYNCg0KV2UgYWxzbyBoYXZlIGEgZGV0YWlsZWQgWUFORyBtb2RlbCBpbi10aGUtd29ya3Mg KGFzIHBlciB0aGUgYWJvdmUpIGFuZCB3ZeKAmXJlIHBsYW5uaW5nIHRvIGluY2x1ZGUgaW4gdGhl IG5leHQgdXBkYXRlIG9mIHRoZSBkcmFmdC4gRm9yIGV4YW1wbGUsIHRoZSB0dW5uZWxzIFlBTkcg bW9kZWwgbG9va3Mgc29tZXRoaW5nIGxpa2UgYmVsb3cuDQoNCkFzIGZvciBjb2xsYWJvcmF0aW9u LCB5ZXMsIHdlIGFyZSB3aWxsaW5nIHRvIGNvbnNvbGlkYXRlIG91ciBlZmZvcnRzIHdpdGggeW91 IHRvIHByb2R1Y2UgdGhlIElFVEYgTVBMUy1URSBZYW5nIG1vZGVsLg0KDQoNCm1vZHVsZTogbXBs cy10ZQ0KDQogICArLS1ydyB0dW5uZWxzLWNmZyENCg0KICAgfCAgKy0tcncgdHVubmVsKiBbbmFt ZSB0eXBlXQ0KDQogICB8ICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAgICBzdHJpbmcN Cg0KICAgfCAgICAgKy0tcncgdHlwZSAgICAgICAgICAgICAgICAgICAgdHVubmVsLXR5cGUNCg0K ICAgfCAgICAgKy0tcncgdHVubmVsLWlkPyAgICAgICAgICAgICAgdWludDE2DQoNCiAgIHwgICAg ICstLXJ3IGRlc2NyaXB0aW9uPyAgICAgICAgICAgIHN0cmluZw0KDQogICB8ICAgICArLS1ydyBk ZXN0aW5hdGlvbiogW2FkZHJlc3NdDQoNCiAgIHwgICAgIHwgICstLXJ3IGFkZHJlc3MgICAgICAg IGluZXQ6aXAtYWRkcmVzcw0KDQogICB8ICAgICB8ICArLS1ydyBwYXRoLW9wdGlvbiogW2luZGV4 XQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBpbmRleCAgICAgICAgICAgICB1aW50OA0KDQogICB8 ICAgICB8ICAgICArLS1ydyAodHlwZSk/DQoNCiAgIHwgICAgIHwgICAgIHwgICstLTooZHluYW1p YykNCg0KICAgfCAgICAgfCAgICAgfCAgfCAgKy0tcncgZHluYW1pYw0KDQogICB8ICAgICB8ICAg ICB8ICArLS06KGV4cGxpY2l0KQ0KDQogICB8ICAgICB8ICAgICB8ICAgICArLS1ydyBleHBsaWNp dA0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICArLS1ydyBleHBsaWNpdC1ob3BsaXN0KiBbaW5k ZXhdDQoNCiAgIHwgICAgIHwgICAgIHwgICAgICAgICAgICstLXJ3IGluZGV4ICAgICAgICAgICAg ICAgICAgIHVpbnQ4DQoNCiAgIHwgICAgIHwgICAgIHwgICAgICAgICAgICstLXJ3IGV4cGxpY2l0 LWhvcC1hZGRyZXNzPyAgIGhvcC1hZGRyZXNzLXR5cGUNCg0KICAgfCAgICAgfCAgICAgfCAgICAg ICAgICAgKy0tcncgZXhwbGljaXQtaG9wLWFjdGlvbj8gICAgaG9wLWFjdGlvbi10eXBlDQoNCiAg IHwgICAgIHwgICAgICstLXJ3IGlncC1jb25zdHJhaW50DQoNCiAgIHwgICAgIHwgICAgIHwgICst LXJ3IGlncD8gICAgICAgICAgZW51bWVyYXRpb24NCg0KICAgfCAgICAgfCAgICAgfCAgKy0tcncg YXJlYS1sZXZlbD8gICB1aW50MzINCg0KICAgfCAgICAgfCAgICAgKy0tcncgdmVyYmF0aW0/ICAg ICAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICAgICArLS1ydyBsb2NrZG93bj8gICAgICAgICBi b29sZWFuDQoNCiAgIHwgICAgICstLXJ3IGxzcC1jZmcqIFtpbmRleF0NCg0KICAgfCAgICAgfCAg Ky0tcncgaW5kZXggICAgICAgICAgICAgbGVhZnJlZg0KDQogICB8ICAgICB8ICArLS1ydyBzb3Vy Y2U/ICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgfCAgKy0tcncgZmFzdC1y ZXJvdXRlPyAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICArLS1ydyByZWNvcmQtcm91dGU/ICAg ICBib29sZWFuDQoNCiAgIHwgICAgIHwgICstLXJ3IHNpZ25hbGVkLW5hbWU/ICAgIHN0cmluZw0K DQogICB8ICAgICB8ICArLS1ydyBwcmlvcml0eQ0KDQogICB8ICAgICB8ICB8ICArLS1ydyBzZXR1 cD8gICB1aW50OA0KDQogICB8ICAgICB8ICB8ICArLS1ydyBob2xkPyAgICB1aW50OA0KDQogICB8 ICAgICB8ICArLS1ydyBhZmZpbml0eQ0KDQogICB8ICAgICB8ICB8ICArLS1ydyBjb25zdHJhaW50 cyogW2FjdGlvbl0NCg0KICAgfCAgICAgfCAgfCAgICAgKy0tcncgYWN0aW9uICAgICAgICBhZmZp bml0eS1hY3Rpb24tdHlwZQ0KDQogICB8ICAgICB8ICB8ICAgICArLS1ydyBjb25zdHJhaW50DQoN CiAgIHwgICAgIHwgIHwgICAgICAgICstLXJ3IGFmZmluaXR5LWxpc3QqIFtuYW1lXQ0KDQogICB8 ICAgICB8ICB8ICAgICAgICAgICArLS1ydyBuYW1lICAgIHN0cmluZw0KDQogICB8ICAgICB8ICAr LS1ydyBwYXRoLXNlbGVjdGlvbg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBjb3N0LWxpbWl0PyAg IHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBob3AtbGltaXQ/ICAgIHVpbnQzMg0KDQog ICB8ICAgICB8ICB8ICArLS1ydyBtZXRyaWM/ICAgICAgIHBhdGgtbWV0cmljLXR5cGUNCg0KICAg fCAgICAgfCAgfCAgKy0tcncgdGllYnJlYWtlcj8gICBwYXRoLXRpZWJyZWFrZXItdHlwZQ0KDQog ICB8ICAgICB8ICArLS1ydyBiZmQNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgdHlwZT8gICAgICAg ICAgICAgICBiZmQtdHlwZQ0KDQogICB8ICAgICB8ICB8ICArLS1ydyBicmluZ3VwLXRpbWVvdXQ/ ICAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBkYW1wZW5pbmc/ICAgICAgICAgIHVp bnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBlbmNhcC1tb2RlPyAgICAgICAgIGJmZC1lbmNh cC1tb2RlLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZmFzdC1kZXRlY3Q/ICAgICAgICBi b29sZWFuDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGxzcC1waW5nDQoNCiAgIHwgICAgIHwgIHwg IHwgICstLXJ3IGRpc2FibGU/ICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgfCAgfCAgKy0tcncg aW50ZXJ2YWw/ICAgdWludDMyDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IG1pbmltdW0taW50ZXJ2 YWw/ICAgdWludDMyDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IG11bHRpcGxpZXI/ICAgICAgICAg dWludDMyDQoNCiAgIHwgICAgIHwgICstLXJ3IGxvZ2dpbmctZXZlbnQqIFtldmVudF0NCg0KICAg fCAgICAgfCAgICAgKy0tcncgZXZlbnQgICAgbG9nZ2luZy1ldmVudC10eXBlDQoNCiAgIHwgICAg ICstLXJ3IChwb2xpY3ktcm91dGluZyk/DQoNCiAgIHwgICAgIHwgICstLTooZm9yd2FyZGluZy1j bGFzcykNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZm9yd2FyZGluZy1jbGFzcw0KDQogICB8ICAg ICB8ICB8ICAgICArLS1ydyBjbGFzcz8gICB1aW50OA0KDQogICB8ICAgICB8ICArLS06KGZvcndh cmRpbmctZ3JvdXApDQoNCiAgIHwgICAgIHwgICAgICstLXJ3IGZvcndhcmRpbmctZ3JvdXANCg0K ICAgfCAgICAgfCAgICAgICAgKy0tcncgY2xhc3NlcyogICB1aW50OA0KDQogICB8ICAgICArLS1y dyBhdXRvLWJhbmR3aWR0aA0KDQogICB8ICAgICB8ICArLS1ydyBvdmVyZmxvdy10aHJlc2hvbGQ/ ICAgIHVpbnQzMg0KDQogICB8ICAgICB8ICArLS1ydyBvdmVyZmxvdy1saW1pdD8gICAgICAgIHVp bnQ4DQoNCiAgIHwgICAgIHwgICstLXJ3IHVuZGVyZmxvdy10aHJlc2hvbGQ/ICAgdWludDMyDQoN CiAgIHwgICAgIHwgICstLXJ3IHVuZGVyZmxvdy1saW1pdD8gICAgICAgdWludDgNCg0KICAgfCAg ICAgfCAgKy0tcncgY29sbGVjdC1vbmx5PyAgICAgICAgICBib29sZWFuDQoNCiAgIHwgICAgICst LXJ3IChhbm5vdW5jZS1hcyk/DQoNCiAgIHwgICAgIHwgICstLTooYXV0b3JvdXRlKQ0KDQogICB8 ICAgICB8ICB8ICArLS1ydyBhdXRvcm91dGUhDQoNCiAgIHwgICAgIHwgIHwgICAgICstLXJ3IGlu Y2x1ZGUtaXB2Ni11bmljYXN0PyAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgfCAgICAgKy0tcncg KG1ldHJpYy10eXBlKT8NCg0KICAgfCAgICAgfCAgfCAgICAgICAgKy0tOihtZXRyaWMpDQoNCiAg IHwgICAgIHwgIHwgICAgICAgIHwgICstLXJ3IG1ldHJpYz8gICAgICAgICAgICAgICAgIHVpbnQ4 DQoNCiAgIHwgICAgIHwgIHwgICAgICAgICstLToocmVsYXRpdmUtbWV0cmljKQ0KDQogICB8ICAg ICB8ICB8ICAgICAgICB8ICArLS1ydyByZWxhdGl2ZS1tZXRyaWM/ICAgICAgICB1aW50OA0KDQog ICB8ICAgICB8ICB8ICAgICAgICArLS06KGFic29sdXRlLW1ldHJpYykNCg0KICAgfCAgICAgfCAg fCAgICAgICAgICAgKy0tcncgYWJzb2x1dGUtbWV0cmljPyAgICAgICAgdWludDgNCg0KICAgfCAg ICAgfCAgKy0tOihmb3J3YXJkaW5nLWFkamFjZW5jeSkNCg0KICAgfCAgICAgfCAgICAgKy0tcncg Zm9yd2FyZGluZy1hZGphY2VuY3khDQoNCiAgIHwgICAgIHwgICAgICAgICstLXJ3IGhvbGR0aW1l PyAgICAgICAgICAgICAgIHVpbnQzMg0KDQogICB8ICAgICB8ICAgICAgICArLS1ydyBpbmNsdWRl LWlwdjYtdW5pY2FzdD8gICBib29sZWFuDQoNCiAgIHwgICAgICstLXJ3IGJhY2t1cC1iYW5kd2lk dGg/ICAgICAgIHVpbnQzMg0KDQogICB8ICAgICArLS1ydyBsb2FkLXNoYXJlPyAgICAgICAgICAg ICB1aW50MzINCg0KICAgfCAgICAgKy0tcncgYmlkaXJlY3Rpb25hbA0KDQogICB8ICAgICAgICAr LS1ydyBhc3NvY2lhdGlvbg0KDQogICB8ICAgICAgICAgICArLS1ydyBpZD8gICAgICAgICAgICAg IHVpbnQzMg0KDQogICB8ICAgICAgICAgICArLS1ydyBzb3VyY2U/ICAgICAgICAgIGluZXQ6aXAt YWRkcmVzcw0KDQogICB8ICAgICAgICAgICArLS1ydyBnbG9iYWwtc291cmNlPyAgIGluZXQ6aXAt YWRkcmVzcw0KDQogICB8ICAgICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAgIGJpZGlyLWFz c29jaWF0aW9uLXR5cGUNCg0KICAgKy0tcncgZ2xvYmFsLWNmZyENCg0KUmVnYXJkcywNClRhcmVr DQoNCkZyb206IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJp bkBodWF3ZWkuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMTQsIDIwMTQgYXQgMTE6MTIg QU0NClRvOiAibXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYu b3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4NClN1YmplY3Q6IFttcGxzXSDnrZTlpI06IFJlZ2Fy ZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1w bHMtdGUteWFuZy1jZmctMDANCg0KSGkgTVBMU2VyLA0KSSB3b3VsZCBsaWtlIHRvIHJlbWluZCB5 b3Ugb2YgdGhlIG90aGVyIHR3byBZYW5nIG1vZGVsIGRyYWZ0czogZHJhZnQtY2hlbi1tcGxzLXRl LXlhbmctY2ZnLTAwIGFuZCBkcmFmdC16aGFuZy1tcGxzLXRwLXlhbmctb2FtLTAwLiBXZWxjb21l IGNvbW1lbnRzIGFuZCBjb2xsYWJvcmF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGVuYmluKFJv YmluKQ0KDQoNCg0KDQoNCuWPkeS7tuS6ujogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIExpemhlbmJpbg0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTDmnIgxNOaXpSAy MjozNA0K5pS25Lu25Lq6OiByZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdhbmRoaUBjaXNjby5j b20+OyB0c2FhZEBjaXNjby5jb208bWFpbHRvOnRzYWFkQGNpc2NvLmNvbT47IHJzYXdheWFAY2lz Y28uY29tPG1haWx0bzpyc2F3YXlhQGNpc2NvLmNvbT4NCuaKhOmAgTogbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NCuS4u+mimDogW21wbHNdIFJlZ2FyZGluZyBkcmFmdC1nYW5k aGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmct MDANCg0KSGkgUmFrZXNoLCBUYXJlayAmIFJvYmVydCwNCkkganVzdCBzYXcgeW91IHByb3Bvc2Vk IHRoZSBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwLiBJIHdvbmRlciBpZiB5b3Ug YXJlIGF3YXJlIG9mIHRoZSBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDAgd2UgcHJvcG9z ZWQgb24gQXVndXN0IDE1LiBGcm9tIG91ciBwb2ludCBvZiB2aWV3LCB3ZSBhcmUgbm90IGV4cGVy aWVuY2VkIGVub3VnaCB0byByZW1pbmQgb3VyIE1QTFNlcnMgb2YgdGhlIG5ldyBkcmFmdCB0byBw cm9wb3NlIHBvc3NpYmxlIGRpc2N1c3Npb24gYW5kIGNvbGxhYm9yYXRpb24uIEkgY29tcGFyZWQg dGhlIHR3byBkcmFmdHMgYXMgZm9sbG93czoNCjEuIFRoZSBwb3NzaWJsZSBvdmVybGFwcGVkIHBh cnQNCiAgICAgIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMA0K ICAgICA0LjEuICBHbG9iYWwgTVBMUy1URSBEYXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0ICAgICAgIC0tPiAgICAgICAgIE1QTFMgVEUgR2xvYmFsIENvbmZpZ3Vy YXRpb24vUlNWUC1URSBHbG9iYWwgQ29uZmlndXJhdGlvbg0KICAgICA0LjIuICBNUExTLVRFIFR1 bm5lbCBJbnRlcmZhY2UgRGF0YSBNb2RlbCBPdmVydmlldyAuIC4gLiAuIC4gLiAuICA2ICAgIC0t PiAgICAgICAgIFJTVlAtVEUgVHVubmVsIENvbmZpZ3VyYXRpb24NCiAgICAgNC4zLiAgTVBMUy1U RSBUdW5uZWwgTFNQIERhdGEgTW9kZWwgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAgNyAg ICAgIC0tPiAgICAgICAgIFJTVlAtVEUgVHVubmVsIENvbmZpZ3VyYXRpb24NCiAgICAgNC40LiAg TVBMUy1URSBMaW5rIERhdGEgTW9kZWwgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOCAgICAgICAgLS0+ICAgICAgICAgTVBMUyBURSBMaW5rIENvbmZpZ3VyYXRpb24vUlNWUC1U RSBJbnRlcmZhY2UgQ29uZmlndXJhdGlvbg0KMi4gZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2Zn LTAwIGRlZmluZXMgZm9sbG93aW5nIGNvbmZpZ3VyYXRpb24gWWFuZyBiZXlvbmQgZHJhZnQtZ2Fu ZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0wMC4NCiAgICAgMy40LiAgRXhwbGljaXQgUGF0aCBDb25m aWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAzLjUuICBQ Mk1QIFRFIExlYWYgTGlzdCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA1DQogICAgIDMuOS4gIENTUEYgQ29uZmlndXJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAgICAgMy4xMC4gUDJNUCBURSBUdW5uZWwgVGVtcGxhdGUg Q29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOA0KMy4gZHJhZnQtY2hlbi1tcGxz LXRlLXlhbmctY2ZnLTAwIGhhcyBhbHJlYWR5IGRlZmluZWQgYWxsIFlhbmcgbW9kZWwgZm9yIHRo ZXNlIGxpc3RlZCBjb25maWd1cmF0aW9uIHdoaWxlIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmct bW9kZWwtMDAgbGVhdmVzIG1hbnkgWWFuZyBNb2RlbCBkZWZpbml0aW9uIGFzIHNwYWNlcy4NCg0K SSB0aGluayBtYXliZSB5b3UgYXJlIG5vdCBhd2FyZSBvZiB0aGUgZXhpc3RpbmcgZHJhZnQuIElm IHlvdSB3b3VsZCBsaWtlIHRvIGNvb3BlcmF0ZSBvbiB0aGUgTVBMUyBURSBZYW5nIE1vZGVscyBk ZWZpbml0aW9uLCB3ZSBhcmUgdmVyeSBnbGFkIHRvIGRpc2N1c3Mgd2l0aCB5b3UgdG8gdHJ5IHRv IHVuaWZ5IHRoZXNlIFlhbmcgbW9kZWxzLg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KWmhlbmJpbihS b2JpbikNCg0KDQoNCg== --_000_D0671B3F3F283rgandhiciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E78EF3C5FA5A841B36ED2A61A5CF07E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyAiPkhpIEVyaWMs PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgIj48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+V2UgZGVmaW5pdGVseSBh Z3JlZSB3aXRoIHlvdXIgZmVlZGJhY2suIFdlIGFscmVhZHkgcmVhbGl6ZSB0aGF0IHN0YW5kYXJk aXppbmcgYW55IFlBTkcgbW9kZWwgaGFzIHRvIGJlIGFzIGdlbmVyaWMgYXMgcG9zc2libGUuPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyAiPlRoaXMgaXMgd2h5IHdlIGFy ZSB0cnlpbmcgdG8gZGV0YWNoIG91cnNlbHZlcyBmcm9tIGFueSBwYXJ0aWN1bGFyIGltcGxlbWVu dGF0aW9uIGluY2x1ZGluZyBvdXJzLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgIj5XZSB3YW50IHRvIGNvdmVyIHRoZSBURSBhc3BlY3RzIGZyb20gbG9naWNh bCBwb2ludCBvZiB2aWV3LiBXZSBhcmUgYWxzbyBhaW1pbmcgdG8gY292ZXIgdGhlIHN0YW5kYXJk cyBpbiB0ZXJtcyBvZiB0aGUgbW9kZWwgY29udGVudHMgYW5kIG5hbWluZy48L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+TW9yZW92ZXIsIHdlIHRyeSB0byBoYXZlIG1v ZGVscyB0aGF0IGluY29ycG9yYXRlIHNvbWUgb2YgdGhlIG90aGVyIHZlbmRvcnMgJm5ic3A7c3Ry b25nIHBvaW50cyBldmVuIGlmIHRoZXkgYXJlIG5vdCBwcmVzZW50IGluIG91ciBpbXBsZW1lbnRh dGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+PGJyPg0KPC9k aXY+DQo8ZGl2PldlIHN0YXJ0ZWQgdGFsa2luZyB0byB0aGUgYXV0aG9ycyBvZiZuYnNwO2RyYWZ0 LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBhbmQgd2UgYXJlIGxvb2tpbmcgdG8gY29ubmVjdCB3 aXRoIG90aGVyIHZlbmRvcnMgYXMgd2VsbCZuYnNwOzxmb250PnRvIGpvaW4gdGhlIGVmZm9ydC48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250Pjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+UmVnYXJkczwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgIj5Sb2JlcnQsIFJha2VzaCBhbmQgVGFyZWs8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyAiPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0O09zYm9ybmUmZ3Q7LCBFcmljICZsdDs8YSBocmVmPSJt YWlsdG86ZXJpYy5vc2Jvcm5lQGxldmVsMy5jb20iPmVyaWMub3Nib3JuZUBsZXZlbDMuY29tPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRo dXJzZGF5LCAxNiBPY3RvYmVyLCAyMDE0IDM6MTggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtUYXJlayBTYWFkICh0c2FhZCkmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzp0c2FhZEBjaXNjby5jb20iPnRzYWFkQGNpc2NvLmNvbTwvYT4mZ3Q7 LCBMaXpoZW5iaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbSI+bGl6 aGVuYmluQGh1YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW21wbHNdIOetlOWkjTogUmVnYXJkaW5nIGRy YWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgYW5kIGRyYWZ0LWNoZW4tbXBscy10ZS15 YW5nLWNmZy0wMDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgeG1sbnM6dj0i dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0 ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBbmRhbGUgTW9ubyI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFu b3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1hbGlnbjpqdXN0 aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246bGVmdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OlNpbVN1bjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsN Cgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgXDk4ODRcOEJCRVw2ODNDXDVGMEYiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFw5 ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQpzcGFuLkhUTUxDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBcOTg4NFw4QkJFXDY4M0NcNUYw RiI7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSIgc3R5bGU9InRleHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JIGxvb2tlZCBhdCBib3RoIGRvY3VtZW50cy4mbmJzcDsgVGhleSBib3RoIGhhdmUgc29tZSBn b29kIGFuZCBzb21lIGJhZC4mbmJzcDsgVGhlIGhhcmRlc3QgcGFydCBpbiByZWNvbmNpbGluZyB0 aGVtIHdpbGwgYmUgdGhhdCB0aGV5IGJvdGggaGF2ZSBhIHZlcnkgdmVuZG9yLXNwZWNpZmljIHZp ZXcgb2YNCiB0aGUgd29ybGQuJm5ic3A7IFRoaXMgaXMgbm8gc3VycHJpc2UgZ2l2ZW4gdGhlIG5h dHVyZSBvZiB0aGUgdGVjaG5vbG9neSwgYW5kIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdW5pcXVl IHRvIFRFLiZuYnNwOyBCR1Agd2lsbCBiZSBhdCBsZWFzdCBhcyBoYXJkIHRvIHNvcnQgb3V0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkkgdGhpbmsgd2UgbmVlZCB0byBjbGVhcmx5IGRlbGluZWF0ZSBiZXR3ZWVuIHN0 YW5kYXJkIGZlYXR1cmVzLCBjb21tb24gZmVhdHVyZXMsIGFuZCB2ZW5kb3Itc3BlY2lmaWMgb25l cy4mbmJzcDsgU3RhbmRhcmQgZmVhdHVyZXMgbWlnaHQgYmUgc2NvcGVkIHRvIGFueXRoaW5nIHRo YXQgaXMgYm90aA0KIHNpZ25hbGVkIGFuZCBSRkPigJlkLCBlLmcuLCBbMzIwOSwgNDQyMCwgNDg3 NSwgNTcxMiwgNzMwOF0uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNvbW1vbiBhcmUgdGhpbmdzIHRoYXQgbWF5IGhh dmUgZGlmZmVyZW50IG5hbWVzIGFuZCB3aGljaCBhcmVu4oCZdCBzaWduYWxlZCwgYnV0IHdoaWNo IGFyZSBpbiB1c2UgaW4gbWFueS9tb3N0L2FsbCBpbXBsZW1lbnRhdGlvbnMg4oCTIHRoaW5ncyBs aWtlIHdoYXQgb25lIHZlbmRvciBjYWxscw0KIOKAmGF1dG9yb3V0ZSBhbm5vdW5jZeKAmSBhbmQg YW5vdGhlciBjYWxscyDigJhpZ3Agc2hvcnRjdXRz4oCZLiZuYnNwOyBGaW5kIGEgY29tbW9uIG5h bWUsIG9yIGEgd2F5IHRvIHVzZSBib3RoLCBhbmQgYnVpbGQgYSBtb2RlbCBmb3IgdGhlIHN1YnNl dCBvZiB0aGluZ3MgdGhhdCBpcyBtb3N0IGNvbW1vbiBhY3Jvc3MgdmVuZG9ycy4gJm5ic3A7VGhp cyBpcyBhIGJpdCBvZiBhIHF1YWdtaXJlIHNpbmNlIGRpZmZlcmVudCB2ZW5kb3JzIHdpbGwgaGF2 ZSBkaWZmZXJlbnQgYXBwcm9hY2hlcw0KIHRvIG1hbnkgZGV0YWlscyBvZiBjb21tb24gZmVhdHVy ZXMsIGFuZCBpdCBtYXkgYmUgdGhlIG1vc3QgZGlmZmljdWx0IHBhcnQgb2YgdGhpcyB3aG9sZSBl eGVyY2lzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5WZW5kb3Itc3BlY2lmaWMgdGhpbmdzIGFyZSBqdXN0IHRoYXQg 4oCTIHRoaW5ncyBpbXBsZW1lbnRlZCBpbiBhIHBhcnRpY3VsYXIgd2F5IGJ5IG9ubHkgb25lIHZl bmRvci4mbmJzcDsgQW4gZXhhbXBsZSBmcm9tIFJvYmVydCwgUmFrZXNoIGFuZCBUYXJla+KAmXMg ZG9jdW1lbnQgbWlnaHQgYmUgYXR0cmlidXRlLXNldHMsDQogd2hpY2ggbWF5IG5vdCBoYXZlIGFu IG9idmlvdXMgcGFyYWxsZWwgaW4gb3RoZXIgdmVuZG9yc+KAmSBnZWFyLiZuYnNwOyBJZiBub3Ro aW5nIGVsc2UgdGhlcmUgbmVlZHMgdG8gYmUgc29tZXBsYWNlIGEgdmVuZG9yIGNhbiBhcHBlbmQg aXRzIG93biBwcm9wcmlldGFyeSBtb2RlbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gdGhlIGVuZCBpdCBtYXkg YmUgbW9yZSBwcm9kdWN0aXZlIHRvIGRvIGl0IHRoaXMgd2F5IOKAkyBzdGFydGluZyB3aXRoIGEg bWluaW11bSBzZXQgb2Ygb2J2aW91bHkgY29tbW9uIGZlYXR1cmVzIGFuZCB3b3JraW5nIHVwIOKA kyB0aGFuIHRyeWluZyB0byByZWNvbmNpbGUgdHdvIGZ1bGx5DQogYmFrZWQgbW9kZWxzIHdpdGgg dmVyeSBkaWZmZXJlbnQgdmlld3Mgb2YgdGhlIHdvcmxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs aWduOmxlZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBtcGxzIFs8YSBocmVmPSJtYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+VGFyZWsgU2FhZCAodHNhYWQpPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBPY3RvYmVyIDE2LCAyMDE0IDk6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IExpemhl bmJpbjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPuetlOWkjTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+OiBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1w bHMtdGUteWFuZy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+SGkgUm9iaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZSB0 byB0aGUgZHJhZnQuIFdlIGhhZCBhIGxvb2sgYXQgaXQuIFdlIGFyZSBwcm9wb3NpbmcgYSBzbGln aHRseSBkaWZmZXJlbnQgbW9kZWwgdGhhdCBpbnRyb2R1Y2VzIGNsZWFyIGRlbGluZWF0aW9uIGJl dHdlZW4gY29uZmlndXJhdGlvbiwgb3BlcmF0aW9uYWwgKHN0YXRlKSwgUlBDIChleGVjdXRpb25h bCksIGFuZCBub3RpZmljYXRpb25zDQogZm9yIE1QTFMtVEUgdHVubmVscywgbHNwcywgbGlua3Ms IGFuZCBnbG9iYWwgZGF0YTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7 IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPm1vZHVs ZTogbXBscy10ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZh bWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsg JiM0MzstLXJ3IHR1bm5lbHMtY2ZnITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog OXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4m bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxzcHMtY2ZnITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBi bGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxpbmtzLWNmZyE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlm OyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBnbG9iYWwtY2ZnITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBN b25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0MzstLXJvIHR1bm5l bHMtb3BlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWls eTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0 MzstLXJvIGxzcHMtb3BlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBm b250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsm bmJzcDsgJiM0MzstLXJvIGxpbmtzLW9wZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7 ICI+Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBnbG9iYWwtb3BlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNv bG9yOiBibGFjazsgIj5ycGNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0 OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJz cDsmbmJzcDsgJiM0MzstLS14IHR1bm5lbHMtcnBjICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNl cmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0teCBsc3BzLXJwYyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog OXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4m bmJzcDsmbmJzcDsgJiM0MzstLS14IGdsb2JhbC1ycGMmbmJzcDsgJm5ic3A7ICZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBN b25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0MzstLS14IGxpbmtz LXJwYyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsg Ij5ub3RpZmljYXRpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBm b250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsm bmJzcDsgJiM0MzstLS1uIHR1bm5lbHMtbm90aWYgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2Vy aWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0MzstLS1uIGxzcHMtbm90aWYmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+ Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tbiBsaW5rcy1ub3RpZiAmbmJzcDsgJm5ic3A7ICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFs ZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgJiM0MzstLS1uIGds b2JhbC1ub3RpZiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2UgYWxzbyBoYXZlIGEgZGV0YWlsZWQgWUFO RyBtb2RlbCBpbi10aGUtd29ya3MgKGFzIHBlciB0aGUgYWJvdmUpIGFuZCB3ZeKAmXJlIHBsYW5u aW5nIHRvIGluY2x1ZGUgaW4gdGhlIG5leHQgdXBkYXRlIG9mIHRoZSBkcmFmdC4gRm9yIGV4YW1w bGUsIHRoZSB0dW5uZWxzIFlBTkcgbW9kZWwgbG9va3Mgc29tZXRoaW5nIGxpa2UgYmVsb3cuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkFzIGZvciBjb2xsYWJvcmF0aW9uLCB5ZXMsIHdlIGFyZSB3aWxsaW5nIHRvIGNvbnNvbGlk YXRlIG91ciBlZmZvcnRzIHdpdGggeW91IHRvIHByb2R1Y2UgdGhlIElFVEYgTVBMUy1URSBZYW5n IG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+bW9kdWxlOiBtcGxzLXRl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5k YWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyAmIzQzOy0tcncg dHVubmVscy1jZmchPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt ZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNw OyB8Jm5ic3A7ICYjNDM7LS1ydyB0dW5uZWwqIFtuYW1lIHR5cGVdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IG5h bWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5 cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZu YnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGUmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHVu bmVsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgdHVubmVsLWlkPyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjog YmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzY3JpcHRp b24/Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RyaW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1v bm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJ3IGRlc3RpbmF0aW9uKiBbYWRkcmVzc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjog YmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBh ZGRyZXNzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6aXAtYWRkcmVzczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25v Jywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgJiM0MzstLXJ3IHBhdGgtb3B0aW9uKiBbaW5kZXhdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29s b3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBpbmRleCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWls eTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgKHR5cGUpPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywg c2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS06KGR5bmFtaWMpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29s b3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZHluYW1pYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9y OiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICYjNDM7LS06KGV4cGxpY2l0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsg Ij4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJ3IGV4cGxpY2l0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAi PiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGV4cGxpY2l0LWhvcGxpc3QqIFtpbmRleF08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUg TW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyBpbmRleCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsg Ij4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGV4cGxpY2l0LWhvcC1hZGRyZXNz PyAmbmJzcDsgaG9wLWFkZHJlc3MtdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsg Ij4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGV4cGxpY2l0LWhvcC1hY3Rpb24/ Jm5ic3A7ICZuYnNwOyBob3AtYWN0aW9uLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxh Y2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0Mzst LXJ3IGlncC1jb25zdHJhaW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7 IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNw OyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3 IGlncD8mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW1lcmF0aW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1v bm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGFyZWEtbGV2ZWw/ICZuYnNwOyB1aW50 MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdB bmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHZlcmJhdGltPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog OXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4m bmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbG9j a2Rvd24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBib29sZWFuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJp ZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3 IGxzcC1jZmcqIFtpbmRleF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7 Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBpbmRleCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmcmVmPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQz Oy0tcncgc291cmNlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6aXAt YWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWls eTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGZhc3QtcmVyb3V0ZT8gJm5ic3A7ICZuYnNw OyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt aWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcmVjb3JkLXJvdXRlPyAmbmJzcDsgJm5i c3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1m YW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBzaWduYWxlZC1uYW1lPyZuYnNwOyAm bmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt ZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpb3JpdHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNl cmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7 IHwmbmJzcDsgJiM0MzstLXJ3IHNldHVwPyAmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBj b2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwmbmJz cDsgJiM0MzstLXJ3IGhvbGQ/Jm5ic3A7ICZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNv bG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0Mzst LXJ3IGFmZmluaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt ZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjb25zdHJhaW50cyog W2FjdGlvbl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWN0aW9uJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFmZmluaXR5LWFjdGlvbi10eXBlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBz ZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGNvbnN0cmFpbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBj b2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFmZmluaXR5LWxpc3QqIFtuYW1lXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFs ZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5i c3A7IHwmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBuYW1lJm5ic3A7ICZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7 ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXRoLXNl bGVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWls eTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY29zdC1saW1pdD8gJm5ic3A7 IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWls eTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgaG9wLWxpbWl0PyZuYnNwOyAm bmJzcDsgdWludDMyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt ZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBtZXRyaWM/ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHBhdGgtbWV0cmljLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjog YmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0 MzstLXJ3IHRpZWJyZWFrZXI/ICZuYnNwOyBwYXRoLXRpZWJyZWFrZXItdHlwZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywg c2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJz cDsgJiM0MzstLXJ3IGJmZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBm b250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsm bmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdHlwZT8gJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJmZC10eXBlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxl IE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBicmluZ3VwLXRpbWVvdXQ/Jm5ic3A7ICZuYnNw OyB1aW50MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGRhbXBlbmluZz8mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9y OiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm IzQzOy0tcncgZW5jYXAtbW9kZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJmZC1lbmNh cC1tb2RlLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1m YW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGZhc3QtZGV0ZWN0PyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6 IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj NDM7LS1ydyBsc3AtcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBm b250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsm bmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBk aXNhYmxlPyZuYnNwOyAmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFj azsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7 ICYjNDM7LS1ydyBpbnRlcnZhbD8gJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9y OiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm IzQzOy0tcncgbWluaW11bS1pbnRlcnZhbD8gJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7 IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZu YnNwOyAmIzQzOy0tcncgbXVsdGlwbGllcj8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVp bnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTog J0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJz cDsgJm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxvZ2dpbmctZXZlbnQqIFtldmVudF08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9u bycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGV2ZW50Jm5ic3A7ICZuYnNwOyBsb2dnaW5nLWV2ZW50 LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6 ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgKHBvbGljeS1yb3V0aW5nKT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBj b2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7 LS06KGZvcndhcmRpbmctY2xhc3MpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5 cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZu YnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBmb3J3 YXJkaW5nLWNsYXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt ZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGNsYXNz PyAmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9u dC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5i c3A7IHwgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS06KGZvcndhcmRpbmctZ3JvdXApPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxl IE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBmb3J3YXJkaW5nLWdyb3VwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBz ZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgY2xhc3NlcyogJm5ic3A7IHVpbnQ4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxl IE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJiM0MzstLXJ3IGF1dG8tYmFuZHdpZHRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNr OyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgb3ZlcmZs b3ctdGhyZXNob2xkPyZuYnNwOyAmbmJzcDsgdWludDMyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6 IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg b3ZlcmZsb3ctbGltaXQ/Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQ4PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8n LCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZu YnNwOyAmIzQzOy0tcncgdW5kZXJmbG93LXRocmVzaG9sZD8gJm5ic3A7IHVpbnQzMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25v Jywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgJiM0MzstLXJ3IHVuZGVyZmxvdy1saW1pdD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWlu dDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdB bmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjb2xsZWN0LW9ubHk/Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAi PiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IChhbm5vdW5jZS1hcyk/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxl IE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgfCZuYnNwOyAmIzQzOy0tOihhdXRvcm91dGUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJs YWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7 LS1ydyBhdXRvcm91dGUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZv bnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGlu Y2x1ZGUtaXB2Ni11bmljYXN0PyAmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9y OiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ydyAobWV0cmljLXR5cGUpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBi bGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tOihtZXRyaWMpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6 IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG1ldHJpYz8gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50ODxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25v Jywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tOihyZWxhdGl2ZS1tZXRy aWMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAn QW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJiM0 MzstLXJ3IHJlbGF0aXZlLW1ldHJpYz8mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRh bGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZu YnNwOyB8Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLTooYWJzb2x1 dGUtbWV0cmljKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZh bWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsg fCAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICYjNDM7LS1ydyBhYnNvbHV0ZS1tZXRyaWM/Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5 OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgfCZuYnNwOyAmIzQzOy0tOihmb3J3YXJkaW5nLWFkamFjZW5jeSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9u bycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGZvcndhcmRpbmctYWRqYWNlbmN5ITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywg c2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGhvbGR0aW1lPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDMyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJp ZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaW5jbHVkZS1pcHY2LXVuaWNhc3Q/ICZuYnNw OyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt aWx5OiAnQW5kYWxlIE1vbm8nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGJhY2t1cC1iYW5kd2lkdGg/ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250 LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBsb2FkLXNoYXJlPyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjog YmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYmlkaXJlY3Rp b25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTog J0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsmbmJzcDsgfCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYXNzb2NpYXRpb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNl cmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaWQ/Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsg Ij4mbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBzb3VyY2U/Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OmlwLWFk ZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6 ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5ic3A7IHwgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZ2xvYmFsLXNvdXJjZT8g Jm5ic3A7IGluZXQ6aXAtYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog OXB0OyBmb250LWZhbWlseTogJ0FuZGFsZSBNb25vJywgc2VyaWY7IGNvbG9yOiBibGFjazsgIj4m bmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyB0eXBlPyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpZGlyLWFz c29jaWF0aW9uLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9u dC1mYW1pbHk6ICdBbmRhbGUgTW9ubycsIHNlcmlmOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyBnbG9iYWwtY2ZnITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5UYXJlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+TGl6aGVuYmluICZsdDs8YSBocmVmPSJtYWlsdG86bGl6aGVuYmlu QGh1YXdlaS5jb20iPmxpemhlbmJpbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+VHVlc2RheSwgT2N0b2JlciAxNCwgMjAxNCBhdCAxMToxMiBBTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlttcGxzXSA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04i IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+ 562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj46 IFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1j aGVuLW1wbHMtdGUteWFuZy1jZmctMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgTVBMU2VyLDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGxpa2UgdG8g cmVtaW5kIHlvdSBvZiB0aGUgb3RoZXIgdHdvIFlhbmcgbW9kZWwgZHJhZnRzOiBkcmFmdC1jaGVu LW1wbHMtdGUteWFuZy1jZmctMDAgYW5kIGRyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1vYW0tMDAu IFdlbGNvbWUgY29tbWVudHMgYW5kIGNvbGxhYm9yYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlpoZW5iaW4oUm9iaW4pPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0 LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTaW1TdW47Y29sb3I6YmxhY2siPg0KIG1wbHMgWzxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj4NCjxzcGFu IGxhbmc9IlpILUNOIj7ku6PooaggPC9zcGFuPjwvYj5MaXpoZW5iaW48YnI+DQo8Yj48c3BhbiBs YW5nPSJaSC1DTiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjo8L2I+IDIwMTQ8c3BhbiBsYW5nPSJaSC1D TiI+5bm0PC9zcGFuPjEwPHNwYW4gbGFuZz0iWkgtQ04iPuaciDwvc3Bhbj4xNDxzcGFuIGxhbmc9 IlpILUNOIj7ml6U8L3NwYW4+IDIyOjM0PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7 tuS6ujwvc3Bhbj46PC9iPiA8YSBocmVmPSJtYWlsdG86cmdhbmRoaUBjaXNjby5jb20iPnJnYW5k aGlAY2lzY28uY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzp0c2FhZEBjaXNjby5jb20iPnRzYWFk QGNpc2NvLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpyc2F3YXlhQGNpc2NvLmNvbSI+DQpyc2F3 YXlhQGNpc2NvLmNvbTwvYT48YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5oqE6YCBPC9zcGFu Pjo8L2I+IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxi cj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+OjwvYj4gW21wbHNdIFJlZ2Fy ZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1w bHMtdGUteWFuZy1jZmctMDA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBSYWtlc2gsIFRhcmVrICZhbXA7IFJvYmVydCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkkganVzdCBzYXcgeW91IHByb3Bvc2VkIHRoZSBkcmFmdC1nYW5kaGktbXBscy10 ZS15YW5nLW1vZGVsLTAwLiBJIHdvbmRlciBpZiB5b3UgYXJlIGF3YXJlIG9mIHRoZSBkcmFmdC1j aGVuLW1wbHMtdGUteWFuZy1jZmctMDAgd2UgcHJvcG9zZWQgb24gQXVndXN0IDE1LiBGcm9tIG91 ciBwb2ludCBvZiB2aWV3LCB3ZSBhcmUgbm90IGV4cGVyaWVuY2VkIGVub3VnaCB0bw0KIHJlbWlu ZCBvdXIgTVBMU2VycyBvZiB0aGUgbmV3IGRyYWZ0IHRvIHByb3Bvc2UgcG9zc2libGUgZGlzY3Vz c2lvbiBhbmQgY29sbGFib3JhdGlvbi4gSSBjb21wYXJlZCB0aGUgdHdvIGRyYWZ0cyBhcyBmb2xs b3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MS4gVGhlIHBvc3NpYmxlIG92ZXJsYXBwZWQgcGFydDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWdhbmRoaS1tcGxzLXRl LXlhbmctbW9kZWwtMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4xLiZuYnNwOyBHbG9iYWwgTVBMUy1URSBEYXRhIE1vZGVs IE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDQmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7LS0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwO01QTFMgVEUgR2xvYmFsIENvbmZpZ3VyYXRpb24vUlNWUC1URSBH bG9iYWwgQ29uZmlndXJhdGlvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs0LjIuJm5ic3A7IE1QTFMtVEUgVHVubmVsIEludGVyZmFjZSBEYXRhIE1vZGVsIE92 ZXJ2aWV3IC4gLiAuIC4gLiAuIC4mbmJzcDsgNiZuYnNwOyZuYnNwOyZuYnNwOyAtLSZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7UlNWUC1URSBUdW5u ZWwgQ29uZmlndXJhdGlvbiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs0LjMuJm5ic3A7IE1QTFMtVEUgVHVubmVsIExTUCBEYXRhIE1vZGVsIE92ZXJ2 aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgNyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDstLSZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7UlNWUC1URSBUdW5uZWwgQ29uZmlndXJhdGlvbiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs0LjQuJm5ic3A7IE1QTFMtVEUgTGluayBEYXRhIE1v ZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgOCZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7TVBMUyBURSBMaW5rIENvbmZpZ3VyYXRpb24v UlNWUC1URSBJbnRlcmZhY2UgQ29uZmlndXJhdGlvbiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiBk cmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDAgZGVmaW5lcyBmb2xsb3dpbmcgY29uZmlndXJh dGlvbiBZYW5nIGJleW9uZCBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuNC4mbmJzcDsgRXhwbGljaXQgUGF0 aCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7 IDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjUuJm5ic3A7IFAyTVAg VEUgTGVhZiBMaXN0IENvbmZpZ3VyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNw OyZuYnNwOyA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy45LiZuYnNw OyBDU1BGIENvbmZpZ3VyYXRpb24mbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiZuYnNwOyZuYnNwOyA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMy4xMC4gUDJNUCBURSBUdW5uZWwgVGVtcGxhdGUgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMuIGRyYWZ0LWNoZW4tbXBscy10 ZS15YW5nLWNmZy0wMCBoYXMgYWxyZWFkeSBkZWZpbmVkIGFsbCBZYW5nIG1vZGVsIGZvciB0aGVz ZSBsaXN0ZWQgY29uZmlndXJhdGlvbiB3aGlsZSBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1v ZGVsLTAwIGxlYXZlcyBtYW55IFlhbmcgTW9kZWwgZGVmaW5pdGlvbiBhcyBzcGFjZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgdGhpbmsgbWF5YmUgeW91IGFyZSBub3QgYXdh cmUgb2YgdGhlIGV4aXN0aW5nIGRyYWZ0LiBJZiB5b3Ugd291bGQgbGlrZSB0byBjb29wZXJhdGUg b24gdGhlIE1QTFMgVEUgWWFuZyBNb2RlbHMgZGVmaW5pdGlvbiwgd2UgYXJlIHZlcnkgZ2xhZCB0 byBkaXNjdXNzIHdpdGggeW91IHRvIHRyeSB0byB1bmlmeSB0aGVzZSBZYW5nIG1vZGVscy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+WmhlbmJpbihSb2Jpbik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_D0671B3F3F283rgandhiciscocom_-- From nobody Fri Oct 17 16:53:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867AE1A7016 for ; Fri, 17 Oct 2014 16:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EicxdEJnO5TX for ; Fri, 17 Oct 2014 16:53:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555781A1AE1 for ; Fri, 17 Oct 2014 16:53:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9HNrr6e009014; Sat, 18 Oct 2014 00:53:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9HNroOE008988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Oct 2014 00:53:51 +0100 From: "Adrian Farrel" To: Date: Sat, 18 Oct 2014 00:53:44 +0100 Message-ID: <008101cfea65$973f7ab0$c5be7010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/qZZG4YDijfiaiRb6NYZl5ExppZA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21034.003 X-TM-AS-Result: No--1.018-10.0-31-10 X-imss-scan-details: No--1.018-10.0-31-10 X-TMASE-MatchedRID: WnUZF13Vb/BDsA41QLYxFHBRIrj8R47F9mnDjfUPq559WQH9y/pSXcCS 2AMm1nQCmDbYDOVEiGy92gLrEY12PRgHZ8655DOPOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDXRqMt8od8RYdRUa5D389wc5h47Brbmm16j7J3yrPomqQ6hDOU1xfzgsJ/jxlXnd3dp9x HuM9AfUiKeUbONtgeTe1ZwdZI0d1+GWChB6AgT5w== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HqYFFdoBLIQx4fmkf_DE7nvUUb4 Cc: mpls@ietf.org, Spencer Dawkins Subject: [mpls] AD review and progressing draft-ietf-mpls-deprecate-bgp-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:53:56 -0000 Hi, I've done my AD review of this tiny draft and have no additional comments. Any time you want to spell my name right, you can go right ahead :-) Since the document has only Juniper authors, I will follow the procedure Alia and I set out when she was appointed as my co-AD and pass the document to another AD to complete the process. Spencer Dawkins has agreed to step in to the breach. Thanks, Adrian From nobody Sat Oct 18 01:49:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3B1A1A68 for ; Sat, 18 Oct 2014 01:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4Ej878Vm-7m for ; Sat, 18 Oct 2014 01:49:11 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1881A1A45 for ; Sat, 18 Oct 2014 01:49:11 -0700 (PDT) Received: from [2.69.45.36] (2.69.45.36.mobile.tre.se [2.69.45.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0C103180006E; Sat, 18 Oct 2014 10:49:10 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Loa Anderson X-Mailer: iPad Mail (12A405) In-Reply-To: <542E752C.3020203@pi.nu> Date: Sat, 18 Oct 2014 10:49:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542E752C.3020203@pi.nu> To: "mpls@ietf.org" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/G6o86N-qw2wCSP_VCrlZvnvKXVM Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 08:49:13 -0000 Working Group, This poll has ended. We have a clear support to adopt the draft as a working= group document. Can the authors please re-post the draft as draft-ietf-mpls= -oam-ipv6-rao without any other changes that the administrative information.= /Loa Sent from my iPad > On 03 Oct 2014, at 12:06, Loa Andersson wrote: >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > There is no IPR disclosures against this document. >=20 > The authors has all stated on the working group mailing > list that they are unaware of any IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > This poll ends October 17, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Oct 18 09:36:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF911A1ADE for ; Sat, 18 Oct 2014 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yKCsSFOHm6t for ; Sat, 18 Oct 2014 09:36:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F991A1ADD for ; Sat, 18 Oct 2014 09:36:39 -0700 (PDT) Received: from BLUPR05MB627.namprd05.prod.outlook.com (10.141.204.150) by BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 16:36:16 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB627.namprd05.prod.outlook.com (10.141.204.150) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 16:36:15 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1054.004; Sat, 18 Oct 2014 16:36:15 +0000 From: John E Drake To: "George Swallow (swallow)" , Shahram Davari , Gregory Mirsky , "Mach Chen" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/Xpwyy8CAgABeSoCAAAMqgIAAj0KAgADS+gCAACmlgIAAAj0AgAAAzICAAAKbAIAAASUAgAADtwCAAANLgIAAGPiAgAAFsUCAAUi9sA== Date: Sat, 18 Oct 2014 16:36:15 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F2831D54A88@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB627;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(199003)(377454003)(51704005)(76104003)(24454002)(189002)(13464003)(37854004)(50986999)(46102003)(19580405001)(86362001)(2656002)(87936001)(92566001)(76576001)(4396001)(85306004)(19580395003)(15975445006)(54356999)(76176999)(74316001)(108616004)(80022003)(230783001)(40100003)(85852003)(95666004)(99286002)(122556002)(76482002)(99396003)(120916001)(33646002)(20776003)(21056001)(105586002)(101416001)(97736003)(106356001)(106116001)(66066001)(64706001)(107046002)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB627; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB723; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/otfOGCvah--U4WRVFJvSEkXl7Yc Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 16:36:43 -0000 Hi, In case any missed them, the operative phrases in my email, below, regardin= g the disposition of draft-chen-mpls-source-label are: 1) "This isn't right. This isn't even wrong." -- Wolfgang Pauli 2) Is it possible to euthanize an I-D? I.e., this draft is not even ill-considered and I oppose its adoption as a = WG draft. Yours Irrespectively, John > -----Original Message----- > From: John E Drake > Sent: Friday, October 17, 2014 2:10 PM > To: 'George Swallow (swallow)'; Shahram Davari; Gregory Mirsky; Mach Chen > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mp= ls- > source-label@tools.ietf.org > Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > George, >=20 > From the draft: >=20 > "For some applications, source identification is a critical requirement. = For > example, performance monitoring, the monitoring nodes need to identify > where packets were sent from and then can count the packets according to > some constraints." >=20 > What do you think could possibly be added to make this list of requiremen= ts > either more clear or more complete 8->? It should also be blindingly obv= ious to > the informed participant that to address this very complete set of > requirements the use of global source labels is the solution that immedia= tely > springs to mind even thought it is completely at odds w/ the MPLS > architecture. "This isn't right. This isn't even wrong." -- Wolfgang Pa= uli >=20 > Is it possible euthanize to an I-D? >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow > > (swallow) > > Sent: Friday, October 17, 2014 1:33 PM > > To: Shahram Davari; Gregory Mirsky; Mach Chen > > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > draft-chen-mpls- source-label@tools.ietf.org > > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > > Folks - > > > > We need a clear set of requirements! This is a huge change to MPLS. > > We certainly do not want to do it to meet a narrow set of > > requirements. We need to clearly articulate what we need in the way of > loss/delay measurement. > > Then we need to explore possible solutions. If a solution can be > > found that does not have a major hardware impact, then we should adopt > that. > > > > George > > > > On 10/17/14 3:04 PM, "Shahram Davari" wrote: > > > > >Hi Greg, > > > > > >I suggest you talk to your co-authors since Mach Chen just wrote this > > >in response to Nobo: > > > > > >> However, I agree with Stewart. The Introduction only specifies that > > >>"performance monitoring" is the only concrete requirement for this > > >>solution. > > >> From "performance monitoring" perspective, the proposed only > > >>provides a solution to limited [1] LSP types (and UHP/PHP of them) > > >>and [2] granularity of measurements. > > > > > >Mach: The solution is intended to solve an existing real problem. We > > >do not expect the solution that could apply to any scenario and solve > > >future occur issues, although it may have the potentiality. This is > > >also the tradition of IETF. > > > > > > > > >SD> First of all Mach says this is an existing real problem. > > >SD> Therefore I > > >would conclude he is not solving the EVPN LM. Secondly he says this > > >is not a generalized solution for future (aka EVPN). So just use the > > >LSP+PW counting and it will solve your problem quickly and without > > >LSP+any > > >respin of HW. No standard is even required, just information RFC. > > > > > >Thanks > > >Shahram > > > > > >-----Original Message----- > > >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > > >Sent: Friday, October 17, 2014 11:52 AM > > >To: Gregory Mirsky; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Greg, > > > > > >draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just > > >a framework and not requirements. I believe the EVPN OAM has much > > >more requirements than just adding a Source label. You have to > > >consider the Load balancing at multiple points, aliasing, Multi-homing= , etc. > > > > > >This requires much more discussion and a thorough requirements > > >analysis before coming to a quick rush solution such a source-label. > > > > > > > > >Thanks > > >Shahram > > > > > >-----Original Message----- > > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > >Sent: Friday, October 17, 2014 11:39 AM > > >To: Shahram Davari; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Shahram, > > >thank you for pointing this. We will review references and update the > > >document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, > > >draft-kumar-spring-sr-oam-requirement, and > > >draft-ashwood-nvo3-oam-requirements, if any is missing. > > > > > > Regards, > > > Greg > > > > > >-----Original Message----- > > >From: Shahram Davari [mailto:davari@broadcom.com] > > >Sent: Friday, October 17, 2014 11:35 AM > > >To: Gregory Mirsky; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Greg > > > > > >I think you are jumping too far. The draft only mentions RFC5036 and > > >RFC4364 as requirements and not EVPN. Are you adding new requirements > > >on the fly? > > >We will solve the EVPN LM when the time comes. (LSP+PW) label > > >counting can be done today without any HW change. > > > > > >Thanks > > >Shahram > > > > > >-----Original Message----- > > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > >Sent: Friday, October 17, 2014 11:26 AM > > >To: Shahram Davari; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Shahram, > > >and if this is EVPN and no PW exist? Are you going to offer piecemeal > > >solutions or look for more generic mechanism? I do believe that > > >SLI/SL, though may cause some pain, is useful and generic solution to > > >the real problem. > > > > > > Regards, > > > Greg > > > > > >-----Original Message----- > > >From: Shahram Davari [mailto:davari@broadcom.com] > > >Sent: Friday, October 17, 2014 11:23 AM > > >To: Gregory Mirsky; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Greg, > > > > > >How about using a combination of (LSP label + PW Label) to uniquely > > >identify the source of the LSP? > > > > > >Thanks > > >Shahram > > > > > >-----Original Message----- > > >From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > >Sent: Friday, October 17, 2014 11:15 AM > > >To: Shahram Davari; Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Hi Shahram, > > >using characteristic information from IP or Ethernet layer to measure > > >MPLS performance? That would be another layer violation, would it not? > > >And what if your payload is neither IP, nor Ethernet, just of > > >academic argument sake? > > >IP has IP PM with OWAMP/TWAMP as active measurement protocol. > > Ethernet > > >- Y.1731. And in both cases none relies on another layer addressing > > >information. I think that what you're suggesting is not the right > > >way, even if customers are buying it for the time being. > > > > > > Regards, > > > Greg > > > > > >-----Original Message----- > > >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > > >Sent: Friday, October 17, 2014 8:46 AM > > >To: Mach Chen > > >Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >draft-chen-mpls-source-label@tools.ietf.org > > >Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > > > > >Let me give you a proper example instead. > > > > > >This is like adding a custom made motor to your son's bike since he > > >wants to get to school faster. While a better solution is just give > > >him a motorcycle or car instead of inventing something new. > > > > > >The solution to DLM already exists. > > > > > >You might say this is optional but as we know vendors have to > > >implement options too. > > > > > >I think the 3 extra labels this solution adds to solve a problem that > > >can be solved using other methods is by itself a show stopper. > > > > > >As Stewart said we need another 2-3 labels for the EL. > > > > > >Another possible way of doing this is by just using SIP from the > > >encapsulated IP header or SA from the encapsulated Ethernet header. > > > > > >Regards, > > >Shahram > > > > > > > > >> On Oct 16, 2014, at 8:10 PM, "Mach Chen" > > wrote: > > >> > > >> HI Shahram, > > >> > > >>> Similarly in this case, if a service provider wants to use MPL S > > >>> and do Direct Loss Measurement (DLM), then they must use P2P > > >>> RSVP-TE LSPs, otherwise they can use MP2MP LDP LSPs. > > >> > > >> If I was a service provider, I will not buy this logic. It just > > >> like someone's son is not good at math, then you suggest him to > > >> replace the son with someone else who is good at math :-) > > >> > > >> > > >> Best regards, > > >> Mach > > >> > > >>> -----Original Message----- > > >>> From: Shahram Davari [mailto:davari@broadcom.com] > > >>> Sent: Friday, October 17, 2014 2:38 AM > > >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > > >>> draft-chen-mpls-source-label@tools.ietf.org > > >>> Cc: mpls-chairs@tools.ietf.org > > >>> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label > > >>> > > >>> Hi, > > >>> > > >>> This is similar to the Traffic Engineering argument. If a service > > >>> provider wants to use MPL S and do traffic Engineering then they > > >>> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. > > >>> > > >>> Similarly in this case, if a service provider wants to use MPL S > > >>> and do Direct Loss Measurement (DLM), then they must use P2P > > >>> RSVP-TE LSPs, otherwise they can use MP2MP LDP LSPs. > > >>> > > >>> Thanks > > >>> Shahram > > >>> > > >>> -----Original Message----- > > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram > > >>> Davari > > >>> Sent: Thursday, October 16, 2014 11:26 AM > > >>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org; > > >>> draft-chen-mpls-source-label@tools.ietf.org > > >>> Cc: mpls-chairs@tools.ietf.org > > >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > >>> > > >>> Hi, > > >>> > > >>> I agree with Stewart. I am not convinced such a label is required. > > >>> This draft adds multiple labels to the label stack (makes the > > >>> label stack much larger than it already is) and requires a respin > > >>> of chips due to its special label handling in the data-plane. > > >>> > > >>> An alternative solution for MP2MP or MP2P Loss Measurement is to > > >>> use ILM from RFC6374. > > >>> > > >>> So until a solid argument is put forward that existing solutions > > >>> (ILM in RFC 6374) or possible other solutions not requiring HW > > >>> change are not adequate, I think it is premature To adopt this draf= t. > > >>> > > >>> > > >>> Thanks > > >>> Shahram > > >>> > > >>> -----Original Message----- > > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart > > >>> Bryant > > >>> Sent: Thursday, October 16, 2014 5:49 AM > > >>> To: Ross Callon; mpls@ietf.org; > > >>> draft-chen-mpls-source-label@tools.ietf.org > > >>> Cc: mpls-chairs@tools.ietf.org > > >>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > > >>> > > >>> Ross > > >>> > > >>> You state that you are starting an IPR poll with a view to > > >>> determining whether this draft is ready for adoption as a WG draft. > > >>> > > >>> It is my view that it is premature to adopt a solution draft such > > >>>as this without first achieving a common understanding of all the > > >>>requirements. > > >>> In this particular case, the solution on the table will require a > > >>>hardware re-spin and will consume a precious 0..15 reserved label > > >>>which is something that we should not do lightly. > > >>> > > >>> In addition I am not convinced that the full set of requirements > > >>>are taken into account in the proposed design. For example the > > >>>solution only proposes to identify the source LSR, whereas it seems > > >>>likely that a finer granularity of flow identification will be > > >>>needed in practice. Additionally in the only use case cited > > >>>(performance > > >>> monitoring) it seems likely that accounting demarcation will be be > > >>>needed to allow for different delays of the ECMP paths and the > > >>>distribution of packets across multiple receiver interfaces. > > >>> > > >>> I think that we need to backup the process and start by agreeing > > >>> the set of requirements before we embark on a design which will be > > >>> expensive in MPLS protocol and implementation resource. > > >>> > > >>> As such I think the IPR poll, and the imminent intention to adopt > > >>>is premature. > > >>> > > >>> - Stewart > > >>> > > >>> > > >>> _______________________________________________ > > >>> mpls mailing list > > >>> mpls@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls > > >>> > > >>> _______________________________________________ > > >>> mpls mailing list > > >>> mpls@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Oct 18 13:19:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A309C1A0278 for ; Sat, 18 Oct 2014 13:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQnVgMpKqmm8 for ; Sat, 18 Oct 2014 13:19:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 E39E51A0276 for ; Sat, 18 Oct 2014 13:19:36 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id AF144DBD69ACA for ; Sat, 18 Oct 2014 20:19:30 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9IKJXOI009776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 18 Oct 2014 22:19:34 +0200 Received: from [135.244.192.120] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 18 Oct 2014 22:19:33 +0200 Message-ID: <5442CB54.3060709@alcatel-lucent.com> Date: Sat, 18 Oct 2014 22:19:32 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fnRaog5t-VBJtyvpEBDOo0GNE3E Subject: [mpls] Slots requests for MPLS WG sessions - IETF 91 - Honolulu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Martin Vigoureux , "mpls-chairs@tools.ietf.org" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 20:19:38 -0000 All, it is time we start building the MPLS WG agenda for Honolulu. The IETF agenda is available at: https://datatracker.ietf.org/meeting/agenda/ The MPLS WG sessions are scheduled on: Monday, November 10th, Morning Session I, 09:00-11:30 and Friday, November 14th, Morning Session I, 09:00-11:30 Please send *me* (by replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + Q&As) *as well as* what the objective of the presentation is. Please send the requests before the 26th of October. Thank you Martin From nobody Sat Oct 18 17:39:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892021A1B6A; Sat, 18 Oct 2014 17:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLAvFMYmd8M5; Sat, 18 Oct 2014 17:39:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6481A00CD; Sat, 18 Oct 2014 17:39:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141019003919.6168.24905.idtracker@ietfa.amsl.com> Date: Sat, 18 Oct 2014 17:39:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tnNInyNCnvOBeRoh3NzVqllWW3A Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-pim-sm-over-mldp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 00:39:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Authors : Yakov Rekhter Rahul Aggarwal Nicolai Leymann Wim Henderickx Quintin Zhao Richard Li Filename : draft-ietf-mpls-pim-sm-over-mldp-02.txt Pages : 12 Date : 2014-10-18 Abstract: When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-pim-sm-over-mldp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-pim-sm-over-mldp-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 Sat Oct 18 22:45:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9FE1A1BB3 for ; Sat, 18 Oct 2014 22:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQJzVMY4T3T7 for ; Sat, 18 Oct 2014 22:45:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66DB1A1B6F for ; Sat, 18 Oct 2014 22:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1714; q=dns/txt; s=iport; t=1413697519; x=1414907119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CoVZ1/kqCmh+QwulWBWtflHKyvs6WlJHZkJNEFm+E7s=; b=aVCDlsfPfSeJ95V0FREHx3Jth5Ns5s37dYvh1oAnrZ8SxVUDPzMsivN3 sM6UCURfpXttdN7ZRFJLcf4sfUxPsHwfTkuQf5uD0cjUfL4u+VeIvZfn4 Hv2hx/o0SQTxxFtezwDDANIaezmChMzYmzKlp5DqJjFM/mSo10f5eAOYm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADRPQ1StJA2D/2dsb2JhbABbgwtTWAS6I5FmCodOAoEOFgF9hAMBAQQBAQE3MQMLDgICAQgYHhAbDAslAgQBDQWIPw2/TAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI9rEQFQB4RLBZIAi1mBMINGjSuEAYI0gUNsgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,748,1406592000"; d="scan'208";a="361347389" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 19 Oct 2014 05:45:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9J5jGxQ026540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Oct 2014 05:45:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.11]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 00:45:16 -0500 From: "Kamran Raza (skraza)" To: Loa Anderson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP6rBpYyZv9/1Ur0emO8KsoJZI/pw2+xSA Date: Sun, 19 Oct 2014 05:45:16 +0000 Message-ID: References: <542E752C.3020203@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.252.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CwqvYnFBFRBRYUXoxwTWsV6n6Ss Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 05:45:21 -0000 Sure, we will post the draft shortly. On 2014-10-18, 4:49 AM, "Loa Anderson" wrote: >Working Group, > >This poll has ended. We have a clear support to adopt the draft as a >working group document. Can the authors please re-post the draft as >draft-ietf-mpls-oam-ipv6-rao without any other changes that the >administrative information. > >/Loa > >Sent from my iPad > >> On 03 Oct 2014, at 12:06, Loa Andersson wrote: >>=20 >> Working Group, >>=20 >> This is to start a two week poll on adopting >> draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >>=20 >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >>=20 >> There is no IPR disclosures against this document. >>=20 >> The authors has all stated on the working group mailing >> list that they are unaware of any IPR claims against this draft. >>=20 >> However if you are on the the mpls working group mailing list and >> aware of IPR that relates to this draft, the time to disclose >> this is now. >>=20 >> This poll ends October 17, 2014. >>=20 >> /Loa >>=20 >> for the MPLS wg co-chairs >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Oct 19 00:06:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C699A1A0013 for ; Sun, 19 Oct 2014 00:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cprB00iytK3 for ; Sun, 19 Oct 2014 00:06:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC3A1A000C for ; Sun, 19 Oct 2014 00:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1973; q=dns/txt; s=iport; t=1413702394; x=1414911994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VoqJ1uKYoYNKMBQ/v2Hqlq+UVlin2PvR5H6yg58uLn8=; b=iS8qYSUJYgeAvqZh66RcIygfndZBX1sRdnt3Lbb1BAS8hagBwCvgyBXN IbMKvuw13kEXjQHpgabkFU/HNMR6R9UlXUW5x3C1+McWtOJMf0lTdoyEg XOVwWikiXjnxBDuwTJPlkECSg4GHg0K3srBV4uqpO/bCF3VVyYtOixCad o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFALZhQ1StJA2F/2dsb2JhbABbgwtTTgoEuiORZgqHTgKBDhYBfYQDAQEEAQEBaAMLDgICAQgYLhsMCyUCBAENBYg/Db8zAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEj2sRAVAHhEsFiySGXItZgTCDRo0rhAGCNIFDbIEPOYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208";a="364474509" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 19 Oct 2014 07:06:34 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9J76XLE018085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Oct 2014 07:06:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.11]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 02:06:33 -0500 From: "Kamran Raza (skraza)" To: "Kamran Raza (skraza)" , Loa Anderson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc Thread-Index: AQHP6rBpYyZv9/1Ur0emO8KsoJZI/pw2+xSAgAAWtgA= Date: Sun, 19 Oct 2014 07:06:32 +0000 Message-ID: References: <542E752C.3020203@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.252.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E16E49EAF443B41AC11E4CD2169487E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HkHfR8X61-lXxkfqOu7s4WGQbKI Cc: "mpls-chairs@tools.ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-raza-mpls-oam-ipv6-rao an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 07:06:39 -0000 I have posted the new rev -00 with =B3draft-ietf=B2. The submission is done but the approval is pending on WG chair. Thx On 2014-10-19, 1:45 AM, "Kamran Raza (skraza)" wrote: >Sure, we will post the draft shortly. > >On 2014-10-18, 4:49 AM, "Loa Anderson" wrote: > >>Working Group, >> >>This poll has ended. We have a clear support to adopt the draft as a >>working group document. Can the authors please re-post the draft as >>draft-ietf-mpls-oam-ipv6-rao without any other changes that the >>administrative information. >> >>/Loa >> >>Sent from my iPad >> >>> On 03 Oct 2014, at 12:06, Loa Andersson wrote: >>>=20 >>> Working Group, >>>=20 >>> This is to start a two week poll on adopting >>> draft-raza-mpls-oam-ipv6-rao-02 as an MPLS working group document. >>>=20 >>> Please send your comments (support/not support) to the mpls working >>> group mailing list (mpls@ietf.org). Please give a technical >>> motivation for your support/not support, especially if you think that >>> the document should not be adopted as a working group document. >>>=20 >>> There is no IPR disclosures against this document. >>>=20 >>> The authors has all stated on the working group mailing >>> list that they are unaware of any IPR claims against this draft. >>>=20 >>> However if you are on the the mpls working group mailing list and >>> aware of IPR that relates to this draft, the time to disclose >>> this is now. >>>=20 >>> This poll ends October 17, 2014. >>>=20 >>> /Loa >>>=20 >>> for the MPLS wg co-chairs >>> --=20 >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > From nobody Sun Oct 19 00:07:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884571A001A; Sun, 19 Oct 2014 00:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa2z2HTkcuRo; Sun, 19 Oct 2014 00:07:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 199A61A0006; Sun, 19 Oct 2014 00:07:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141019070732.3637.32574.idtracker@ietfa.amsl.com> Date: Sun, 19 Oct 2014 00:07:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TAKFdINsOuPxnT7JCWjgiN_AUGw Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-oam-ipv6-rao-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 07:07:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-ietf-mpls-oam-ipv6-rao-00.txt Pages : 5 Date : 2014-10-19 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-oam-ipv6-rao-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 19 13:31:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B471A6F7E for ; Sun, 19 Oct 2014 13:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzmlmL5LYdW4 for ; Sun, 19 Oct 2014 13:30:59 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689291A6F8A for ; Sun, 19 Oct 2014 13:30:59 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9JKUukd000570; Sun, 19 Oct 2014 21:30:56 +0100 Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9JKUrxC000540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Oct 2014 21:30:55 +0100 From: "Adrian Farrel" To: "'Sam Aldrin'" References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> In-Reply-To: <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> Date: Sun, 19 Oct 2014 21:30:50 +0100 Message-ID: <000001cfebdb$966acaa0$c3405fe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF/pdyeP66Oj6m75MIWld08Pg9XHgGBADhynMxWKmA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21038.002 X-TM-AS-Result: No--21.906-10.0-31-10 X-imss-scan-details: No--21.906-10.0-31-10 X-TMASE-MatchedRID: 9vvqFUF7IWk4HKI/yaqRm86vz9r9NIijGNMTWh+TA9tcKZwALwMGs2n+ ZklyqxAEw/XbfgDonR/qeMF40HjEq1GwFwdOGsB3XbTfocfAWb/3JLu++S9VRpMxNpDOG+h6HOW W/Rp/isr8VHo6G3Z6LqElnJ9d1F2ICO+xk15zOXTOeIV+MVeozgXXmzqmsIi7HL8D2Jlysh/25f V6sdKa1ruOi1h8ys03nTOBcTulmoEoMmKpHm2CtTCIlN/eSPB9Kx5ICGp/WtHIvQIyugvKdXqTh zRnmCXSClo/pc4UOG+hGGCt9tM+c+2BiAEaYX2ewtxO0yU8hpUHevTGT3uBiFvo8FSqar5SIL+j 00cxUVopuXDkBXQ7Wbe9oArc/WZWZ0UbqdNQrsuVOwZbcOalS0KzuF0egUUDqanaW7tMOzo6HpL 1rTu6fgpQXUCxx6PZ/YxFsESgS9EcYHsGkuuPpe4cR1fWOaygVX7TxgU0dK5kljqvtoNIdiKjPe 4FIcZXOM9bGTvu+ELCl8APrESr9Xd1pR4I4fod6rBZUF8y6+g1TzP60UkdHcgQbkHs2Rjy/O8v7 /ij1TygNiVDXf8v8SS6Iy62DYwpQC3LLi0TN9p/X+VjlJBqd1WFfI9jgEJlut/GVGOoEnf0/WAk 5AfCS59fgc3KiNKkeTjw/FyRX6RNfs8n85Te8v7E6GNqs6ceseWplitmp0j6C0ePs7A07QKmARN 5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yrxCgA4KmPqcnmpPbBG4h6Sux28 Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org, 'mpls' Subject: Re: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:31:03 -0000 Hi Sam, > >> Do you really need the pre-RFC5378 disclaimer? > As this updates or add to RFC4379, we need that. Would you agree? No, not really. You can included it if you believe you are reproducing text that does not have a transfer of copyright and for which it is hard to get the authors to confirm copyright transfer. But the act of updating is not, itself, a reason to include the disclaimer. > >> Section 2 would be enhanced by a figure. [snip] > %sam - We deliberated on this and feel it will add more confusion than helping > the reader to understand. Also, it may necessitates lot of changes to the text to > reflect the use of R1, R2 etc. > Would you be ok if we don't add this ASCII art and keep it simple? I won't object more than to say "I thought it would help". > >> It seems that proxy ping messages would be relatively easy to spoof. > >> This, combined with the fact that the receipt of a proxy ping causes > >> the proxy to retain state and to issue echo requests to the network > >> looks like two DoS vectors for the price of one. > >> > >> So, I think you need: > >> - discussion of authentication for proxy requests > >> - recommendation to rate limit receipt of proxy requests > >> - recommendation to discard "duplicate" proxy requests > >> > %sam - Proxy do NOT maintain any state. Hence, not sure why the above apply to > proxy and not regular Echo requests. When proxy echo request is, it (proxy LSR) > merely issues a request and no state is maintained on it. > For ex: it has no way to discard duplicate requests, because is doesn't maintain > any state for the requests. I read in 3.2 (the description of processing at a Proxy) The header fields Sender's Handle and Sequence Number are not examined, but are saved to be included in the MPLS proxy ping reply or MPLS Echo Request messages. Maybe that "saving" is ambiguous? Maybe this is an implementation specific note for the message that is being built, and is not actually "state". If so, I think you should strike "saved to be", s/message/message/ and add "...if one is sent as a direct result of the received message." Anyhow, the fact that a branch node will make copies of a ping to send downstream *is* a vector. > >> I'm not quite sure about the initiator being allowed to instruct the > >> proxy about which source port it must use in an echo request. > >> > >> (Incidentally, Section 3.2 doesn't restate that this has to happen > >> although 3.2.4.1 does restate it). > >> > >> What happens if the proxy request asks for a reserved port number to be > >> used? What if the port is already in use by the proxy for something > >> else? Why does it matter which source port the proxy uses? Why does the > >> proxy need to be able to control that? Why can't the proxy select its > >> own source port? > %sam - I think there is some confusion here. The source port number is not to > request Proxy to use, rather to issue a request, so that the replying router could > send the reply back to the initiator at the right port. > proxy echo request does not specify what port Proxy has to use. Section 3.1 is about how to handle a received Proxy message The Reply mode and Global Flags of the Proxy Echo Parameters TLV are set to the values to be used in the MPLS Echo Request message header. The Source UDP Port is set to the value to be used in the MPLS Echo Request packet. The TTL is set to the value to be used in the outgoing MPLS label stack. See Section 5.1 for further details. 3.2.4.1 is describing how to build an echo request from a proxy request. The message is then encapsulated in a UDP packet. The source UDP port is copied from the Proxy Echo Parameters TLV. The destination port copied from the proxy ping request message. And to be clear section 5.1 describes the Proxy Echo Parameters TLV The Proxy Echo Parameters TLV is a TLV that MUST be included in an MPLS proxy ping request message. I didn't go back and search the rest of the document. If you do not intend that the proxy message can control the ports used in the echo request, I think you have some text to fix. But surely this text is clear and reflects the intention of the WG, in which case my questions hold. Cheers, Adrian From nobody Sun Oct 19 13:48:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769221A0271 for ; Sun, 19 Oct 2014 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz-arARjbGbo for ; Sun, 19 Oct 2014 13:48:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A661A0231 for ; Sun, 19 Oct 2014 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5762; q=dns/txt; s=iport; t=1413751696; x=1414961296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cORYc9eQufU7qGTuE/oHGb9rHnXX86jGBu348Inw0iM=; b=Chs+W+itQxZKy9K6xmx5R/3p/fs75sJIqHuEYbaJBM42ue97sFKNO0w6 G6EiqDFcHsvB+LeNvH2mlSbVv5UwjhUAqWa9QM2Os3QzIj136KGirqIX+ zfNG121ySTNe3okl3tbL6jT+gNiyio7iRlSnG65wpykQi84EyDyQM9hyM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFABcjRFStJA2J/2dsb2JhbABbgmgjU1gEzAkKh04CgQ4WAX2EAgEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgBiDYBDL9sAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AgMQcGgyeBHgWPZIIchEaIQzyDCpEsg3dsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208";a="364557022" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2014 20:48:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9JKmEbE001193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Oct 2014 20:48:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 15:48:13 -0500 From: "Nobo Akiya (nobo)" To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0IawwgEFPqICAArRj8A== Date: Sun, 19 Oct 2014 20:48:12 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FDyoXbxe4XfiaxoCz7zD-eTve0U Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:48:17 -0000 MPLS WG, Many thanks for kicking this off Mustapha. I, for one, like Mustaphas suggestion and would be supportive of making tha= t change. I would also be happy to change draft-ietf-mpls-lsp-ping-reply-mo= de-simple document to reflect this change, if there are consensus to do so. I have cc'ed the authors of RFC7110 in case they can also chime in with tho= ughts. Additionally, suggested changes should be very minimal even to those who ha= s already implemented RC7110. However, if anybody has implemented and if an= ybody has concerns, I think this is a great time for to speak up. Thanks! -Nobo > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, October 17, 2014 6:19 PM > To: Nobo Akiya (nobo); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net) > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e- > 00.txt >=20 > Dear all, > This is a follow-up to the action below from the MPLS-RT review of this d= raft. >=20 > Instead of defining a new reply mode as proposed in Section 3.1 of the dr= aft, > I suggested to relax the rule in RFC 7110 such that if the echo request > includes reply mode 5 "Reply via Specified Path" and the Reply Path TLV w= as > not included, the responder node will interpret this as an implicit reque= st to > reply via the reverse direction of the tested LSP. >=20 > This approach would address the requirement that the sender be able of > requesting the reply via the reverse path of an LSP without having to > include an additional TLV. >=20 > I appreciate comments on this proposal. >=20 > Regards, > Mustapha. >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > (nobo) > > Sent: Saturday, September 06, 2014 9:59 AM > > To: mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net) > > Subject: Re: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > Thank you Ross and the WG. > > > > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > Authors would like the WG help to discuss and close off on these two > aspects: > > > > - From Bruno Decraene: Reply Mode for SPRING and applicability of > this > > document. > > o There's already a thread for this. > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > o Mustapha or myself will start a thread on this topic later. > > > > Once above are close off, then we will roll out -01 that includes: > > > > - Conclusion from the two aspects above. > > - A comment received from Tarek Saad. > > - Comments received from Lou Berger (will reply to the review > comments > > from Lou soon) > > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp= -ping- > reply-mode- > > simple-00.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-pi= ng-reply- > mode- > > simple/ > > Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-rep= ly- > mode-simple-00 > > > > Thanks! > > > > -Nobo, on behalf of authors > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > drafts@ietf.org > > > Sent: Saturday, September 06, 2014 3:41 AM > > > To: i-d-announce@ietf.org > > > Cc: mpls@ietf.org > > > Subject: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > 00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Multiprotocol Label Switching > > > Working Group of the IETF. > > > > > > Title : Label Switched Path (LSP) Ping/Traceroute R= eply Mode > > > Simplification > > > Authors : Nobo Akiya > > > George Swallow > > > Carlos Pignataro > > > Loa Andersson > > > Mach(Guoyi) Chen > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > Pages : 11 > > > Date : 2014-09-05 > > > > > > Abstract: > > > The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) > > > Ping and Traceroute use the Reply Mode field to signal the method = to > > > be used in the MPLS echo reply. This document adds one value to t= he > > > Reply Mode field to indicate reverse LSP. This document also adds= an > > > optional TLV which can carry ordered list of Reply Mode values. > > > > > > This document updates RFC4379. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode > > > - > > > simple/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simpl > > > e- > > > 00 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Oct 19 23:35:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D710F1A6FA0; Sun, 19 Oct 2014 23:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7OWbdQ9aLO7; Sun, 19 Oct 2014 23:35:55 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF081A0378; Sun, 19 Oct 2014 23:35:54 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb1so4505640pad.25 for ; Sun, 19 Oct 2014 23:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=p75a6uDOdh5BGbYzctWuGn1iL80pP30rxLZV96CU+1k=; b=OZ/eD54y2NFf2LA+LEEZB+LFpBFNosR95xgJ+xitb/D5VSBYBxkcZpSqAumO+Am5Xi gTUbz3ZNeQfUKW6uQUBjS2xXF2Nz2QBMmw1Wk5Qt4c9HnWf3bwwVs0O90StHvhl8kZdC NPuhMUGI9xb0s2BLQC6MeU5Tvo3Mq6JOYz4dQG4hszTB861RW2/XVujqiXMhg3lRnOcQ y8Pt6qzWTkQVlGhvnYD7AOu4+gE801YUwgwgBnTpiQOMO49Q5yACyDaGTNbOcL2anea9 Pf6Ez1h1C3HYdzWqMNcb4uAZP87hOp/1Ft30RGem/8BNHv08Ov2U6bA5cQJVLL0jEpen Ssvw== X-Received: by 10.70.51.42 with SMTP id h10mr25279255pdo.21.1413786954540; Sun, 19 Oct 2014 23:35:54 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id ki1sm8180706pdb.59.2014.10.19.23.35.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 19 Oct 2014 23:35:53 -0700 (PDT) From: "Lizhong Jin" To: Date: Mon, 20 Oct 2014 14:35:48 +0800 Message-ID: <012001cfec30$18d91920$4a8b4b60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/sFilNAh9y4m1ARjuK37y9yFgbfA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EzgYpodQXPosrFAaiSgAnRgVo1Q Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , mahoney@nostrum.com, ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:35:57 -0000 Hi Joel, Sorry for the late reply. I missed this email, and was reminded by Adrian. Thank you for the review. Please see my comments inline below. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 08 Oct 2014 19:20:17 -0400 > From: "Joel M. Halpern" > To: "A. Jean Mahoney" , gen-art@ietf.org, > "mpls@ietf.org" , Adrian Farrel > , > IETF discussion list > Subject: [mpls] [Gen-art] review: > draft-ietf-mpls-lsp-ping-relay-reply-04 > Message-ID: <5435C6B1.2090908@joelhalpern.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I am the assigned Gen-ART reviewer for this draft. For background on Gen- > ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-mpls-lsp-ping-relay-reply-04 > Relayed Echo Reply mechanism for LSP Ping > Reviewer: Joel M. Halpern > Review Date: 8-October-2014 > IETF LC End Date: 13-October-2014 > IESG Telechat date: (if known) > > Summary: This document is not ready for publication as a Proposed Standard > > Major issues: > There is either a major technical flaw in this document, or there is a need > for significantly better explanation. The following is what I was able to > understand from reading the document. > The procedure in the document calls for a responding or relaying LSR to > search the response addresses from the top to the bottom (top being the > originator of the request, bottom being visible originators). > The responder then sends the reply to the first usable address it can find in > the stack. Usable is variously described as "public routable" > and as "routable" (in sections 4.2), the converse is described as "unroutable" > in section 4.3, while section 4.4 uses "routable". > If it means "routable", then this assumes that the private addresses used by > one AS will not happen to also be used in another AS (which would make > them routable in that domain, directing the reply to completely the wrong > place. > If it means "publicly routable", this would seem to fail since routers do not > know whether routable addresses are public, private, or simply not martian. [Lizhong] the "routable address" means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS. I will add the definition explicitly in the document. And for section 2, change "private address" to "routable address in AS1, but not routable in AS2". For section 4.2, change "first public routable IP address" to "first routable IP address". Hope above changing will make things clear. > > Minor issues: > The procedures assume that border routers will know the correct address > to put in the reply stack. It is not bovious that even if the router has a public > address, it will get put on. The requirement stated here is that the address > put on be the same one used to originate the reply. Which would seem likely > to be na internal address in many cases. [Lizhong] If there is a public address on the node, it is also possible to add that address to the stack, which will help to relay the reply back. Rephrase section 4.2: The first address entry added by the replying LSR MUST be same as the source IP address of Relay Echo Reply (section 4.3) or Echo Reply message (section 4.5) being sent. A second or more address entries could also be added if necessary, which depends on implementation. > > The procedure for setting k=0 allowing entries to be removed from the > stack seems fragile. It relies on routers being able to determine that their > address will not be needed for relay by the next hop. [Lizhong] if k=0, then the Relay Node Address Stack TLV could be compressed to reduce the relayed hop number. This is a useful feature, and top to down searching of the routable address will ensure relaying reply back correctly. > > Nits/editorial comments: > Some of the procedure for originating a reply is described in section 4.2 on > Receiving a request, rather than in seciton 4.3 on originating the reply. > (Information such as the address to put on the stack, where it goes on the > stack, and the handling of the reply packet being too large all belong in 4.3.) [Lizhong] we try to put all Relay Node Address Stack processing into one place to make it clear. Splitting the stack processing words into two sections may cause confusion. But we could add a sentence in section 4.3, saying that the updating of Relay Node Address Stack TLV in Relayed Echo Reply is described in section 4.2. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > ------------------------------ > > End of mpls Digest, Vol 126, Issue 10 > ************************************* From nobody Mon Oct 20 03:04:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF01A7028 for ; Mon, 20 Oct 2014 03:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9ybkqBjjDzm for ; Mon, 20 Oct 2014 03:04:31 -0700 (PDT) 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 565491A701A for ; Mon, 20 Oct 2014 03:04:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNV41138; Mon, 20 Oct 2014 10:04:27 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 11:04:22 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 18:04:18 +0800 From: Mach Chen To: Eric Rosen , "Carlos Pignataro (cpignata)" , Ross Callon Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgABupQCAAbAhgIAAExGAgARPWrA= Date: Mon, 20 Oct 2014 10:04:17 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> In-Reply-To: <5441960B.7040305@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qymjGWPGniR7bmQHmDxEcTiO_WM Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 10:04:39 -0000 Hi Eric , Carlos, Stewart and others, Thanks for the discussion! Sorry for the top post. I do think that you're really exaggerating the complexity and negatives. Gi= ven an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO = it's not difficult for such kind of routers to support SL. I looked though the whole discussions so far, and I am not going to reply e= ach email one by email, I summarized the topics as follows: 1) Requirement=20 Whether the requirement is compelling depends on whether you need it. We di= d receive the requirements from SPs to support passive PM for MP2P based LS= Ps, especially for the case of MPLS based IP backhaul network. So for those= SPs, it's a compelling requirement. Indeed, PM is not an easy work, and in= IETF, several dedicated WGs work on PM related stuff, some WGs have worked= on it over decade. This draft is mainly about how to do source identification that is one of t= he critical requirements of the passive PM, it is not intended to cover all= aspects of PM. This is clearly stated in the document. Other aspects, for = example, the multiple line cards in the egress as Stewart pointed out, I do= really think that is an implementation issue. For that case, you do need a= centralized component to sum up and analyze the statistics and their corre= lations. 2) Label stack depth Regarding the label stack depth, there were some related discussions (inclu= ding this WG and other WGs) , some vendors have showed that is not a big pr= oblem, especially for those new generation modern routers/switches. 3) Granularity It depends on how you use it. In theory, the solution can support any numbe= r flows. But there always be some tradeoff, as I replied in a precious emai= l, the SI number itself is not the issue, the HW resource (e.g., the timers= ) is the critical constraint. That means, you cannot expect a router to sup= port unlimited flows. For SI number, I guess that the main concern is mainl= y about the state maintenance and advertisement, actually it could be optim= ized to maintain and advertize a single SI block for each LSR. This way, th= e state and advertisement is a fixed number corresponding to the number of = the LSR in the domain.=20 Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen > Sent: Saturday, October 18, 2014 6:20 AM > To: Carlos Pignataro (cpignata); Ross Callon > Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Carlos> Basically, two or three labels are added to the label stack, >=20 > Actually, that's two or three labels per LSP. A packet may be going thro= ugh a > nested set of LSPs, which each label in the stack representing one of tho= se LSPs. > Each LSP may have its own source label. Since a source label is likely t= o require > three label stack entries, the number of labels in the stack could be qua= drupled. > And for what? >=20 > Carlos> the document only lists PM as the application that needs source l= abels. >=20 > There doesn't seem to be general agreement that this is a compelling use = case. > Certainly not compelling enough to justify the complexity and the overhea= d that > it brings. >=20 > Carlos> What happens if a finer granularity than the source node is neede= d? >=20 > This is inevitable. How long before folks are complaining "we can't run = our > network unless the egress LSR can determine the ingress interface for eac= h > packet". This could lead to thousands of source label values for each in= gress LSR. > And what will happen when someone decides that the granularity needs to b= e > per-subscriber, not merely per-interface? >=20 > And it's not just "finer granularity" we have to worry about. What if so= meone > decides that an ingress LSR needs to convey an arbitrary amount of "meta-= data" > about an LSP to the egress LSR. Will the label stack become a set of lab= els > alternating with meta-data containers? >=20 > Do we really want to put stuff that doesn't affect the packet forwarding = into the > label stack? Where will we draw the line? >=20 > I don't think the authors really intend the mechanism to be generalized i= n this > manner. They're probably thinking "But we only intend for this to be dep= loyed > in a very simple case, where packets are being tunneled, where the ingres= s LSR > knows who the egress LSR is, where they're in the same administrative dom= ain, > etc. etc. You're really exaggerating the negatives." But the proposed > mechanisms do lend themselves to abuse or this sort. Once we start putti= ng > stuff in the label stack that isn't used for forwarding, how will we know= when to > stop? >=20 > Carlos> Given this dramatic set of extensions and strong requirements, it= seems > prudent to me to better understand the problem space of PM gaps before > adopting a solution. >=20 > I agree. I think Stewart has made a good case that further analysis is n= eeded. > The problem isn't that there is no use for source labels, the problem is = that the > mechanism seems to bring a lot of problems with it. Is this really the o= nly > solution? And if so, is it so important to be able to do PM that we shou= ld be > willing to take on all these problems? >=20 > I also think the proposed LDP and BGP extensions are problematic, but tho= se > issues are really of secondary importance right now. >=20 > So I don't support the adoption of this draft. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Oct 20 04:10:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5621A86E3 for ; Mon, 20 Oct 2014 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiA9y2Xugzkx for ; Mon, 20 Oct 2014 04:10:27 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1C31A8547 for ; Mon, 20 Oct 2014 04:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7956; q=dns/txt; s=iport; t=1413803427; x=1415013027; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6xTn8QZgbCvTQot9zoRFxZd260mJ+gIjGOqyCwnfDOg=; b=UaCzN5e25ivUGEig+7YubSCfZaLTpLlIhK0+pCSvDVjC/RRQSBi2yPEN q15t8vckVf7oW64atqAzvTZmdtyQAmgGq35x+LDOiNapHHC0AK9wpa2uP kg5w4cmky93PFPmN943qmsf8V5Cc+DbI9Y5K2CV+7ukRAS6Mk1+LdlCMq I=; X-IronPort-AV: E=Sophos;i="5.04,755,1406592000"; d="scan'208";a="88583595" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 20 Oct 2014 11:10:26 +0000 Received: from [10.21.66.80] (sjc-vpn3-592.cisco.com [10.21.66.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9KBAPsi027661; Mon, 20 Oct 2014 11:10:25 GMT Message-ID: <5444EDA4.3070002@cisco.com> Date: Mon, 20 Oct 2014 12:10:28 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mach Chen , Eric Rosen , "Carlos Pignataro (cpignata)" , Ross Callon References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5W6-5pBsztfn5zCAVnM6JQD_7gs Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:10:29 -0000 Mach On 20/10/2014 11:04, Mach Chen wrote: > Hi Eric , Carlos, Stewart and others, > > Thanks for the discussion! Sorry for the top post. > > I do think that you're really exaggerating the complexity and negatives. Given an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it's not difficult for such kind of routers to support SL. Those solutions are not the same. ELs - have no impact on the receiver. I admit that they have an impact on the transmitter (but only two labels) but the only flow state is that an EL needs to be generated, you do not need additional transmitter context since this is generated from the packet itself. SR - has no impact at ay node other than the transmitter, and in many cases the impact is one or two labels. It does not change the dataplane.. Context labels - I am not sure how wide the support for the general context label use case is. What you are proposing is a far more fundamental change to the dataplane than any of the above. > > I looked though the whole discussions so far, and I am not going to reply each email one by email, I summarized the topics as follows: > > 1) Requirement > Whether the requirement is compelling depends on whether you need it. We did receive the requirements from SPs to support passive PM for MP2P based LSPs, especially for the case of MPLS based IP backhaul network. So for those SPs, it's a compelling requirement. Indeed, PM is not an easy work, and in IETF, several dedicated WGs work on PM related stuff, some WGs have worked on it over decade. I am not disputing the requirement for a method of measuring loss of customer traffic. However the requirement for domain wide source labels is not established. It is one method of identifying the source in a PM measurement, but it is not the only method. > > This draft is mainly about how to do source identification that is one of the critical requirements of the passive PM, It is about one method. The method you propose is not the only method. Also you have jumped directly to a S-D identification approach, without justifying this as being the required unit of identification. > it is not intended to cover all aspects of PM. This is clearly stated in the document. Other aspects, for example, the multiple line cards in the egress as Stewart pointed out, I do really think that is an implementation issue. For that case, you do need a centralized component to sum up and analyze the statistics and their correlations. It is not that simple as you know from your other draft, and it does not make sense to me to address the two requirements as ships in the night solutions. Given that you receive a packet on one line card, you have no idea whether a packet received on another line card (or even line interface on that card) was transmitted before of after the one you are taking as your accounting reference point. > 2) Label stack depth > Regarding the label stack depth, there were some related discussions (including this WG and other WGs) , some vendors have showed that is not a big problem, especially for those new generation modern routers/switches. That is an assumption that you need to justify, particular at the network edge. > > 3) Granularity > It depends on how you use it. In theory, the solution can support any number flows. But there always be some tradeoff, as I replied in a precious email, the SI number itself is not the issue, the HW resource (e.g., the timers) is the critical constraint. That means, you cannot expect a router to support unlimited flows. For SI number, I guess that the main concern is mainly about the state maintenance and advertisement, actually it could be optimized to maintain and advertize a single SI block for each LSR. This way, the state and advertisement is a fixed number corresponding to the number of the LSR in the domain. The timers can be in s/w in the supervisor, since the time that a measurement is taken is not critical, so whilst there might be a filter and counter issue in the h/w, though no worse than IPFIX, there is not h/w issue with timers. Stewart > > Best regards, > Mach > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen >> Sent: Saturday, October 18, 2014 6:20 AM >> To: Carlos Pignataro (cpignata); Ross Callon >> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Carlos> Basically, two or three labels are added to the label stack, >> >> Actually, that's two or three labels per LSP. A packet may be going through a >> nested set of LSPs, which each label in the stack representing one of those LSPs. >> Each LSP may have its own source label. Since a source label is likely to require >> three label stack entries, the number of labels in the stack could be quadrupled. >> And for what? >> >> Carlos> the document only lists PM as the application that needs source labels. >> >> There doesn't seem to be general agreement that this is a compelling use case. >> Certainly not compelling enough to justify the complexity and the overhead that >> it brings. >> >> Carlos> What happens if a finer granularity than the source node is needed? >> >> This is inevitable. How long before folks are complaining "we can't run our >> network unless the egress LSR can determine the ingress interface for each >> packet". This could lead to thousands of source label values for each ingress LSR. >> And what will happen when someone decides that the granularity needs to be >> per-subscriber, not merely per-interface? >> >> And it's not just "finer granularity" we have to worry about. What if someone >> decides that an ingress LSR needs to convey an arbitrary amount of "meta-data" >> about an LSP to the egress LSR. Will the label stack become a set of labels >> alternating with meta-data containers? >> >> Do we really want to put stuff that doesn't affect the packet forwarding into the >> label stack? Where will we draw the line? >> >> I don't think the authors really intend the mechanism to be generalized in this >> manner. They're probably thinking "But we only intend for this to be deployed >> in a very simple case, where packets are being tunneled, where the ingress LSR >> knows who the egress LSR is, where they're in the same administrative domain, >> etc. etc. You're really exaggerating the negatives." But the proposed >> mechanisms do lend themselves to abuse or this sort. Once we start putting >> stuff in the label stack that isn't used for forwarding, how will we know when to >> stop? >> >> Carlos> Given this dramatic set of extensions and strong requirements, it seems >> prudent to me to better understand the problem space of PM gaps before >> adopting a solution. >> >> I agree. I think Stewart has made a good case that further analysis is needed. >> The problem isn't that there is no use for source labels, the problem is that the >> mechanism seems to bring a lot of problems with it. Is this really the only >> solution? And if so, is it so important to be able to do PM that we should be >> willing to take on all these problems? >> >> I also think the proposed LDP and BGP extensions are problematic, but those >> issues are really of secondary importance right now. >> >> So I don't support the adoption of this draft. >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Mon Oct 20 07:47:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45E21A0282; Mon, 20 Oct 2014 07:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtxUExW3V1NZ; Mon, 20 Oct 2014 07:46:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 369A41A8A65; Mon, 20 Oct 2014 07:22:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141020142217.27308.41043.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 07:22:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Y9wFuibAmHKD8tDVg_RpE1Pi73Y Cc: mpls@ietf.org Subject: [mpls] Last Call: (Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:46:57 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-11-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2189/ From nobody Mon Oct 20 08:12:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04F61A8821 for ; Mon, 20 Oct 2014 08:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-0TPRu0q-OW for ; Mon, 20 Oct 2014 08:12:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392931A88A9 for ; Mon, 20 Oct 2014 07:51:06 -0700 (PDT) Received: from [172.29.33.55] (66.129.241.14) by DM2PR0501MB1103.namprd05.prod.outlook.com (25.160.245.13) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 14:51:03 +0000 Message-ID: <54452150.1070605@juniper.net> Date: Mon, 20 Oct 2014 10:50:56 -0400 From: Eric Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mach Chen , "Carlos Pignataro (cpignata)" , Ross Callon References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR01CA039.prod.exchangelabs.com (25.160.23.29) To DM2PR0501MB1103.namprd05.prod.outlook.com (25.160.245.13) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1103; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 03706074BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(51444003)(80022003)(50466002)(77096002)(87976001)(46102003)(117636001)(102836001)(76482002)(64706001)(85852003)(101416001)(20776003)(47776003)(42186005)(120916001)(122386002)(40100003)(99396003)(1941001)(31966008)(4396001)(65816999)(21056001)(66066001)(86362001)(92726001)(92566001)(36756003)(95666004)(107046002)(230783001)(93886004)(59896002)(106356001)(76176999)(50986999)(87266999)(54356999)(85306004)(23746002)(105586002)(97736003)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1103; H:[172.29.33.55]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LNr2ocJ6dTk1wiS0AVVJP3EBaX4 Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:12:44 -0000 Mach> Given an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it's not difficult for such kind of routers to support SL. I don't see the argument here. In all these applications of MPLS, the label lookup produces information that is used for determining how to dispatch the packet, i.e., how to choose the adjacency to which it must be forwarded, or how to determine the context for further processing. The SL is very different, as it carries data about the packet that is not used for determining how to dispatch the packet. The use of the label stack to carry arbitrary information about the packet, for use by monitoring applications, is quite different. That's why folks keep pointing out that it's a change to the MPLS architecture. Mach> Regarding the label stack depth, there were some related discussions (including this WG and other WGs) , some vendors have showed that is not a big problem, especially for those new generation modern routers/switches. I wasn't complaining about the cost of adding a few more labels, but about the potential explosion in the label stack size if a packet has to travel through a set of nested LSPs, and each LSP augments the stack with information needed to monitor that LSP. Perhaps the previous discussions did not take this possibility into account. I think the case of nested LSPs certainly has to be taken into account. Mach> We did receive the requirements from SPs to support passive PM for MP2P based LSPs, especially for the case of MPLS based IP backhaul network. So for those SPs, it's a compelling requirement. I think that's a non-sequitur. I'm sure some SPs want to do PM, but perhaps not at any cost. Mach> 3) Granularity -- It depends on how you use it How do we know that the supported granularity meets the requirements without running into scaling problems? Mach> This draft is mainly about how to do source identification that is one of the critical requirements of the passive PM, it is not intended to cover all aspects of PM. Then it certainly doesn't seem wise to adopt this draft in isolation. From nobody Mon Oct 20 08:47:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF111A0A6A for ; Mon, 20 Oct 2014 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9fBNNDtvdDg for ; Mon, 20 Oct 2014 08:47:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42491A03A2 for ; Mon, 20 Oct 2014 08:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66943; q=dns/txt; s=iport; t=1413819959; x=1415029559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ae64Z5mRM14NNPSeLRrH2hMCA3uZ7tOE34Fdpqoby0I=; b=MA9D7X7+QSF+XyFsGtK6mMg0Btjn7O2zq1mvxsXLg88hFXzT9/V6WgDD LaJEjYa7XGFHVyiZi8sW4oygIduD+0TV/xf6DuGJULWE1vSmpVl6CsvKp EMVSGrquLFSZeBR8TuefEBLCdXcb7qFUCEW0S1uH6eDM6PoteA7/6AwFD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFANYtRVStJV2Z/2dsb2JhbABcgkhGU1gEgwLQdQIbdhYBfYQCAQEBBCcGTBACAQYCEQMBAQELFgEGBQICMBQGAwgCBAENBQiIN5UGnEkIlCQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2YUJhYKEQYBgnM6gR4BBJIBjQmNVoccgjSBQ2yBB0GBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,756,1406592000"; d="scan'208,217";a="364796753" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 20 Oct 2014 15:45:53 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9KFjrGV006379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 15:45:53 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.63]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 10:45:53 -0500 From: "Matt Hartley (mhartley)" To: "Osborne, Eric" , "Tarek Saad (tsaad)" , Lizhenbin , "mpls@ietf.org" Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6ICBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUt?= =?gb2312?B?eWFuZy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2Zn?= =?gb2312?Q?-00?= Thread-Index: AQHP58FeZIbQv9djREeRA2f1MRZyjpwzIMQA///4guCABg75kA== Date: Mon, 20 Oct 2014 15:45:52 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC14AE05AB@xmb-rcd-x03.cisco.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.81] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE05ABxmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/G7mc_Hqhpy5mgG1Hl2kjHEDCwns Cc: "Matt Hartley \(mhartley\)" Subject: Re: [mpls] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBs?= =?gb2312?b?cy10ZS15YW5nLW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFu?= =?gb2312?b?Zy1jZmctMDA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:47:40 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE05ABxmbrcdx03ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SaGvbSBpbmNsaW5lZCB0byBhZ3JlZS4NCg0KSXQgc3RyaWtlcyBtZSB0aGF0IGl0oa9zIHByb2Jh Ymx5IG5vdCBuZWNlc3NhcnkgdG8gZG8gYWxsIHRoaXMgaW4gb25lIGh1Z2UgZHJhZnQsIGFuZCB0 aGF0IGl0IG1pZ2h0IGJlIGEgZ29vZCBpZGVhIHRvIGV4cGxpY2l0bHkgYnJlYWsgdGhpbmdzIHVw LiBXZSBjb3VsZCB0aGVyZWZvcmUgY3JlYXRlIGEgYmFzZSBkcmFmdCBmb3IgdGhlIHN0dWZmIHRo YXShr3Mgc3RhbmRhcmRpemVkIGFuZCB3aWxsIChob3BlZnVsbHkpIG5vdCBiZSB0b28gY29udHJv dmVyc2lhbCwgaGF2ZSB0aGF0IG1vdmUgZm9yd2FyZCBhcyBhIGJhc2VsaW5lIHRoYXQgZXZlcnl0 aGluZyBlbHNlIGNhbiBidWlsZCBvbiwgYW5kIHRoZW4gaGF2ZSBhIHNlY29uZCAob3IgZXZlbiBz ZXZlcmFsKSBkcmFmdHMgZm9yIHRoZSB0aGluZ3MgdGhhdCBhcmUgbGlrZWx5IHRvIHJlcXVpcmUg cm9idXN0IGRlYmF0ZSBwcmlvciB0byBhcnJpdmluZyBhdCBjb25zZW5zdXMuIEhhdmluZyB0aGF0 IGJhc2VsaW5lIGFsc28gYWxsb3dzIGluZGl2aWR1YWwgdmVuZG9ycyB0byB1c2UgaXQgYXMgYSBi YXNlIGZvciB0aGVpciBvd24gcHJvcHJpZXRhcnkgZXh0ZW5zaW9ucyBpZiB0aGV5IHdpc2guDQoN ClRoaXMgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSAoSU1ITzsgWU1NVikgdGhhdCBpdCBicmVha3Mg dGhpbmdzIGRvd24gaW50byByYXRoZXIgbW9yZSBtYW5hZ2VhYmxlIGNodW5rcywgcmF0aGVyIHRo YW4ganVzdCBoYXZpbmcgb25lIGludGltaWRhdGluZ2x5LWxhcmdlIGRvY3VtZW50IGF0IHRoZSBl bmQgb2YgYSBsb25nIHByb2Nlc3OhrQ0KDQpDaGVlcnMNCg0KTWF0dA0KDQpJIGxvb2tlZCBhdCBi b3RoIGRvY3VtZW50cy4gIFRoZXkgYm90aCBoYXZlIHNvbWUgZ29vZCBhbmQgc29tZSBiYWQuICBU aGUgaGFyZGVzdCBwYXJ0IGluIHJlY29uY2lsaW5nIHRoZW0gd2lsbCBiZSB0aGF0IHRoZXkgYm90 aCBoYXZlIGEgdmVyeSB2ZW5kb3Itc3BlY2lmaWMgdmlldyBvZiB0aGUgd29ybGQuICBUaGlzIGlz IG5vIHN1cnByaXNlIGdpdmVuIHRoZSBuYXR1cmUgb2YgdGhlIHRlY2hub2xvZ3ksIGFuZCBJIGRv bqGvdCB0aGluayBpdKGvcyB1bmlxdWUgdG8gVEUuICBCR1Agd2lsbCBiZSBhdCBsZWFzdCBhcyBo YXJkIHRvIHNvcnQgb3V0Lg0KDQpJIHRoaW5rIHdlIG5lZWQgdG8gY2xlYXJseSBkZWxpbmVhdGUg YmV0d2VlbiBzdGFuZGFyZCBmZWF0dXJlcywgY29tbW9uIGZlYXR1cmVzLCBhbmQgdmVuZG9yLXNw ZWNpZmljIG9uZXMuICBTdGFuZGFyZCBmZWF0dXJlcyBtaWdodCBiZSBzY29wZWQgdG8gYW55dGhp bmcgdGhhdCBpcyBib3RoIHNpZ25hbGVkIGFuZCBSRkOhr2QsIGUuZy4sIFszMjA5LCA0NDIwLCA0 ODc1LCA1NzEyLCA3MzA4XS4NCg0KQ29tbW9uIGFyZSB0aGluZ3MgdGhhdCBtYXkgaGF2ZSBkaWZm ZXJlbnQgbmFtZXMgYW5kIHdoaWNoIGFyZW6hr3Qgc2lnbmFsZWQsIGJ1dCB3aGljaCBhcmUgaW4g dXNlIGluIG1hbnkvbW9zdC9hbGwgaW1wbGVtZW50YXRpb25zIKhDIHRoaW5ncyBsaWtlIHdoYXQg b25lIHZlbmRvciBjYWxscyChrmF1dG9yb3V0ZSBhbm5vdW5jZaGvIGFuZCBhbm90aGVyIGNhbGxz IKGuaWdwIHNob3J0Y3V0c6GvLiAgRmluZCBhIGNvbW1vbiBuYW1lLCBvciBhIHdheSB0byB1c2Ug Ym90aCwgYW5kIGJ1aWxkIGEgbW9kZWwgZm9yIHRoZSBzdWJzZXQgb2YgdGhpbmdzIHRoYXQgaXMg bW9zdCBjb21tb24gYWNyb3NzIHZlbmRvcnMuICBUaGlzIGlzIGEgYml0IG9mIGEgcXVhZ21pcmUg c2luY2UgZGlmZmVyZW50IHZlbmRvcnMgd2lsbCBoYXZlIGRpZmZlcmVudCBhcHByb2FjaGVzIHRv IG1hbnkgZGV0YWlscyBvZiBjb21tb24gZmVhdHVyZXMsIGFuZCBpdCBtYXkgYmUgdGhlIG1vc3Qg ZGlmZmljdWx0IHBhcnQgb2YgdGhpcyB3aG9sZSBleGVyY2lzZS4NCg0KVmVuZG9yLXNwZWNpZmlj IHRoaW5ncyBhcmUganVzdCB0aGF0IKhDIHRoaW5ncyBpbXBsZW1lbnRlZCBpbiBhIHBhcnRpY3Vs YXIgd2F5IGJ5IG9ubHkgb25lIHZlbmRvci4gIEFuIGV4YW1wbGUgZnJvbSBSb2JlcnQsIFJha2Vz aCBhbmQgVGFyZWuhr3MgZG9jdW1lbnQgbWlnaHQgYmUgYXR0cmlidXRlLXNldHMsIHdoaWNoIG1h eSBub3QgaGF2ZSBhbiBvYnZpb3VzIHBhcmFsbGVsIGluIG90aGVyIHZlbmRvcnOhryBnZWFyLiAg SWYgbm90aGluZyBlbHNlIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWVwbGFjZSBhIHZlbmRvciBjYW4g YXBwZW5kIGl0cyBvd24gcHJvcHJpZXRhcnkgbW9kZWxzLg0KDQpJbiB0aGUgZW5kIGl0IG1heSBi ZSBtb3JlIHByb2R1Y3RpdmUgdG8gZG8gaXQgdGhpcyB3YXkgqEMgc3RhcnRpbmcgd2l0aCBhIG1p bmltdW0gc2V0IG9mIG9idmlvdWx5IGNvbW1vbiBmZWF0dXJlcyBhbmQgd29ya2luZyB1cCCoQyB0 aGFuIHRyeWluZyB0byByZWNvbmNpbGUgdHdvIGZ1bGx5IGJha2VkIG1vZGVscyB3aXRoIHZlcnkg ZGlmZmVyZW50IHZpZXdzIG9mIHRoZSB3b3JsZC4NCg0KDQoNCg0KDQplcmljDQoNCg0KDQoNCkZy b206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXJl ayBTYWFkICh0c2FhZCkNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE2LCAyMDE0IDk6MzQgQU0N ClRvOiBMaXpoZW5iaW47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW21wbHNdILTwuLQ6IFJlZ2FyZGluZyBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5n LW1vZGVsLTAwIGFuZCBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCg0KSGkgUm9iaW4s DQoNClRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZSB0byB0aGUgZHJhZnQuIFdlIGhhZCBhIGxvb2sg YXQgaXQuIFdlIGFyZSBwcm9wb3NpbmcgYSBzbGlnaHRseSBkaWZmZXJlbnQgbW9kZWwgdGhhdCBp bnRyb2R1Y2VzIGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gY29uZmlndXJhdGlvbiwgb3BlcmF0 aW9uYWwgKHN0YXRlKSwgUlBDIChleGVjdXRpb25hbCksIGFuZCBub3RpZmljYXRpb25zIGZvciBN UExTLVRFIHR1bm5lbHMsIGxzcHMsIGxpbmtzLCBhbmQgZ2xvYmFsIGRhdGE6DQoNCg0KbW9kdWxl OiBtcGxzLXRlDQoNCiAgICstLXJ3IHR1bm5lbHMtY2ZnIQ0KDQogICArLS1ydyBsc3BzLWNmZyEN Cg0KICAgKy0tcncgbGlua3MtY2ZnIQ0KDQogICArLS1ydyBnbG9iYWwtY2ZnIQ0KDQogICArLS1y byB0dW5uZWxzLW9wZXINCg0KICAgKy0tcm8gbHNwcy1vcGVyDQoNCiAgICstLXJvIGxpbmtzLW9w ZXINCg0KICAgKy0tcm8gZ2xvYmFsLW9wZXINCg0KcnBjczoNCg0KICAgKy0tLXggdHVubmVscy1y cGMNCg0KICAgKy0tLXggbHNwcy1ycGMNCg0KICAgKy0tLXggZ2xvYmFsLXJwYw0KDQogICArLS0t eCBsaW5rcy1ycGMNCg0Kbm90aWZpY2F0aW9uczoNCg0KICAgKy0tLW4gdHVubmVscy1ub3RpZg0K DQogICArLS0tbiBsc3BzLW5vdGlmDQoNCiAgICstLS1uIGxpbmtzLW5vdGlmDQoNCiAgICstLS1u IGdsb2JhbC1ub3RpZg0KDQpXZSBhbHNvIGhhdmUgYSBkZXRhaWxlZCBZQU5HIG1vZGVsIGluLXRo ZS13b3JrcyAoYXMgcGVyIHRoZSBhYm92ZSkgYW5kIHdloa9yZSBwbGFubmluZyB0byBpbmNsdWRl IGluIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgZHJhZnQuIEZvciBleGFtcGxlLCB0aGUgdHVubmVs cyBZQU5HIG1vZGVsIGxvb2tzIHNvbWV0aGluZyBsaWtlIGJlbG93Lg0KDQpBcyBmb3IgY29sbGFi b3JhdGlvbiwgeWVzLCB3ZSBhcmUgd2lsbGluZyB0byBjb25zb2xpZGF0ZSBvdXIgZWZmb3J0cyB3 aXRoIHlvdSB0byBwcm9kdWNlIHRoZSBJRVRGIE1QTFMtVEUgWWFuZyBtb2RlbC4NCg0KDQptb2R1 bGU6IG1wbHMtdGUNCg0KICAgKy0tcncgdHVubmVscy1jZmchDQoNCiAgIHwgICstLXJ3IHR1bm5l bCogW25hbWUgdHlwZV0NCg0KICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAg c3RyaW5nDQoNCiAgIHwgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgIHR1bm5lbC10 eXBlDQoNCiAgIHwgICAgICstLXJ3IHR1bm5lbC1pZD8gICAgICAgICAgICAgIHVpbnQxNg0KDQog ICB8ICAgICArLS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICAgICBzdHJpbmcNCg0KICAgfCAgICAg Ky0tcncgZGVzdGluYXRpb24qIFthZGRyZXNzXQ0KDQogICB8ICAgICB8ICArLS1ydyBhZGRyZXNz ICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgfCAgKy0tcncgcGF0aC1vcHRpb24q IFtpbmRleF0NCg0KICAgfCAgICAgfCAgICAgKy0tcncgaW5kZXggICAgICAgICAgICAgdWludDgN Cg0KICAgfCAgICAgfCAgICAgKy0tcncgKHR5cGUpPw0KDQogICB8ICAgICB8ICAgICB8ICArLS06 KGR5bmFtaWMpDQoNCiAgIHwgICAgIHwgICAgIHwgIHwgICstLXJ3IGR5bmFtaWMNCg0KICAgfCAg ICAgfCAgICAgfCAgKy0tOihleHBsaWNpdCkNCg0KICAgfCAgICAgfCAgICAgfCAgICAgKy0tcncg ZXhwbGljaXQNCg0KICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcncgZXhwbGljaXQtaG9wbGlz dCogW2luZGV4XQ0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAgICArLS1ydyBpbmRleCAgICAg ICAgICAgICAgICAgICB1aW50OA0KDQogICB8ICAgICB8ICAgICB8ICAgICAgICAgICArLS1ydyBl eHBsaWNpdC1ob3AtYWRkcmVzcz8gICBob3AtYWRkcmVzcy10eXBlDQoNCiAgIHwgICAgIHwgICAg IHwgICAgICAgICAgICstLXJ3IGV4cGxpY2l0LWhvcC1hY3Rpb24/ICAgIGhvcC1hY3Rpb24tdHlw ZQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBpZ3AtY29uc3RyYWludA0KDQogICB8ICAgICB8ICAg ICB8ICArLS1ydyBpZ3A/ICAgICAgICAgIGVudW1lcmF0aW9uDQoNCiAgIHwgICAgIHwgICAgIHwg ICstLXJ3IGFyZWEtbGV2ZWw/ICAgdWludDMyDQoNCiAgIHwgICAgIHwgICAgICstLXJ3IHZlcmJh dGltPyAgICAgICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgICAgKy0tcncgbG9ja2Rvd24/ICAg ICAgICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1ydyBsc3AtY2ZnKiBbaW5kZXhdDQoNCiAgIHwg ICAgIHwgICstLXJ3IGluZGV4ICAgICAgICAgICAgIGxlYWZyZWYNCg0KICAgfCAgICAgfCAgKy0t cncgc291cmNlPyAgICAgICAgICAgaW5ldDppcC1hZGRyZXNzDQoNCiAgIHwgICAgIHwgICstLXJ3 IGZhc3QtcmVyb3V0ZT8gICAgIGJvb2xlYW4NCg0KICAgfCAgICAgfCAgKy0tcncgcmVjb3JkLXJv dXRlPyAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICArLS1ydyBzaWduYWxlZC1uYW1lPyAgICBz dHJpbmcNCg0KICAgfCAgICAgfCAgKy0tcncgcHJpb3JpdHkNCg0KICAgfCAgICAgfCAgfCAgKy0t cncgc2V0dXA/ICAgdWludDgNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9sZD8gICAgdWludDgN Cg0KICAgfCAgICAgfCAgKy0tcncgYWZmaW5pdHkNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgY29u c3RyYWludHMqIFthY3Rpb25dDQoNCiAgIHwgICAgIHwgIHwgICAgICstLXJ3IGFjdGlvbiAgICAg ICAgYWZmaW5pdHktYWN0aW9uLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgICAgKy0tcncgY29uc3Ry YWludA0KDQogICB8ICAgICB8ICB8ICAgICAgICArLS1ydyBhZmZpbml0eS1saXN0KiBbbmFtZV0N Cg0KICAgfCAgICAgfCAgfCAgICAgICAgICAgKy0tcncgbmFtZSAgICBzdHJpbmcNCg0KICAgfCAg ICAgfCAgKy0tcncgcGF0aC1zZWxlY3Rpb24NCg0KICAgfCAgICAgfCAgfCAgKy0tcncgY29zdC1s aW1pdD8gICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgaG9wLWxpbWl0PyAgICB1aW50 MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgbWV0cmljPyAgICAgICBwYXRoLW1ldHJpYy10eXBl DQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IHRpZWJyZWFrZXI/ICAgcGF0aC10aWVicmVha2VyLXR5 cGUNCg0KICAgfCAgICAgfCAgKy0tcncgYmZkDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IHR5cGU/ ICAgICAgICAgICAgICAgYmZkLXR5cGUNCg0KICAgfCAgICAgfCAgfCAgKy0tcncgYnJpbmd1cC10 aW1lb3V0PyAgICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZGFtcGVuaW5nPyAgICAg ICAgICB1aW50MzINCg0KICAgfCAgICAgfCAgfCAgKy0tcncgZW5jYXAtbW9kZT8gICAgICAgICBi ZmQtZW5jYXAtbW9kZS10eXBlDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZhc3QtZGV0ZWN0PyAg ICAgICAgYm9vbGVhbg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBsc3AtcGluZw0KDQogICB8ICAg ICB8ICB8ICB8ICArLS1ydyBkaXNhYmxlPyAgICBib29sZWFuDQoNCiAgIHwgICAgIHwgIHwgIHwg ICstLXJ3IGludGVydmFsPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBtaW5pbXVt LWludGVydmFsPyAgIHVpbnQzMg0KDQogICB8ICAgICB8ICB8ICArLS1ydyBtdWx0aXBsaWVyPyAg ICAgICAgIHVpbnQzMg0KDQogICB8ICAgICB8ICArLS1ydyBsb2dnaW5nLWV2ZW50KiBbZXZlbnRd DQoNCiAgIHwgICAgIHwgICAgICstLXJ3IGV2ZW50ICAgIGxvZ2dpbmctZXZlbnQtdHlwZQ0KDQog ICB8ICAgICArLS1ydyAocG9saWN5LXJvdXRpbmcpPw0KDQogICB8ICAgICB8ICArLS06KGZvcndh cmRpbmctY2xhc3MpDQoNCiAgIHwgICAgIHwgIHwgICstLXJ3IGZvcndhcmRpbmctY2xhc3MNCg0K ICAgfCAgICAgfCAgfCAgICAgKy0tcncgY2xhc3M/ICAgdWludDgNCg0KICAgfCAgICAgfCAgKy0t Oihmb3J3YXJkaW5nLWdyb3VwKQ0KDQogICB8ICAgICB8ICAgICArLS1ydyBmb3J3YXJkaW5nLWdy b3VwDQoNCiAgIHwgICAgIHwgICAgICAgICstLXJ3IGNsYXNzZXMqICAgdWludDgNCg0KICAgfCAg ICAgKy0tcncgYXV0by1iYW5kd2lkdGgNCg0KICAgfCAgICAgfCAgKy0tcncgb3ZlcmZsb3ctdGhy ZXNob2xkPyAgICB1aW50MzINCg0KICAgfCAgICAgfCAgKy0tcncgb3ZlcmZsb3ctbGltaXQ/ICAg ICAgICB1aW50OA0KDQogICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctdGhyZXNob2xkPyAgIHVp bnQzMg0KDQogICB8ICAgICB8ICArLS1ydyB1bmRlcmZsb3ctbGltaXQ/ICAgICAgIHVpbnQ4DQoN CiAgIHwgICAgIHwgICstLXJ3IGNvbGxlY3Qtb25seT8gICAgICAgICAgYm9vbGVhbg0KDQogICB8 ICAgICArLS1ydyAoYW5ub3VuY2UtYXMpPw0KDQogICB8ICAgICB8ICArLS06KGF1dG9yb3V0ZSkN Cg0KICAgfCAgICAgfCAgfCAgKy0tcncgYXV0b3JvdXRlIQ0KDQogICB8ICAgICB8ICB8ICAgICAr LS1ydyBpbmNsdWRlLWlwdjYtdW5pY2FzdD8gICBib29sZWFuDQoNCiAgIHwgICAgIHwgIHwgICAg ICstLXJ3IChtZXRyaWMtdHlwZSk/DQoNCiAgIHwgICAgIHwgIHwgICAgICAgICstLToobWV0cmlj KQ0KDQogICB8ICAgICB8ICB8ICAgICAgICB8ICArLS1ydyBtZXRyaWM/ICAgICAgICAgICAgICAg ICB1aW50OA0KDQogICB8ICAgICB8ICB8ICAgICAgICArLS06KHJlbGF0aXZlLW1ldHJpYykNCg0K ICAgfCAgICAgfCAgfCAgICAgICAgfCAgKy0tcncgcmVsYXRpdmUtbWV0cmljPyAgICAgICAgdWlu dDgNCg0KICAgfCAgICAgfCAgfCAgICAgICAgKy0tOihhYnNvbHV0ZS1tZXRyaWMpDQoNCiAgIHwg ICAgIHwgIHwgICAgICAgICAgICstLXJ3IGFic29sdXRlLW1ldHJpYz8gICAgICAgIHVpbnQ4DQoN CiAgIHwgICAgIHwgICstLTooZm9yd2FyZGluZy1hZGphY2VuY3kpDQoNCiAgIHwgICAgIHwgICAg ICstLXJ3IGZvcndhcmRpbmctYWRqYWNlbmN5IQ0KDQogICB8ICAgICB8ICAgICAgICArLS1ydyBo b2xkdGltZT8gICAgICAgICAgICAgICB1aW50MzINCg0KICAgfCAgICAgfCAgICAgICAgKy0tcncg aW5jbHVkZS1pcHY2LXVuaWNhc3Q/ICAgYm9vbGVhbg0KDQogICB8ICAgICArLS1ydyBiYWNrdXAt YmFuZHdpZHRoPyAgICAgICB1aW50MzINCg0KICAgfCAgICAgKy0tcncgbG9hZC1zaGFyZT8gICAg ICAgICAgICAgdWludDMyDQoNCiAgIHwgICAgICstLXJ3IGJpZGlyZWN0aW9uYWwNCg0KICAgfCAg ICAgICAgKy0tcncgYXNzb2NpYXRpb24NCg0KICAgfCAgICAgICAgICAgKy0tcncgaWQ/ICAgICAg ICAgICAgICB1aW50MzINCg0KICAgfCAgICAgICAgICAgKy0tcncgc291cmNlPyAgICAgICAgICBp bmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgZ2xvYmFsLXNvdXJjZT8gICBp bmV0OmlwLWFkZHJlc3MNCg0KICAgfCAgICAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICBi aWRpci1hc3NvY2lhdGlvbi10eXBlDQoNCiAgICstLXJ3IGdsb2JhbC1jZmchDQoNClJlZ2FyZHMs DQpUYXJlaw0KDQpGcm9tOiBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPG1haWx0bzps aXpoZW5iaW5AaHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDE0IGF0 IDExOjEyIEFNDQpUbzogIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbXBsc10gtPC4tDog UmVnYXJkaW5nIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlhbmctbW9kZWwtMDAgYW5kIGRyYWZ0LWNo ZW4tbXBscy10ZS15YW5nLWNmZy0wMA0KDQpIaSBNUExTZXIsDQpJIHdvdWxkIGxpa2UgdG8gcmVt aW5kIHlvdSBvZiB0aGUgb3RoZXIgdHdvIFlhbmcgbW9kZWwgZHJhZnRzOiBkcmFmdC1jaGVuLW1w bHMtdGUteWFuZy1jZmctMDAgYW5kIGRyYWZ0LXpoYW5nLW1wbHMtdHAteWFuZy1vYW0tMDAuIFdl bGNvbWUgY29tbWVudHMgYW5kIGNvbGxhYm9yYXRpb24uDQoNCkJlc3QgUmVnYXJkcywNClpoZW5i aW4oUm9iaW4pDQoNCg0KDQoNCg0Kt6K8/sjLOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIExpemhlbmJpbg0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIxNMjVIDIyOjM0DQrK 1bz+yMs6IHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT47IHRzYWFk QGNpc2NvLmNvbTxtYWlsdG86dHNhYWRAY2lzY28uY29tPjsgcnNhd2F5YUBjaXNjby5jb208bWFp bHRvOnJzYXdheWFAY2lzY28uY29tPg0Ks63LzTogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCtb3zOI6IFttcGxzXSBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMtdGUteWFu Zy1tb2RlbC0wMCBhbmQgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwDQoNCkhpIFJha2Vz aCwgVGFyZWsgJiBSb2JlcnQsDQpJIGp1c3Qgc2F3IHlvdSBwcm9wb3NlZCB0aGUgZHJhZnQtZ2Fu ZGhpLW1wbHMtdGUteWFuZy1tb2RlbC0wMC4gSSB3b25kZXIgaWYgeW91IGFyZSBhd2FyZSBvZiB0 aGUgZHJhZnQtY2hlbi1tcGxzLXRlLXlhbmctY2ZnLTAwIHdlIHByb3Bvc2VkIG9uIEF1Z3VzdCAx NS4gRnJvbSBvdXIgcG9pbnQgb2Ygdmlldywgd2UgYXJlIG5vdCBleHBlcmllbmNlZCBlbm91Z2gg dG8gcmVtaW5kIG91ciBNUExTZXJzIG9mIHRoZSBuZXcgZHJhZnQgdG8gcHJvcG9zZSBwb3NzaWJs ZSBkaXNjdXNzaW9uIGFuZCBjb2xsYWJvcmF0aW9uLiBJIGNvbXBhcmVkIHRoZSB0d28gZHJhZnRz IGFzIGZvbGxvd3M6DQoxLiBUaGUgcG9zc2libGUgb3ZlcmxhcHBlZCBwYXJ0DQogICAgICBkcmFm dC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkcmFmdC1jaGVuLW1wbHMtdGUteWFuZy1jZmctMDANCiAgICAgNC4xLiAgR2xv YmFsIE1QTFMtVEUgRGF0YSBNb2RlbCBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NCAgICAgICAtLT4gICAgICAgICBNUExTIFRFIEdsb2JhbCBDb25maWd1cmF0aW9uL1JTVlAtVEUg R2xvYmFsIENvbmZpZ3VyYXRpb24NCiAgICAgNC4yLiAgTVBMUy1URSBUdW5uZWwgSW50ZXJmYWNl IERhdGEgTW9kZWwgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAgNiAgICAtLT4gICAgICAgICBSU1ZQ LVRFIFR1bm5lbCBDb25maWd1cmF0aW9uDQogICAgIDQuMy4gIE1QTFMtVEUgVHVubmVsIExTUCBE YXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcgICAgICAtLT4gICAgICAg ICBSU1ZQLVRFIFR1bm5lbCBDb25maWd1cmF0aW9uDQogICAgIDQuNC4gIE1QTFMtVEUgTGluayBE YXRhIE1vZGVsIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDggICAgICAgIC0t PiAgICAgICAgIE1QTFMgVEUgTGluayBDb25maWd1cmF0aW9uL1JTVlAtVEUgSW50ZXJmYWNlIENv bmZpZ3VyYXRpb24NCjIuIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0wMCBkZWZpbmVzIGZv bGxvd2luZyBjb25maWd1cmF0aW9uIFlhbmcgYmV5b25kIGRyYWZ0LWdhbmRoaS1tcGxzLXRlLXlh bmctbW9kZWwtMDAuDQogICAgIDMuNC4gIEV4cGxpY2l0IFBhdGggQ29uZmlndXJhdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgMy41LiAgUDJNUCBURSBMZWFmIExp c3QgQ29uZmlndXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAzLjku ICBDU1BGIENvbmZpZ3VyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA4DQogICAgIDMuMTAuIFAyTVAgVEUgVHVubmVsIFRlbXBsYXRlIENvbmZpZ3VyYXRpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCjMuIGRyYWZ0LWNoZW4tbXBscy10ZS15YW5nLWNmZy0w MCBoYXMgYWxyZWFkeSBkZWZpbmVkIGFsbCBZYW5nIG1vZGVsIGZvciB0aGVzZSBsaXN0ZWQgY29u ZmlndXJhdGlvbiB3aGlsZSBkcmFmdC1nYW5kaGktbXBscy10ZS15YW5nLW1vZGVsLTAwIGxlYXZl cyBtYW55IFlhbmcgTW9kZWwgZGVmaW5pdGlvbiBhcyBzcGFjZXMuDQoNCkkgdGhpbmsgbWF5YmUg eW91IGFyZSBub3QgYXdhcmUgb2YgdGhlIGV4aXN0aW5nIGRyYWZ0LiBJZiB5b3Ugd291bGQgbGlr ZSB0byBjb29wZXJhdGUgb24gdGhlIE1QTFMgVEUgWWFuZyBNb2RlbHMgZGVmaW5pdGlvbiwgd2Ug YXJlIHZlcnkgZ2xhZCB0byBkaXNjdXNzIHdpdGggeW91IHRvIHRyeSB0byB1bmlmeSB0aGVzZSBZ YW5nIG1vZGVscy4NCg0KDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4pDQoNCg0KDQo= --_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE05ABxmbrcdx03ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I=A1=AFm inclined to= agree.

 

It strikes me that i= t=A1=AFs probably not necessary to do all this in one huge draft, and that = it might be a good idea to explicitly break things up. We could therefore create a base draft for the stuff that=A1=AFs standardized and w= ill (hopefully) not be too controversial, have that move forward as a basel= ine that everything else can build on, and then have a second (or even seve= ral) drafts for the things that are likely to require robust debate prior to arriving at consensus. Having that basel= ine also allows individual vendors to use it as a base for their own propri= etary extensions if they wish.

 

This also has the ad= vantage (IMHO; YMMV) that it breaks things down into rather more manageable= chunks, rather than just having one intimidatingly-large document at the end of a long process=A1=AD

 

Cheers

 

Matt

 

I looked at both documents.  They both have some= good and some bad.  The hardest part in reconciling them will be that= they both have a very vendor-specific view of the world.  This is no surprise given the nature of the technology, a= nd I don=A1=AFt think it=A1=AFs unique to TE.  BGP will be at least as= hard to sort out.

 

I think we need to clearly delineate between standard= features, common features, and vendor-specific ones.  Standard featur= es might be scoped to anything that is both signaled and RFC=A1=AFd, e.g., [3209, 4420, 4875, 5712, 7308]. =

 

Common are things that may have different names and w= hich aren=A1=AFt signaled, but which are in use in many/most/all implementa= tions =A8C things like what one vendor calls =A1=AEautoroute announce=A1=AF and another calls =A1=AEigp shortcuts=A1=AF= .  Find a common name, or a way to use both, and build a model for the= subset of things that is most common across vendors.  This is a bit o= f a quagmire since different vendors will have different approaches to many details of common features, and it may be the most difficult part = of this whole exercise.

 

Vendor-specific things are just that =A8C things impl= emented in a particular way by only one vendor.  An example from Rober= t, Rakesh and Tarek=A1=AFs document might be attribute-sets, which may not have an obvious parallel in other vendors=A1=AF gear.  = If nothing else there needs to be someplace a vendor can append its own pro= prietary models.

 

In the end it may be more productive to do it this wa= y =A8C starting with a minimum set of obviouly common features and working = up =A8C than trying to reconcile two fully baked models with very different views of the world.

 

 

 

 

 

eric

 

 

 

 

From: = mpls [mailto:mpls-bounces@ietf.org= ] On Behalf Of Tarek Saad (tsaad)
Sent: Thursday, October 16, 2014 9:34 AM
To: Lizhenbin; mpls@ietf.org Subject: Re: [mpls] =B4=F0=B8=B4: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-ya= ng-cfg-00

 =

Hi Robin,

 =

Thanks for the reference= to the draft. We had a look at it. We are proposing a slightly different m= odel that introduces clear delineation between configuration, operational (= state), RPC (executional), and notifications for MPLS-TE tunnels, lsps, links, and global data:

 =

module= : mpls-te

 =   +--rw tunnels-cfg!

 =   +--rw lsps-cfg!

 =   +--rw links-cfg!

 =   +--rw global-cfg!

 =   +--ro tunnels-oper

 =   +--ro lsps-oper

 =   +--ro links-oper

 =   +--ro global-oper

rpcs:<= o:p>

 =   +---x tunnels-rpc    

 =   +---x lsps-rpc       

 =   +---x global-rpc     

 =   +---x links-rpc      

notifi= cations:

 =   +---n tunnels-notif    

 =   +---n lsps-notif       

 =   +---n links-notif      

 =   +---n global-notif 

 =

We also have a detailed = YANG model in-the-works (as per the above) and we=A1=AFre planning to inclu= de in the next update of the draft. For example, the tunnels YANG model loo= ks something like below.

 =

As for collaboration, ye= s, we are willing to consolidate our efforts with you to produce the IETF M= PLS-TE Yang model.

 =

module= : mpls-te

 =   +--rw tunnels-cfg!

 =   |  +--rw tunnel* [name type]

 =   |     +--rw name          &nb= sp;         string

 =   |     +--rw type          &nb= sp;         tunnel-type

 =   |     +--rw tunnel-id?        &nbs= p;     uint16

 =   |     +--rw description?        &n= bsp;   string

 =   |     +--rw destination* [address]

 =   |     |  +--rw address       = inet:ip-address

 =   |     |  +--rw path-option* [index]

 =   |     |     +--rw index      =       uint8

 =   |     |     +--rw (type)?<= /p>

 =   |     |     |  +--:(dynamic)=

 =   |     |     |  |  +--rw dynamic

 =   |     |     |  +--:(explicit)

 =   |     |     |     +--rw explicit

 =   |     |     |        +--= rw explicit-hoplist* [index]

 =   |     |     |          = +--rw index                 &n= bsp; uint8

 =   |     |     |          = +--rw explicit-hop-address?   hop-address-type<= /p>

 =   |     |     |          = +--rw explicit-hop-action?    hop-action-type

 =   |     |     +--rw igp-constraint<= /span>

 =   |     |     |  +--rw igp?    =       enumeration

 =   |     |     |  +--rw area-level?  = uint32

 =   |     |     +--rw verbatim?     &n= bsp;   boolean

 =   |     |     +--rw lockdown?     &n= bsp;   boolean

 =   |     +--rw lsp-cfg* [index]

 =   |     |  +--rw index         =     leafref

 =   |     |  +--rw source?        = ;   inet:ip-address

 =   |     |  +--rw fast-reroute?     boolea= n

 =   |     |  +--rw record-route?     boolea= n

 =   |     |  +--rw signaled-name?    string=

 =   |     |  +--rw priority

 =   |     |  |  +--rw setup?   uint8

 =   |     |  |  +--rw hold?    uint8

 =   |     |  +--rw affinity

 =   |     |  |  +--rw constraints* [action]=

 =   |     |  |     +--rw action   = ;     affinity-action-type

 =   |     |  |     +--rw constraint

 =   |     |  |        +--rw affin= ity-list* [name]

 =   |     |  |           +--= rw name    string

 =   |     |  +--rw path-selection

 =   |     |  |  +--rw cost-limit?   uint32<= o:p>

 =   |     |  |  +--rw hop-limit?    ui= nt32

 =   |     |  |  +--rw metric?     &nbs= p; path-metric-type

 =   |     |  |  +--rw tiebreaker?   path-ti= ebreaker-type

 =   |     |  +--rw bfd

 =   |     |  |  +--rw type?      =         bfd-type

 =   |     |  |  +--rw bringup-timeout?  &nb= sp; uint32

 =   |     |  |  +--rw dampening?    &n= bsp;     uint32

 =   |     |  |  +--rw encap-mode?     =     bfd-encap-mode-type

 =   |     |  |  +--rw fast-detect?    =     boolean

 =   |     |  |  +--rw lsp-ping=

 =   |     |  |  |  +--rw disable?  &nb= sp; boolean

 =   |     |  |  |  +--rw interval?   u= int32

 =   |     |  |  +--rw minimum-interval?   u= int32

 =   |     |  |  +--rw multiplier?     =     uint32

 =   |     |  +--rw logging-event* [event]<= /span>

 =   |     |     +--rw event    logging= -event-type

 =   |     +--rw (policy-routing)?

 =   |     |  +--:(forwarding-class)=

 =   |     |  |  +--rw forwarding-class

 =   |     |  |     +--rw class?   uint= 8

 =   |     |  +--:(forwarding-group)=

 =   |     |     +--rw forwarding-group

 =   |     |        +--rw classes* &nbs= p; uint8

 =   |     +--rw auto-bandwidth

 =   |     |  +--rw overflow-threshold?    u= int32

 =   |     |  +--rw overflow-limit?     = ;   uint8

 =   |     |  +--rw underflow-threshold?   uint32=

 =   |     |  +--rw underflow-limit?     &nb= sp; uint8

 =   |     |  +--rw collect-only?      =     boolean

 =   |     +--rw (announce-as)?

 =   |     |  +--:(autoroute)

 =   |     |  |  +--rw autoroute!

 =   |     |  |     +--rw include-ipv6-unica= st?   boolean

 =   |     |  |     +--rw (metric-type)?

 =   |     |  |        +--:(metric= )

 =   |     |  |        |  +--= rw metric?                 uint8

 =   |     |  |        +--:(relati= ve-metric)

 =   |     |  |        |  +--= rw relative-metric?        uint8

 =   |     |  |        +--:(absolu= te-metric)

 =   |     |  |           +--= rw absolute-metric?        uint8

 =   |     |  +--:(forwarding-adjacency)

 =   |     |     +--rw forwarding-adjacency!=

 =   |     |        +--rw holdtime? &nb= sp;             uint32

 =   |     |        +--rw include-ipv6-= unicast?   boolean

 =   |     +--rw backup-bandwidth?       uin= t32

 =   |     +--rw load-share?         &n= bsp;   uint32

 =   |     +--rw bidirectional

 =   |        +--rw association=

 =   |           +--rw id?    &nbs= p;         uint32

 =   |           +--rw source?    =       inet:ip-address

 =   |           +--rw global-source?  = inet:ip-address

 =   |           +--rw type?    &n= bsp;       bidir-association-type

 =   +--rw global-cfg!

 =

Regards,

Tarek<= /p>

 =

From= : Lizhenbin <lizhenbin@huawei.com>
Date: Tuesday, October 14, 2014 at 11:12 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: [mpls] =B4=F0=B8=B4: Regarding draft-gandhi-mpls-te-yang-model-00 and d= raft-chen-mpls-te-yang-cfg-00

 =

Hi MPLSer,

I would like to remind= you of the other two Yang model drafts: draft-chen-mpls-te-yang-cfg-00 and= draft-zhang-mpls-tp-yang-oam-00. Welcome comments and collaboration.

 

Best Regards,

Zhenbin(Robin)<= span style=3D"color:black">

 

 

 

 

 

=B7= =A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.or= g] =B4=FA=B1=ED Lizhenbin
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C214=C8=D5 22:34
=CA=D5=BC=FE=C8=CB: rgandhi@cisco.com; tsaad@cisco.com; rsawaya@cisco.com
=B3=AD=CB=CD: mpls@ietf.org
=D6=F7=CC=E2: [mpls] Regarding draft-gan= dhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

 

Hi Rakesh, Tarek & R= obert,

I just saw you proposed = the draft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the dr= aft-chen-mpls-te-yang-cfg-00 we proposed on August 15. From our point of vi= ew, we are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and col= laboration. I compared the two drafts as follows:

1. The possible overlapp= ed part

    =   draft-gandhi-mpls-te-yang-model-00     &nbs= p;            &= nbsp;           &nbs= p;       draft-chen-mpls-te-yang-cfg-00<= /o:p>

    = 4.1.  Global MPLS-TE Data Model Overview . . . . . . . . . . . . = ; 4       -->     = ;    MPLS TE Global Configuration/RSVP-TE Global Configurati= on

    =  4.2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .=   6    -->        = ; RSVP-TE Tunnel Configuration 

    =  4.3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .=   7      -->     =     RSVP-TE Tunnel Configuration 

    =  4.4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .=   8        -->   =       MPLS TE Link Configuration/RSVP-TE Interface= Configuration 

2. draft-chen-mpls-te-ya= ng-cfg-00 defines following configuration Yang beyond draft-gandhi-mpls-te-= yang-model-00.

    = 3.4.  Explicit Path Configuration . . . . . . . . . . . . . . . =   5

    = 3.5.  P2MP TE Leaf List Configuration . . . . . . . . . . . . . =   5

    = 3.9.  CSPF Configuration  . . . . . . . . . . . . . . . . . . .&= nbsp;  8

    = 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . .  = ; 8

3. draft-chen-mpls-te-ya= ng-cfg-00 has already defined all Yang model for these listed configuration= while draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition= as spaces.

 =

I think maybe you are no= t aware of the existing draft. If you would like to cooperate on the MPLS T= E Yang Models definition, we are very glad to discuss with you to try to un= ify these Yang models.

 =

 =

 =

Best Regards,=

Zhenbin(Robin)

 

 =

--_000_9D50FCE7413E3D4EA5E42331115FB5BC14AE05ABxmbrcdx03ciscoc_-- From nobody Mon Oct 20 09:12:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D2B1A0369 for ; Mon, 20 Oct 2014 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNYFaJhvfAG7 for ; Mon, 20 Oct 2014 09:12:27 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4475D1A02BE for ; Mon, 20 Oct 2014 09:12:26 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so3404919yha.26 for ; Mon, 20 Oct 2014 09:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uDv9jPNdK68AovYJopWDkXi6pdKE7SSFbPl9CN1ycMM=; b=pieGFPehQFN9BjrFu+sY1+yVpeOgkjOwDmIIQhbLa4rVgqhaE9VqIzsADt97qxWiby xo4dcJjpdX4rdDmKuFNyt8fdtFueq7y7H4YvagKnVa40oMDrkA/3aewRDE9uucZmIKPU cc7fjgZpqYR0+8ngK7hvTifUgw+se4YYqtBofzZ9v0xH4VRLEIDJnKDyO7hRcgtkdbv/ vZtnwObQC1jbQeulpHNkysKuEu50ie3eya58wsYOvBGg89yIb4dhSu47/+Jl8uNT7Wwd OTR1W5W0P8c3meg2XFyuPNHTSPsGV1hdlFlvZQ+54b0VLlywvP4iTymOj1aF/vyzSfmA 7zYw== MIME-Version: 1.0 X-Received: by 10.236.105.139 with SMTP id k11mr14099056yhg.107.1413821545506; Mon, 20 Oct 2014 09:12:25 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Mon, 20 Oct 2014 09:12:25 -0700 (PDT) In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC14AE05AB@xmb-rcd-x03.cisco.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> <9D50FCE7413E3D4EA5E42331115FB5BC14AE05AB@xmb-rcd-x03.cisco.com> Date: Mon, 20 Oct 2014 12:12:25 -0400 Message-ID: From: Alia Atlas To: "Matt Hartley (mhartley)" Content-Type: multipart/alternative; boundary=089e0158be2afeed9b0505dcfa0c Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/v6UCFWQdJBPicZ4OOoz7-w2vOG0 Cc: "mpls@ietf.org" Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBSZWdhcmRpbmcgZHJhZnQtZ2FuZGhpLW1wbHMt?= =?utf-8?q?te-yang-model-00_and_draft-chen-mpls-te-yang-cfg-00?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:12:31 -0000 --089e0158be2afeed9b0505dcfa0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One of the advantages of YANG is its extensibility. I think that this suggestion of breaking up the work is quite useful. I also expect that we may see some good groupings that are suitable for reuse in different YANG models. I would encourage anyone working on YANG models in the Routing Area to also join the rtg-yang-coord@ietf.org mailing list so that we can get common discussion and coordination. Regards, Alia On Mon, Oct 20, 2014 at 11:45 AM, Matt Hartley (mhartley) < mhartley@cisco.com> wrote: > I=E2=80=99m inclined to agree. > > > > It strikes me that it=E2=80=99s probably not necessary to do all this in = one huge > draft, and that it might be a good idea to explicitly break things up. We > could therefore create a base draft for the stuff that=E2=80=99s standard= ized and > will (hopefully) not be too controversial, have that move forward as a > baseline that everything else can build on, and then have a second (or ev= en > several) drafts for the things that are likely to require robust debate > prior to arriving at consensus. Having that baseline also allows individu= al > vendors to use it as a base for their own proprietary extensions if they > wish. > > > > This also has the advantage (IMHO; YMMV) that it breaks things down into > rather more manageable chunks, rather than just having one > intimidatingly-large document at the end of a long process=E2=80=A6 > > > > Cheers > > > > Matt > > > > I looked at both documents. They both have some good and some bad. The > hardest part in reconciling them will be that they both have a very > vendor-specific view of the world. This is no surprise given the nature = of > the technology, and I don=E2=80=99t think it=E2=80=99s unique to TE. BGP= will be at least > as hard to sort out. > > > > I think we need to clearly delineate between standard features, common > features, and vendor-specific ones. Standard features might be scoped to > anything that is both signaled and RFC=E2=80=99d, e.g., [3209, 4420, 4875= , 5712, > 7308]. > > > > Common are things that may have different names and which aren=E2=80=99t = signaled, > but which are in use in many/most/all implementations =E2=80=93 things li= ke what > one vendor calls =E2=80=98autoroute announce=E2=80=99 and another calls = =E2=80=98igp shortcuts=E2=80=99. > Find a common name, or a way to use both, and build a model for the subse= t > of things that is most common across vendors. This is a bit of a quagmir= e > since different vendors will have different approaches to many details of > common features, and it may be the most difficult part of this whole > exercise. > > > > Vendor-specific things are just that =E2=80=93 things implemented in a pa= rticular > way by only one vendor. An example from Robert, Rakesh and Tarek=E2=80= =99s > document might be attribute-sets, which may not have an obvious parallel = in > other vendors=E2=80=99 gear. If nothing else there needs to be someplace= a vendor > can append its own proprietary models. > > > > In the end it may be more productive to do it this way =E2=80=93 starting= with a > minimum set of obviouly common features and working up =E2=80=93 than try= ing to > reconcile two fully baked models with very different views of the world. > > > > > > > > > > > > eric > > > > > > > > > > *From:* mpls [mailto:mpls-bounces@ietf.org ] *On > Behalf Of *Tarek Saad (tsaad) > *Sent:* Thursday, October 16, 2014 9:34 AM > *To:* Lizhenbin; mpls@ietf.org > *Subject:* Re: [mpls] =E7=AD=94=E5=A4=8D: Regarding draft-gandhi-mpls-te-= yang-model-00 > and draft-chen-mpls-te-yang-cfg-00 > > > > Hi Robin, > > > > Thanks for the reference to the draft. We had a look at it. We are > proposing a slightly different model that introduces clear delineation > between configuration, operational (state), RPC (executional), and > notifications for MPLS-TE tunnels, lsps, links, and global data: > > > > module: mpls-te > > +--rw tunnels-cfg! > > +--rw lsps-cfg! > > +--rw links-cfg! > > +--rw global-cfg! > > +--ro tunnels-oper > > +--ro lsps-oper > > +--ro links-oper > > +--ro global-oper > > rpcs: > > +---x tunnels-rpc > > +---x lsps-rpc > > +---x global-rpc > > +---x links-rpc > > notifications: > > +---n tunnels-notif > > +---n lsps-notif > > +---n links-notif > > +---n global-notif > > > > We also have a detailed YANG model in-the-works (as per the above) and > we=E2=80=99re planning to include in the next update of the draft. For ex= ample, the > tunnels YANG model looks something like below. > > > > As for collaboration, yes, we are willing to consolidate our efforts with > you to produce the IETF MPLS-TE Yang model. > > > > module: mpls-te > > +--rw tunnels-cfg! > > | +--rw tunnel* [name type] > > | +--rw name string > > | +--rw type tunnel-type > > | +--rw tunnel-id? uint16 > > | +--rw description? string > > | +--rw destination* [address] > > | | +--rw address inet:ip-address > > | | +--rw path-option* [index] > > | | +--rw index uint8 > > | | +--rw (type)? > > | | | +--:(dynamic) > > | | | | +--rw dynamic > > | | | +--:(explicit) > > | | | +--rw explicit > > | | | +--rw explicit-hoplist* [index] > > | | | +--rw index uint8 > > | | | +--rw explicit-hop-address? hop-address-type > > | | | +--rw explicit-hop-action? hop-action-type > > | | +--rw igp-constraint > > | | | +--rw igp? enumeration > > | | | +--rw area-level? uint32 > > | | +--rw verbatim? boolean > > | | +--rw lockdown? boolean > > | +--rw lsp-cfg* [index] > > | | +--rw index leafref > > | | +--rw source? inet:ip-address > > | | +--rw fast-reroute? boolean > > | | +--rw record-route? boolean > > | | +--rw signaled-name? string > > | | +--rw priority > > | | | +--rw setup? uint8 > > | | | +--rw hold? uint8 > > | | +--rw affinity > > | | | +--rw constraints* [action] > > | | | +--rw action affinity-action-type > > | | | +--rw constraint > > | | | +--rw affinity-list* [name] > > | | | +--rw name string > > | | +--rw path-selection > > | | | +--rw cost-limit? uint32 > > | | | +--rw hop-limit? uint32 > > | | | +--rw metric? path-metric-type > > | | | +--rw tiebreaker? path-tiebreaker-type > > | | +--rw bfd > > | | | +--rw type? bfd-type > > | | | +--rw bringup-timeout? uint32 > > | | | +--rw dampening? uint32 > > | | | +--rw encap-mode? bfd-encap-mode-type > > | | | +--rw fast-detect? boolean > > | | | +--rw lsp-ping > > | | | | +--rw disable? boolean > > | | | | +--rw interval? uint32 > > | | | +--rw minimum-interval? uint32 > > | | | +--rw multiplier? uint32 > > | | +--rw logging-event* [event] > > | | +--rw event logging-event-type > > | +--rw (policy-routing)? > > | | +--:(forwarding-class) > > | | | +--rw forwarding-class > > | | | +--rw class? uint8 > > | | +--:(forwarding-group) > > | | +--rw forwarding-group > > | | +--rw classes* uint8 > > | +--rw auto-bandwidth > > | | +--rw overflow-threshold? uint32 > > | | +--rw overflow-limit? uint8 > > | | +--rw underflow-threshold? uint32 > > | | +--rw underflow-limit? uint8 > > | | +--rw collect-only? boolean > > | +--rw (announce-as)? > > | | +--:(autoroute) > > | | | +--rw autoroute! > > | | | +--rw include-ipv6-unicast? boolean > > | | | +--rw (metric-type)? > > | | | +--:(metric) > > | | | | +--rw metric? uint8 > > | | | +--:(relative-metric) > > | | | | +--rw relative-metric? uint8 > > | | | +--:(absolute-metric) > > | | | +--rw absolute-metric? uint8 > > | | +--:(forwarding-adjacency) > > | | +--rw forwarding-adjacency! > > | | +--rw holdtime? uint32 > > | | +--rw include-ipv6-unicast? boolean > > | +--rw backup-bandwidth? uint32 > > | +--rw load-share? uint32 > > | +--rw bidirectional > > | +--rw association > > | +--rw id? uint32 > > | +--rw source? inet:ip-address > > | +--rw global-source? inet:ip-address > > | +--rw type? bidir-association-type > > +--rw global-cfg! > > > > Regards, > > Tarek > > > > *From: *Lizhenbin > *Date: *Tuesday, October 14, 2014 at 11:12 AM > *To: *"mpls@ietf.org" > *Subject: *[mpls] =E7=AD=94=E5=A4=8D: Regarding draft-gandhi-mpls-te-yang= -model-00 and > draft-chen-mpls-te-yang-cfg-00 > > > > Hi MPLSer, > > I would like to remind you of the other two Yang model drafts: > draft-chen-mpls-te-yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. Welco= me > comments and collaboration. > > > > Best Regards, > > Zhenbin(Robin) > > > > > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* mpls [mailto:mpls-bounces@ietf.org ] * =E4=BB=A3=E8=A1=A8 > *Lizhenbin > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B410=E6=9C=8814=E6=97= =A5 22:34 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* rgandhi@cisco.com; tsaad@cisco.com; rsaway= a@cisco.com > *=E6=8A=84=E9=80=81:* mpls@ietf.org > *=E4=B8=BB=E9=A2=98:* [mpls] Regarding draft-gandhi-mpls-te-yang-model-00= and > draft-chen-mpls-te-yang-cfg-00 > > > > Hi Rakesh, Tarek & Robert, > > I just saw you proposed the draft-gandhi-mpls-te-yang-model-00. I wonder > if you are aware of the draft-chen-mpls-te-yang-cfg-00 we proposed on > August 15. From our point of view, we are not experienced enough to remin= d > our MPLSers of the new draft to propose possible discussion and > collaboration. I compared the two drafts as follows: > > 1. The possible overlapped part > > > draft-gandhi-mpls-te-yang-model-00 > draft-chen-mpls-te-yang-cfg-00 > > 4.1. Global MPLS-TE Data Model Overview . . . . . . . . . . . . > 4 --> MPLS TE Global Configuration/RSVP-TE Global > Configuration > > 4.2. MPLS-TE Tunnel Interface Data Model Overview . . . . . . . > 6 --> RSVP-TE Tunnel Configuration > > 4.3. MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . . > 7 --> RSVP-TE Tunnel Configuration > > 4.4. MPLS-TE Link Data Model Overview . . . . . . . . . . . . . > 8 --> MPLS TE Link Configuration/RSVP-TE Interface > Configuration > > 2. draft-chen-mpls-te-yang-cfg-00 defines following configuration Yang > beyond draft-gandhi-mpls-te-yang-model-00. > > 3.4. Explicit Path Configuration . . . . . . . . . . . . . . . 5 > > 3.5. P2MP TE Leaf List Configuration . . . . . . . . . . . . . 5 > > 3.9. CSPF Configuration . . . . . . . . . . . . . . . . . . . 8 > > 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . . 8 > > 3. draft-chen-mpls-te-yang-cfg-00 has already defined all Yang model for > these listed configuration while draft-gandhi-mpls-te-yang-model-00 leave= s > many Yang Model definition as spaces. > > > > I think maybe you are not aware of the existing draft. If you would like > to cooperate on the MPLS TE Yang Models definition, we are very glad to > discuss with you to try to unify these Yang models. > > > > > > > > Best Regards, > > Zhenbin(Robin) > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --089e0158be2afeed9b0505dcfa0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the advantages of YANG is its extensibility.=C2=A0 = I think that this suggestion of breaking up the
work is quite useful.= =C2=A0 I also expect that we may see some good groupings that are suitable = for reuse
in different YANG models.

I wo= uld encourage anyone working on YANG models in the Routing Area to also joi= n the rtg-yang-coord@ietf.org


On Mon, Oct 20, 2014 at 11:= 45 AM, Matt Hartley (mhartley) <mhartley@cisco.com> wrote:<= br>

I=E2=80=99m inclined= to agree.

=C2=A0=

It strikes me that i= t=E2=80=99s probably not necessary to do all this in one huge draft, and th= at it might be a good idea to explicitly break things up. We could therefore create a base draft for the stuff that=E2=80=99s standardized an= d will (hopefully) not be too controversial, have that move forward as a ba= seline that everything else can build on, and then have a second (or even s= everal) drafts for the things that are likely to require robust debate prior to arriving at consensus. Having that basel= ine also allows individual vendors to use it as a base for their own propri= etary extensions if they wish.

=C2=A0=

This also has the ad= vantage (IMHO; YMMV) that it breaks things down into rather more manageable= chunks, rather than just having one intimidatingly-large document at the end of a long process=E2=80=A6

=C2=A0=

Cheers

=C2=A0=

Matt

=C2=A0=

I loo= ked at both documents.=C2=A0 They both have some good and some bad.=C2=A0 T= he hardest part in reconciling them will be that they both have a very vend= or-specific view of the world.=C2=A0 This is no surprise given the nature of the technology, a= nd I don=E2=80=99t think it=E2=80=99s unique to TE.=C2=A0 BGP will be at le= ast as hard to sort out.

=C2=A0

I thi= nk we need to clearly delineate between standard features, common features,= and vendor-specific ones.=C2=A0 Standard features might be scoped to anyth= ing that is both signaled and RFC=E2=80=99d, e.g., [3209, 4420, 4875, 5712, 7308]. <= u>

=C2=A0

Commo= n are things that may have different names and which aren=E2=80=99t signale= d, but which are in use in many/most/all implementations =E2=80=93 things l= ike what one vendor calls =E2=80=98autoroute announce=E2=80=99 and another calls =E2=80=98igp shortc= uts=E2=80=99.=C2=A0 Find a common name, or a way to use both, and build a m= odel for the subset of things that is most common across vendors.=C2=A0 Thi= s is a bit of a quagmire since different vendors will have different approa= ches to many details of common features, and it may be the most difficult part = of this whole exercise.

=C2=A0

Vendo= r-specific things are just that =E2=80=93 things implemented in a particula= r way by only one vendor.=C2=A0 An example from Robert, Rakesh and Tarek=E2= =80=99s document might be attribute-sets, which may not have an obvious parallel in other vendors=E2=80=99 gear.=C2= =A0 If nothing else there needs to be someplace a vendor can append its own= proprietary models.

=C2=A0

In th= e end it may be more productive to do it this way =E2=80=93 starting with a= minimum set of obviouly common features and working up =E2=80=93 than tryi= ng to reconcile two fully baked models with very different views of the world.<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

eric<= u>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: = mpls [mailto:mpl= s-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Thursday, October 16, 2014 9:34 AM
To: Lizhenbin; mp= ls@ietf.org
Subject: Re: [mpls] =E7=AD=94=E5=A4=8D: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls= -te-yang-cfg-00

=C2= =A0

Hi Robin,<= /span>

=C2=A0

Thanks for the reference= to the draft. We had a look at it. We are proposing a slightly different m= odel that introduces clear delineation between configuration, operational (= state), RPC (executional), and notifications for MPLS-TE tunnels, lsps, links, and global data:

=C2=A0

module= : mpls-te

=C2=A0= =C2=A0 +--rw tunnels-cfg!

=C2=A0= =C2=A0 +--rw lsps-cfg!

=C2=A0= =C2=A0 +--rw links-cfg!

=C2=A0= =C2=A0 +--rw global-cfg!

=C2=A0= =C2=A0 +--ro tunnels-oper

=C2=A0= =C2=A0 +--ro lsps-oper

=C2=A0= =C2=A0 +--ro links-oper

=C2=A0= =C2=A0 +--ro global-oper

rpcs:<= u>

=C2=A0= =C2=A0 +---x tunnels-rpc =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---x lsps-rpc=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---x global-rpc=C2=A0 =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---x links-rpc =C2=A0 =C2=A0 =C2=A0

notifi= cations:

=C2=A0= =C2=A0 +---n tunnels-notif =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---n lsps-notif=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---n links-notif =C2=A0 =C2=A0 =C2=A0

=C2=A0= =C2=A0 +---n global-notif=C2=A0

=C2=A0

We also have a detailed = YANG model in-the-works (as per the above) and we=E2=80=99re planning to in= clude in the next update of the draft. For example, the tunnels YANG model = looks something like below.

=C2=A0

As for collaboration, ye= s, we are willing to consolidate our efforts with you to produce the IETF M= PLS-TE Yang model.

=C2=A0

module= : mpls-te

=C2=A0= =C2=A0 +--rw tunnels-cfg!

=C2=A0= =C2=A0 |=C2=A0 +--rw tunnel* [name type]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 string

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 tunnel-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw tunnel-id?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 uint16

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw description?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 string

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw destination* [address]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw address=C2=A0 =C2=A0 =C2=A0 =C2=A0 ine= t:ip-address

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw path-option* [index]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw index =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw (type)?

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(dynamic)<= /span>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw dynamic=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(explicit)=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw explicit

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw e= xplicit-hoplist* [index]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw index =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw explicit-hop-address? =C2=A0 hop-address-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw explicit-hop-action?=C2=A0 =C2=A0 hop-action-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw igp-constraint

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw igp?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 enumeration

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw area-level? =C2=A0 uin= t32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw verbatim? =C2=A0 =C2=A0 =C2=A0= =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw lockdown? =C2=A0 =C2=A0 =C2=A0= =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw lsp-cfg* [index]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw index =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 leafref

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw source? =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 inet:ip-address

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw fast-reroute? =C2=A0 =C2=A0 boolean=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw record-route? =C2=A0 =C2=A0 boolean=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw signaled-name?=C2=A0 =C2=A0 string<= /u>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw priority

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw setup? =C2=A0 uint8<= /u>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw hold?=C2=A0 =C2=A0 uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw affinity

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw constraints* [action]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 +--rw action=C2=A0 =C2=A0 = =C2=A0 =C2=A0 affinity-action-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 +--rw constraint

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw affinity-= list* [name]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw n= ame=C2=A0 =C2=A0 string

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw path-selection

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw cost-limit? =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw hop-limit?=C2=A0 =C2=A0 uint32=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw metric? =C2=A0 =C2=A0 =C2=A0 p= ath-metric-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw tiebreaker? =C2=A0 path-tiebre= aker-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw bfd

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 bfd-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw bringup-timeout?=C2=A0 =C2=A0 = uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw dampening?=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw encap-mode? =C2=A0 =C2=A0 =C2= =A0 =C2=A0 bfd-encap-mode-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw fast-detect?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw lsp-ping<= /p>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--rw disable?=C2=A0 =C2=A0 = boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--rw interval? =C2=A0 uint3= 2

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw minimum-interval? =C2=A0 uint3= 2

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw multiplier? =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw logging-event* [event]

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw event=C2=A0 =C2=A0 logging-eve= nt-type

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw (policy-routing)?

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(forwarding-class)<= /p>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw forwarding-class=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 +--rw class? =C2=A0 uint8=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(forwarding-group)<= /p>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw forwarding-group=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw classes* =C2=A0 u= int8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw auto-bandwidth

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw overflow-threshold?=C2=A0 =C2=A0 uint3= 2

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw overflow-limit?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw underflow-threshold? =C2=A0 uint32<= /u>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw underflow-limit? =C2=A0 =C2=A0 =C2=A0 = uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--rw collect-only?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw (announce-as)?

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(autoroute)

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw autoroute!

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 +--rw include-ipv6-unicast? = =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 +--rw (metric-type)?<= u>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(metric)=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw m= etric? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8=

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(relative-m= etric)

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw r= elative-metric?=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(absolute-m= etric)

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw a= bsolute-metric?=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 +--:(forwarding-adjacency)

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw forwarding-adjacency!

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw holdtime? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw include-ipv6-unic= ast? =C2=A0 boolean

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw backup-bandwidth? =C2=A0 =C2=A0 =C2=A0 uint32<= u>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw load-share? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw bidirectional

=C2=A0= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw association<= /p>

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw id?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw source?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:ip-address

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw global-source? =C2=A0 ine= t:ip-address

=C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type?=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 bidir-association-type

=C2=A0= =C2=A0 +--rw global-cfg!

=C2=A0

Regards,

Tarek

=C2=A0

From= : Lizhenbin <lizhenbin@huawei.com= >
Date: Tuesday, October 14, 2014 at 11:12 AM
To: "mpls@ie= tf.org" <mpl= s@ietf.org>
Subject: [mpls] =E7=AD=94=E5=A4=8D: Regarding draft-gandhi-mpls-te-yang-model-00= and draft-chen-mpls-te-yang-cfg-00

=C2=A0

Hi MPLSer,

I would like to remind= you of the other two Yang model drafts: draft-chen-mpls-te-yang-cfg-00 and= draft-zhang-mpls-tp-yang-oam-00. Welcome comments and collaboration.

=C2=A0

Best Regards,

Zhenbin(Robin)<= span style=3D"color:black">

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E5= =8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mp= ls-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Lizhenbin
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 14=E5=B9=B410=E6=9C=8814=E6=97=A5 22:34
=E6=94=B6=E4=BB=B6=E4=BA=BA: rgandhi@cisco.com; tsaad@cisco.com; <= a href=3D"mailto:rsawaya@cisco.com" target=3D"_blank"> rsawaya@cisco.com
=E6=8A=84=E9=80=81: mpls@ietf.org
=E4=B8=BB=E9=A2=98: [mpls] Regarding dra= ft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

=C2=A0

Hi Rakesh, Tarek & R= obert,

I just saw you proposed = the draft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the dr= aft-chen-mpls-te-yang-cfg-00 we proposed on August 15. From our point of vi= ew, we are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and col= laboration. I compared the two drafts as follows:

1. The possible overlapp= ed part

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 draft-gandhi-mpls-te-yang-model-00=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-chen-mpls-te-yang-cfg-00

=C2=A0=C2=A0=C2=A0=C2=A0= 4.1.=C2=A0 Global MPLS-TE Data Model Overview . . . . . . . . . . . .=C2= =A0 4=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0-->=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0MPLS TE Global Configuration/RSVP-TE Global Configura= tion

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A04.2.=C2=A0 MPLS-TE Tunnel Interface Data Model Overview . . . . . . .= =C2=A0 6=C2=A0=C2=A0=C2=A0 -->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0RSVP-TE Tunnel Configuration=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A04.3.=C2=A0 MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .= =C2=A0 7=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0-->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0RSVP-TE Tunnel Configuration=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A04.4.=C2=A0 MPLS-TE Link Data Model Overview . . . . . . . . . . . . .= =C2=A0 8=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0-->=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0MPLS TE Link Configuration/RSVP-TE Interface= Configuration=C2=A0

2. draft-chen-mpls-te-ya= ng-cfg-00 defines following configuration Yang beyond draft-gandhi-mpls-te-= yang-model-00.

=C2=A0=C2=A0=C2=A0=C2=A0= 3.4.=C2=A0 Explicit Path Configuration . . . . . . . . . . . . . . .=C2=A0= =C2=A0 5

=C2=A0=C2=A0=C2=A0=C2=A0= 3.5.=C2=A0 P2MP TE Leaf List Configuration . . . . . . . . . . . . .=C2=A0= =C2=A0 5

=C2=A0=C2=A0=C2=A0=C2=A0= 3.9.=C2=A0 CSPF Configuration=C2=A0 . . . . . . . . . . . . . . . . . . .= =C2=A0=C2=A0 8

=C2=A0=C2=A0=C2=A0=C2=A0= 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . .=C2=A0=C2= =A0 8

3. draft-chen-mpls-te-ya= ng-cfg-00 has already defined all Yang model for these listed configuration= while draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition= as spaces.

=C2=A0

I think maybe you are no= t aware of the existing draft. If you would like to cooperate on the MPLS T= E Yang Models definition, we are very glad to discuss with you to try to un= ify these Yang models.

=C2=A0

=C2=A0

=C2=A0

Best Regards,<= /u>

Zhenbin(Robin)= 

=C2=A0

=C2=A0


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--089e0158be2afeed9b0505dcfa0c-- From nobody Mon Oct 20 12:47:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A83C1ACD30; Mon, 20 Oct 2014 12:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a8fErIrlw64; Mon, 20 Oct 2014 12:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B42EE1ACD2E; Mon, 20 Oct 2014 12:47:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141020194724.21511.39669.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 12:47:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lqioCslStB43_jp__DJ3FQAN4Ck Cc: mpls@ietf.org Subject: [mpls] Last Call: (Deprecation of BGP Entropy Label Capability Attribute) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:47:30 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Deprecation of BGP Entropy Label Capability Attribute' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-11-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 6790 defines the BGP Entropy Label Capability attribute. Regrettably, it has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 20 14:38:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45E1ACEFD for ; Mon, 20 Oct 2014 14:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5XOuKmi82fA for ; Mon, 20 Oct 2014 14:38:21 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D681ACEF2 for ; Mon, 20 Oct 2014 14:38:21 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id cc085445.0.8101402.00-2293.22803206.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Oct 2014 21:38:21 +0000 (UTC) X-MXL-Hash: 544580cd33693f6d-3413c2cd6efdd3c2c3aea49531fad6860ec36cfc 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 s9KLcKW9021601 for ; Mon, 20 Oct 2014 17:38:20 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9KLcGoB021580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 20 Oct 2014 17:38:17 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Mon, 20 Oct 2014 21:38:01 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.237]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 17:38:00 -0400 From: "BRUNGARD, DEBORAH A" To: "mpls@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 Thread-Index: Ac/srhYtw41OE3HgTrCehOgSOP9pkA== Date: Mon, 20 Oct 2014 21:38:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.11.14] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8166CAF76MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ae/Wa2Ut c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=DeRuKWwG-P8A:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=PBiA53ArKs] X-AnalysisOut: [byUZ-9ktMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=RGpcvmhV4ycaDLjjpTUA:9 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-h] X-AnalysisOut: [UA:10 a=8TsrQbuD-ozQqB9o:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dO1Xzjri-2ODYkhQc6__xLYuUC0 Subject: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:38:24 -0000 --_000_F64C10EAA68C8044B33656FA214632C8166CAF76MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Monday, October 20, 2014 5:27 PM To: ccamp@ietf.org Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-11 All, This starts a two-week working group last call on draft-ietf-ccamp-mpls-tp-= rsvpte-ext-associated-lsp-11. This working group last call ends on Nov. 3rd. Please send your comments to= the CCAMP mailing list. As noted, there is one IPR disclosed. Thanks, Deborah (and Lou) --_000_F64C10EAA68C8044B33656FA214632C8166CAF76MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI -

 <= /p>

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, October 20, 2014 5:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-11

 

All,

 

This starts a two-week working group la= st call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11.

 

This working group last call ends on No= v. 3rd. Please send your comments to the CCAMP mailing list.

 

As noted, there is one IPR disclosed.

 

Thanks,

Deborah (and Lou)

 

--_000_F64C10EAA68C8044B33656FA214632C8166CAF76MISOUT7MSGUSRDE_-- From nobody Mon Oct 20 21:00:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0647D1A1B79 for ; Mon, 20 Oct 2014 21:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6hubNxQ71VR for ; Mon, 20 Oct 2014 21:00:39 -0700 (PDT) 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 DDEF21A1B75 for ; Mon, 20 Oct 2014 21:00:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW15778; Tue, 21 Oct 2014 04:00:36 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 05:00:30 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 12:00:27 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: AQHP6hKmkEmia1R/oUuykzp+wfdi1Jw56yww Date: Tue, 21 Oct 2014 04:00:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3747@NKGEML512-MBS.china.huawei.com> References: <544120D1.6000303@pi.nu> In-Reply-To: <544120D1.6000303@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/y6g5XVTpwJ3KhPBxhxtgeW9WExM Cc: "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 04:00:42 -0000 Hi Loa, I am not aware of any patent other than the one which has been disclosed ag= ainst draft-kini-mpls-entropy-label-src-stacked-tunnels. That patent may ap= ply to draft-kini-mpls-spring-entropy-label as well and I will check this i= n detail and respond as soon as possible. Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, October 17, 2014 10:00 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > Subject: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label >=20 > Working Group, >=20 > We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. >=20 > The outcome is such that we anticipate a poll for working group adoption = after > the authors have updated the draft. >=20 > Before we do poll to see if we have consensus to accept the document as a > working group document we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- = label? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are one IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. *Th= e > response needs to be sent to the MPLS wg mailing list.* The document will= not > advance to the next stage until a response has been received from each au= thor > and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR that > has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 21 00:19:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C511AD0A1 for ; Tue, 21 Oct 2014 00:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy3gp8BmT5Ej for ; Tue, 21 Oct 2014 00:19:15 -0700 (PDT) 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 14DE41AD09A for ; Tue, 21 Oct 2014 00:19:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW31249; Tue, 21 Oct 2014 07:19:12 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 08:19:11 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 15:19:05 +0800 From: Mach Chen To: "stbryant@cisco.com" , Eric Rosen , "Carlos Pignataro (cpignata)" , Ross Callon Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgABupQCAAbAhgIAAExGAgARPWrD//6yZAIABnw0Q Date: Tue, 21 Oct 2014 07:19:04 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com> In-Reply-To: <5444EDA4.3070002@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CEuAIA-rggUp1DG-lLxXp7yIqGo Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 07:19:17 -0000 Hi Stewart, Please see my replies inline... > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, October 20, 2014 7:10 PM > To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon > Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Mach >=20 > On 20/10/2014 11:04, Mach Chen wrote: > > Hi Eric , Carlos, Stewart and others, > > > > Thanks for the discussion! Sorry for the top post. > > > > I do think that you're really exaggerating the complexity and negatives= . Given > an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it= 's not > difficult for such kind of routers to support SL. > Those solutions are not the same. >=20 > ELs - have no impact on the receiver. I admit that they have an impact on= the > transmitter (but only two labels) but the only flow state is that an EL n= eeds to be > generated, you do not need additional transmitter context since this is g= enerated > from the packet itself. >=20 > SR - has no impact at ay node other than the transmitter, and in many cas= es the > impact is one or two labels. It does not change the dataplane.. >=20 > Context labels - I am not sure how wide the support for the general cont= ext > label use case is. >=20 > What you are proposing is a far more fundamental change to the dataplane > than any of the above. I may have different view on this, let me make a little bit comparison betw= een SL and EL: 1) For ingress LSR, it's almost the same, except that EL requires the ingre= ss LSR to generate the Entropy, then both just put information into the lab= el stack;=20 2) For transit LSR, EL requires the LSR to know how to handle the ELI and E= L, otherwise cannot benefit from the EL; SL does not bring any requirement = to transit LSR; 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when do S= L based PM, the egress LSR has to use the SL for accounting, but such accou= nting is basic and necessary work for PM; Based above, from the dataplane point of view, the processing and complexit= y is as the same level of EL, and it DOES NOT bring "fundamental" change to= the dataplane; >=20 > > > > I looked though the whole discussions so far, and I am not going to rep= ly each > email one by email, I summarized the topics as follows: > > > > 1) Requirement > > Whether the requirement is compelling depends on whether you need it. W= e > did receive the requirements from SPs to support passive PM for MP2P base= d > LSPs, especially for the case of MPLS based IP backhaul network. So for t= hose SPs, > it's a compelling requirement. Indeed, PM is not an easy work, and in IET= F, > several dedicated WGs work on PM related stuff, some WGs have worked on i= t > over decade. > I am not disputing the requirement for a method of measuring loss of cust= omer > traffic. >=20 > However the requirement for domain wide source labels is not established.= It is > one method of identifying the source in a PM measurement, but it is not t= he only > method. Actually, the latest version DOES NOT require domain wide source labels, th= e source label is just a carrier that is used to carry the domain wide uniq= ue Source Identifier (SI); the SI is transparent to the SL, from the convey= information point of view, it's the same as EL.=20 > > > > This draft is mainly about how to do source identification that is one > > of the critical requirements of the passive PM, > It is about one method. The method you propose is not the only method. >=20 > Also you have jumped directly to a S-D identification approach, without j= ustifying > this as being the required unit of identification. Other than S-D identification, I am not sure that there are other ways that= could be used to perform passive PM. I noticed you mention destination bas= ed approach in another email, can you please elaborate how it works? > > it is not intended to cover all aspects of PM. This is clearly stated i= n the > document. Other aspects, for example, the multiple line cards in the egre= ss as > Stewart pointed out, I do really think that is an implementation issue. F= or that > case, you do need a centralized component to sum up and analyze the stati= stics > and their correlations. > It is not that simple as you know from your other draft, and it does not = make > sense to me to address the two requirements as ships in the night solutio= ns. > Given that you receive a packet on one line card, you have no idea whethe= r a > packet received on another line card (or even line interface on that card= ) was > transmitted before of after the one you are taking as your accounting > reference point. We have a prototype doing IP based passive PM and do consider such scenario= and it works. In this case, you do need a centralized component (which cou= ld reside in a linecard, the main control card or an external entity (e.g.,= NMS)) that can collect all statistic information of the tested flow.=20 > > 2) Label stack depth > > Regarding the label stack depth, there were some related discussions (i= ncluding > this WG and other WGs) , some vendors have showed that is not a big probl= em, > especially for those new generation modern routers/switches. > That is an assumption that you need to justify, particular at the network= edge. We will see such devices come out, especially when Segment Routing progress= ing. > > > > 3) Granularity > > It depends on how you use it. In theory, the solution can support any n= umber > flows. But there always be some tradeoff, as I replied in a precious emai= l, the SI > number itself is not the issue, the HW resource (e.g., the timers) is the= critical > constraint. That means, you cannot expect a router to support unlimited f= lows. > For SI number, I guess that the main concern is mainly about the state > maintenance and advertisement, actually it could be optimized to maintain= and > advertize a single SI block for each LSR. This way, the state and adverti= sement is a > fixed number corresponding to the number of the LSR in the domain. >=20 > The timers can be in s/w in the supervisor, since the time that a measure= ment is > taken is not critical, so whilst there might be a filter and counter issu= e in the h/w, > though no worse than IPFIX, there is not h/w issue with timers. It depends on how you implement the measurement, timer for measurement is i= mportant, it sometime determines the accurate of the measurement. And I als= o agree that filter and counter are the other critical issues. And all thes= e belong to the HW resource. So, I am trying to say, when consider these HW= constraints, the SI state should be not a bit deal. Because you cannot mon= itor unlimited flows on a device. Best regards, Mach >=20 > Stewart > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen > >> Sent: Saturday, October 18, 2014 6:20 AM > >> To: Carlos Pignataro (cpignata); Ross Callon > >> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >> mpls-chairs@tools.ietf.org > >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >> > >> Carlos> Basically, two or three labels are added to the label stack, > >> > >> Actually, that's two or three labels per LSP. A packet may be going > >> through a nested set of LSPs, which each label in the stack representi= ng one > of those LSPs. > >> Each LSP may have its own source label. Since a source label is > >> likely to require three label stack entries, the number of labels in t= he stack > could be quadrupled. > >> And for what? > >> > >> Carlos> the document only lists PM as the application that needs sourc= e > labels. > >> > >> There doesn't seem to be general agreement that this is a compelling u= se > case. > >> Certainly not compelling enough to justify the complexity and the > >> overhead that it brings. > >> > >> Carlos> What happens if a finer granularity than the source node is ne= eded? > >> > >> This is inevitable. How long before folks are complaining "we can't > >> run our network unless the egress LSR can determine the ingress > >> interface for each packet". This could lead to thousands of source la= bel > values for each ingress LSR. > >> And what will happen when someone decides that the granularity needs > >> to be per-subscriber, not merely per-interface? > >> > >> And it's not just "finer granularity" we have to worry about. What > >> if someone decides that an ingress LSR needs to convey an arbitrary am= ount > of "meta-data" > >> about an LSP to the egress LSR. Will the label stack become a set of > >> labels alternating with meta-data containers? > >> > >> Do we really want to put stuff that doesn't affect the packet > >> forwarding into the label stack? Where will we draw the line? > >> > >> I don't think the authors really intend the mechanism to be > >> generalized in this manner. They're probably thinking "But we only > >> intend for this to be deployed in a very simple case, where packets > >> are being tunneled, where the ingress LSR knows who the egress LSR > >> is, where they're in the same administrative domain, etc. etc. > >> You're really exaggerating the negatives." But the proposed > >> mechanisms do lend themselves to abuse or this sort. Once we start > >> putting stuff in the label stack that isn't used for forwarding, how w= ill we know > when to stop? > >> > >> Carlos> Given this dramatic set of extensions and strong > >> Carlos> requirements, it seems > >> prudent to me to better understand the problem space of PM gaps > >> before adopting a solution. > >> > >> I agree. I think Stewart has made a good case that further analysis i= s > needed. > >> The problem isn't that there is no use for source labels, the problem > >> is that the mechanism seems to bring a lot of problems with it. Is > >> this really the only solution? And if so, is it so important to be > >> able to do PM that we should be willing to take on all these problems? > >> > >> I also think the proposed LDP and BGP extensions are problematic, but > >> those issues are really of secondary importance right now. > >> > >> So I don't support the adoption of this draft. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > . > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Oct 21 01:43:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7671A008D for ; Tue, 21 Oct 2014 01:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hwf0wr-c5zL for ; Tue, 21 Oct 2014 01:43:29 -0700 (PDT) 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 BCDAA1A008A for ; Tue, 21 Oct 2014 01:43:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW41897; Tue, 21 Oct 2014 08:43:25 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 09:43:24 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 16:43:18 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX4OkhgWsQGIUeAKGjjOVb0U5v0ZR+AgDvz/2CAB0l4AIAC2yvw Date: Tue, 21 Oct 2014 08:43:17 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jF0E6z3q5RhJYTer_XR5tBrUTeQ Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 08:43:32 -0000 Hi Nobo and Mustapha, I think this may not just require minor changes to RFC7110, it at least req= uires: 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with B bit = set) to notify along reverse direction of the tested LSP; Given there may be existing implementations and the original proposal (defi= ned in RFC7110) works and does not require too much process cost, I incline= to leave it as is and suggest not to define the new dedicated reply mode a= s well. =20 Best regards, Mach=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) > Sent: Monday, October 20, 2014 4:48 AM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e-00.txt >=20 > MPLS WG, >=20 > Many thanks for kicking this off Mustapha. >=20 > I, for one, like Mustaphas suggestion and would be supportive of making t= hat > change. I would also be happy to change > draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect this chang= e, if > there are consensus to do so. >=20 > I have cc'ed the authors of RFC7110 in case they can also chime in with t= houghts. >=20 > Additionally, suggested changes should be very minimal even to those who = has > already implemented RC7110. However, if anybody has implemented and if > anybody has concerns, I think this is a great time for to speak up. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Friday, October 17, 2014 6:19 PM > > To: Nobo Akiya (nobo); mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net) > > Subject: RE: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > 00.txt > > > > Dear all, > > This is a follow-up to the action below from the MPLS-RT review of this= draft. > > > > Instead of defining a new reply mode as proposed in Section 3.1 of the > > draft, I suggested to relax the rule in RFC 7110 such that if the echo > > request includes reply mode 5 "Reply via Specified Path" and the Reply > > Path TLV was not included, the responder node will interpret this as > > an implicit request to reply via the reverse direction of the tested LS= P. > > > > This approach would address the requirement that the sender be able of > > requesting the reply via the reverse path of an LSP without having to > > include an additional TLV. > > > > I appreciate comments on this proposal. > > > > Regards, > > Mustapha. > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > > (nobo) > > > Sent: Saturday, September 06, 2014 9:59 AM > > > To: mpls@ietf.org > > > Cc: Ross Callon (rcallon@juniper.net) > > > Subject: Re: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > Thank you Ross and the WG. > > > > > > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as > > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > > > Authors would like the WG help to discuss and close off on these two > > aspects: > > > > > > - From Bruno Decraene: Reply Mode for SPRING and applicability of > > this > > > document. > > > o There's already a thread for this. > > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by > > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > > o Mustapha or myself will start a thread on this topic later. > > > > > > Once above are close off, then we will roll out -01 that includes: > > > > > > - Conclusion from the two aspects above. > > > - A comment received from Tarek Saad. > > > - Comments received from Lou Berger (will reply to the review > > comments > > > from Lou soon) > > > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > > reply-mode- > > > simple-00.txt > > > Status: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > mode- > > > simple/ > > > Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-r= eply- > > mode-simple-00 > > > > > > Thanks! > > > > > > -Nobo, on behalf of authors > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > > drafts@ietf.org > > > > Sent: Saturday, September 06, 2014 3:41 AM > > > > To: i-d-announce@ietf.org > > > > Cc: mpls@ietf.org > > > > Subject: [mpls] I-D Action: > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > 00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > This draft is a work item of the Multiprotocol Label Switching > > > > Working Group of the IETF. > > > > > > > > Title : Label Switched Path (LSP) Ping/Traceroute > Reply Mode > > > > Simplification > > > > Authors : Nobo Akiya > > > > George Swallow > > > > Carlos Pignataro > > > > Loa Andersson > > > > Mach(Guoyi) Chen > > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.tx= t > > > > Pages : 11 > > > > Date : 2014-09-05 > > > > > > > > Abstract: > > > > The Multiprotocol Label Switching (MPLS) Label Switched Path (LS= P) > > > > Ping and Traceroute use the Reply Mode field to signal the metho= d to > > > > be used in the MPLS echo reply. This document adds one value to= the > > > > Reply Mode field to indicate reverse LSP. This document also ad= ds an > > > > optional TLV which can carry ordered list of Reply Mode values. > > > > > > > > This document updates RFC4379. > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mo > > > > de > > > > - > > > > simple/ > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-sim > > > > pl > > > > e- > > > > 00 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 21 02:11:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB471A010E for ; Tue, 21 Oct 2014 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIv3vwBu84LL for ; Tue, 21 Oct 2014 02:11:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D601A016B for ; Tue, 21 Oct 2014 02:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12162; q=dns/txt; s=iport; t=1413882655; x=1415092255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8H7pF995XBW9h7x+hFWLWA8jbx/aQAEQdS3VG6wfZSo=; b=WqhCaJN4Q62OuH8fGgOCErcDIVCkBJnptu5mVmS+mHlkvHOTLCawwqc/ APcdY6lN9kuW9UGQysyYgIIyV7w4mEB5CqUbFQqGTDGjFkCj2pAGkOZoJ NAUaMsoYfL7nfCfQyMQFj0uDu3/5xllztPhGlvskYoQGLYOOhgmYxJnAX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFsXRlStJA2G/2dsb2JhbABcgmsjU1jMDAqHTQKBDhYBfYQCAQEBAwEBAQE3LQcLBQcEAgEIEQQBAQEeCQcnCxQJCAIEDgUbiBwIAQzEDgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKU4UbAREBHTMCBQaDJ4EeBZIBi1mBMINGjSuEAYN3bAGBDoE8AQEB X-IronPort-AV: E=Sophos;i="5.04,760,1406592000"; d="scan'208";a="365245658" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 21 Oct 2014 09:10:54 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9L9AqjW025007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 09:10:52 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 04:10:52 -0500 From: "Carlos Pignataro (cpignata)" To: Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+l2b155pZvakGO4uRCWsmh1pwzbxUAgAGwIACAABMSgIAD6XaAgAASfgCAAVGtAP//y2uE Date: Tue, 21 Oct 2014 09:10:51 +0000 Message-ID: <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/a6WXLyMpJGN8qytNw1fIYCpwbGc Cc: "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:11:05 -0000 Hi Mach, Please find one set of comments inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Oct 21, 2014, at 3:19 AM, Mach Chen wrote: >=20 > Hi Stewart, >=20 > Please see my replies inline... >=20 >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Monday, October 20, 2014 7:10 PM >> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon >> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> Mach >>=20 >>> On 20/10/2014 11:04, Mach Chen wrote: >>> Hi Eric , Carlos, Stewart and others, >>>=20 >>> Thanks for the discussion! Sorry for the top post. >>>=20 >>> I do think that you're really exaggerating the complexity and negatives= . Given >> an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO i= t's not >> difficult for such kind of routers to support SL. >> Those solutions are not the same. >>=20 >> ELs - have no impact on the receiver. I admit that they have an impact o= n the >> transmitter (but only two labels) but the only flow state is that an EL = needs to be >> generated, you do not need additional transmitter context since this is = generated >> from the packet itself. >>=20 >> SR - has no impact at ay node other than the transmitter, and in many ca= ses the >> impact is one or two labels. It does not change the dataplane.. >>=20 >> Context labels - I am not sure how wide the support for the general con= text >> label use case is. >>=20 >> What you are proposing is a far more fundamental change to the dataplan= e >> than any of the above. >=20 > I may have different view on this, let me make a little bit comparison be= tween SL and EL: >=20 The EL is used for forwarding/dispatch decisions. The SL is metadata, not u= sed for forwarding. The fundamental change to the dataplane is using it to = carry metadata.=20 > 1) For ingress LSR, it's almost the same, except that EL requires the ing= ress LSR to generate the Entropy, then both just put information into the l= abel stack;=20 >=20 > 2) For transit LSR, EL requires the LSR to know how to handle the ELI and= EL, otherwise cannot benefit from the EL; SL does not bring any requiremen= t to transit LSR; >=20 > 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when do= SL based PM, the egress LSR has to use the SL for accounting, but such acc= ounting is basic and necessary work for PM; >=20 Extrapolating from your argument, we could add a number of labels to the st= ack that do not carry forwarding instructions without any concerns. SL, wha= t's next? > Based above, from the dataplane point of view, the processing and complex= ity is as the same level of EL, and it DOES NOT bring "fundamental" change = to the dataplane; >=20 The change, in my view, is in the semantics of the label.=20 Given how fundamental this is (in my mind) it calls for a more comprehensiv= e understanding of the problem being solved.=20 Thanks, Carlos.=20 >>=20 >>>=20 >>> I looked though the whole discussions so far, and I am not going to rep= ly each >> email one by email, I summarized the topics as follows: >>>=20 >>> 1) Requirement >>> Whether the requirement is compelling depends on whether you need it. W= e >> did receive the requirements from SPs to support passive PM for MP2P bas= ed >> LSPs, especially for the case of MPLS based IP backhaul network. So for = those SPs, >> it's a compelling requirement. Indeed, PM is not an easy work, and in IE= TF, >> several dedicated WGs work on PM related stuff, some WGs have worked on = it >> over decade. >> I am not disputing the requirement for a method of measuring loss of cus= tomer >> traffic. >>=20 >> However the requirement for domain wide source labels is not established= . It is >> one method of identifying the source in a PM measurement, but it is not = the only >> method. >=20 > Actually, the latest version DOES NOT require domain wide source labels, = the source label is just a carrier that is used to carry the domain wide un= ique Source Identifier (SI); the SI is transparent to the SL, from the conv= ey information point of view, it's the same as EL.=20 >=20 >>>=20 >>> This draft is mainly about how to do source identification that is one >>> of the critical requirements of the passive PM, >> It is about one method. The method you propose is not the only method. >>=20 >> Also you have jumped directly to a S-D identification approach, without = justifying >> this as being the required unit of identification. >=20 > Other than S-D identification, I am not sure that there are other ways th= at could be used to perform passive PM. I noticed you mention destination b= ased approach in another email, can you please elaborate how it works? >=20 >>> it is not intended to cover all aspects of PM. This is clearly stated i= n the >> document. Other aspects, for example, the multiple line cards in the egr= ess as >> Stewart pointed out, I do really think that is an implementation issue. = For that >> case, you do need a centralized component to sum up and analyze the stat= istics >> and their correlations. >> It is not that simple as you know from your other draft, and it does not= make >> sense to me to address the two requirements as ships in the night soluti= ons. >> Given that you receive a packet on one line card, you have no idea wheth= er a >> packet received on another line card (or even line interface on that car= d) was >> transmitted before of after the one you are taking as your accounting >> reference point. >=20 > We have a prototype doing IP based passive PM and do consider such scenar= io and it works. In this case, you do need a centralized component (which c= ould reside in a linecard, the main control card or an external entity (e.g= ., NMS)) that can collect all statistic information of the tested flow.=20 >=20 >>> 2) Label stack depth >>> Regarding the label stack depth, there were some related discussions (i= ncluding >> this WG and other WGs) , some vendors have showed that is not a big prob= lem, >> especially for those new generation modern routers/switches. >> That is an assumption that you need to justify, particular at the networ= k edge. >=20 > We will see such devices come out, especially when Segment Routing progre= ssing. >=20 >>>=20 >>> 3) Granularity >>> It depends on how you use it. In theory, the solution can support any n= umber >> flows. But there always be some tradeoff, as I replied in a precious ema= il, the SI >> number itself is not the issue, the HW resource (e.g., the timers) is th= e critical >> constraint. That means, you cannot expect a router to support unlimited = flows. >> For SI number, I guess that the main concern is mainly about the state >> maintenance and advertisement, actually it could be optimized to maintai= n and >> advertize a single SI block for each LSR. This way, the state and advert= isement is a >> fixed number corresponding to the number of the LSR in the domain. >>=20 >> The timers can be in s/w in the supervisor, since the time that a measur= ement is >> taken is not critical, so whilst there might be a filter and counter iss= ue in the h/w, >> though no worse than IPFIX, there is not h/w issue with timers. >=20 > It depends on how you implement the measurement, timer for measurement is= important, it sometime determines the accurate of the measurement. And I a= lso agree that filter and counter are the other critical issues. And all th= ese belong to the HW resource. So, I am trying to say, when consider these = HW constraints, the SI state should be not a bit deal. Because you cannot m= onitor unlimited flows on a device. >=20 > Best regards, > Mach >=20 >>=20 >> Stewart >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen >>>> Sent: Saturday, October 18, 2014 6:20 AM >>>> To: Carlos Pignataro (cpignata); Ross Callon >>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>> mpls-chairs@tools.ietf.org >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>=20 >>>> Carlos> Basically, two or three labels are added to the label stack, >>>>=20 >>>> Actually, that's two or three labels per LSP. A packet may be going >>>> through a nested set of LSPs, which each label in the stack representi= ng one >> of those LSPs. >>>> Each LSP may have its own source label. Since a source label is >>>> likely to require three label stack entries, the number of labels in t= he stack >> could be quadrupled. >>>> And for what? >>>>=20 >>>> Carlos> the document only lists PM as the application that needs sourc= e >> labels. >>>>=20 >>>> There doesn't seem to be general agreement that this is a compelling u= se >> case. >>>> Certainly not compelling enough to justify the complexity and the >>>> overhead that it brings. >>>>=20 >>>> Carlos> What happens if a finer granularity than the source node is ne= eded? >>>>=20 >>>> This is inevitable. How long before folks are complaining "we can't >>>> run our network unless the egress LSR can determine the ingress >>>> interface for each packet". This could lead to thousands of source la= bel >> values for each ingress LSR. >>>> And what will happen when someone decides that the granularity needs >>>> to be per-subscriber, not merely per-interface? >>>>=20 >>>> And it's not just "finer granularity" we have to worry about. What >>>> if someone decides that an ingress LSR needs to convey an arbitrary am= ount >> of "meta-data" >>>> about an LSP to the egress LSR. Will the label stack become a set of >>>> labels alternating with meta-data containers? >>>>=20 >>>> Do we really want to put stuff that doesn't affect the packet >>>> forwarding into the label stack? Where will we draw the line? >>>>=20 >>>> I don't think the authors really intend the mechanism to be >>>> generalized in this manner. They're probably thinking "But we only >>>> intend for this to be deployed in a very simple case, where packets >>>> are being tunneled, where the ingress LSR knows who the egress LSR >>>> is, where they're in the same administrative domain, etc. etc. >>>> You're really exaggerating the negatives." But the proposed >>>> mechanisms do lend themselves to abuse or this sort. Once we start >>>> putting stuff in the label stack that isn't used for forwarding, how w= ill we know >> when to stop? >>>>=20 >>>> Carlos> Given this dramatic set of extensions and strong >>>> Carlos> requirements, it seems >>>> prudent to me to better understand the problem space of PM gaps >>>> before adopting a solution. >>>>=20 >>>> I agree. I think Stewart has made a good case that further analysis i= s >> needed. >>>> The problem isn't that there is no use for source labels, the problem >>>> is that the mechanism seems to bring a lot of problems with it. Is >>>> this really the only solution? And if so, is it so important to be >>>> able to do PM that we should be willing to take on all these problems? >>>>=20 >>>> I also think the proposed LDP and BGP extensions are problematic, but >>>> those issues are really of secondary importance right now. >>>>=20 >>>> So I don't support the adoption of this draft. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> . >>=20 >>=20 >> -- >> For corporate legal information go to: >>=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From nobody Tue Oct 21 02:55:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D151A017E for ; Tue, 21 Oct 2014 02:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azphme4cb9MZ for ; Tue, 21 Oct 2014 02:55:07 -0700 (PDT) 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 4C14A1A00B2 for ; Tue, 21 Oct 2014 02:54:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKT79963; Tue, 21 Oct 2014 09:54:41 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 10:54:39 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 17:54:36 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgABupQCAAbAhgIAAExGAgARPWrD//6yZAIABnw0Q///R3YCAAJCAsA== Date: Tue, 21 Oct 2014 09:54:35 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> In-Reply-To: <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_SX6-KGJjyL7dA7mwxw-iHKxbPk Cc: "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:55:09 -0000 Hi Carlos, Thanks for sharing your point! > The EL is used for forwarding/dispatch decisions. The SL is metadata, not= used for > forwarding. The fundamental change to the dataplane is using it to carry > metadata. If the criteria is whether a label is used for forwarding, how about GAL? Best regards, Mach > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Tuesday, October 21, 2014 5:11 PM > To: Mach Chen > Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon; > draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Hi Mach, >=20 > Please find one set of comments inline. >=20 > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows >=20 > > On Oct 21, 2014, at 3:19 AM, Mach Chen wrote: > > > > Hi Stewart, > > > > Please see my replies inline... > > > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Monday, October 20, 2014 7:10 PM > >> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon > >> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >> mpls-chairs@tools.ietf.org > >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >> > >> Mach > >> > >>> On 20/10/2014 11:04, Mach Chen wrote: > >>> Hi Eric , Carlos, Stewart and others, > >>> > >>> Thanks for the discussion! Sorry for the top post. > >>> > >>> I do think that you're really exaggerating the complexity and > >>> negatives. Given > >> an LSR can support EL, Segment Routing, MVPN, context label, etc, > >> IMHO it's not difficult for such kind of routers to support SL. > >> Those solutions are not the same. > >> > >> ELs - have no impact on the receiver. I admit that they have an > >> impact on the transmitter (but only two labels) but the only flow > >> state is that an EL needs to be generated, you do not need additional > >> transmitter context since this is generated from the packet itself. > >> > >> SR - has no impact at ay node other than the transmitter, and in many > >> cases the impact is one or two labels. It does not change the dataplan= e.. > >> > >> Context labels - I am not sure how wide the support for the general > >> context label use case is. > >> > >> What you are proposing is a far more fundamental change to the > >> dataplane than any of the above. > > > > I may have different view on this, let me make a little bit comparison = between > SL and EL: > > >=20 > The EL is used for forwarding/dispatch decisions. The SL is metadata, not= used for > forwarding. The fundamental change to the dataplane is using it to carry > metadata. >=20 > > 1) For ingress LSR, it's almost the same, except that EL requires the > > ingress LSR to generate the Entropy, then both just put information > > into the label stack; > > > > 2) For transit LSR, EL requires the LSR to know how to handle the ELI > > and EL, otherwise cannot benefit from the EL; SL does not bring any > > requirement to transit LSR; > > > > 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when > > do SL based PM, the egress LSR has to use the SL for accounting, but > > such accounting is basic and necessary work for PM; > > >=20 > Extrapolating from your argument, we could add a number of labels to the = stack > that do not carry forwarding instructions without any concerns. SL, what'= s next? >=20 > > Based above, from the dataplane point of view, the processing and > > complexity is as the same level of EL, and it DOES NOT bring > > "fundamental" change to the dataplane; > > >=20 > The change, in my view, is in the semantics of the label. >=20 > Given how fundamental this is (in my mind) it calls for a more comprehens= ive > understanding of the problem being solved. >=20 > Thanks, >=20 > Carlos. >=20 > >> > >>> > >>> I looked though the whole discussions so far, and I am not going to > >>> reply each > >> email one by email, I summarized the topics as follows: > >>> > >>> 1) Requirement > >>> Whether the requirement is compelling depends on whether you need > >>> it. We > >> did receive the requirements from SPs to support passive PM for MP2P > >> based LSPs, especially for the case of MPLS based IP backhaul > >> network. So for those SPs, it's a compelling requirement. Indeed, PM > >> is not an easy work, and in IETF, several dedicated WGs work on PM > >> related stuff, some WGs have worked on it over decade. > >> I am not disputing the requirement for a method of measuring loss of > >> customer traffic. > >> > >> However the requirement for domain wide source labels is not > >> established. It is one method of identifying the source in a PM > >> measurement, but it is not the only method. > > > > Actually, the latest version DOES NOT require domain wide source labels= , the > source label is just a carrier that is used to carry the domain wide uniq= ue Source > Identifier (SI); the SI is transparent to the SL, from the convey informa= tion point > of view, it's the same as EL. > > > >>> > >>> This draft is mainly about how to do source identification that is > >>> one of the critical requirements of the passive PM, > >> It is about one method. The method you propose is not the only method. > >> > >> Also you have jumped directly to a S-D identification approach, > >> without justifying this as being the required unit of identification. > > > > Other than S-D identification, I am not sure that there are other ways = that could > be used to perform passive PM. I noticed you mention destination based > approach in another email, can you please elaborate how it works? > > > >>> it is not intended to cover all aspects of PM. This is clearly > >>> stated in the > >> document. Other aspects, for example, the multiple line cards in the > >> egress as Stewart pointed out, I do really think that is an > >> implementation issue. For that case, you do need a centralized > >> component to sum up and analyze the statistics and their correlations. > >> It is not that simple as you know from your other draft, and it does > >> not make sense to me to address the two requirements as ships in the n= ight > solutions. > >> Given that you receive a packet on one line card, you have no idea > >> whether a packet received on another line card (or even line > >> interface on that card) was transmitted before of after the one you > >> are taking as your accounting reference point. > > > > We have a prototype doing IP based passive PM and do consider such scen= ario > and it works. In this case, you do need a centralized component (which co= uld > reside in a linecard, the main control card or an external entity (e.g., = NMS)) that > can collect all statistic information of the tested flow. > > > >>> 2) Label stack depth > >>> Regarding the label stack depth, there were some related discussions > >>> (including > >> this WG and other WGs) , some vendors have showed that is not a big > >> problem, especially for those new generation modern routers/switches. > >> That is an assumption that you need to justify, particular at the netw= ork edge. > > > > We will see such devices come out, especially when Segment Routing > progressing. > > > >>> > >>> 3) Granularity > >>> It depends on how you use it. In theory, the solution can support > >>> any number > >> flows. But there always be some tradeoff, as I replied in a precious > >> email, the SI number itself is not the issue, the HW resource (e.g., > >> the timers) is the critical constraint. That means, you cannot expect = a router to > support unlimited flows. > >> For SI number, I guess that the main concern is mainly about the > >> state maintenance and advertisement, actually it could be optimized > >> to maintain and advertize a single SI block for each LSR. This way, > >> the state and advertisement is a fixed number corresponding to the num= ber > of the LSR in the domain. > >> > >> The timers can be in s/w in the supervisor, since the time that a > >> measurement is taken is not critical, so whilst there might be a > >> filter and counter issue in the h/w, though no worse than IPFIX, there= is not > h/w issue with timers. > > > > It depends on how you implement the measurement, timer for measurement > is important, it sometime determines the accurate of the measurement. And= I > also agree that filter and counter are the other critical issues. And all= these belong > to the HW resource. So, I am trying to say, when consider these HW constr= aints, > the SI state should be not a bit deal. Because you cannot monitor unlimit= ed flows > on a device. > > > > Best regards, > > Mach > > > >> > >> Stewart > >>> > >>> Best regards, > >>> Mach > >>> > >>>> -----Original Message----- > >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen > >>>> Sent: Saturday, October 18, 2014 6:20 AM > >>>> To: Carlos Pignataro (cpignata); Ross Callon > >>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >>>> mpls-chairs@tools.ietf.org > >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >>>> > >>>> Carlos> Basically, two or three labels are added to the label > >>>> Carlos> stack, > >>>> > >>>> Actually, that's two or three labels per LSP. A packet may be > >>>> going through a nested set of LSPs, which each label in the stack > >>>> representing one > >> of those LSPs. > >>>> Each LSP may have its own source label. Since a source label is > >>>> likely to require three label stack entries, the number of labels > >>>> in the stack > >> could be quadrupled. > >>>> And for what? > >>>> > >>>> Carlos> the document only lists PM as the application that needs > >>>> Carlos> source > >> labels. > >>>> > >>>> There doesn't seem to be general agreement that this is a > >>>> compelling use > >> case. > >>>> Certainly not compelling enough to justify the complexity and the > >>>> overhead that it brings. > >>>> > >>>> Carlos> What happens if a finer granularity than the source node is > needed? > >>>> > >>>> This is inevitable. How long before folks are complaining "we > >>>> can't run our network unless the egress LSR can determine the > >>>> ingress interface for each packet". This could lead to thousands > >>>> of source label > >> values for each ingress LSR. > >>>> And what will happen when someone decides that the granularity > >>>> needs to be per-subscriber, not merely per-interface? > >>>> > >>>> And it's not just "finer granularity" we have to worry about. What > >>>> if someone decides that an ingress LSR needs to convey an arbitrary > >>>> amount > >> of "meta-data" > >>>> about an LSP to the egress LSR. Will the label stack become a set > >>>> of labels alternating with meta-data containers? > >>>> > >>>> Do we really want to put stuff that doesn't affect the packet > >>>> forwarding into the label stack? Where will we draw the line? > >>>> > >>>> I don't think the authors really intend the mechanism to be > >>>> generalized in this manner. They're probably thinking "But we only > >>>> intend for this to be deployed in a very simple case, where packets > >>>> are being tunneled, where the ingress LSR knows who the egress LSR > >>>> is, where they're in the same administrative domain, etc. etc. > >>>> You're really exaggerating the negatives." But the proposed > >>>> mechanisms do lend themselves to abuse or this sort. Once we start > >>>> putting stuff in the label stack that isn't used for forwarding, > >>>> how will we know > >> when to stop? > >>>> > >>>> Carlos> Given this dramatic set of extensions and strong > >>>> Carlos> requirements, it seems > >>>> prudent to me to better understand the problem space of PM gaps > >>>> before adopting a solution. > >>>> > >>>> I agree. I think Stewart has made a good case that further > >>>> analysis is > >> needed. > >>>> The problem isn't that there is no use for source labels, the > >>>> problem is that the mechanism seems to bring a lot of problems with > >>>> it. Is this really the only solution? And if so, is it so > >>>> important to be able to do PM that we should be willing to take on a= ll these > problems? > >>>> > >>>> I also think the proposed LDP and BGP extensions are problematic, > >>>> but those issues are really of secondary importance right now. > >>>> > >>>> So I don't support the adoption of this draft. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>> . > >> > >> > >> -- > >> For corporate legal information go to: > >> > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > From nobody Tue Oct 21 04:21:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B961A1A97 for ; Tue, 21 Oct 2014 04:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GP8wljNzc6e for ; Tue, 21 Oct 2014 04:21:03 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E161A1A93 for ; Tue, 21 Oct 2014 04:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13321; q=dns/txt; s=iport; t=1413890463; x=1415100063; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SGV6vqKb4p5hKbjHk5GXfXl8rWJwR3UaRyVawtYtHiA=; b=Za4XHnMOwpAJtx+JkQGDEPMcdLeqGymjAqMazoIStL4LWvKXosGZt49d m8ltHRySJezG12ztnENTlxrEGInHsHzLF3GfdO+0gBQNXf2cIt/i5eqLi 1yA85el+03mxyFJpcZC0AznnJFFZFNWKoKIS/DhKj7ckTbomB7CC0zMvl I=; X-IronPort-AV: E=Sophos;i="5.04,761,1406592000"; d="scan'208";a="88943613" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 21 Oct 2014 11:21:02 +0000 Received: from [10.21.66.80] (sjc-vpn3-592.cisco.com [10.21.66.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9LBL1pf013092; Tue, 21 Oct 2014 11:21:02 GMT Message-ID: <5446419F.7020005@cisco.com> Date: Tue, 21 Oct 2014 12:21:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mach Chen , "Carlos Pignataro (cpignata)" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZAwvx5rpusfCkwmJsJFflHsIw0s Cc: Ross Callon , "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:21:07 -0000 GAL tells an LSR what to do with the pkt - it says please dispatch to the OAM handler. - Stewart On 21/10/2014 10:54, Mach Chen wrote: > Hi Carlos, > > Thanks for sharing your point! > >> The EL is used for forwarding/dispatch decisions. The SL is metadata, not used for >> forwarding. The fundamental change to the dataplane is using it to carry >> metadata. > If the criteria is whether a label is used for forwarding, how about GAL? > > Best regards, > Mach > >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Tuesday, October 21, 2014 5:11 PM >> To: Mach Chen >> Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon; >> draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >> >> Hi Mach, >> >> Please find one set of comments inline. >> >> Thumb typed by Carlos Pignataro. >> Excuze typofraphicak errows >> >>> On Oct 21, 2014, at 3:19 AM, Mach Chen wrote: >>> >>> Hi Stewart, >>> >>> Please see my replies inline... >>> >>>> -----Original Message----- >>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>> Sent: Monday, October 20, 2014 7:10 PM >>>> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon >>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>> mpls-chairs@tools.ietf.org >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>> >>>> Mach >>>> >>>>> On 20/10/2014 11:04, Mach Chen wrote: >>>>> Hi Eric , Carlos, Stewart and others, >>>>> >>>>> Thanks for the discussion! Sorry for the top post. >>>>> >>>>> I do think that you're really exaggerating the complexity and >>>>> negatives. Given >>>> an LSR can support EL, Segment Routing, MVPN, context label, etc, >>>> IMHO it's not difficult for such kind of routers to support SL. >>>> Those solutions are not the same. >>>> >>>> ELs - have no impact on the receiver. I admit that they have an >>>> impact on the transmitter (but only two labels) but the only flow >>>> state is that an EL needs to be generated, you do not need additional >>>> transmitter context since this is generated from the packet itself. >>>> >>>> SR - has no impact at ay node other than the transmitter, and in many >>>> cases the impact is one or two labels. It does not change the dataplane.. >>>> >>>> Context labels - I am not sure how wide the support for the general >>>> context label use case is. >>>> >>>> What you are proposing is a far more fundamental change to the >>>> dataplane than any of the above. >>> I may have different view on this, let me make a little bit comparison between >> SL and EL: >> The EL is used for forwarding/dispatch decisions. The SL is metadata, not used for >> forwarding. The fundamental change to the dataplane is using it to carry >> metadata. >> >>> 1) For ingress LSR, it's almost the same, except that EL requires the >>> ingress LSR to generate the Entropy, then both just put information >>> into the label stack; >>> >>> 2) For transit LSR, EL requires the LSR to know how to handle the ELI >>> and EL, otherwise cannot benefit from the EL; SL does not bring any >>> requirement to transit LSR; >>> >>> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when >>> do SL based PM, the egress LSR has to use the SL for accounting, but >>> such accounting is basic and necessary work for PM; >>> >> Extrapolating from your argument, we could add a number of labels to the stack >> that do not carry forwarding instructions without any concerns. SL, what's next? >> >>> Based above, from the dataplane point of view, the processing and >>> complexity is as the same level of EL, and it DOES NOT bring >>> "fundamental" change to the dataplane; >>> >> The change, in my view, is in the semantics of the label. >> >> Given how fundamental this is (in my mind) it calls for a more comprehensive >> understanding of the problem being solved. >> >> Thanks, >> >> Carlos. >> >>>>> I looked though the whole discussions so far, and I am not going to >>>>> reply each >>>> email one by email, I summarized the topics as follows: >>>>> 1) Requirement >>>>> Whether the requirement is compelling depends on whether you need >>>>> it. We >>>> did receive the requirements from SPs to support passive PM for MP2P >>>> based LSPs, especially for the case of MPLS based IP backhaul >>>> network. So for those SPs, it's a compelling requirement. Indeed, PM >>>> is not an easy work, and in IETF, several dedicated WGs work on PM >>>> related stuff, some WGs have worked on it over decade. >>>> I am not disputing the requirement for a method of measuring loss of >>>> customer traffic. >>>> >>>> However the requirement for domain wide source labels is not >>>> established. It is one method of identifying the source in a PM >>>> measurement, but it is not the only method. >>> Actually, the latest version DOES NOT require domain wide source labels, the >> source label is just a carrier that is used to carry the domain wide unique Source >> Identifier (SI); the SI is transparent to the SL, from the convey information point >> of view, it's the same as EL. >>>>> This draft is mainly about how to do source identification that is >>>>> one of the critical requirements of the passive PM, >>>> It is about one method. The method you propose is not the only method. >>>> >>>> Also you have jumped directly to a S-D identification approach, >>>> without justifying this as being the required unit of identification. >>> Other than S-D identification, I am not sure that there are other ways that could >> be used to perform passive PM. I noticed you mention destination based >> approach in another email, can you please elaborate how it works? >>>>> it is not intended to cover all aspects of PM. This is clearly >>>>> stated in the >>>> document. Other aspects, for example, the multiple line cards in the >>>> egress as Stewart pointed out, I do really think that is an >>>> implementation issue. For that case, you do need a centralized >>>> component to sum up and analyze the statistics and their correlations. >>>> It is not that simple as you know from your other draft, and it does >>>> not make sense to me to address the two requirements as ships in the night >> solutions. >>>> Given that you receive a packet on one line card, you have no idea >>>> whether a packet received on another line card (or even line >>>> interface on that card) was transmitted before of after the one you >>>> are taking as your accounting reference point. >>> We have a prototype doing IP based passive PM and do consider such scenario >> and it works. In this case, you do need a centralized component (which could >> reside in a linecard, the main control card or an external entity (e.g., NMS)) that >> can collect all statistic information of the tested flow. >>>>> 2) Label stack depth >>>>> Regarding the label stack depth, there were some related discussions >>>>> (including >>>> this WG and other WGs) , some vendors have showed that is not a big >>>> problem, especially for those new generation modern routers/switches. >>>> That is an assumption that you need to justify, particular at the network edge. >>> We will see such devices come out, especially when Segment Routing >> progressing. >>>>> 3) Granularity >>>>> It depends on how you use it. In theory, the solution can support >>>>> any number >>>> flows. But there always be some tradeoff, as I replied in a precious >>>> email, the SI number itself is not the issue, the HW resource (e.g., >>>> the timers) is the critical constraint. That means, you cannot expect a router to >> support unlimited flows. >>>> For SI number, I guess that the main concern is mainly about the >>>> state maintenance and advertisement, actually it could be optimized >>>> to maintain and advertize a single SI block for each LSR. This way, >>>> the state and advertisement is a fixed number corresponding to the number >> of the LSR in the domain. >>>> The timers can be in s/w in the supervisor, since the time that a >>>> measurement is taken is not critical, so whilst there might be a >>>> filter and counter issue in the h/w, though no worse than IPFIX, there is not >> h/w issue with timers. >>> It depends on how you implement the measurement, timer for measurement >> is important, it sometime determines the accurate of the measurement. And I >> also agree that filter and counter are the other critical issues. And all these belong >> to the HW resource. So, I am trying to say, when consider these HW constraints, >> the SI state should be not a bit deal. Because you cannot monitor unlimited flows >> on a device. >>> Best regards, >>> Mach >>> >>>> Stewart >>>>> Best regards, >>>>> Mach >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen >>>>>> Sent: Saturday, October 18, 2014 6:20 AM >>>>>> To: Carlos Pignataro (cpignata); Ross Callon >>>>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>>>> mpls-chairs@tools.ietf.org >>>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>> >>>>>> Carlos> Basically, two or three labels are added to the label >>>>>> Carlos> stack, >>>>>> >>>>>> Actually, that's two or three labels per LSP. A packet may be >>>>>> going through a nested set of LSPs, which each label in the stack >>>>>> representing one >>>> of those LSPs. >>>>>> Each LSP may have its own source label. Since a source label is >>>>>> likely to require three label stack entries, the number of labels >>>>>> in the stack >>>> could be quadrupled. >>>>>> And for what? >>>>>> >>>>>> Carlos> the document only lists PM as the application that needs >>>>>> Carlos> source >>>> labels. >>>>>> There doesn't seem to be general agreement that this is a >>>>>> compelling use >>>> case. >>>>>> Certainly not compelling enough to justify the complexity and the >>>>>> overhead that it brings. >>>>>> >>>>>> Carlos> What happens if a finer granularity than the source node is >> needed? >>>>>> This is inevitable. How long before folks are complaining "we >>>>>> can't run our network unless the egress LSR can determine the >>>>>> ingress interface for each packet". This could lead to thousands >>>>>> of source label >>>> values for each ingress LSR. >>>>>> And what will happen when someone decides that the granularity >>>>>> needs to be per-subscriber, not merely per-interface? >>>>>> >>>>>> And it's not just "finer granularity" we have to worry about. What >>>>>> if someone decides that an ingress LSR needs to convey an arbitrary >>>>>> amount >>>> of "meta-data" >>>>>> about an LSP to the egress LSR. Will the label stack become a set >>>>>> of labels alternating with meta-data containers? >>>>>> >>>>>> Do we really want to put stuff that doesn't affect the packet >>>>>> forwarding into the label stack? Where will we draw the line? >>>>>> >>>>>> I don't think the authors really intend the mechanism to be >>>>>> generalized in this manner. They're probably thinking "But we only >>>>>> intend for this to be deployed in a very simple case, where packets >>>>>> are being tunneled, where the ingress LSR knows who the egress LSR >>>>>> is, where they're in the same administrative domain, etc. etc. >>>>>> You're really exaggerating the negatives." But the proposed >>>>>> mechanisms do lend themselves to abuse or this sort. Once we start >>>>>> putting stuff in the label stack that isn't used for forwarding, >>>>>> how will we know >>>> when to stop? >>>>>> Carlos> Given this dramatic set of extensions and strong >>>>>> Carlos> requirements, it seems >>>>>> prudent to me to better understand the problem space of PM gaps >>>>>> before adopting a solution. >>>>>> >>>>>> I agree. I think Stewart has made a good case that further >>>>>> analysis is >>>> needed. >>>>>> The problem isn't that there is no use for source labels, the >>>>>> problem is that the mechanism seems to bring a lot of problems with >>>>>> it. Is this really the only solution? And if so, is it so >>>>>> important to be able to do PM that we should be willing to take on all these >> problems? >>>>>> I also think the proposed LDP and BGP extensions are problematic, >>>>>> but those issues are really of secondary importance right now. >>>>>> >>>>>> So I don't support the adoption of this draft. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> . >>>> >>>> -- >>>> For corporate legal information go to: >>>> >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Oct 21 05:19:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA151A1B34 for ; Tue, 21 Oct 2014 05:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYxI8FwpwQ6c for ; Tue, 21 Oct 2014 05:19:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B921A1B30 for ; Tue, 21 Oct 2014 05:19:11 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 73EBF190533; Tue, 21 Oct 2014 14:19:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 52F84C8065; Tue, 21 Oct 2014 14:19:09 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.32]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 14:19:09 +0200 From: To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: AQHP6hKiuMkUZwLvnkCemcvl6hItVJw6fj0A Date: Tue, 21 Oct 2014 12:19:08 +0000 Message-ID: <25199_1413893949_54464F3D_25199_10912_1_9E32478DFA9976438E7A22F69B08FF9213AE58@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <544120D1.6000303@pi.nu> In-Reply-To: <544120D1.6000303@pi.nu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.21.110025 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/e5Y3xYl2ezl_2Q9q7ArSKboBQuo Cc: "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:19:14 -0000 I'm not aware of any IPR -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, October 17, 2014 16:00 To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-kini-mpls-spring-entropy-label@tools.= ietf.org Subject: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Working Group, We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. The outcome is such that we anticipate a poll for working group adoption af= ter the authors have updated the draft. Before we do poll to see if we have consensus to accept the document as a w= orking group document we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- la= bel? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). Currently there are one IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS wg mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Oct 21 06:30:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236741A3B9D; Tue, 21 Oct 2014 06:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev-SkLNzfChG; Tue, 21 Oct 2014 06:30:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23D21A6EE4; Tue, 21 Oct 2014 06:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 562581BC17C3; Tue, 21 Oct 2014 06:30:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EECF41BC1841; Tue, 21 Oct 2014 06:30:22 -0700 (PDT) Message-ID: <54465FED.6030005@joelhalpern.com> Date: Tue, 21 Oct 2014 09:30:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lizhong Jin References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> In-Reply-To: <012001cfec30$18d91920$4a8b4b60$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S26ZZEBQUZ0A1ddZwXbojGXbqUs Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:30:29 -0000 If the process for this draft is to use the top address that can be reached in the routing table, then there is a significant probability that the original source address, which is always at the top of the list, will be used. As such, the intended problem will not be solved. Assuming that the source domain and the replying domain are not using the same private address space, while trying to craft a solution for replying to messages sourced by nodes in a private address domain, does not seem effective. Yes, changing the text so that you never refer to public address and always talk about routable address will make the document consistent. But that does not seem to me to be sufficient. The design, with the search order and the removal of entries, is clearly aimed at using as few relays as possible. Which is understandable. But makes the problem very hard. Yours, Joel On 10/20/14, 2:35 AM, Lizhong Jin wrote: > Hi Joel, > Sorry for the late reply. I missed this email, and was reminded by Adrian. > Thank you for the review. Please see my comments inline below. > > Regards > Lizhong > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 08 Oct 2014 19:20:17 -0400 >> From: "Joel M. Halpern" >> To: "A. Jean Mahoney" , gen-art@ietf.org, >> "mpls@ietf.org" , Adrian Farrel >> , >> IETF discussion list >> Subject: [mpls] [Gen-art] review: >> draft-ietf-mpls-lsp-ping-relay-reply-04 >> Message-ID: <5435C6B1.2090908@joelhalpern.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> I am the assigned Gen-ART reviewer for this draft. For background on Gen- >> ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-mpls-lsp-ping-relay-reply-04 >> Relayed Echo Reply mechanism for LSP Ping >> Reviewer: Joel M. Halpern >> Review Date: 8-October-2014 >> IETF LC End Date: 13-October-2014 >> IESG Telechat date: (if known) >> >> Summary: This document is not ready for publication as a Proposed Standard >> >> Major issues: >> There is either a major technical flaw in this document, or there is > a need >> for significantly better explanation. The following is what I was able to >> understand from reading the document. >> The procedure in the document calls for a responding or relaying LSR > to >> search the response addresses from the top to the bottom (top being the >> originator of the request, bottom being visible originators). >> The responder then sends the reply to the first usable address it can > find in >> the stack. Usable is variously described as "public routable" >> and as "routable" (in sections 4.2), the converse is described as > "unroutable" >> in section 4.3, while section 4.4 uses "routable". >> If it means "routable", then this assumes that the private addresses used > by >> one AS will not happen to also be used in another AS (which would make >> them routable in that domain, directing the reply to completely the wrong >> place. >> If it means "publicly routable", this would seem to fail since routers do > not >> know whether routable addresses are public, private, or simply not > martian. > [Lizhong] the "routable address" means that it is possible to route an IP > packet to this address using the normal information exchanged by the IGP > operating in the AS. I will add the definition explicitly in the document. > And for section 2, change "private address" to "routable address in AS1, but > not routable in AS2". For section 4.2, change "first public routable IP > address" to "first routable IP address". > Hope above changing will make things clear. > >> >> Minor issues: >> The procedures assume that border routers will know the correct > address >> to put in the reply stack. It is not bovious that even if the router has > a public >> address, it will get put on. The requirement stated here is that the > address >> put on be the same one used to originate the reply. Which would seem > likely >> to be na internal address in many cases. > [Lizhong] If there is a public address on the node, it is also possible to > add that address to the stack, which will help to relay the reply back. > Rephrase section 4.2: > The first address entry added by the replying LSR MUST be same as the source > IP address of Relay Echo Reply (section 4.3) or Echo Reply message (section > 4.5) being sent. A second or more address entries could also be added if > necessary, which depends on implementation. > >> >> The procedure for setting k=0 allowing entries to be removed from the >> stack seems fragile. It relies on routers being able to determine that > their >> address will not be needed for relay by the next hop. > [Lizhong] if k=0, then the Relay Node Address Stack TLV could be compressed > to reduce the relayed hop number. This is a useful feature, and top to down > searching of the routable address will ensure relaying reply back correctly. > >> >> Nits/editorial comments: >> Some of the procedure for originating a reply is described in section > 4.2 on >> Receiving a request, rather than in seciton 4.3 on originating the reply. >> (Information such as the address to put on the stack, where it goes on the >> stack, and the handling of the reply packet being too large all belong in > 4.3.) > [Lizhong] we try to put all Relay Node Address Stack processing into one > place to make it clear. Splitting the stack processing words into two > sections may cause confusion. But we could add a sentence in section 4.3, > saying that the updating of Relay Node Address Stack TLV in Relayed Echo > Reply is described in section 4.2. > >> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> ------------------------------ >> >> End of mpls Digest, Vol 126, Issue 10 >> ************************************* > > From nobody Tue Oct 21 07:36:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02751A6FFF; Tue, 21 Oct 2014 07:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSKkuYtnC964; Tue, 21 Oct 2014 07:36:14 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358A31A6FF9; Tue, 21 Oct 2014 07:36:14 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id v10so1450336pde.22 for ; Tue, 21 Oct 2014 07:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I0h/O4udNtcDpt0MsbNR5AePpII7AsTUbqi7+M2DMCU=; b=XpcEe0bkf+hV00wNCvcna76Sxv9ABb41VL402mIdDt3nozwvFQS5dVBNguvCUiPnHj LYxFwJcNa5vndyImegquUkxr2dKsMPp4KZqtaIHw0z4J+bLy+1McIipDtYzf2KLXwrxB zbS/03C/CFXSDjlWRKsYmJ9xZSrOlCjL7aOwgkxWIGQCzliqWCeLTZmQFvAw5dwkh1GV ACxQ9SuCRaAN2YYkIAP5RVzmUiHvpq4niMYUI5iipk0HnDs4G+EMmdDL9gN/8/Sl7M35 EEo0c3wd4gn+DRlJJ1X8GQHy5H6BLkCy1du0h3BLIuXEwxpqwcGOHUCv/4bXfasqdajD OTAw== X-Received: by 10.66.246.196 with SMTP id xy4mr36267655pac.29.1413902173835; Tue, 21 Oct 2014 07:36:13 -0700 (PDT) Received: from [192.168.1.101] ([114.62.209.216]) by mx.google.com with ESMTPSA id pc2sm9752789pbb.85.2014.10.21.07.36.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 07:36:13 -0700 (PDT) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: "lizho.jin@gmail.com" X-Mailer: iPad Mail (12A405) In-Reply-To: <54465FED.6030005@joelhalpern.com> Date: Tue, 21 Oct 2014 22:36:07 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5Cw_TbQlCDxafi24t_1ugeWLlZo Cc: "mpls@ietf.org" , "gen-art@ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply.all" , "ietf@ietf.org" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:36:19 -0000 Hi Joel, see inline below, thanks. Lizhong > 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern wrote =A3= =BA >=20 > If the process for this draft is to use the top address that can be reache= d in the routing table, then there is a significant probability that the ori= ginal source address, which is always at the top of the list, will be used. = As such, the intended problem will not be solved. [Lizhong] let me give an example to explain: the source address A is firstly= added to the stack, then a second routable address B for replying AS is als= o added. The reply node will not use address A since it's not routable, then= it will use address B. So it will work and I don't see the problem. >=20 > Assuming that the source domain and the replying domain are not using the s= ame private address space, while trying to craft a solution for replying to m= essages sourced by nodes in a private address domain, does not seem effectiv= e. [Lizhong] still use the example above, source address A may be skipped if th= e node is able to reach the initiator directly. The reply path will not be r= edundant. >=20 > Yes, changing the text so that you never refer to public address and alway= s talk about routable address will make the document consistent. But that do= es not seem to me to be sufficient. The design, with the search order and t= he removal of entries, is clearly aimed at using as few relays as possible. = Which is understandable. But makes the problem very hard. [Lizhong] any suggestion would be appreciated. >=20 > Yours, > Joel >=20 >> On 10/20/14, 2:35 AM, Lizhong Jin wrote: >> Hi Joel, >> Sorry for the late reply. I missed this email, and was reminded by Adrian= . >> Thank you for the review. Please see my comments inline below. >>=20 >> Regards >> Lizhong >>=20 >>> ---------------------------------------------------------------------- >>>=20 >>> Message: 1 >>> Date: Wed, 08 Oct 2014 19:20:17 -0400 >>> From: "Joel M. Halpern" >>> To: "A. Jean Mahoney" , gen-art@ietf.org, >>> "mpls@ietf.org" , Adrian Farrel >>> , >>> IETF discussion list >>> Subject: [mpls] [Gen-art] review: >>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>> Message-ID: <5435C6B1.2090908@joelhalpern.com> >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. For background on Gen= - >>> ART, please see the FAQ at >>>=20 >>> . >>>=20 >>> Please resolve these comments along with any other Last Call comments yo= u >>> may receive. >>>=20 >>> Document: draft-ietf-mpls-lsp-ping-relay-reply-04 >>> Relayed Echo Reply mechanism for LSP Ping >>> Reviewer: Joel M. Halpern >>> Review Date: 8-October-2014 >>> IETF LC End Date: 13-October-2014 >>> IESG Telechat date: (if known) >>>=20 >>> Summary: This document is not ready for publication as a Proposed Standa= rd >>>=20 >>> Major issues: >>> There is either a major technical flaw in this document, or there i= s >> a need >>> for significantly better explanation. The following is what I was able t= o >>> understand from reading the document. >>> The procedure in the document calls for a responding or relaying LS= R >> to >>> search the response addresses from the top to the bottom (top being the >>> originator of the request, bottom being visible originators). >>> The responder then sends the reply to the first usable address it can >> find in >>> the stack. Usable is variously described as "public routable" >>> and as "routable" (in sections 4.2), the converse is described as >> "unroutable" >>> in section 4.3, while section 4.4 uses "routable". >>> If it means "routable", then this assumes that the private addresses use= d >> by >>> one AS will not happen to also be used in another AS (which would make >>> them routable in that domain, directing the reply to completely the wron= g >>> place. >>> If it means "publicly routable", this would seem to fail since routers d= o >> not >>> know whether routable addresses are public, private, or simply not >> martian. >> [Lizhong] the "routable address" means that it is possible to route an IP= >> packet to this address using the normal information exchanged by the IGP >> operating in the AS. I will add the definition explicitly in the document= . >> And for section 2, change "private address" to "routable address in AS1, b= ut >> not routable in AS2". For section 4.2, change "first public routable IP >> address" to "first routable IP address". >> Hope above changing will make things clear. >>=20 >>>=20 >>> Minor issues: >>> The procedures assume that border routers will know the correct >> address >>> to put in the reply stack. It is not bovious that even if the router ha= s >> a public >>> address, it will get put on. The requirement stated here is that the >> address >>> put on be the same one used to originate the reply. Which would seem >> likely >>> to be na internal address in many cases. >> [Lizhong] If there is a public address on the node, it is also possible t= o >> add that address to the stack, which will help to relay the reply back. >> Rephrase section 4.2: >> The first address entry added by the replying LSR MUST be same as the sou= rce >> IP address of Relay Echo Reply (section 4.3) or Echo Reply message (secti= on >> 4.5) being sent. A second or more address entries could also be added if >> necessary, which depends on implementation. >>=20 >>>=20 >>> The procedure for setting k=3D0 allowing entries to be removed from= the >>> stack seems fragile. It relies on routers being able to determine that >> their >>> address will not be needed for relay by the next hop. >> [Lizhong] if k=3D0, then the Relay Node Address Stack TLV could be compre= ssed >> to reduce the relayed hop number. This is a useful feature, and top to do= wn >> searching of the routable address will ensure relaying reply back correct= ly. >>=20 >>>=20 >>> Nits/editorial comments: >>> Some of the procedure for originating a reply is described in sectio= n >> 4.2 on >>> Receiving a request, rather than in seciton 4.3 on originating the reply= . >>> (Information such as the address to put on the stack, where it goes on t= he >>> stack, and the handling of the reply packet being too large all belong i= n >> 4.3.) >> [Lizhong] we try to put all Relay Node Address Stack processing into one >> place to make it clear. Splitting the stack processing words into two >> sections may cause confusion. But we could add a sentence in section 4.3,= >> saying that the updating of Relay Node Address Stack TLV in Relayed Echo >> Reply is described in section 4.2. >>=20 >>>=20 >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Subject: Digest Footer >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> End of mpls Digest, Vol 126, Issue 10 >>> ************************************* >>=20 >>=20 From nobody Tue Oct 21 09:06:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94241A88FF; Tue, 21 Oct 2014 09:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9pVr8G4c6G5; Tue, 21 Oct 2014 09:06:42 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F045A1A8904; Tue, 21 Oct 2014 09:06:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5ADD61BC6E0B; Tue, 21 Oct 2014 09:06:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4C14C1BC6E32; Tue, 21 Oct 2014 09:06:23 -0700 (PDT) Message-ID: <5446847D.4030500@joelhalpern.com> Date: Tue, 21 Oct 2014 12:06:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "lizho.jin@gmail.com" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iqOudOawlPWQ-3KfGtKyAOVBBVU Cc: "mpls@ietf.org" , "gen-art@ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply.all" , "ietf@ietf.org" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:06:47 -0000 In line. On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: > Hi Joel, see inline below, thanks. > > Lizhong > > >> 2014.10.21£¬PM9:30£¬Joel M. Halpern wrote £º >> >> If the process for this draft is to use the top address that can be >> reached in the routing table, then there is a significant >> probability that the original source address, which is always at >> the top of the list, will be used. As such, the intended problem >> will not be solved. > [Lizhong] let me give an example to explain: the source address A is > firstly added to the stack, then a second routable address B for > replying AS is also added. The reply node will not use address A > since it's not routable, then it will use address B. So it will work > and I don't see the problem. The whole point of this relay mechanism, as I understand it, is to cope with the case when the responder X can not actually reach the source A. Now suppose that the packet arrives at X with the Address stack A, B, ... X examines the stack. The domain of A was numbered using net 10. The domain of X is numbered using net 10. A's address is probably routable in X's routing table. The problem is, that routing will not get to A. X examines the stack, determines that A is "routable", and sends the packet. This fails to meet the goal. Yours, Joel From nobody Tue Oct 21 09:27:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937C51A8963; Tue, 21 Oct 2014 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tH5jlyztcap; Tue, 21 Oct 2014 09:27:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA11A8904; Tue, 21 Oct 2014 09:27:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021162700.15156.33570.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 09:27:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hoY0h1vRj1ui7ViR2TjczWxSdrk Cc: mpls@ietf.org, gbingham@broadband-forum.org, charles.a.rexrode@verizon.com, rmersh@broadband-forum.org, christophe.alter@orange.com Subject: [mpls] =?utf-8?q?New_Liaison_Statement=2C_=22Response_to_your_lia?= =?utf-8?q?ison_entitled_=E2=80=9CIETF_draft_on_mobile_backhaul=E2=80=9C?= =?utf-8?q?=22?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:27:01 -0000 Title: Response to your liaison entitled “IETF draft on mobile backhaul“ Submission Date: 2014-10-21 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1356/ From: Broadband Forum (Christophe Alter ) To: Multiprotocol Label Switching (Loa Andersson , George Swallow , Ross Callon ) Cc: Adrian Farrel ,Alia Atlas ,mpls@ietf.org,David Sinicrope ,christophe.alter@orange.com,rmersh@broadband-forum.org,gbingham@broadband-forum.org,charles.a.rexrode@verizon.com Response Contact: Technical Contact: Purpose: In response Referenced liaison: IETF draft on mobile back haul (http://datatracker.ietf.org/liaison/1343/) Body: Dear Loa, The IP MPLS & Core WG thanks the IETF MPLS WG for your liaison on “IETF draft on mobile backhaul.†We have reviewed it and the individual draft it references, (http://tools.ietf.org/id/draft-li-mpls-seamless-mpls-mbh-00.txt), at our Q3 meeting in Dublin. The WG concluded that the draft does not seem to specify extending or enhancing protocols but appears to be more a solution architecture and requirements document. Indeed, in the introduction of the draft, we find “the proposed requirements make it possible to work out the complete solution for a flexible deployment of an end to end mobile backhaul service delivery.†The BBF has a history of working in this space; see for example TR-221, TR-178 and TR-224. While not all the issues and requirements mentioned in the draft are covered in these documents, we believe there is significant overlap. We believe the work outlined in the draft is in the scope of our work and that it would be appropriate to address it within the BBF. We note that the author’s companies are all members of BBF, we would be happy to entertain contributions from them on this topic here. We attach below a schedule of our future meetings for your information. Sincerely, Christophe Alter Broadband Forum Technical Committee Chair Attachments: Response to your liaison entitled “IETF draft on mobile backhaul“ https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broadband-forum-mpls-response-to-your-liaison-entitled-ietf-draft-on-mobile-backhaul-attachment-1.pdf From nobody Tue Oct 21 09:59:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791861A8720 for ; Tue, 21 Oct 2014 09:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWDyIb_oAcWK for ; Tue, 21 Oct 2014 09:59:33 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9201A6FD9 for ; Tue, 21 Oct 2014 09:59:33 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so1795868pab.20 for ; Tue, 21 Oct 2014 09:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VDjgCvWouJcbif6wviFJgJ6u/Wx1zqCJDdEXAxadVsQ=; b=f8kyp8Peq0Pxs59v4Cw5pQpT7rEyaS9ypxBB2vezYHc1LvKnuPJ1IqV/jgUOa+GT5+ eb6wJq1yU/YskEiEOoyO1ysbmvuOG5dTAmFHNXCNHumjlufDg/fZPQPB6mynnnsm/J5J jEB36YX6iloM1wvleF5JVQKoiK+i8mrbBYY/6ZGKdfJWRBtWfT14AaiXHv9RTsdrn7v5 Ixtnp3pvGjEL2s3nVHHVl2ndnc/mjQrTfyFtjmoOdbRKV+sjzX/rMjyit1FmenbTy9gb nhp2/GGc23e08Kyu9Ql5f8E2oZpsoOoouTdOqJVoyxIvG36fQzH3JsLIyutEWy+8rmHW 3SDw== X-Received: by 10.66.194.17 with SMTP id hs17mr36662710pac.72.1413910772862; Tue, 21 Oct 2014 09:59:32 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.102.14 with HTTP; Tue, 21 Oct 2014 09:59:02 -0700 (PDT) In-Reply-To: <544162EF.1070806@pi.nu> References: <544120D1.6000303@pi.nu> <544162EF.1070806@pi.nu> From: Sriganesh Kini Date: Tue, 21 Oct 2014 09:59:02 -0700 X-Google-Sender-Auth: cMqKl6h34xcj6QUOBMb-hsoCl1k Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7bf15e205c56e40505f1c1cc Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1Yd8arSrHTwP-aqIxUVrxaJBD_s Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:59:36 -0000 --047d7bf15e205c56e40505f1c1cc Content-Type: text/plain; charset=UTF-8 Hi Loa, I am not aware of IPR related to solutions recommended in this draft. Sri On Fri, Oct 17, 2014 at 11:41 AM, Loa Andersson wrote: > Folks, > > I have been made aware of that I have there is a mistake in this > IPR poll. > > I wrote that there is one IPR disclosed against this document, that > is not correct. There are no IPRs disclosed against the document. > > The authors that have responded that they are not aware of IPRs, will > not have to re-state this. > > /Loa > > > On 2014-10-17 15:59, Loa Andersson wrote: > >> Working Group, >> >> We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. >> >> The outcome is such that we anticipate a poll for working group adoption >> after the authors have updated the draft. >> >> Before we do poll to see if we have consensus to accept the document >> as a working group document we want to do an IPR poll on the document. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- >> label? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> Currently there are one IPR disclosures that relates to this document. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thanks, Loa >> (as MPLS WG co-chair) >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bf15e205c56e40505f1c1cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

I am not aware of IPR related t= o solutions recommended in this draft.

Sri

On Fri, Oct 17, 201= 4 at 11:41 AM, Loa Andersson <loa@pi.nu> wrote:
Folks,

I have been made aware of that I have there is a mistake in this
IPR poll.

I wrote that there is one IPR disclosed against this document, that
is not correct. There are no IPRs disclosed against the document.

The authors that have responded that they are not aware of IPRs, will
not have to re-state this.

/Loa


On 2014-10-17 15:59, Loa Andersson wrote:
Working Group,

We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-lab= el.

The outcome is such that we anticipate a poll for working group adoption after the authors have updated the draft.

Before we do poll to see if we have consensus to accept the document
as a working group document we want to do an IPR poll on the document.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-kini-mpls-spring-entr= opy-
label?

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

Currently there are one IPR disclosures that relates to this document.

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

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

Thanks, Loa
(as MPLS WG co-chair)

--


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

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7bf15e205c56e40505f1c1cc-- From nobody Tue Oct 21 14:52:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E261A87D0 for ; Tue, 21 Oct 2014 14:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ_GHNfn9vei for ; Tue, 21 Oct 2014 14:52:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE2F1A87C6 for ; Tue, 21 Oct 2014 14:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8386; q=dns/txt; s=iport; t=1413928368; x=1415137968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yMsOhRppd1/3324oU0yW2xKiZxMxnEGe+NDB8SsUvUo=; b=YIWrO0dkUtCLGVpnsf6JBanczW4L72VQLFEe6LFq+4DnovDKSiZmZQag Qbn2rUILgBVXNcAMHYnjHDKnXRXpiQ33RWkW/8tLlufRdq+LyLsxsO2G/ DGn3ptLhAzvtidudaAvGlu3OwN3n5HE0/Q2VEfbrqTtusNjifsKVAefLl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAEzVRlStJV2Q/2dsb2JhbABcgmsjU1gEzHIKh00CgRYWAX2EAgEBAQMBAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAYguCAEMxmcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXilaFUDEHBoMngR4Fj2WCHIRGiEM8gwyRLYN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,764,1406592000"; d="scan'208";a="365458972" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 21 Oct 2014 21:52:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9LLqkj8026343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 21:52:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:52:46 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0IawwgEFPqICAArRj8IACsOyAgACHbwA= Date: Tue, 21 Oct 2014 21:52:46 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RyB2uUeBMvLDQT1zd7wcqYBVSGI Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:52:51 -0000 Hi Mach, > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Tuesday, October 21, 2014 4:43 AM > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); draft-ietf-mpls-lsp-ping-reply-mod= e- > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > ping@tools.ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e- > 00.txt >=20 > Hi Nobo and Mustapha, >=20 > I think this may not just require minor changes to RFC7110, it at least > requires: >=20 > 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and >=20 > 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with B bi= t > set) to notify along reverse direction of the tested LSP; >=20 > Given there may be existing implementations and the original proposal > (defined in RFC7110) works and does not require too much process cost, I > incline to leave it as is and suggest not to define the new dedicated rep= ly > mode as well. For backwards compatibility sake, we should preserve (2). Thus only change = required is (1) which is a fairly small change. With this direction, what d= o you think? Thanks! -Nobo >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > (nobo) > > Sent: Monday, October 20, 2014 4:48 AM > > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net); > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > Subject: Re: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > MPLS WG, > > > > Many thanks for kicking this off Mustapha. > > > > I, for one, like Mustaphas suggestion and would be supportive of > > making that change. I would also be happy to change > > draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect this > > change, if there are consensus to do so. > > > > I have cc'ed the authors of RFC7110 in case they can also chime in with > thoughts. > > > > Additionally, suggested changes should be very minimal even to those > > who has already implemented RC7110. However, if anybody has > > implemented and if anybody has concerns, I think this is a great time f= or to > speak up. > > > > Thanks! > > > > -Nobo > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > > > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Friday, October 17, 2014 6:19 PM > > > To: Nobo Akiya (nobo); mpls@ietf.org > > > Cc: Ross Callon (rcallon@juniper.net) > > > Subject: RE: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > 00.txt > > > > > > Dear all, > > > This is a follow-up to the action below from the MPLS-RT review of th= is > draft. > > > > > > Instead of defining a new reply mode as proposed in Section 3.1 of > > > the draft, I suggested to relax the rule in RFC 7110 such that if > > > the echo request includes reply mode 5 "Reply via Specified Path" > > > and the Reply Path TLV was not included, the responder node will > > > interpret this as an implicit request to reply via the reverse direct= ion of > the tested LSP. > > > > > > This approach would address the requirement that the sender be able > > > of requesting the reply via the reverse path of an LSP without > > > having to include an additional TLV. > > > > > > I appreciate comments on this proposal. > > > > > > Regards, > > > Mustapha. > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > > > (nobo) > > > > Sent: Saturday, September 06, 2014 9:59 AM > > > > To: mpls@ietf.org > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > Subject: Re: [mpls] I-D Action: > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > Thank you Ross and the WG. > > > > > > > > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as > > > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > > > > > Authors would like the WG help to discuss and close off on these > > > > two > > > aspects: > > > > > > > > - From Bruno Decraene: Reply Mode for SPRING and applicability of > > > this > > > > document. > > > > o There's already a thread for this. > > > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by > > > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > > > o Mustapha or myself will start a thread on this topic later. > > > > > > > > Once above are close off, then we will roll out -01 that includes: > > > > > > > > - Conclusion from the two aspects above. > > > > - A comment received from Tarek Saad. > > > > - Comments received from Lou Berger (will reply to the review > > > comments > > > > from Lou soon) > > > > > > > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > > > reply-mode- > > > > simple-00.txt > > > > Status: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > > mode- > > > > simple/ > > > > Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping= -reply- > > > mode-simple-00 > > > > > > > > Thanks! > > > > > > > > -Nobo, on behalf of authors > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > > > drafts@ietf.org > > > > > Sent: Saturday, September 06, 2014 3:41 AM > > > > > To: i-d-announce@ietf.org > > > > > Cc: mpls@ietf.org > > > > > Subject: [mpls] I-D Action: > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > 00.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the Multiprotocol Label Switching > > > > > Working Group of the IETF. > > > > > > > > > > Title : Label Switched Path (LSP) Ping/Tracerou= te > > Reply Mode > > > > > Simplification > > > > > Authors : Nobo Akiya > > > > > George Swallow > > > > > Carlos Pignataro > > > > > Loa Andersson > > > > > Mach(Guoyi) Chen > > > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.= txt > > > > > Pages : 11 > > > > > Date : 2014-09-05 > > > > > > > > > > Abstract: > > > > > The Multiprotocol Label Switching (MPLS) Label Switched Path (= LSP) > > > > > Ping and Traceroute use the Reply Mode field to signal the met= hod > to > > > > > be used in the MPLS echo reply. This document adds one value = to > the > > > > > Reply Mode field to indicate reverse LSP. This document also = adds > an > > > > > optional TLV which can carry ordered list of Reply Mode values= . > > > > > > > > > > This document updates RFC4379. > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > > > > mo > > > > > de > > > > > - > > > > > simple/ > > > > > > > > > > There's also a htmlized version available at: > > > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-s > > > > > im > > > > > pl > > > > > e- > > > > > 00 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time > > > > > of submission until the htmlized version and diff are available > > > > > at > > > tools.ietf.org. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 21 17:23:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF311A8855 for ; Tue, 21 Oct 2014 17:23:43 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id holpY8fMeH0x for ; Tue, 21 Oct 2014 17:23:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4461A886C for ; Tue, 21 Oct 2014 17:23:39 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-db-54469efe6d1a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6D.16.25146.EFE96445; Tue, 21 Oct 2014 19:59:26 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 20:23:32 -0400 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Thread-Index: AQHP6hKiTAr6z4H7xkW4uUlBAMXhkZw04vCAgAYzZ4A= Date: Wed, 22 Oct 2014 00:23:31 +0000 Message-ID: References: <544120D1.6000303@pi.nu> <544162EF.1070806@pi.nu> In-Reply-To: <544162EF.1070806@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPlO6/eW4hBje26Fi0fJ3AaPFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr4/TZiYwFbWIV V2bNZm5gfC7YxcjJISFgIvF97hp2CFtM4sK99WxdjFwcQgJHGSX+Lr7KAuEsZ5S4vWEKWBWb gIHE/2/HWUBsEQE7iY2v/jGCFDELrGOUuLRlDVCCg0NYwEXi9F1biBpXiaNrnzNB2FYSK36B bODkYBFQleg4/RlsJq+AucS7Db1gM4UEbCU+vD/NDGJzAtVc/XQWzGYEuu77qTVgc5gFxCVu PZnPBHG1gMSSPeeZIWxRiZeP/7GC2KICehLPNmyG+kxRYl//dHaIXj2JG1OnsEHY1hK3Fs9i gbC1JZYtfM0McY+gxMmZT1gmMErMQrJuFpL2WUjaZyFpn4WkfQEj6ypGjtLi1LLcdCPDTYzA aDwmwea4g3HBJ8tDjAIcjEo8vAt8XUOEWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cDYtvGgWF1i0vc1sw8d9va5lbXkYu/x24m7tO+51LMIvts9wXnH9NdL U4SLPZfuetEi8mfjzzXrz55ZNKnOm+2tw16vjHkL48IbeN5a9W+WnDPz9VuWrMI1s94qOlzQ f96s2sAVnpB4Y9+h5179qd1O7PPMJULmXnjcoimafcb86Xy1cMbsuXs4lFiKMxINtZiLihMB ZkS5UacCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Uiq0Pc7YOY3ZjVyAyVRcQA3hOOo Cc: "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:23:43 -0000 Hi Loa, I=B9m not aware of any IPR. Thanks! Cheers, Jeff -----Original Message----- From: Loa Andersson Date: Friday, October 17, 2014 at 11:41 AM To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-kini-mpls-spring-entropy-label Resent-To: Jeff Tantsura , "kireeti@juniper.net" , , , , , Wim Henderickx , , , Loa Andersson , , Martin Vigoureux >Folks, > >I have been made aware of that I have there is a mistake in this >IPR poll. > >I wrote that there is one IPR disclosed against this document, that >is not correct. There are no IPRs disclosed against the document. > >The authors that have responded that they are not aware of IPRs, will >not have to re-state this. > >/Loa > >On 2014-10-17 15:59, Loa Andersson wrote: >> Working Group, >> >> We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label. >> >> The outcome is such that we anticipate a poll for working group adoption >> after the authors have updated the draft. >> >> Before we do poll to see if we have consensus to accept the document >> as a working group document we want to do an IPR poll on the document. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy- >> label? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> Currently there are one IPR disclosures that relates to this document. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thanks, Loa >> (as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 21 17:52:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516A1A88C7 for ; Tue, 21 Oct 2014 17:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CWmRPO2MHO4 for ; Tue, 21 Oct 2014 17:52:53 -0700 (PDT) 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 8F5E51A88D6 for ; Tue, 21 Oct 2014 17:52:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU42290; Wed, 22 Oct 2014 00:52:51 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 01:52:50 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 08:52:45 +0800 From: Mach Chen To: "stbryant@cisco.com" , "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwyRaSAgABupQCAAbAhgIAAExGAgARPWrD//6yZAIABnw0Q///R3YCAAJCAsP//k+CAACz7efA= Date: Wed, 22 Oct 2014 00:52:45 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <5446419F.7020005@cisco.com> In-Reply-To: <5446419F.7020005@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZWo3CBc8f6eUfX8rJSkEJ8D7nSg Cc: Ross Callon , "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:52:56 -0000 Hi Stewart, OK, if this is the logic, then SL/SLI tells the LSR dispatch the packet to = PM engine for accounting then keep processing. Best regards, Mach > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, October 21, 2014 7:21 PM > To: Mach Chen; Carlos Pignataro (cpignata) > Cc: Eric Rosen; Ross Callon; draft-chen-mpls-source-label@tools.ietf.org; > mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > GAL tells an LSR what to do with the pkt - it says please dispatch to th= e OAM > handler. >=20 > - Stewart >=20 > On 21/10/2014 10:54, Mach Chen wrote: > > Hi Carlos, > > > > Thanks for sharing your point! > > > >> The EL is used for forwarding/dispatch decisions. The SL is metadata, > >> not used for forwarding. The fundamental change to the dataplane is > >> using it to carry metadata. > > If the criteria is whether a label is used for forwarding, how about GA= L? > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > >> Sent: Tuesday, October 21, 2014 5:11 PM > >> To: Mach Chen > >> Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon; > >> draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >> mpls-chairs@tools.ietf.org > >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >> > >> Hi Mach, > >> > >> Please find one set of comments inline. > >> > >> Thumb typed by Carlos Pignataro. > >> Excuze typofraphicak errows > >> > >>> On Oct 21, 2014, at 3:19 AM, Mach Chen wrote: > >>> > >>> Hi Stewart, > >>> > >>> Please see my replies inline... > >>> > >>>> -----Original Message----- > >>>> From: Stewart Bryant [mailto:stbryant@cisco.com] > >>>> Sent: Monday, October 20, 2014 7:10 PM > >>>> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon > >>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >>>> mpls-chairs@tools.ietf.org > >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >>>> > >>>> Mach > >>>> > >>>>> On 20/10/2014 11:04, Mach Chen wrote: > >>>>> Hi Eric , Carlos, Stewart and others, > >>>>> > >>>>> Thanks for the discussion! Sorry for the top post. > >>>>> > >>>>> I do think that you're really exaggerating the complexity and > >>>>> negatives. Given > >>>> an LSR can support EL, Segment Routing, MVPN, context label, etc, > >>>> IMHO it's not difficult for such kind of routers to support SL. > >>>> Those solutions are not the same. > >>>> > >>>> ELs - have no impact on the receiver. I admit that they have an > >>>> impact on the transmitter (but only two labels) but the only flow > >>>> state is that an EL needs to be generated, you do not need > >>>> additional transmitter context since this is generated from the pack= et itself. > >>>> > >>>> SR - has no impact at ay node other than the transmitter, and in > >>>> many cases the impact is one or two labels. It does not change the > dataplane.. > >>>> > >>>> Context labels - I am not sure how wide the support for the > >>>> general context label use case is. > >>>> > >>>> What you are proposing is a far more fundamental change to the > >>>> dataplane than any of the above. > >>> I may have different view on this, let me make a little bit > >>> comparison between > >> SL and EL: > >> The EL is used for forwarding/dispatch decisions. The SL is metadata, > >> not used for forwarding. The fundamental change to the dataplane is > >> using it to carry metadata. > >> > >>> 1) For ingress LSR, it's almost the same, except that EL requires > >>> the ingress LSR to generate the Entropy, then both just put > >>> information into the label stack; > >>> > >>> 2) For transit LSR, EL requires the LSR to know how to handle the > >>> ELI and EL, otherwise cannot benefit from the EL; SL does not bring > >>> any requirement to transit LSR; > >>> > >>> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, > >>> when do SL based PM, the egress LSR has to use the SL for > >>> accounting, but such accounting is basic and necessary work for PM; > >>> > >> Extrapolating from your argument, we could add a number of labels to > >> the stack that do not carry forwarding instructions without any concer= ns. SL, > what's next? > >> > >>> Based above, from the dataplane point of view, the processing and > >>> complexity is as the same level of EL, and it DOES NOT bring > >>> "fundamental" change to the dataplane; > >>> > >> The change, in my view, is in the semantics of the label. > >> > >> Given how fundamental this is (in my mind) it calls for a more > >> comprehensive understanding of the problem being solved. > >> > >> Thanks, > >> > >> Carlos. > >> > >>>>> I looked though the whole discussions so far, and I am not going > >>>>> to reply each > >>>> email one by email, I summarized the topics as follows: > >>>>> 1) Requirement > >>>>> Whether the requirement is compelling depends on whether you need > >>>>> it. We > >>>> did receive the requirements from SPs to support passive PM for > >>>> MP2P based LSPs, especially for the case of MPLS based IP backhaul > >>>> network. So for those SPs, it's a compelling requirement. Indeed, > >>>> PM is not an easy work, and in IETF, several dedicated WGs work on > >>>> PM related stuff, some WGs have worked on it over decade. > >>>> I am not disputing the requirement for a method of measuring loss > >>>> of customer traffic. > >>>> > >>>> However the requirement for domain wide source labels is not > >>>> established. It is one method of identifying the source in a PM > >>>> measurement, but it is not the only method. > >>> Actually, the latest version DOES NOT require domain wide source > >>> labels, the > >> source label is just a carrier that is used to carry the domain wide > >> unique Source Identifier (SI); the SI is transparent to the SL, from > >> the convey information point of view, it's the same as EL. > >>>>> This draft is mainly about how to do source identification that is > >>>>> one of the critical requirements of the passive PM, > >>>> It is about one method. The method you propose is not the only metho= d. > >>>> > >>>> Also you have jumped directly to a S-D identification approach, > >>>> without justifying this as being the required unit of identification= . > >>> Other than S-D identification, I am not sure that there are other > >>> ways that could > >> be used to perform passive PM. I noticed you mention destination > >> based approach in another email, can you please elaborate how it works= ? > >>>>> it is not intended to cover all aspects of PM. This is clearly > >>>>> stated in the > >>>> document. Other aspects, for example, the multiple line cards in > >>>> the egress as Stewart pointed out, I do really think that is an > >>>> implementation issue. For that case, you do need a centralized > >>>> component to sum up and analyze the statistics and their correlation= s. > >>>> It is not that simple as you know from your other draft, and it > >>>> does not make sense to me to address the two requirements as ships > >>>> in the night > >> solutions. > >>>> Given that you receive a packet on one line card, you have no idea > >>>> whether a packet received on another line card (or even line > >>>> interface on that card) was transmitted before of after the one you > >>>> are taking as your accounting reference point. > >>> We have a prototype doing IP based passive PM and do consider such > >>> scenario > >> and it works. In this case, you do need a centralized component > >> (which could reside in a linecard, the main control card or an > >> external entity (e.g., NMS)) that can collect all statistic informatio= n of the > tested flow. > >>>>> 2) Label stack depth > >>>>> Regarding the label stack depth, there were some related > >>>>> discussions (including > >>>> this WG and other WGs) , some vendors have showed that is not a big > >>>> problem, especially for those new generation modern routers/switches= . > >>>> That is an assumption that you need to justify, particular at the ne= twork > edge. > >>> We will see such devices come out, especially when Segment Routing > >> progressing. > >>>>> 3) Granularity > >>>>> It depends on how you use it. In theory, the solution can support > >>>>> any number > >>>> flows. But there always be some tradeoff, as I replied in a > >>>> precious email, the SI number itself is not the issue, the HW > >>>> resource (e.g., the timers) is the critical constraint. That means, > >>>> you cannot expect a router to > >> support unlimited flows. > >>>> For SI number, I guess that the main concern is mainly about the > >>>> state maintenance and advertisement, actually it could be optimized > >>>> to maintain and advertize a single SI block for each LSR. This way, > >>>> the state and advertisement is a fixed number corresponding to the > >>>> number > >> of the LSR in the domain. > >>>> The timers can be in s/w in the supervisor, since the time that a > >>>> measurement is taken is not critical, so whilst there might be a > >>>> filter and counter issue in the h/w, though no worse than IPFIX, > >>>> there is not > >> h/w issue with timers. > >>> It depends on how you implement the measurement, timer for > >>> measurement > >> is important, it sometime determines the accurate of the measurement. > >> And I also agree that filter and counter are the other critical > >> issues. And all these belong to the HW resource. So, I am trying to > >> say, when consider these HW constraints, the SI state should be not a > >> bit deal. Because you cannot monitor unlimited flows on a device. > >>> Best regards, > >>> Mach > >>> > >>>> Stewart > >>>>> Best regards, > >>>>> Mach > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen > >>>>>> Sent: Saturday, October 18, 2014 6:20 AM > >>>>>> To: Carlos Pignataro (cpignata); Ross Callon > >>>>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > >>>>>> mpls-chairs@tools.ietf.org > >>>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label > >>>>>> > >>>>>> Carlos> Basically, two or three labels are added to the label > >>>>>> Carlos> stack, > >>>>>> > >>>>>> Actually, that's two or three labels per LSP. A packet may be > >>>>>> going through a nested set of LSPs, which each label in the stack > >>>>>> representing one > >>>> of those LSPs. > >>>>>> Each LSP may have its own source label. Since a source label is > >>>>>> likely to require three label stack entries, the number of labels > >>>>>> in the stack > >>>> could be quadrupled. > >>>>>> And for what? > >>>>>> > >>>>>> Carlos> the document only lists PM as the application that needs > >>>>>> Carlos> source > >>>> labels. > >>>>>> There doesn't seem to be general agreement that this is a > >>>>>> compelling use > >>>> case. > >>>>>> Certainly not compelling enough to justify the complexity and the > >>>>>> overhead that it brings. > >>>>>> > >>>>>> Carlos> What happens if a finer granularity than the source node > >>>>>> Carlos> is > >> needed? > >>>>>> This is inevitable. How long before folks are complaining "we > >>>>>> can't run our network unless the egress LSR can determine the > >>>>>> ingress interface for each packet". This could lead to thousands > >>>>>> of source label > >>>> values for each ingress LSR. > >>>>>> And what will happen when someone decides that the granularity > >>>>>> needs to be per-subscriber, not merely per-interface? > >>>>>> > >>>>>> And it's not just "finer granularity" we have to worry about. > >>>>>> What if someone decides that an ingress LSR needs to convey an > >>>>>> arbitrary amount > >>>> of "meta-data" > >>>>>> about an LSP to the egress LSR. Will the label stack become a > >>>>>> set of labels alternating with meta-data containers? > >>>>>> > >>>>>> Do we really want to put stuff that doesn't affect the packet > >>>>>> forwarding into the label stack? Where will we draw the line? > >>>>>> > >>>>>> I don't think the authors really intend the mechanism to be > >>>>>> generalized in this manner. They're probably thinking "But we > >>>>>> only intend for this to be deployed in a very simple case, where > >>>>>> packets are being tunneled, where the ingress LSR knows who the > >>>>>> egress LSR is, where they're in the same administrative domain, et= c. etc. > >>>>>> You're really exaggerating the negatives." But the proposed > >>>>>> mechanisms do lend themselves to abuse or this sort. Once we > >>>>>> start putting stuff in the label stack that isn't used for > >>>>>> forwarding, how will we know > >>>> when to stop? > >>>>>> Carlos> Given this dramatic set of extensions and strong > >>>>>> Carlos> requirements, it seems > >>>>>> prudent to me to better understand the problem space of PM gaps > >>>>>> before adopting a solution. > >>>>>> > >>>>>> I agree. I think Stewart has made a good case that further > >>>>>> analysis is > >>>> needed. > >>>>>> The problem isn't that there is no use for source labels, the > >>>>>> problem is that the mechanism seems to bring a lot of problems > >>>>>> with it. Is this really the only solution? And if so, is it so > >>>>>> important to be able to do PM that we should be willing to take > >>>>>> on all these > >> problems? > >>>>>> I also think the proposed LDP and BGP extensions are problematic, > >>>>>> but those issues are really of secondary importance right now. > >>>>>> > >>>>>> So I don't support the adoption of this draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> . > >>>> > >>>> -- > >>>> For corporate legal information go to: > >>>> > >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > . > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Oct 21 18:19:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9591A88D8 for ; Tue, 21 Oct 2014 18:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI0y5F0GZ93f for ; Tue, 21 Oct 2014 18:19:15 -0700 (PDT) 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 935321A88FA for ; Tue, 21 Oct 2014 18:19:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU43520; Wed, 22 Oct 2014 01:19:09 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 02:19:08 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 09:19:04 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX4OkhgWsQGIUeAKGjjOVb0U5v0ZR+AgDvz/2CAB0l4AIAC2yvwgABbiQCAAL9W0A== Date: Wed, 22 Oct 2014 01:19:03 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Em78KljgvpP1BMwlXIbZZ5rZsck Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 01:19:18 -0000 Hi Nobo, I am fine with this change. Best regards, Mach > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 22, 2014 5:53 AM > To: Mach Chen; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e-00.txt >=20 > Hi Mach, >=20 > > -----Original Message----- > > From: Mach Chen [mailto:mach.chen@huawei.com] > > Sent: Tuesday, October 21, 2014 4:43 AM > > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net); > > draft-ietf-mpls-lsp-ping-reply-mode- > > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > > ping@tools.ietf.org > > Subject: RE: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > 00.txt > > > > Hi Nobo and Mustapha, > > > > I think this may not just require minor changes to RFC7110, it at > > least > > requires: > > > > 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and > > > > 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with B > > bit > > set) to notify along reverse direction of the tested LSP; > > > > Given there may be existing implementations and the original proposal > > (defined in RFC7110) works and does not require too much process cost, > > I incline to leave it as is and suggest not to define the new > > dedicated reply mode as well. >=20 > For backwards compatibility sake, we should preserve (2). Thus only chang= e > required is (1) which is a fairly small change. With this direction, what= do you > think? >=20 > Thanks! >=20 > -Nobo >=20 > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > > (nobo) > > > Sent: Monday, October 20, 2014 4:48 AM > > > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Cc: Ross Callon (rcallon@juniper.net); > > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > > Subject: Re: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > MPLS WG, > > > > > > Many thanks for kicking this off Mustapha. > > > > > > I, for one, like Mustaphas suggestion and would be supportive of > > > making that change. I would also be happy to change > > > draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect this > > > change, if there are consensus to do so. > > > > > > I have cc'ed the authors of RFC7110 in case they can also chime in > > > with > > thoughts. > > > > > > Additionally, suggested changes should be very minimal even to those > > > who has already implemented RC7110. However, if anybody has > > > implemented and if anybody has concerns, I think this is a great > > > time for to > > speak up. > > > > > > Thanks! > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: Aissaoui, Mustapha (Mustapha) > > > > [mailto:mustapha.aissaoui@alcatel- > > > > lucent.com] > > > > Sent: Friday, October 17, 2014 6:19 PM > > > > To: Nobo Akiya (nobo); mpls@ietf.org > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > Subject: RE: [mpls] I-D Action: > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > 00.txt > > > > > > > > Dear all, > > > > This is a follow-up to the action below from the MPLS-RT review of > > > > this > > draft. > > > > > > > > Instead of defining a new reply mode as proposed in Section 3.1 of > > > > the draft, I suggested to relax the rule in RFC 7110 such that if > > > > the echo request includes reply mode 5 "Reply via Specified Path" > > > > and the Reply Path TLV was not included, the responder node will > > > > interpret this as an implicit request to reply via the reverse > > > > direction of > > the tested LSP. > > > > > > > > This approach would address the requirement that the sender be > > > > able of requesting the reply via the reverse path of an LSP > > > > without having to include an additional TLV. > > > > > > > > I appreciate comments on this proposal. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo > > > > > Akiya > > > > > (nobo) > > > > > Sent: Saturday, September 06, 2014 9:59 AM > > > > > To: mpls@ietf.org > > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > > Subject: Re: [mpls] I-D Action: > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > > > Thank you Ross and the WG. > > > > > > > > > > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as > > > > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > > > > > > > Authors would like the WG help to discuss and close off on these > > > > > two > > > > aspects: > > > > > > > > > > - From Bruno Decraene: Reply Mode for SPRING and applicability of > > > > this > > > > > document. > > > > > o There's already a thread for this. > > > > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by > > > > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > > > > o Mustapha or myself will start a thread on this topic later. > > > > > > > > > > Once above are close off, then we will roll out -01 that includes= : > > > > > > > > > > - Conclusion from the two aspects above. > > > > > - A comment received from Tarek Saad. > > > > > - Comments received from Lou Berger (will reply to the review > > > > comments > > > > > from Lou soon) > > > > > > > > > > URL: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > > > > reply-mode- > > > > > simple-00.txt > > > > > Status: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > > > mode- > > > > > simple/ > > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- > > > > mode-simple-00 > > > > > > > > > > Thanks! > > > > > > > > > > -Nobo, on behalf of authors > > > > > > > > > > > -----Original Message----- > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > > > > > internet- drafts@ietf.org > > > > > > Sent: Saturday, September 06, 2014 3:41 AM > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: mpls@ietf.org > > > > > > Subject: [mpls] I-D Action: > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > > 00.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the Multiprotocol Label > > > > > > Switching Working Group of the IETF. > > > > > > > > > > > > Title : Label Switched Path (LSP) Ping/Tracer= oute > > > Reply Mode > > > > > > Simplification > > > > > > Authors : Nobo Akiya > > > > > > George Swallow > > > > > > Carlos Pignataro > > > > > > Loa Andersson > > > > > > Mach(Guoyi) Chen > > > > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-0= 0.txt > > > > > > Pages : 11 > > > > > > Date : 2014-09-05 > > > > > > > > > > > > Abstract: > > > > > > The Multiprotocol Label Switching (MPLS) Label Switched Path= (LSP) > > > > > > Ping and Traceroute use the Reply Mode field to signal the > > > > > > method > > to > > > > > > be used in the MPLS echo reply. This document adds one > > > > > > value to > > the > > > > > > Reply Mode field to indicate reverse LSP. This document > > > > > > also adds > > an > > > > > > optional TLV which can carry ordered list of Reply Mode valu= es. > > > > > > > > > > > > This document updates RFC4379. > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-repl > > > > > > y- > > > > > > mo > > > > > > de > > > > > > - > > > > > > simple/ > > > > > > > > > > > > There's also a htmlized version available at: > > > > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode > > > > > > -s > > > > > > im > > > > > > pl > > > > > > e- > > > > > > 00 > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time > > > > > > of submission until the htmlized version and diff are > > > > > > available at > > > > tools.ietf.org. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > _______________________________________________ > > > > > > mpls mailing list > > > > > > mpls@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 21 19:06:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6D1A89C6; Tue, 21 Oct 2014 19:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1ieOySwnhxO; Tue, 21 Oct 2014 19:06:30 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE86B1A89B5; Tue, 21 Oct 2014 19:06:30 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so2491072pdj.41 for ; Tue, 21 Oct 2014 19:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=r8SnPRiYhs5obEzgCzQpEsfTyvvzDKAunnj7BbC8HyU=; b=Kfqo0Rhu8CxwKxSxU3q0nA3s4Dwa55mQ0j4lOC6eobcaMmH87vuSqBGfgM8QWOmqYP Xb+Uv3YyfM6PJ+Au1TplXp+nU92meUlK+pTilrwEL2/1YVixNA/CXLTqSRQLZ+sFxcz7 08bOTz4g7zxC8UP9Dsp6jmSu3Lj+XEjr1/lbalaL6HlHkDl/uQuFD1Ta6biOVScs9ZHy GS6U6gI5zII2oxEk/m2EI562ZI5US2UyIDDc5c5dTe4zI2f4Y/ZcJk+tGD4yOFzfP4BB uLe01kYtcgsVXRXJMtjibuX4AeSTAGQZjKIp2pZeMHvCy81I0TckAWFfODYPaZgAdEqo GNpQ== X-Received: by 10.67.24.7 with SMTP id ie7mr9457597pad.94.1413943590372; Tue, 21 Oct 2014 19:06:30 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id hp4sm12895186pbb.95.2014.10.21.19.06.26 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 19:06:29 -0700 (PDT) From: "Lizhong Jin" To: "'Joel M. Halpern'" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> In-Reply-To: <5446847D.4030500@joelhalpern.com> Date: Wed, 22 Oct 2014 10:06:15 +0800 Message-ID: <00ff01cfed9c$caf88740$60e995c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoLsexpoDjeNgEXN4xVax6BLciqgI4g/XAAhLnkzMCHjdnV5tXiyLA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/M2SQ1uXtdw5D7c50PeT8MmLSvO4 Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:06:32 -0000 Inline, thanks. > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 2014=C4=EA10=D4=C222=C8=D5 0:06 > To: lizho.jin@gmail.com > Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; draft-ietf-mpls-lsp-ping- > relay-reply.all > Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 >=20 > In line. >=20 > On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: > > Hi Joel, see inline below, thanks. > > > > Lizhong > > > > > >> 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern = wrote =A3=BA > >> > >> If the process for this draft is to use the top address that can be > >> reached in the routing table, then there is a significant = probability > >> that the original source address, which is always at the top of the > >> list, will be used. As such, the intended problem will not be > >> solved. > > [Lizhong] let me give an example to explain: the source address A is > > firstly added to the stack, then a second routable address B for > > replying AS is also added. The reply node will not use address A = since > > it's not routable, then it will use address B. So it will work and I > > don't see the problem. >=20 > The whole point of this relay mechanism, as I understand it, is to = cope with > the case when the responder X can not actually reach the source A. > Now suppose that the packet arrives at X with the Address stack A, B, = ... X > examines the stack. The domain of A was numbered using net 10. > The domain of X is numbered using net 10. A's address is probably routable > in X's routing table. The problem is, that routing will not get to A. = X examines > the stack, determines that A is "routable", and sends the packet. = This fails to > meet the goal. [Lizhong] The source A you are referring is the initiator, right? The = goal of relay mechanism is to reach the initiator. If X is routable to the initiator (address A), then it is great, other relay node in the stack = will be skipped. If the source A you are referring is the interface address of one intermediate node, then I do not understand "routing will not get to A. = X examines the stack, determines that A is "routable", and sends the = packet". Why routing will not get to A, but A is routable? Regards Lizhong >=20 > Yours, > Joel From nobody Tue Oct 21 19:15:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3DA1A8A1A; Tue, 21 Oct 2014 19:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr9hvZpWgZ4R; Tue, 21 Oct 2014 19:14:59 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD5D1A8A0F; Tue, 21 Oct 2014 19:14:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EA6301BC875A; Tue, 21 Oct 2014 19:14:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8CB9F1BC8767; Tue, 21 Oct 2014 19:14:56 -0700 (PDT) Message-ID: <5447131F.5040709@joelhalpern.com> Date: Tue, 21 Oct 2014 22:14:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lizhong Jin References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> In-Reply-To: <00ff01cfed9c$caf88740$60e995c0$@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/__MmNWerfv4IfVG1ujexqgvMPGI Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:15:01 -0000 The problem is that the original source A, that we are trying to reach with a reply, has an address that appears to the responder X to be routable. But the destination that is reached by that address is either a black hole or some other entity using the same address. The reason for the duplication is that, as described in the draft, the source address for A is a private address. That same address may well be reachable according to the routing table at X. But it won't get to A. If the problem is something other than private addressing preventing reachability, it is likely there is still a mistaken routability problem, but I can not illustrate the failure without some other case being described. Yours, Joel On 10/21/14, 10:06 PM, Lizhong Jin wrote: > Inline, thanks. > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 2014Äê10ÔÂ22ÈÕ 0:06 >> To: lizho.jin@gmail.com >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > draft-ietf-mpls-lsp-ping- >> relay-reply.all >> Subject: Re: [mpls] [Gen-art] review: > draft-ietf-mpls-lsp-ping-relay-reply-04 >> >> In line. >> >> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: >>> Hi Joel, see inline below, thanks. >>> >>> Lizhong >>> >>> >>>> 2014.10.21£¬PM9:30£¬Joel M. Halpern wrote £º >>>> >>>> If the process for this draft is to use the top address that can be >>>> reached in the routing table, then there is a significant probability >>>> that the original source address, which is always at the top of the >>>> list, will be used. As such, the intended problem will not be >>>> solved. >>> [Lizhong] let me give an example to explain: the source address A is >>> firstly added to the stack, then a second routable address B for >>> replying AS is also added. The reply node will not use address A since >>> it's not routable, then it will use address B. So it will work and I >>> don't see the problem. >> >> The whole point of this relay mechanism, as I understand it, is to cope > with >> the case when the responder X can not actually reach the source A. >> Now suppose that the packet arrives at X with the Address stack A, B, ... > X >> examines the stack. The domain of A was numbered using net 10. >> The domain of X is numbered using net 10. A's address is probably > routable >> in X's routing table. The problem is, that routing will not get to A. X > examines >> the stack, determines that A is "routable", and sends the packet. This > fails to >> meet the goal. > [Lizhong] The source A you are referring is the initiator, right? The goal > of relay mechanism is to reach the initiator. If X is routable to the > initiator (address A), then it is great, other relay node in the stack will > be skipped. > If the source A you are referring is the interface address of one > intermediate node, then I do not understand "routing will not get to A. X > examines the stack, determines that A is "routable", and sends the packet". > Why routing will not get to A, but A is routable? > > Regards > Lizhong > > >> >> Yours, >> Joel > > > From nobody Tue Oct 21 19:39:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A561A8A3E for ; Tue, 21 Oct 2014 19:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWP_HhrbSb_V for ; Tue, 21 Oct 2014 19:39:00 -0700 (PDT) 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 9FF811A8A4A for ; Tue, 21 Oct 2014 19:38:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU47636; Wed, 22 Oct 2014 02:38:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 03:38:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 10:38:46 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+eqYlo34/Uuk+WldaSxF4jM5wylSgAgAGwIYCAABMQgIAD6XaAgAASfgCAAVGtAIAAHzyAgAGoUBA= Date: Wed, 22 Oct 2014 02:38:46 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> In-Reply-To: <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UNGnhD9Tgkb5sUGMol93sIf6cWI Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:39:01 -0000 Hi Carlos, > The EL is used for forwarding/dispatch decisions. The SL is metadata, not= used > for forwarding. The fundamental change to the dataplane is using it to ca= rry > metadata. In fact, one of other use cases of the SL is to make the MP2P LDP available= for multicast VPN in the ingress replication mode (For more details, see 6= .4.5. Ingress Replication of RFC6513). In this use case, the SL is now used= for forwarding decisions. We could add this use case in the next revision. Best regards, Xiaohu From nobody Tue Oct 21 19:51:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223CE1A8A72; Tue, 21 Oct 2014 19:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp-qKX5q0gWo; Tue, 21 Oct 2014 19:51:18 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7314A1A8A71; Tue, 21 Oct 2014 19:51:18 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id fp1so2576963pdb.35 for ; Tue, 21 Oct 2014 19:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=D3qRjmwuZabTKrwfAYn0Jj5oqRzDwBrB9Gl+5ZBhlzI=; b=JS1bNWi7NclpP3RSGCl5jPBEwaxf+SYM3FcwCiwa4xrUCU+2UVBAXLIFoz/RYivXDn 79L1EzB3oGs4K3M/7AHfqVAah9AC8wmZuHYQSsrGJLYblMDGh78AZwrWkCO4DiQBAwBh ZR5u3Mw/ZclSn5vM10DbGfOgql0eGLylMvyMvtPFenTOxlbg8uMSJEybpS2V3Tdm8S9x k8imUHMsovSn9eKe0TvTzC9CRSNcEh2SVzkuu2VhgFCoJS1a919aYMX7hGtDkPU5RD9B 6cLuT+crRYTt2B5On4UbgINIPf46Rl6XRdJHKbHGyTWWapGZqN6jsKpROPb8C+o9HXoP sqCQ== X-Received: by 10.66.142.230 with SMTP id rz6mr14446134pab.129.1413946278081; Tue, 21 Oct 2014 19:51:18 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id pw8sm12972912pbb.70.2014.10.21.19.51.14 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 19:51:17 -0700 (PDT) From: "Lizhong Jin" To: "'Joel M. Halpern'" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> In-Reply-To: <5447131F.5040709@joelhalpern.com> Date: Wed, 22 Oct 2014 10:51:09 +0800 Message-ID: <010101cfeda3$0cfaf820$26f0e860$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoLsexpoDjeNgEXN4xVax6BLciqgI4g/XAAhLnkzMCHjdnVwJETDgiAMwAguObPxWKYA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/txZ1NKXAqzVZHrC-MRvdYIUcGik Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:51:21 -0000 Hi Joel, I now see your concern. The "private" word in draft is not correct, I = will remove it. The original motivation of "draft-relay-reply" is from the scenario where IP address distribution is restricted among AS or IGP = area. And the IP address is not private address. As I know, most deployed = inter-AS or inter-area MPLS LSP is in the network without private IP address.=20 Regards Lizhong > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 2014=C4=EA10=D4=C222=C8=D5 10:15 > To: Lizhong Jin > Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; 'draft-ietf-mpls-lsp-ping- > relay-reply.all' > Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 >=20 > The problem is that the original source A, that we are trying to reach with a > reply, has an address that appears to the responder X to be routable. = But > the destination that is reached by that address is either a black hole = or some > other entity using the same address. >=20 > The reason for the duplication is that, as described in the draft, the source > address for A is a private address. That same address may well be reachable > according to the routing table at X. But it won't get to A. >=20 > If the problem is something other than private addressing preventing > reachability, it is likely there is still a mistaken routability = problem, but I can > not illustrate the failure without some other case being described. >=20 > Yours, > Joel >=20 > On 10/21/14, 10:06 PM, Lizhong Jin wrote: > > Inline, thanks. > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: 2014=C4=EA10=D4=C222=C8=D5 0:06 > >> To: lizho.jin@gmail.com > >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > > draft-ietf-mpls-lsp-ping- > >> relay-reply.all > >> Subject: Re: [mpls] [Gen-art] review: > > draft-ietf-mpls-lsp-ping-relay-reply-04 > >> > >> In line. > >> > >> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: > >>> Hi Joel, see inline below, thanks. > >>> > >>> Lizhong > >>> > >>> > >>>> 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern = wrote =A3=BA > >>>> > >>>> If the process for this draft is to use the top address that can = be > >>>> reached in the routing table, then there is a significant > >>>> probability that the original source address, which is always at > >>>> the top of the list, will be used. As such, the intended problem > >>>> will not be solved. > >>> [Lizhong] let me give an example to explain: the source address A = is > >>> firstly added to the stack, then a second routable address B for > >>> replying AS is also added. The reply node will not use address A > >>> since it's not routable, then it will use address B. So it will = work > >>> and I don't see the problem. > >> > >> The whole point of this relay mechanism, as I understand it, is to > >> cope > > with > >> the case when the responder X can not actually reach the source A. > >> Now suppose that the packet arrives at X with the Address stack = A, B, ... > > X > >> examines the stack. The domain of A was numbered using net 10. > >> The domain of X is numbered using net 10. A's address is probably > > routable > >> in X's routing table. The problem is, that routing will not get to > >> A. X > > examines > >> the stack, determines that A is "routable", and sends the packet. > >> This > > fails to > >> meet the goal. > > [Lizhong] The source A you are referring is the initiator, right? = The > > goal of relay mechanism is to reach the initiator. If X is routable = to > > the initiator (address A), then it is great, other relay node in the > > stack will be skipped. > > If the source A you are referring is the interface address of one > > intermediate node, then I do not understand "routing will not get to > > A. X examines the stack, determines that A is "routable", and sends = the > packet". > > Why routing will not get to A, but A is routable? > > > > Regards > > Lizhong > > > > > >> > >> Yours, > >> Joel > > > > > > From nobody Tue Oct 21 20:14:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A31A8A6E; Tue, 21 Oct 2014 20:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM6090wtS16o; Tue, 21 Oct 2014 20:14:23 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFDF1A8A6D; Tue, 21 Oct 2014 20:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BD0A11BC877C; Tue, 21 Oct 2014 20:14:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E74A21BC8785; Tue, 21 Oct 2014 20:14:16 -0700 (PDT) Message-ID: <544720FD.5030703@joelhalpern.com> Date: Tue, 21 Oct 2014 23:14:05 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lizhong Jin References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> In-Reply-To: <010101cfeda3$0cfaf820$26f0e860$@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LFyIQuW8CYDNOhE6YrpJ54fTf1U Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 03:14:26 -0000 ou are saying that this is only for the case where an AS is using public addresses for its internal numbering, but is not distributing that address block externally? If so, you need to state that very clearly. I believe a far more common case is one where the numbering is from a portion of a publicly allocated space, but firewalled. Which would produce the same problem, but would not be amenable to this solution. And it is well known that many ISPs do internal number assignment from private blocks. So what you are now saying is that this draft solves a very small portion of the problem? But it works for that small portion? If so, at the very least you need to be VERY clear about what cases this works for and what cases it does not. And I fear that even if you are clear, it is going to be very confusing for folks who are trying to use it. Yours, Joel On 10/21/14, 10:51 PM, Lizhong Jin wrote: > Hi Joel, > I now see your concern. The "private" word in draft is not correct, I will > remove it. The original motivation of "draft-relay-reply" is from the > scenario where IP address distribution is restricted among AS or IGP area. > And the IP address is not private address. As I know, most deployed inter-AS > or inter-area MPLS LSP is in the network without private IP address. > > Regards > Lizhong > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 2014Äê10ÔÂ22ÈÕ 10:15 >> To: Lizhong Jin >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > 'draft-ietf-mpls-lsp-ping- >> relay-reply.all' >> Subject: Re: [mpls] [Gen-art] review: > draft-ietf-mpls-lsp-ping-relay-reply-04 >> >> The problem is that the original source A, that we are trying to reach > with a >> reply, has an address that appears to the responder X to be routable. But >> the destination that is reached by that address is either a black hole or > some >> other entity using the same address. >> >> The reason for the duplication is that, as described in the draft, the > source >> address for A is a private address. That same address may well be > reachable >> according to the routing table at X. But it won't get to A. >> >> If the problem is something other than private addressing preventing >> reachability, it is likely there is still a mistaken routability problem, > but I can >> not illustrate the failure without some other case being described. >> >> Yours, >> Joel >> >> On 10/21/14, 10:06 PM, Lizhong Jin wrote: >>> Inline, thanks. >>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: 2014Äê10ÔÂ22ÈÕ 0:06 >>>> To: lizho.jin@gmail.com >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >>> draft-ietf-mpls-lsp-ping- >>>> relay-reply.all >>>> Subject: Re: [mpls] [Gen-art] review: >>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>> >>>> In line. >>>> >>>> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: >>>>> Hi Joel, see inline below, thanks. >>>>> >>>>> Lizhong >>>>> >>>>> >>>>>> 2014.10.21£¬PM9:30£¬Joel M. Halpern wrote £º >>>>>> >>>>>> If the process for this draft is to use the top address that can be >>>>>> reached in the routing table, then there is a significant >>>>>> probability that the original source address, which is always at >>>>>> the top of the list, will be used. As such, the intended problem >>>>>> will not be solved. >>>>> [Lizhong] let me give an example to explain: the source address A is >>>>> firstly added to the stack, then a second routable address B for >>>>> replying AS is also added. The reply node will not use address A >>>>> since it's not routable, then it will use address B. So it will work >>>>> and I don't see the problem. >>>> >>>> The whole point of this relay mechanism, as I understand it, is to >>>> cope >>> with >>>> the case when the responder X can not actually reach the source A. >>>> Now suppose that the packet arrives at X with the Address stack A, B, > ... >>> X >>>> examines the stack. The domain of A was numbered using net 10. >>>> The domain of X is numbered using net 10. A's address is probably >>> routable >>>> in X's routing table. The problem is, that routing will not get to >>>> A. X >>> examines >>>> the stack, determines that A is "routable", and sends the packet. >>>> This >>> fails to >>>> meet the goal. >>> [Lizhong] The source A you are referring is the initiator, right? The >>> goal of relay mechanism is to reach the initiator. If X is routable to >>> the initiator (address A), then it is great, other relay node in the >>> stack will be skipped. >>> If the source A you are referring is the interface address of one >>> intermediate node, then I do not understand "routing will not get to >>> A. X examines the stack, determines that A is "routable", and sends the >> packet". >>> Why routing will not get to A, but A is routable? >>> >>> Regards >>> Lizhong >>> >>> >>>> >>>> Yours, >>>> Joel >>> >>> >>> > From nobody Tue Oct 21 21:47:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624E41A8A97; Tue, 21 Oct 2014 21:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUYKgfbTebZ7; Tue, 21 Oct 2014 21:47:06 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4AE1A8A8D; Tue, 21 Oct 2014 21:47:06 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id g10so716367pdj.36 for ; Tue, 21 Oct 2014 21:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=9Zx+yjs/nDlkwihYa3VOk2YbqZswE85Jm6BdA2uPzTA=; b=zFGeo6+XMkynjQT2pVAKPvdKAG1Uq0pZfbwL5BIttkq9oOGHszUKI97XmFT2fGODi5 RD5I3LJ/dWtCSY6advjsDixOXUsSJwf31gBRpuu61TOB1maN5lX1JTrPqHwlYlHeWkqw P3QHmQy6Nw/nDgIMKVja19QgfL0GOLbqc2Nn89Qd/FIhOSbeLB0Pp1pDaXWk6ptWmLBC DUTWNhpGdlVw3stKdIZTuIigw3COFWh5UBMJ5tKxgCYGc6QdBGpuY1vkyd9uqfnXFJ5Q q0SIaimSsTHbsVS33TV/fPSv9Z0FOX91QpoQyZgHomKRbqu8aTlyvUozH/JEizngWJXj bO/w== X-Received: by 10.70.89.48 with SMTP id bl16mr39711175pdb.29.1413953225856; Tue, 21 Oct 2014 21:47:05 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id hp4sm13143855pbb.95.2014.10.21.21.47.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 21:47:05 -0700 (PDT) From: "Lizhong Jin" To: "'Joel M. Halpern'" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com> In-Reply-To: <544720FD.5030703@joelhalpern.com> Date: Wed, 22 Oct 2014 12:46:58 +0800 Message-ID: <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoLsexpoDjeNgEXN4xVax6BLciqgI4g/XAAhLnkzMCHjdnVwJETDgiAMwAguMCSbWPXwLVKPYomxY9O3A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1ypzGJWQnpD4n4TKqM82GzADAHo Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:47:08 -0000 Hi Joel, The things may not be that bad. You could add a second address (address = B in our example) with K bit set. The address entry with K bit set must be as = a relay node, and could not be skipped.=20 Section 4.4 should be changed to: Find the first routable address A, and = the first address B with K bit set. If address A is before address B in the stack, then use address B as the relay address. Otherwise, use address A = as the relay address. In that case, if A is the private address, the packet will be firstly relayed to address B. And address A and B belong to one router. Here I assume one router at least has one routable address for another AS. Regards Lizhong > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 2014=C4=EA10=D4=C222=C8=D5 11:14 > To: Lizhong Jin > Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; 'draft-ietf-mpls-lsp-ping- > relay-reply.all' > Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 >=20 > ou are saying that this is only for the case where an AS is using = public > addresses for its internal numbering, but is not distributing that = address block > externally? >=20 > If so, you need to state that very clearly. > I believe a far more common case is one where the numbering is from a > portion of a publicly allocated space, but firewalled. Which would produce > the same problem, but would not be amenable to this solution. > And it is well known that many ISPs do internal number assignment from > private blocks. >=20 > So what you are now saying is that this draft solves a very small = portion of the > problem? But it works for that small portion? If so, at the very = least you > need to be VERY clear about what cases this works for and what cases = it does > not. And I fear that even if you are clear, it is going to be very confusing for > folks who are trying to use it. >=20 > Yours, > Joel >=20 > On 10/21/14, 10:51 PM, Lizhong Jin wrote: > > Hi Joel, > > I now see your concern. The "private" word in draft is not correct, = I > > will remove it. The original motivation of "draft-relay-reply" is = from > > the scenario where IP address distribution is restricted among AS or = IGP > area. > > And the IP address is not private address. As I know, most deployed > > inter-AS or inter-area MPLS LSP is in the network without private IP address. > > > > Regards > > Lizhong > > > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: 2014=C4=EA10=D4=C222=C8=D5 10:15 > >> To: Lizhong Jin > >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > > 'draft-ietf-mpls-lsp-ping- > >> relay-reply.all' > >> Subject: Re: [mpls] [Gen-art] review: > > draft-ietf-mpls-lsp-ping-relay-reply-04 > >> > >> The problem is that the original source A, that we are trying to > >> reach > > with a > >> reply, has an address that appears to the responder X to be = routable. > >> But the destination that is reached by that address is either a = black > >> hole or > > some > >> other entity using the same address. > >> > >> The reason for the duplication is that, as described in the draft, > >> the > > source > >> address for A is a private address. That same address may well be > > reachable > >> according to the routing table at X. But it won't get to A. > >> > >> If the problem is something other than private addressing = preventing > >> reachability, it is likely there is still a mistaken routability > >> problem, > > but I can > >> not illustrate the failure without some other case being described. > >> > >> Yours, > >> Joel > >> > >> On 10/21/14, 10:06 PM, Lizhong Jin wrote: > >>> Inline, thanks. > >>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Sent: 2014=C4=EA10=D4=C222=C8=D5 0:06 > >>>> To: lizho.jin@gmail.com > >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > >>> draft-ietf-mpls-lsp-ping- > >>>> relay-reply.all > >>>> Subject: Re: [mpls] [Gen-art] review: > >>> draft-ietf-mpls-lsp-ping-relay-reply-04 > >>>> > >>>> In line. > >>>> > >>>> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: > >>>>> Hi Joel, see inline below, thanks. > >>>>> > >>>>> Lizhong > >>>>> > >>>>> > >>>>>> 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern = > wrote =A3=BA > >>>>>> > >>>>>> If the process for this draft is to use the top address that = can > >>>>>> be reached in the routing table, then there is a significant > >>>>>> probability that the original source address, which is always = at > >>>>>> the top of the list, will be used. As such, the intended = problem > >>>>>> will not be solved. > >>>>> [Lizhong] let me give an example to explain: the source address = A > >>>>> is firstly added to the stack, then a second routable address B > >>>>> for replying AS is also added. The reply node will not use = address > >>>>> A since it's not routable, then it will use address B. So it = will > >>>>> work and I don't see the problem. > >>>> > >>>> The whole point of this relay mechanism, as I understand it, is = to > >>>> cope > >>> with > >>>> the case when the responder X can not actually reach the source = A. > >>>> Now suppose that the packet arrives at X with the Address = stack > >>>> A, B, > > ... > >>> X > >>>> examines the stack. The domain of A was numbered using net 10. > >>>> The domain of X is numbered using net 10. A's address is = probably > >>> routable > >>>> in X's routing table. The problem is, that routing will not get = to > >>>> A. X > >>> examines > >>>> the stack, determines that A is "routable", and sends the packet. > >>>> This > >>> fails to > >>>> meet the goal. > >>> [Lizhong] The source A you are referring is the initiator, right? > >>> The goal of relay mechanism is to reach the initiator. If X is > >>> routable to the initiator (address A), then it is great, other = relay > >>> node in the stack will be skipped. > >>> If the source A you are referring is the interface address of one > >>> intermediate node, then I do not understand "routing will not get = to > >>> A. X examines the stack, determines that A is "routable", and = sends > >>> the > >> packet". > >>> Why routing will not get to A, but A is routable? > >>> > >>> Regards > >>> Lizhong > >>> > >>> > >>>> > >>>> Yours, > >>>> Joel > >>> > >>> > >>> > > From nobody Tue Oct 21 23:43:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372E1A6F9D for ; Tue, 21 Oct 2014 23:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTcMSWIZGB0G for ; Tue, 21 Oct 2014 23:42:59 -0700 (PDT) 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 DBD301A6F85 for ; Tue, 21 Oct 2014 23:42:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNX36752; Wed, 22 Oct 2014 06:42:57 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 07:42:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 14:42:48 +0800 From: Xuxiaohu To: Xuxiaohu , "Carlos Pignataro (cpignata)" , Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+eqYlo34/Uuk+WldaSxF4jM5wylSgAgAGwIYCAABMQgIAD6XaAgAASfgCAAVGtAIAAHzyAgAGoUBCAADz0IA== Date: Wed, 22 Oct 2014 06:42:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3DCA@NKGEML512-MBS.china.huawei.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/msDFrOMM3oKOK2u4JP5yq8_Kn8k Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 06:43:01 -0000 > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > Sent: Wednesday, October 22, 2014 10:39 AM > To: Carlos Pignataro (cpignata); Mach Chen > Cc: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org; Ross Call= on; > mpls-chairs@tools.ietf.org > Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label >=20 > Hi Carlos, >=20 > > The EL is used for forwarding/dispatch decisions. The SL is metadata, > > not used for forwarding. The fundamental change to the dataplane is > > using it to carry metadata. >=20 > In fact, one of other use cases of the SL is to make the MP2P LDP availab= le for > multicast VPN in the ingress replication mode (For more details, see 6.4.= 5. > Ingress Replication of RFC6513). In this use case, the SL is now used for > forwarding decisions. We could add this use case in the next revision. To better understand the need for identifying the ingress PE of the receive= d multicast VPN packet by the egress PE in the ingress replication mode, p= lease refer to section 6.1. of draft-rosen-l3vpn-ir-01 (http://tools.ietf.o= rg/html/draft-rosen-l3vpn-ir-01#section-6.1). Best regards, Xiaohu > Best regards, > Xiaohu From nobody Wed Oct 22 05:18:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C836F1A901E for ; Wed, 22 Oct 2014 05:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLS2U23Ixl7y for ; Wed, 22 Oct 2014 05:18:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55DA1A8AFE for ; Wed, 22 Oct 2014 05:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15418; q=dns/txt; s=iport; t=1413980294; x=1415189894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EDyO/fw7mK/Vpop/ZX0SPDcshWEoqbIwi3APZG03O98=; b=UUHDbnzvIHNHtV0Je8bUVDXiFFcn4j6a+a2XwmN0Vycq5meRq00QO88V n3+afXe+x5Uk3687BCxSst/iaHpQ3DzW3tsgI6Nh5iOx79TSZjD47AXu3 xK+NUQWXLqyQ1ysMKPyNpGE5SiFhGzXGyVTOcSBV/im4OVxcToouTTId3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAESgR1StJV2Q/2dsb2JhbABcgmsjVFgEzF4Kh00CgQsWAX2EAgEBAQMBAQEBNy0HCwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FG4gdCAEMxWkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXilaFHgERAR0zAgUGgyeBHgWPZoIei1mBMYNJjS+EAYN4bAGBDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,768,1406592000"; d="scan'208";a="365485301" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2014 12:18:11 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9MCIBNf026876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:18:11 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 07:18:11 -0500 From: "Carlos Pignataro (cpignata)" To: Mach Chen Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+l2b155pZvakGO4uRCWsmh1pwzbxUAgAGwIACAABMSgIAD6XaAgAASfgCAAVGtAP//y2uEgABgCYCAABgogIAA4sqAgAC/gAA= Date: Wed, 22 Oct 2014 12:18:10 +0000 Message-ID: <1D991106-8DCD-4AD2-A874-862EEBB2C641@cisco.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com> <, <>> <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <5446419F.7020005@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MbCT1Ae3sTl6-UQ2HS7y7pcFcpA Cc: "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:18:18 -0000 Hi, Mach, The fundamental difference is that a GAL dispatches to packet to an OAM pro= cessing engine (i.e., what to do *with* the packet), whereas the SL tells a= counter to increment itself while the packet continues its face (i.e., wha= t to do *about* the packet, and not *with* the packet). My comment is that = it's an expensive change without understanding the problem space. Is really= SL/SLI the best solution for that (given the granularily, label stack, and= other comments)? Thanks, Carlos. > On Oct 21, 2014, at 8:52 PM, Mach Chen wrote: >=20 > Hi Stewart, >=20 > OK, if this is the logic, then SL/SLI tells the LSR dispatch the packet t= o PM engine for accounting then keep processing. >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Tuesday, October 21, 2014 7:21 PM >> To: Mach Chen; Carlos Pignataro (cpignata) >> Cc: Eric Rosen; Ross Callon; draft-chen-mpls-source-label@tools.ietf.org= ; >> mpls@ietf.org; mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>=20 >> GAL tells an LSR what to do with the pkt - it says please dispatch to t= he OAM >> handler. >>=20 >> - Stewart >>=20 >> On 21/10/2014 10:54, Mach Chen wrote: >>> Hi Carlos, >>>=20 >>> Thanks for sharing your point! >>>=20 >>>> The EL is used for forwarding/dispatch decisions. The SL is metadata, >>>> not used for forwarding. The fundamental change to the dataplane is >>>> using it to carry metadata. >>> If the criteria is whether a label is used for forwarding, how about GA= L? >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----Original Message----- >>>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>> Sent: Tuesday, October 21, 2014 5:11 PM >>>> To: Mach Chen >>>> Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon; >>>> draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>> mpls-chairs@tools.ietf.org >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>=20 >>>> Hi Mach, >>>>=20 >>>> Please find one set of comments inline. >>>>=20 >>>> Thumb typed by Carlos Pignataro. >>>> Excuze typofraphicak errows >>>>=20 >>>>> On Oct 21, 2014, at 3:19 AM, Mach Chen wrote: >>>>>=20 >>>>> Hi Stewart, >>>>>=20 >>>>> Please see my replies inline... >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>>>> Sent: Monday, October 20, 2014 7:10 PM >>>>>> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon >>>>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>>>> mpls-chairs@tools.ietf.org >>>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>>=20 >>>>>> Mach >>>>>>=20 >>>>>>> On 20/10/2014 11:04, Mach Chen wrote: >>>>>>> Hi Eric , Carlos, Stewart and others, >>>>>>>=20 >>>>>>> Thanks for the discussion! Sorry for the top post. >>>>>>>=20 >>>>>>> I do think that you're really exaggerating the complexity and >>>>>>> negatives. Given >>>>>> an LSR can support EL, Segment Routing, MVPN, context label, etc, >>>>>> IMHO it's not difficult for such kind of routers to support SL. >>>>>> Those solutions are not the same. >>>>>>=20 >>>>>> ELs - have no impact on the receiver. I admit that they have an >>>>>> impact on the transmitter (but only two labels) but the only flow >>>>>> state is that an EL needs to be generated, you do not need >>>>>> additional transmitter context since this is generated from the pack= et itself. >>>>>>=20 >>>>>> SR - has no impact at ay node other than the transmitter, and in >>>>>> many cases the impact is one or two labels. It does not change the >> dataplane.. >>>>>>=20 >>>>>> Context labels - I am not sure how wide the support for the >>>>>> general context label use case is. >>>>>>=20 >>>>>> What you are proposing is a far more fundamental change to the >>>>>> dataplane than any of the above. >>>>> I may have different view on this, let me make a little bit >>>>> comparison between >>>> SL and EL: >>>> The EL is used for forwarding/dispatch decisions. The SL is metadata, >>>> not used for forwarding. The fundamental change to the dataplane is >>>> using it to carry metadata. >>>>=20 >>>>> 1) For ingress LSR, it's almost the same, except that EL requires >>>>> the ingress LSR to generate the Entropy, then both just put >>>>> information into the label stack; >>>>>=20 >>>>> 2) For transit LSR, EL requires the LSR to know how to handle the >>>>> ELI and EL, otherwise cannot benefit from the EL; SL does not bring >>>>> any requirement to transit LSR; >>>>>=20 >>>>> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, >>>>> when do SL based PM, the egress LSR has to use the SL for >>>>> accounting, but such accounting is basic and necessary work for PM; >>>>>=20 >>>> Extrapolating from your argument, we could add a number of labels to >>>> the stack that do not carry forwarding instructions without any concer= ns. SL, >> what's next? >>>>=20 >>>>> Based above, from the dataplane point of view, the processing and >>>>> complexity is as the same level of EL, and it DOES NOT bring >>>>> "fundamental" change to the dataplane; >>>>>=20 >>>> The change, in my view, is in the semantics of the label. >>>>=20 >>>> Given how fundamental this is (in my mind) it calls for a more >>>> comprehensive understanding of the problem being solved. >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos. >>>>=20 >>>>>>> I looked though the whole discussions so far, and I am not going >>>>>>> to reply each >>>>>> email one by email, I summarized the topics as follows: >>>>>>> 1) Requirement >>>>>>> Whether the requirement is compelling depends on whether you need >>>>>>> it. We >>>>>> did receive the requirements from SPs to support passive PM for >>>>>> MP2P based LSPs, especially for the case of MPLS based IP backhaul >>>>>> network. So for those SPs, it's a compelling requirement. Indeed, >>>>>> PM is not an easy work, and in IETF, several dedicated WGs work on >>>>>> PM related stuff, some WGs have worked on it over decade. >>>>>> I am not disputing the requirement for a method of measuring loss >>>>>> of customer traffic. >>>>>>=20 >>>>>> However the requirement for domain wide source labels is not >>>>>> established. It is one method of identifying the source in a PM >>>>>> measurement, but it is not the only method. >>>>> Actually, the latest version DOES NOT require domain wide source >>>>> labels, the >>>> source label is just a carrier that is used to carry the domain wide >>>> unique Source Identifier (SI); the SI is transparent to the SL, from >>>> the convey information point of view, it's the same as EL. >>>>>>> This draft is mainly about how to do source identification that is >>>>>>> one of the critical requirements of the passive PM, >>>>>> It is about one method. The method you propose is not the only metho= d. >>>>>>=20 >>>>>> Also you have jumped directly to a S-D identification approach, >>>>>> without justifying this as being the required unit of identification= . >>>>> Other than S-D identification, I am not sure that there are other >>>>> ways that could >>>> be used to perform passive PM. I noticed you mention destination >>>> based approach in another email, can you please elaborate how it works= ? >>>>>>> it is not intended to cover all aspects of PM. This is clearly >>>>>>> stated in the >>>>>> document. Other aspects, for example, the multiple line cards in >>>>>> the egress as Stewart pointed out, I do really think that is an >>>>>> implementation issue. For that case, you do need a centralized >>>>>> component to sum up and analyze the statistics and their correlation= s. >>>>>> It is not that simple as you know from your other draft, and it >>>>>> does not make sense to me to address the two requirements as ships >>>>>> in the night >>>> solutions. >>>>>> Given that you receive a packet on one line card, you have no idea >>>>>> whether a packet received on another line card (or even line >>>>>> interface on that card) was transmitted before of after the one you >>>>>> are taking as your accounting reference point. >>>>> We have a prototype doing IP based passive PM and do consider such >>>>> scenario >>>> and it works. In this case, you do need a centralized component >>>> (which could reside in a linecard, the main control card or an >>>> external entity (e.g., NMS)) that can collect all statistic informatio= n of the >> tested flow. >>>>>>> 2) Label stack depth >>>>>>> Regarding the label stack depth, there were some related >>>>>>> discussions (including >>>>>> this WG and other WGs) , some vendors have showed that is not a big >>>>>> problem, especially for those new generation modern routers/switches= . >>>>>> That is an assumption that you need to justify, particular at the ne= twork >> edge. >>>>> We will see such devices come out, especially when Segment Routing >>>> progressing. >>>>>>> 3) Granularity >>>>>>> It depends on how you use it. In theory, the solution can support >>>>>>> any number >>>>>> flows. But there always be some tradeoff, as I replied in a >>>>>> precious email, the SI number itself is not the issue, the HW >>>>>> resource (e.g., the timers) is the critical constraint. That means, >>>>>> you cannot expect a router to >>>> support unlimited flows. >>>>>> For SI number, I guess that the main concern is mainly about the >>>>>> state maintenance and advertisement, actually it could be optimized >>>>>> to maintain and advertize a single SI block for each LSR. This way, >>>>>> the state and advertisement is a fixed number corresponding to the >>>>>> number >>>> of the LSR in the domain. >>>>>> The timers can be in s/w in the supervisor, since the time that a >>>>>> measurement is taken is not critical, so whilst there might be a >>>>>> filter and counter issue in the h/w, though no worse than IPFIX, >>>>>> there is not >>>> h/w issue with timers. >>>>> It depends on how you implement the measurement, timer for >>>>> measurement >>>> is important, it sometime determines the accurate of the measurement. >>>> And I also agree that filter and counter are the other critical >>>> issues. And all these belong to the HW resource. So, I am trying to >>>> say, when consider these HW constraints, the SI state should be not a >>>> bit deal. Because you cannot monitor unlimited flows on a device. >>>>> Best regards, >>>>> Mach >>>>>=20 >>>>>> Stewart >>>>>>> Best regards, >>>>>>> Mach >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen >>>>>>>> Sent: Saturday, October 18, 2014 6:20 AM >>>>>>>> To: Carlos Pignataro (cpignata); Ross Callon >>>>>>>> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; >>>>>>>> mpls-chairs@tools.ietf.org >>>>>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >>>>>>>>=20 >>>>>>>> Carlos> Basically, two or three labels are added to the label >>>>>>>> Carlos> stack, >>>>>>>>=20 >>>>>>>> Actually, that's two or three labels per LSP. A packet may be >>>>>>>> going through a nested set of LSPs, which each label in the stack >>>>>>>> representing one >>>>>> of those LSPs. >>>>>>>> Each LSP may have its own source label. Since a source label is >>>>>>>> likely to require three label stack entries, the number of labels >>>>>>>> in the stack >>>>>> could be quadrupled. >>>>>>>> And for what? >>>>>>>>=20 >>>>>>>> Carlos> the document only lists PM as the application that needs >>>>>>>> Carlos> source >>>>>> labels. >>>>>>>> There doesn't seem to be general agreement that this is a >>>>>>>> compelling use >>>>>> case. >>>>>>>> Certainly not compelling enough to justify the complexity and the >>>>>>>> overhead that it brings. >>>>>>>>=20 >>>>>>>> Carlos> What happens if a finer granularity than the source node >>>>>>>> Carlos> is >>>> needed? >>>>>>>> This is inevitable. How long before folks are complaining "we >>>>>>>> can't run our network unless the egress LSR can determine the >>>>>>>> ingress interface for each packet". This could lead to thousands >>>>>>>> of source label >>>>>> values for each ingress LSR. >>>>>>>> And what will happen when someone decides that the granularity >>>>>>>> needs to be per-subscriber, not merely per-interface? >>>>>>>>=20 >>>>>>>> And it's not just "finer granularity" we have to worry about. >>>>>>>> What if someone decides that an ingress LSR needs to convey an >>>>>>>> arbitrary amount >>>>>> of "meta-data" >>>>>>>> about an LSP to the egress LSR. Will the label stack become a >>>>>>>> set of labels alternating with meta-data containers? >>>>>>>>=20 >>>>>>>> Do we really want to put stuff that doesn't affect the packet >>>>>>>> forwarding into the label stack? Where will we draw the line? >>>>>>>>=20 >>>>>>>> I don't think the authors really intend the mechanism to be >>>>>>>> generalized in this manner. They're probably thinking "But we >>>>>>>> only intend for this to be deployed in a very simple case, where >>>>>>>> packets are being tunneled, where the ingress LSR knows who the >>>>>>>> egress LSR is, where they're in the same administrative domain, et= c. etc. >>>>>>>> You're really exaggerating the negatives." But the proposed >>>>>>>> mechanisms do lend themselves to abuse or this sort. Once we >>>>>>>> start putting stuff in the label stack that isn't used for >>>>>>>> forwarding, how will we know >>>>>> when to stop? >>>>>>>> Carlos> Given this dramatic set of extensions and strong >>>>>>>> Carlos> requirements, it seems >>>>>>>> prudent to me to better understand the problem space of PM gaps >>>>>>>> before adopting a solution. >>>>>>>>=20 >>>>>>>> I agree. I think Stewart has made a good case that further >>>>>>>> analysis is >>>>>> needed. >>>>>>>> The problem isn't that there is no use for source labels, the >>>>>>>> problem is that the mechanism seems to bring a lot of problems >>>>>>>> with it. Is this really the only solution? And if so, is it so >>>>>>>> important to be able to do PM that we should be willing to take >>>>>>>> on all these >>>> problems? >>>>>>>> I also think the proposed LDP and BGP extensions are problematic, >>>>>>>> but those issues are really of secondary importance right now. >>>>>>>>=20 >>>>>>>> So I don't support the adoption of this draft. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> . >>>>>>=20 >>>>>> -- >>>>>> For corporate legal information go to: >>>>>>=20 >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> . >>>=20 >>=20 >>=20 >> -- >> For corporate legal information go to: >>=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From nobody Wed Oct 22 05:19:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3561A9041 for ; Wed, 22 Oct 2014 05:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvP6_jYEqHEs for ; Wed, 22 Oct 2014 05:19:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667C81A9026 for ; Wed, 22 Oct 2014 05:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=960; q=dns/txt; s=iport; t=1413980371; x=1415189971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ws4rzon/Nd1HwFeJgAGNfi0JcuPsUb3sUW+knArVobE=; b=GYiPbxXjerMCcWc79tXXbhIDzqCbpMwKKKecMMuXdjmaIabF/dyZYzqz 7cMb4M+xMUPij182iasyfXzB+kfFZEOUp0A4OcHJ4OS7jgbv/6rxCYYll 9HBzyQ+vfXrpvfDorf+kkIe37+ngD5sKLksqKE7+BzRJ062Zud4qtT24D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAESgR1StJA2E/2dsb2JhbABcgmsjgSwE1DUCgQsWAX2EAgEBAQMBOj8FCwIBCBgeEDIlAgQOBRuIHQgBxXUBAQEBAQEBAQEBAQEBAQEBAQEBGZAkMweDLYEeAQSPZoIei1mWKoIGGIFabIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,768,1406592000"; d="scan'208";a="89301794" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 22 Oct 2014 12:19:30 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9MCJUYW031929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:19:30 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 07:19:30 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+l2b155pZvakGO4uRCWsmh1pwzbxUAgAGwIACAABMSgIAD6XaAgAASfgCAAVGtAP//y2uEgAF4mgCAAKJAgA== Date: Wed, 22 Oct 2014 12:19:29 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com> <,> <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <030214ADE951DE40999BF7836C3C29CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8RZhotJ2KlCVhw_pUgtbaaOnE2s Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:19:38 -0000 Hi Mach, I do not think it is healthy to cherry pick random orthogonal requirements = to fit a proposed solution for something else. I believe the right argument= is understanding the universe of the problem being solved first, and then = find the best (i.e., minimal) solution for it. Thanks, Carlos. > On Oct 21, 2014, at 10:38 PM, Xuxiaohu wrote: >=20 > Hi Carlos, >=20 >> The EL is used for forwarding/dispatch decisions. The SL is metadata, no= t used >> for forwarding. The fundamental change to the dataplane is using it to c= arry >> metadata. >=20 > In fact, one of other use cases of the SL is to make the MP2P LDP availab= le for multicast VPN in the ingress replication mode (For more details, see= 6.4.5. Ingress Replication of RFC6513). In this use case, the SL is now us= ed for forwarding decisions. We could add this use case in the next revisio= n. >=20 > Best regards, > Xiaohu >=20 From nobody Wed Oct 22 05:22:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDC91A9036 for ; Wed, 22 Oct 2014 05:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5K3NrjtnzWy for ; Wed, 22 Oct 2014 05:21:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5921A8F45 for ; Wed, 22 Oct 2014 05:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1627; q=dns/txt; s=iport; t=1413980514; x=1415190114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4i6PV1Au6kYZCf0xaQs4reTFW7Opmd3AStILLoCfMoI=; b=gAYSYR+mlB/dohZx0qhlM8XPzByLIpX0RvLNus3icYUf4jjiN+/UDC4e 16RE1yUylcm5dFupHApy+hpJse9fMS7LROiXah64kvjQ1WdcjtmZAhen1 REL0eoFPAuN7IxdHYWWk1bazDxB3lImA+e7JQAZkHkespyPxHjaMP/YYP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAESgR1StJV2Q/2dsb2JhbABcgmsjVE4KBMxeCodNAoELFgF9hAIBAQEEAQEBawsMBAIBCBEDAQIBLicLHQgCBAENBRuIJQEMxWkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBJBXBwaERQEEiyWGX4tZliqCBhiBWmyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,768,1406592000"; d="scan'208";a="365486418" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2014 12:21:53 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9MCLrgv030178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:21:53 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 07:21:53 -0500 From: "Carlos Pignataro (cpignata)" To: "Carlos Pignataro (cpignata)" , Xiaohu Xu Thread-Topic: [mpls] IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP6T+l2b155pZvakGO4uRCWsmh1pwzbxUAgAGwIACAABMSgIAD6XaAgAASfgCAAVGtAP//y2uEgAF4mgCAAKJAgP//vZoA Date: Wed, 22 Oct 2014 12:21:52 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com> <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C3CF3@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.82.248.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17FF0006067E1B41867A13B8A70BD841@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Lt3W_Gu7sV8B2ArWxeDqBvTmzjY Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:22:00 -0000 [Apologies, I meant =B3Hi, Xiaohu,=B2, mis-addressed to Mach] -----Original Message----- From: Carlos Pignataro Date: Wednesday, October 22, 2014 at 8:19 AM To: Xiaohu Xu Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label >Hi Mach, > >I do not think it is healthy to cherry pick random orthogonal >requirements to fit a proposed solution for something else. I believe the >right argument is understanding the universe of the problem being solved >first, and then find the best (i.e., minimal) solution for it. > >Thanks, > >Carlos. > >> On Oct 21, 2014, at 10:38 PM, Xuxiaohu wrote: >>=20 >> Hi Carlos, >>=20 >>> The EL is used for forwarding/dispatch decisions. The SL is metadata, >>>not used >>> for forwarding. The fundamental change to the dataplane is using it to >>>carry >>> metadata. >>=20 >> In fact, one of other use cases of the SL is to make the MP2P LDP >>available for multicast VPN in the ingress replication mode (For more >>details, see 6.4.5. Ingress Replication of RFC6513). In this use case, >>the SL is now used for forwarding decisions. We could add this use case >>in the next revision. >>=20 >> Best regards, >> Xiaohu >>=20 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 22 06:14:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7821A9131 for ; Wed, 22 Oct 2014 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGmJ1aQUV1fy for ; Wed, 22 Oct 2014 06:14:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFD41A9127 for ; Wed, 22 Oct 2014 06:14:34 -0700 (PDT) Received: from [172.29.33.97] (66.129.241.11) by BN3PR0501MB1092.namprd05.prod.outlook.com (25.160.113.139) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 13:14:32 +0000 Message-ID: <5447ADB1.9040201@juniper.net> Date: Wed, 22 Oct 2014 09:14:25 -0400 From: Eric Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mach Chen , "stbryant@cisco.com" , "Carlos Pignataro (cpignata)" References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> <543FBEBD.4010908@cisco.com> <40EF0A05-49B7-4727-8264-71B53BC812CA@cisco.com> <5441960B.7040305@juniper.net> <5444EDA4.3070002@cisco.com>, <49D42FF4-59E7-48AF-A2D1-F99EE658BB3C@cisco.com> <5446419F.7020005@cisco.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR09CA0032.namprd09.prod.outlook.com (25.160.111.170) To BN3PR0501MB1092.namprd05.prod.outlook.com (25.160.113.139) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1092; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174003)(377454003)(199003)(189002)(24454002)(2501002)(102836001)(33656002)(99396003)(106356001)(77096002)(97736003)(76176999)(65816999)(54356999)(50986999)(50466002)(107046002)(101416001)(20776003)(4396001)(47776003)(40100003)(105586002)(65806001)(64706001)(21056001)(64126003)(42186005)(66066001)(120916001)(65956001)(23746002)(85306004)(36756003)(85852003)(93886004)(83506001)(122386002)(80316001)(95666004)(92566001)(31966008)(230783001)(87266999)(86362001)(59896002)(76482002)(46102003)(92726001)(80022003)(87976001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1092; H:[172.29.33.97]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JydlT0m_sSCPn7gD7GJbb_b9mgs Cc: Ross Callon , "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:14:36 -0000 On 10/21/2014 8:52 PM, Mach Chen wrote: Mach> OK, if this is the logic, then SL/SLI tells the LSR dispatch the packet Mach> to PM engine for accounting then keep processing. If you really want a label for this purpose, the egress can assign one dynamically (perhaps distributing it via IGP extensions), and there is no need to include a source identifier (or other meta-data) in the label stack. This would then require only one label stack entry, not three. It's also hard to believe that folks who are monitoring their traffic will want to ignore traffic that comes from ingress LSRs that don't support the source label. Xiaohu> In fact, one of other use cases of the SL is to make the MP2P Xiaohu> LDP available for multicast VPN in the ingress replication mode This seems incompatible with the idea that the purpose of the label is to mark the packet as needing PM. Also, per draft-rosen-l3vpn-ir-01, there is no need for a source label when using MP2P LDP for MVPN IR, as the labels carried in the Leaf A-D routes are perfectly satisfactory for that purpose. These labels allow you to tell when a packet comes from the expected ingress VRF (a fact needed for extranet), and they also allow you to determine the set of egress VRFs for a given packet. This is just not a good application for source labels. Carlos> I do not think it is healthy to cherry pick random orthogonal Carlos> requirements to fit a proposed solution for something else. I Carlos> believe the right argument is understanding the universe of the Carlos> problem being solved first, and then find the best (i.e., Carlos> minimal) solution for it. I think Carlos has put it very well. I'm sure that if we had a source label we could invent a variety of uses for it (not necessarily all compatible), but that is just not a good enough reason to have it. From nobody Wed Oct 22 06:30:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A061A9148; Wed, 22 Oct 2014 06:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt18LevfnrtU; Wed, 22 Oct 2014 06:30:55 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461B01A9130; Wed, 22 Oct 2014 06:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 281802403A8; Wed, 22 Oct 2014 06:30:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-195.clppva.east.verizon.net [70.106.134.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B0A53240207; Wed, 22 Oct 2014 06:30:53 -0700 (PDT) Message-ID: <5447B18C.7050109@joelhalpern.com> Date: Wed, 22 Oct 2014 09:30:52 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lizhong Jin , "'Joel M. Halpern'" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com> <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> In-Reply-To: <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RHLO4MwWLU71Kgg2vTElQG7zCYk Cc: mpls@ietf.org, gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:30:57 -0000 It would be good to see a revision that clearly spelled out what the draft was solving, how the initial end-point knew what to create, and how the responder knew what to use. It may well be that there is an effective solution to the problems here. I look forward to seeing it in writing. Yours, Joel On 10/22/14, 12:46 AM, Lizhong Jin wrote: > Hi Joel, > The things may not be that bad. You could add a second address (address B in > our example) with K bit set. The address entry with K bit set must be as a > relay node, and could not be skipped. > Section 4.4 should be changed to: Find the first routable address A, and the > first address B with K bit set. If address A is before address B in the > stack, then use address B as the relay address. Otherwise, use address A as > the relay address. > In that case, if A is the private address, the packet will be firstly > relayed to address B. And address A and B belong to one router. Here I > assume one router at least has one routable address for another AS. > > Regards > Lizhong > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 2014Äê10ÔÂ22ÈÕ 11:14 >> To: Lizhong Jin >> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > 'draft-ietf-mpls-lsp-ping- >> relay-reply.all' >> Subject: Re: [mpls] [Gen-art] review: > draft-ietf-mpls-lsp-ping-relay-reply-04 >> >> ou are saying that this is only for the case where an AS is using public >> addresses for its internal numbering, but is not distributing that address > block >> externally? >> >> If so, you need to state that very clearly. >> I believe a far more common case is one where the numbering is from a >> portion of a publicly allocated space, but firewalled. Which would > produce >> the same problem, but would not be amenable to this solution. >> And it is well known that many ISPs do internal number assignment from >> private blocks. >> >> So what you are now saying is that this draft solves a very small portion > of the >> problem? But it works for that small portion? If so, at the very least > you >> need to be VERY clear about what cases this works for and what cases it > does >> not. And I fear that even if you are clear, it is going to be very > confusing for >> folks who are trying to use it. >> >> Yours, >> Joel >> >> On 10/21/14, 10:51 PM, Lizhong Jin wrote: >>> Hi Joel, >>> I now see your concern. The "private" word in draft is not correct, I >>> will remove it. The original motivation of "draft-relay-reply" is from >>> the scenario where IP address distribution is restricted among AS or IGP >> area. >>> And the IP address is not private address. As I know, most deployed >>> inter-AS or inter-area MPLS LSP is in the network without private IP > address. >>> >>> Regards >>> Lizhong >>> >>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: 2014Äê10ÔÂ22ÈÕ 10:15 >>>> To: Lizhong Jin >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >>> 'draft-ietf-mpls-lsp-ping- >>>> relay-reply.all' >>>> Subject: Re: [mpls] [Gen-art] review: >>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>> >>>> The problem is that the original source A, that we are trying to >>>> reach >>> with a >>>> reply, has an address that appears to the responder X to be routable. >>>> But the destination that is reached by that address is either a black >>>> hole or >>> some >>>> other entity using the same address. >>>> >>>> The reason for the duplication is that, as described in the draft, >>>> the >>> source >>>> address for A is a private address. That same address may well be >>> reachable >>>> according to the routing table at X. But it won't get to A. >>>> >>>> If the problem is something other than private addressing preventing >>>> reachability, it is likely there is still a mistaken routability >>>> problem, >>> but I can >>>> not illustrate the failure without some other case being described. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 10/21/14, 10:06 PM, Lizhong Jin wrote: >>>>> Inline, thanks. >>>>> >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: 2014Äê10ÔÂ22ÈÕ 0:06 >>>>>> To: lizho.jin@gmail.com >>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >>>>> draft-ietf-mpls-lsp-ping- >>>>>> relay-reply.all >>>>>> Subject: Re: [mpls] [Gen-art] review: >>>>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>>>> >>>>>> In line. >>>>>> >>>>>> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: >>>>>>> Hi Joel, see inline below, thanks. >>>>>>> >>>>>>> Lizhong >>>>>>> >>>>>>> >>>>>>>> 2014.10.21£¬PM9:30£¬Joel M. Halpern >> wrote £º >>>>>>>> >>>>>>>> If the process for this draft is to use the top address that can >>>>>>>> be reached in the routing table, then there is a significant >>>>>>>> probability that the original source address, which is always at >>>>>>>> the top of the list, will be used. As such, the intended problem >>>>>>>> will not be solved. >>>>>>> [Lizhong] let me give an example to explain: the source address A >>>>>>> is firstly added to the stack, then a second routable address B >>>>>>> for replying AS is also added. The reply node will not use address >>>>>>> A since it's not routable, then it will use address B. So it will >>>>>>> work and I don't see the problem. >>>>>> >>>>>> The whole point of this relay mechanism, as I understand it, is to >>>>>> cope >>>>> with >>>>>> the case when the responder X can not actually reach the source A. >>>>>> Now suppose that the packet arrives at X with the Address stack >>>>>> A, B, >>> ... >>>>> X >>>>>> examines the stack. The domain of A was numbered using net 10. >>>>>> The domain of X is numbered using net 10. A's address is probably >>>>> routable >>>>>> in X's routing table. The problem is, that routing will not get to >>>>>> A. X >>>>> examines >>>>>> the stack, determines that A is "routable", and sends the packet. >>>>>> This >>>>> fails to >>>>>> meet the goal. >>>>> [Lizhong] The source A you are referring is the initiator, right? >>>>> The goal of relay mechanism is to reach the initiator. If X is >>>>> routable to the initiator (address A), then it is great, other relay >>>>> node in the stack will be skipped. >>>>> If the source A you are referring is the interface address of one >>>>> intermediate node, then I do not understand "routing will not get to >>>>> A. X examines the stack, determines that A is "routable", and sends >>>>> the >>>> packet". >>>>> Why routing will not get to A, but A is routable? >>>>> >>>>> Regards >>>>> Lizhong >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>> >>>>> >>>>> >>> > From nobody Wed Oct 22 07:06:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA21AC3ED; Wed, 22 Oct 2014 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 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, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6mHcWIsbG-2; Wed, 22 Oct 2014 07:06:20 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010D71AC3E4; Wed, 22 Oct 2014 07:05:22 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id p10so1589297pdj.19 for ; Wed, 22 Oct 2014 07:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DYQs2VNZO4igGgBo7KxY4Wc0vsmn4bOUuDMmTNPm4vE=; b=PmuRB5tl6vcLvuONOvFmpYGrJ4XpHHzGvgINVwIBwabZbCtpILIpxwZRkTYv6/PQfw yBJShwCzV6OnpsLVcZAB/gZ5OBatYnX0mNOwaLrGU+sxItOmlUo1zVG4WYEkxYu4Rl/U lHejTTvczq3xPV0rDn7jqwu9tjH7MeRKZKtrJcf8QoLIJWG+/XJjLy3gZlH+tMk3mv5i 6W+aL3q9njkS1i/pwuvUSTrfQJOUF0V2wFnGVP7oqJiaJqB2mdkOgfbz09i34b1kmVFT uhBNRDJdU0KSYy4nTnnAteqoR3mRnhxogwstq23XiiNUPbbU2ERAh5zW0HAaIvOzh+HB qppA== X-Received: by 10.70.100.229 with SMTP id fb5mr18432454pdb.126.1413986722530; Wed, 22 Oct 2014 07:05:22 -0700 (PDT) Received: from [192.168.1.101] ([114.62.206.86]) by mx.google.com with ESMTPSA id p1sm14434431pds.80.2014.10.22.07.05.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 07:05:21 -0700 (PDT) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: "lizho.jin@gmail.com" X-Mailer: iPad Mail (12A405) In-Reply-To: <5447B18C.7050109@joelhalpern.com> Date: Wed, 22 Oct 2014 22:05:16 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6088D699-48F9-4CE1-BA02-D65D1A4777C9@gmail.com> References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com> <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> <5447B18C.7050109@joelhalpern.com> To: Joel Halpern Direct Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0p8wgjuY-kaEyGe3Pr7AEAzOenI Cc: "mpls@ietf.org" , "gen-art@ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply.all" , "ietf@ietf.org" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:06:28 -0000 Joel, thank you for the review. We will send out a new version soon to refle= ct the discussion. Regards Lizhong=20 > =D4=DA 2014=C4=EA10=D4=C222=C8=D5=A3=AC=CF=C2=CE=E79:30=A3=ACJoel Halpern D= irect wrote=A3=BA >=20 > It would be good to see a revision that clearly spelled out what the > draft was solving, how the initial end-point knew what to create, and > how the responder knew what to use. It may well be that there is an > effective solution to the problems here. I look forward to seeing it in > writing. >=20 > Yours, > Joel >=20 >> On 10/22/14, 12:46 AM, Lizhong Jin wrote: >> Hi Joel, >> The things may not be that bad. You could add a second address (address B= in >> our example) with K bit set. The address entry with K bit set must be as a= >> relay node, and could not be skipped. >> Section 4.4 should be changed to: Find the first routable address A, and t= he >> first address B with K bit set. If address A is before address B in the >> stack, then use address B as the relay address. Otherwise, use address A a= s >> the relay address. >> In that case, if A is the private address, the packet will be firstly >> relayed to address B. And address A and B belong to one router. Here I >> assume one router at least has one routable address for another AS. >>=20 >> Regards >> Lizhong >>=20 >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: 2014=C4=EA10=D4=C222=C8=D5 11:14 >>> To: Lizhong Jin >>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >> 'draft-ietf-mpls-lsp-ping- >>> relay-reply.all' >>> Subject: Re: [mpls] [Gen-art] review: >> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>=20 >>> ou are saying that this is only for the case where an AS is using public= >>> addresses for its internal numbering, but is not distributing that addre= ss >> block >>> externally? >>>=20 >>> If so, you need to state that very clearly. >>> I believe a far more common case is one where the numbering is from a >>> portion of a publicly allocated space, but firewalled. Which would >> produce >>> the same problem, but would not be amenable to this solution. >>> And it is well known that many ISPs do internal number assignment from >>> private blocks. >>>=20 >>> So what you are now saying is that this draft solves a very small portio= n >> of the >>> problem? But it works for that small portion? If so, at the very least= >> you >>> need to be VERY clear about what cases this works for and what cases it >> does >>> not. And I fear that even if you are clear, it is going to be very >> confusing for >>> folks who are trying to use it. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 10/21/14, 10:51 PM, Lizhong Jin wrote: >>>> Hi Joel, >>>> I now see your concern. The "private" word in draft is not correct, I >>>> will remove it. The original motivation of "draft-relay-reply" is from >>>> the scenario where IP address distribution is restricted among AS or IG= P >>> area. >>>> And the IP address is not private address. As I know, most deployed >>>> inter-AS or inter-area MPLS LSP is in the network without private IP >> address. >>>>=20 >>>> Regards >>>> Lizhong >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: 2014=C4=EA10=D4=C222=C8=D5 10:15 >>>>> To: Lizhong Jin >>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >>>> 'draft-ietf-mpls-lsp-ping- >>>>> relay-reply.all' >>>>> Subject: Re: [mpls] [Gen-art] review: >>>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>>>=20 >>>>> The problem is that the original source A, that we are trying to >>>>> reach >>>> with a >>>>> reply, has an address that appears to the responder X to be routable. >>>>> But the destination that is reached by that address is either a black >>>>> hole or >>>> some >>>>> other entity using the same address. >>>>>=20 >>>>> The reason for the duplication is that, as described in the draft, >>>>> the >>>> source >>>>> address for A is a private address. That same address may well be >>>> reachable >>>>> according to the routing table at X. But it won't get to A. >>>>>=20 >>>>> If the problem is something other than private addressing preventing >>>>> reachability, it is likely there is still a mistaken routability >>>>> problem, >>>> but I can >>>>> not illustrate the failure without some other case being described. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 10/21/14, 10:06 PM, Lizhong Jin wrote: >>>>>> Inline, thanks. >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Sent: 2014=C4=EA10=D4=C222=C8=D5 0:06 >>>>>>> To: lizho.jin@gmail.com >>>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; >>>>>> draft-ietf-mpls-lsp-ping- >>>>>>> relay-reply.all >>>>>>> Subject: Re: [mpls] [Gen-art] review: >>>>>> draft-ietf-mpls-lsp-ping-relay-reply-04 >>>>>>>=20 >>>>>>> In line. >>>>>>>=20 >>>>>>>> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: >>>>>>>> Hi Joel, see inline below, thanks. >>>>>>>>=20 >>>>>>>> Lizhong >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern >>> wrote =A3=BA >>>>>>>>>=20 >>>>>>>>> If the process for this draft is to use the top address that can >>>>>>>>> be reached in the routing table, then there is a significant >>>>>>>>> probability that the original source address, which is always at >>>>>>>>> the top of the list, will be used. As such, the intended problem >>>>>>>>> will not be solved. >>>>>>>> [Lizhong] let me give an example to explain: the source address A >>>>>>>> is firstly added to the stack, then a second routable address B >>>>>>>> for replying AS is also added. The reply node will not use address >>>>>>>> A since it's not routable, then it will use address B. So it will >>>>>>>> work and I don't see the problem. >>>>>>>=20 >>>>>>> The whole point of this relay mechanism, as I understand it, is to >>>>>>> cope >>>>>> with >>>>>>> the case when the responder X can not actually reach the source A. >>>>>>> Now suppose that the packet arrives at X with the Address stack >>>>>>> A, B, >>>> ... >>>>>> X >>>>>>> examines the stack. The domain of A was numbered using net 10. >>>>>>> The domain of X is numbered using net 10. A's address is probably >>>>>> routable >>>>>>> in X's routing table. The problem is, that routing will not get to >>>>>>> A. X >>>>>> examines >>>>>>> the stack, determines that A is "routable", and sends the packet. >>>>>>> This >>>>>> fails to >>>>>>> meet the goal. >>>>>> [Lizhong] The source A you are referring is the initiator, right? >>>>>> The goal of relay mechanism is to reach the initiator. If X is >>>>>> routable to the initiator (address A), then it is great, other relay >>>>>> node in the stack will be skipped. >>>>>> If the source A you are referring is the interface address of one >>>>>> intermediate node, then I do not understand "routing will not get to >>>>>> A. X examines the stack, determines that A is "routable", and sends >>>>>> the >>>>> packet". >>>>>> Why routing will not get to A, but A is routable? >>>>>>=20 >>>>>> Regards >>>>>> Lizhong >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>=20 From nobody Wed Oct 22 08:18:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005061ACD69 for ; Wed, 22 Oct 2014 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtGALKuhKXRV for ; Wed, 22 Oct 2014 08:17:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACD81ACD5C for ; Wed, 22 Oct 2014 08:17:47 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2F1A518013BE; Wed, 22 Oct 2014 17:17:45 +0200 (CEST) Message-ID: <5447CA9C.2070108@pi.nu> Date: Wed, 22 Oct 2014 17:17:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mach Chen , "Nobo Akiya (nobo)" , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vcuSvQ5WZSc32uuoHBUjZyyNDKY Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:18:06 -0000 Nobo, I'm a bit behind on this, but I've read now and is OK with the change. /Loa On 2014-10-22 03:19, Mach Chen wrote: > Hi Nobo, > > I am fine with this change. > > Best regards, > Mach > >> -----Original Message----- >> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] >> Sent: Wednesday, October 22, 2014 5:53 AM >> To: Mach Chen; Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> Cc: Ross Callon (rcallon@juniper.net); >> draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; >> draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org >> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt >> >> Hi Mach, >> >>> -----Original Message----- >>> From: Mach Chen [mailto:mach.chen@huawei.com] >>> Sent: Tuesday, October 21, 2014 4:43 AM >>> To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org >>> Cc: Ross Callon (rcallon@juniper.net); >>> draft-ietf-mpls-lsp-ping-reply-mode- >>> simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- >>> ping@tools.ietf.org >>> Subject: RE: [mpls] I-D Action: >>> draft-ietf-mpls-lsp-ping-reply-mode-simple- >>> 00.txt >>> >>> Hi Nobo and Mustapha, >>> >>> I think this may not just require minor changes to RFC7110, it at >>> least >>> requires: >>> >>> 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and >>> >>> 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with B >>> bit >>> set) to notify along reverse direction of the tested LSP; >>> >>> Given there may be existing implementations and the original proposal >>> (defined in RFC7110) works and does not require too much process cost, >>> I incline to leave it as is and suggest not to define the new >>> dedicated reply mode as well. >> >> For backwards compatibility sake, we should preserve (2). Thus only change >> required is (1) which is a fairly small change. With this direction, what do you >> think? >> >> Thanks! >> >> -Nobo >> >>> >>> Best regards, >>> Mach >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya >>>> (nobo) >>>> Sent: Monday, October 20, 2014 4:48 AM >>>> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >>>> Cc: Ross Callon (rcallon@juniper.net); >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; >>>> draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org >>>> Subject: Re: [mpls] I-D Action: >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt >>>> >>>> MPLS WG, >>>> >>>> Many thanks for kicking this off Mustapha. >>>> >>>> I, for one, like Mustaphas suggestion and would be supportive of >>>> making that change. I would also be happy to change >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect this >>>> change, if there are consensus to do so. >>>> >>>> I have cc'ed the authors of RFC7110 in case they can also chime in >>>> with >>> thoughts. >>>> >>>> Additionally, suggested changes should be very minimal even to those >>>> who has already implemented RC7110. However, if anybody has >>>> implemented and if anybody has concerns, I think this is a great >>>> time for to >>> speak up. >>>> >>>> Thanks! >>>> >>>> -Nobo >>>> >>>>> -----Original Message----- >>>>> From: Aissaoui, Mustapha (Mustapha) >>>>> [mailto:mustapha.aissaoui@alcatel- >>>>> lucent.com] >>>>> Sent: Friday, October 17, 2014 6:19 PM >>>>> To: Nobo Akiya (nobo); mpls@ietf.org >>>>> Cc: Ross Callon (rcallon@juniper.net) >>>>> Subject: RE: [mpls] I-D Action: >>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple- >>>>> 00.txt >>>>> >>>>> Dear all, >>>>> This is a follow-up to the action below from the MPLS-RT review of >>>>> this >>> draft. >>>>> >>>>> Instead of defining a new reply mode as proposed in Section 3.1 of >>>>> the draft, I suggested to relax the rule in RFC 7110 such that if >>>>> the echo request includes reply mode 5 "Reply via Specified Path" >>>>> and the Reply Path TLV was not included, the responder node will >>>>> interpret this as an implicit request to reply via the reverse >>>>> direction of >>> the tested LSP. >>>>> >>>>> This approach would address the requirement that the sender be >>>>> able of requesting the reply via the reverse path of an LSP >>>>> without having to include an additional TLV. >>>>> >>>>> I appreciate comments on this proposal. >>>>> >>>>> Regards, >>>>> Mustapha. >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo >>>>>> Akiya >>>>>> (nobo) >>>>>> Sent: Saturday, September 06, 2014 9:59 AM >>>>>> To: mpls@ietf.org >>>>>> Cc: Ross Callon (rcallon@juniper.net) >>>>>> Subject: Re: [mpls] I-D Action: >>>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt >>>>>> >>>>>> Thank you Ross and the WG. >>>>>> >>>>>> We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as >>>>>> draft-ietf-mpls- lsp-ping-reply-mode-simple-00. >>>>>> >>>>>> Authors would like the WG help to discuss and close off on these >>>>>> two >>>>> aspects: >>>>>> >>>>>> - From Bruno Decraene: Reply Mode for SPRING and applicability of >>>>> this >>>>>> document. >>>>>> o There's already a thread for this. >>>>>> - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by >>>>>> RFC7110 instead of defining a new Reply Mode for Reverse LSP. >>>>>> o Mustapha or myself will start a thread on this topic later. >>>>>> >>>>>> Once above are close off, then we will roll out -01 that includes: >>>>>> >>>>>> - Conclusion from the two aspects above. >>>>>> - A comment received from Tarek Saad. >>>>>> - Comments received from Lou Berger (will reply to the review >>>>> comments >>>>>> from Lou soon) >>>>>> >>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- >>>>> reply-mode- >>>>>> simple-00.txt >>>>>> Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- >>>>> mode- >>>>>> simple/ >>>>>> Htmlized: >> http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- >>>>> mode-simple-00 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -Nobo, on behalf of authors >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of >>>>>>> internet- drafts@ietf.org >>>>>>> Sent: Saturday, September 06, 2014 3:41 AM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: [mpls] I-D Action: >>>>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple- >>>>>>> 00.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>> This draft is a work item of the Multiprotocol Label >>>>>>> Switching Working Group of the IETF. >>>>>>> >>>>>>> Title : Label Switched Path (LSP) Ping/Traceroute >>>> Reply Mode >>>>>>> Simplification >>>>>>> Authors : Nobo Akiya >>>>>>> George Swallow >>>>>>> Carlos Pignataro >>>>>>> Loa Andersson >>>>>>> Mach(Guoyi) Chen >>>>>>> Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt >>>>>>> Pages : 11 >>>>>>> Date : 2014-09-05 >>>>>>> >>>>>>> Abstract: >>>>>>> The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) >>>>>>> Ping and Traceroute use the Reply Mode field to signal the >>>>>>> method >>> to >>>>>>> be used in the MPLS echo reply. This document adds one >>>>>>> value to >>> the >>>>>>> Reply Mode field to indicate reverse LSP. This document >>>>>>> also adds >>> an >>>>>>> optional TLV which can carry ordered list of Reply Mode values. >>>>>>> >>>>>>> This document updates RFC4379. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-repl >>>>>>> y- >>>>>>> mo >>>>>>> de >>>>>>> - >>>>>>> simple/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode >>>>>>> -s >>>>>>> im >>>>>>> pl >>>>>>> e- >>>>>>> 00 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time >>>>>>> of submission until the htmlized version and diff are >>>>>>> available at >>>>> tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Oct 22 10:09:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505731ACE4E for ; Wed, 22 Oct 2014 10:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vbdt6qP_NzM for ; Wed, 22 Oct 2014 10:09:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6AC1ACE49 for ; Wed, 22 Oct 2014 10:09:52 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 17:09:29 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.142]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.142]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 17:09:29 +0000 From: Ronald Bonica To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-bonica-mpls-self-ping-01.txt Thread-Index: AQHP7hnnLnoytDI040KX4YDibKcrc5w8V7aA Date: Wed, 22 Oct 2014 17:09:28 +0000 Message-ID: References: <20141022170156.19414.79472.idtracker@ietfa.amsl.com> In-Reply-To: <20141022170156.19414.79472.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377424004)(377454003)(51704005)(199003)(120916001)(64706001)(2656002)(15202345003)(19580395003)(76576001)(2351001)(2501002)(99396003)(101416001)(19580405001)(106356001)(107046002)(46102003)(77096002)(87936001)(86362001)(85306004)(99286002)(107886001)(110136001)(76482002)(106116001)(40100003)(230783001)(15975445006)(108616004)(21056001)(92566001)(66066001)(33646002)(20776003)(31966008)(80022003)(4396001)(97736003)(122556002)(76176999)(85852003)(105586002)(95666004)(50986999)(74316001)(54356999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ddWqIEd9XQidMItww08DbpvEqic Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:09:55 -0000 Rm9sa3MsDQoNClBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGlzIHVwZGF0ZWQgZHJhZnQgdmVyc2lv bi4gSXQgYWRkcmVzc2VzIG1hbnkgb2YgdGhlIGNvbW1lbnRzIHBvc3RlZCBvbiB0aGUgbGlzdC4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTQgMTowMiBQTQ0KPiBUbzogUm9uYWxkIEJvbmljYTsgRVhU IC0gbHVpcy50b21vdGFraUB2ZXJpem9uLmNvbTsgUmF2ZWVuZHJhIFRvcnZpOw0KPiBNaWNoYWVs IENvbm47IFJhdmVlbmRyYSBUb3J2aTsgRGFudGUgUGFjZWxsYTsgUm9uYWxkIEJvbmljYTsgRVhU IC0NCj4gbWFyay53eWdhbnRAdmVyaXpvbi5jb207IEVYVCAtIGx1aXMudG9tb3Rha2lAdmVyaXpv bi5jb207IE1pY2hhZWwgQ29ubjsNCj4gRGFudGUgUGFjZWxsYTsgRVhUIC0gbWFyay53eWdhbnRA dmVyaXpvbi5jb20NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1ib25pY2EtbXBscy1zZWxmLXBpbmctMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZy0wMS50eHQNCj4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb24gQm9uaWNhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYN Cj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1ib25pY2EtbXBscy1zZWxmLXBpbmcN Cj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJTFNQIFNlbGYtUGluZw0KPiBEb2N1bWVudCBkYXRl OgkyMDE0LTEwLTIyDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJ OA0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nLQ0KPiAwMS50eHQNCj4gU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvbmljYS1tcGxzLXNlbGYt cGluZy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJvbmljYS1tcGxzLXNlbGYtcGluZy0wMQ0KPiBEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nLTAxDQo+IA0K PiBBYnN0cmFjdDoNCj4gICAgVGhpcyBtZW1vIGRlc2NyaWJlcyBMU1AgU2VsZi1waW5nLiAgSW5n cmVzcyBMU1IncyBjYW4gdXNlIExTUCBTZWxmLQ0KPiAgICBwaW5nIHRvIHZlcmlmeSB0aGF0IGFu IExTUCBpcyByZWFkeSB0byBjYXJyeSB0cmFmZmljLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Wed Oct 22 16:46:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19FC1A87CE; Wed, 22 Oct 2014 16:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1iypf2vUblb; Wed, 22 Oct 2014 16:46:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A15391A87AF; Wed, 22 Oct 2014 16:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022234622.19592.50599.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 16:46:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WThGAAsELwmU7eAfYFzQKmPFk_E Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:46:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) Authors : Nobo Akiya George Swallow Carlos Pignataro Andrew G. Malis Sam Aldrin Filename : draft-akiya-mpls-entropy-lsp-ping-03.txt Pages : 21 Date : 2014-10-22 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal-Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when EL based LSP is stitched with another LSP which can be EL based or non-EL based. This document extends the MPLS LSP Ping and Traceroute mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of Entropy Label. This document updates RFC4379, RFC6424 and RFC6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-entropy-lsp-ping-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 Oct 22 16:47:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349461A87E9; Wed, 22 Oct 2014 16:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9ZrqN0whiqb; Wed, 22 Oct 2014 16:47:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A649D1A87CC; Wed, 22 Oct 2014 16:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022234754.32618.40326.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 16:47:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HZkYbSjz87XEHjL4no3Cx7wxrtI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:47:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Filename : draft-akiya-mpls-lsp-ping-lag-multipath-02.txt Pages : 20 Date : 2014-10-22 Abstract: This document defines an extension to the Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to describe Multipath Information for Link Aggregation (LAG) member links separately, thus allowing MPLS LSP Ping and Traceroute to discover and exercise specific paths of layer 2 (L2) Equal-Cost Multipath (ECMP) over LAG interfaces. This document updates RFC4379 and RFC6424. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-lag-multipath-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 Wed Oct 22 16:50:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40BF1A8822 for ; Wed, 22 Oct 2014 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bseJ3OR7gEpB for ; Wed, 22 Oct 2014 16:50:43 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 B08E51A6F2F for ; Wed, 22 Oct 2014 16:50:39 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id D38B2FE76C769; Wed, 22 Oct 2014 23:50:35 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s9MNocBF031496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 19:50:38 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 19:50:38 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: Mach Chen , "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX4OkhgWsQGIUeAKGjjOVb0U5v0ZR+AgDvz/2CACBKiAIACWiCAgADclACAADmjgIABMfsw Date: Wed, 22 Oct 2014 23:50:37 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D9477F433@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5e5ElbbXQ4UPQSCzXYUgnba71Wo Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:50:50 -0000 Hi Mach and Nobo, Just to be sure we are in sync. You are suggesting that the sender of the e= cho request can use two methods to request that the reply use the reverse p= ath of the tested LSP: 1. The explicit one in RFC 7110 which includes the reply path TLV with the = B-bit but with no additional sub-TLVs and requests the reply mode 5 "Reply = via Specified Path". The echo reply message must include the reply TLV. 2. The relaxed one, which is implicit, and which does not include the reply= path TLV and requests the same reply mode 5. Since there is no path reply = TLV in the echo request, the echo reply will also not contain an reply TLV.= In this case the sender node knows the relationship between the two direct= ions of the LSP and will know if the reply was successfully received in the= reverse direction without the replying node explicitly stating it.=20 If that is the case, then I agree. Regards, Mustapha. > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Tuesday, October 21, 2014 9:19 PM > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); draft-ietf-mpls-lsp-ping-reply-mod= e- > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp-ping@too= ls.ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e-00.txt >=20 > Hi Nobo, >=20 > I am fine with this change. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Wednesday, October 22, 2014 5:53 AM > > To: Mach Chen; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net); > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > Subject: RE: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > Hi Mach, > > > > > -----Original Message----- > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > Sent: Tuesday, October 21, 2014 4:43 AM > > > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Cc: Ross Callon (rcallon@juniper.net); > > > draft-ietf-mpls-lsp-ping-reply-mode- > > > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > > > ping@tools.ietf.org > > > Subject: RE: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > 00.txt > > > > > > Hi Nobo and Mustapha, > > > > > > I think this may not just require minor changes to RFC7110, it at > > > least > > > requires: > > > > > > 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and > > > > > > 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with > > > B bit > > > set) to notify along reverse direction of the tested LSP; > > > > > > Given there may be existing implementations and the original > > > proposal (defined in RFC7110) works and does not require too much > > > process cost, I incline to leave it as is and suggest not to define > > > the new dedicated reply mode as well. > > > > For backwards compatibility sake, we should preserve (2). Thus only > > change required is (1) which is a fairly small change. With this > > direction, what do you think? > > > > Thanks! > > > > -Nobo > > > > > > > > Best regards, > > > Mach > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > > > (nobo) > > > > Sent: Monday, October 20, 2014 4:48 AM > > > > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > Cc: Ross Callon (rcallon@juniper.net); > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > > > Subject: Re: [mpls] I-D Action: > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > MPLS WG, > > > > > > > > Many thanks for kicking this off Mustapha. > > > > > > > > I, for one, like Mustaphas suggestion and would be supportive of > > > > making that change. I would also be happy to change > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect > > > > this change, if there are consensus to do so. > > > > > > > > I have cc'ed the authors of RFC7110 in case they can also chime in > > > > with > > > thoughts. > > > > > > > > Additionally, suggested changes should be very minimal even to > > > > those who has already implemented RC7110. However, if anybody has > > > > implemented and if anybody has concerns, I think this is a great > > > > time for to > > > speak up. > > > > > > > > Thanks! > > > > > > > > -Nobo > > > > > > > > > -----Original Message----- > > > > > From: Aissaoui, Mustapha (Mustapha) > > > > > [mailto:mustapha.aissaoui@alcatel- > > > > > lucent.com] > > > > > Sent: Friday, October 17, 2014 6:19 PM > > > > > To: Nobo Akiya (nobo); mpls@ietf.org > > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > > Subject: RE: [mpls] I-D Action: > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > 00.txt > > > > > > > > > > Dear all, > > > > > This is a follow-up to the action below from the MPLS-RT review > > > > > of this > > > draft. > > > > > > > > > > Instead of defining a new reply mode as proposed in Section 3.1 > > > > > of the draft, I suggested to relax the rule in RFC 7110 such > > > > > that if the echo request includes reply mode 5 "Reply via Specifi= ed Path" > > > > > and the Reply Path TLV was not included, the responder node will > > > > > interpret this as an implicit request to reply via the reverse > > > > > direction of > > > the tested LSP. > > > > > > > > > > This approach would address the requirement that the sender be > > > > > able of requesting the reply via the reverse path of an LSP > > > > > without having to include an additional TLV. > > > > > > > > > > I appreciate comments on this proposal. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > > > > > > > -----Original Message----- > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo > > > > > > Akiya > > > > > > (nobo) > > > > > > Sent: Saturday, September 06, 2014 9:59 AM > > > > > > To: mpls@ietf.org > > > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > > > Subject: Re: [mpls] I-D Action: > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > > > > > Thank you Ross and the WG. > > > > > > > > > > > > We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 > > > > > > as > > > > > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > > > > > > > > > Authors would like the WG help to discuss and close off on > > > > > > these two > > > > > aspects: > > > > > > > > > > > > - From Bruno Decraene: Reply Mode for SPRING and applicability = of > > > > > this > > > > > > document. > > > > > > o There's already a thread for this. > > > > > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced b= y > > > > > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > > > > > o Mustapha or myself will start a thread on this topic later. > > > > > > > > > > > > Once above are close off, then we will roll out -01 that includ= es: > > > > > > > > > > > > - Conclusion from the two aspects above. > > > > > > - A comment received from Tarek Saad. > > > > > > - Comments received from Lou Berger (will reply to the review > > > > > comments > > > > > > from Lou soon) > > > > > > > > > > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > > > > > reply-mode- > > > > > > simple-00.txt > > > > > > Status: > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > > > > mode- > > > > > > simple/ > > > > > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- > > > > > mode-simple-00 > > > > > > > > > > > > Thanks! > > > > > > > > > > > > -Nobo, on behalf of authors > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > > > > > > internet- drafts@ietf.org > > > > > > > Sent: Saturday, September 06, 2014 3:41 AM > > > > > > > To: i-d-announce@ietf.org > > > > > > > Cc: mpls@ietf.org > > > > > > > Subject: [mpls] I-D Action: > > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > > > 00.txt > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > Internet-Drafts directories. > > > > > > > This draft is a work item of the Multiprotocol Label > > > > > > > Switching Working Group of the IETF. > > > > > > > > > > > > > > Title : Label Switched Path (LSP) Ping/Trac= eroute > > > > Reply Mode > > > > > > > Simplification > > > > > > > Authors : Nobo Akiya > > > > > > > George Swallow > > > > > > > Carlos Pignataro > > > > > > > Loa Andersson > > > > > > > Mach(Guoyi) Chen > > > > > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple= -00.txt > > > > > > > Pages : 11 > > > > > > > Date : 2014-09-05 > > > > > > > > > > > > > > Abstract: > > > > > > > The Multiprotocol Label Switching (MPLS) Label Switched Pa= th (LSP) > > > > > > > Ping and Traceroute use the Reply Mode field to signal > > > > > > > the method > > > to > > > > > > > be used in the MPLS echo reply. This document adds one > > > > > > > value to > > > the > > > > > > > Reply Mode field to indicate reverse LSP. This document > > > > > > > also adds > > > an > > > > > > > optional TLV which can carry ordered list of Reply Mode va= lues. > > > > > > > > > > > > > > This document updates RFC4379. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-re > > > > > > > pl > > > > > > > y- > > > > > > > mo > > > > > > > de > > > > > > > - > > > > > > > simple/ > > > > > > > > > > > > > > There's also a htmlized version available at: > > > > > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mo > > > > > > > de > > > > > > > -s > > > > > > > im > > > > > > > pl > > > > > > > e- > > > > > > > 00 > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the > > > > > > > time of submission until the htmlized version and diff are > > > > > > > available at > > > > > tools.ietf.org. > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mpls mailing list > > > > > > > mpls@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > > > > mpls mailing list > > > > > > mpls@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 22 16:51:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA31A87E8; Wed, 22 Oct 2014 16:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qozrVGRMlhqo; Wed, 22 Oct 2014 16:51:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7961AD0A0; Wed, 22 Oct 2014 16:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2999; q=dns/txt; s=iport; t=1414021910; x=1415231510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mtaMLCNtrY57REHGFED39TDNJmWxrUdJxeMge9i6PXM=; b=dCSEyVo3kWhgeUNZjmmMuLBIo+p1MzkDPG03EaOzFnl3HfbLaGvrjK3m jUY2E2LdZkVgmqIEZj7EVDkSxhxZFoM0SPCc44k5O9/F1TNi8UsJKdXF1 VDU2JBOVxbtMWKycsqunp1UIGa//vIlBCD2fpUVFYNHMfbL8naM8x7Mg2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAARCSFStJV2S/2dsb2JhbABcgmsjVFMFBMxVCodNAoELFgF9hAIBAQEEAQEBCywrCQsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgBiDgBBwXFfAEBAQEBAQEBAQEBAQEBAQEBAQEBAReQJTEHBoMngR4Fj2eCHoRGiEM8gw2RM4N4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,772,1406592000"; d="scan'208";a="89505521" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 22 Oct 2014 23:51:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9MNpnPV014791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 23:51:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 18:51:49 -0500 From: "Nobo Akiya (nobo)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-03.txt Thread-Index: AQHP7lJp3OFcFIJntEmeWXBI4gwY+pw8ySrA Date: Wed, 22 Oct 2014 23:51:48 +0000 Message-ID: References: <20141022234622.19592.50599.idtracker@ietfa.amsl.com> In-Reply-To: <20141022234622.19592.50599.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zOeOWXVTvMHXuqs_tyFh4O9Jx3w Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:51:52 -0000 Hi MPLS WG, draft-decraene-mpls-lsp-ping-registry was recently published to create miss= ing LSP Ping/Trace registries. draft-akiya-mpls-entropy-lsp-ping was updated to point to draft-decraene-mp= ls-lsp-ping-registry. Thanks! -Nobo, on behalf of authors =09 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, October 22, 2014 7:46 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Label Switched Path (LSP) and Pseudowire (PW) P= ing/Trace > over MPLS Network using Entropy Labels (EL) > Authors : Nobo Akiya > George Swallow > Carlos Pignataro > Andrew G. Malis > Sam Aldrin > Filename : draft-akiya-mpls-entropy-lsp-ping-03.txt > Pages : 21 > Date : 2014-10-22 >=20 > Abstract: > The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) > Ping and Traceroute are used to exercise specific paths of Equal-Cost > Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) > described in RFC6790, the ability for LSP Ping and Traceroute > operation to discover and exercise ECMP paths has been lost in > scenarios which LSRs apply deviating load balance techniques. One > such scenario is when some LSRs apply EL based load balancing while > other LSRs apply non-EL based load balancing (ex: IP). Another > scenario is when EL based LSP is stitched with another LSP which can > be EL based or non-EL based. >=20 > This document extends the MPLS LSP Ping and Traceroute mechanisms to > restore the ability of exercising specific paths of ECMP over LSP > which make use of Entropy Label. This document updates RFC4379, > RFC6424 and RFC6790. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-lsp-ping/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-entropy-lsp-ping-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 22 16:52:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C044C1AD3EC for ; Wed, 22 Oct 2014 16:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMyrSaaA73et for ; Wed, 22 Oct 2014 16:52:24 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DEB1AD0A0 for ; Wed, 22 Oct 2014 16:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1414021944; x=1415231544; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K3o7niOLLE1EQRkU5kBwWjrAcb+6F5pT4IstR8xUPw8=; b=evHGwVT9XRifohgox+sZ4Oc4dvYDUoXxz0MQAMSPxkSN+paNBmyvQn2+ FSc2qBAf8flxAUKwV5KFe9k8kaV2ELyql931JiOa9AuOFkgNPhToEy4cu D+hqzl17fiuagimxuT9Flo2aHweeu2jVqH9i1J3D4B/kqR+481dJnFXAD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAARCSFStJA2F/2dsb2JhbABcgmsjVFMFBMxVDIdLAoELFgFyC4QCAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIOAEHBcV8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AlOAaDJ4EeBY9ngh6ERohDPIMNkTODeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,772,1406592000"; d="scan'208";a="89505637" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 22 Oct 2014 23:52:24 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9MNqOPm015215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Oct 2014 23:52:24 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 18:52:23 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-02.txt Thread-Index: AQHP7lKizgrg5KzDX0+QGsoWlHiLrJw8yabg Date: Wed, 22 Oct 2014 23:52:23 +0000 Message-ID: References: <20141022234754.32618.40326.idtracker@ietfa.amsl.com> In-Reply-To: <20141022234754.32618.40326.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YLlx-bohgHi-2F6ZvuHDuDteEC8 Subject: Re: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:52:26 -0000 Hi MPLS WG, draft-decraene-mpls-lsp-ping-registry was recently published to create miss= ing LSP Ping/Trace registries. draft-akiya-mpls-lsp-ping-lag-multipath was updated to point to draft-decra= ene-mpls-lsp-ping-registry. Thanks! -Nobo, on behalf of authors > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, October 22, 2014 7:48 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-02.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Label Switched Path (LSP) Ping/Trace Multipath = Support for > Link Aggregation Group (LAG) Interfaces > Authors : Nobo Akiya > George Swallow > Stephane Litkowski > Bruno Decraene > John E. Drake > Filename : draft-akiya-mpls-lsp-ping-lag-multipath-02.txt > Pages : 20 > Date : 2014-10-22 >=20 > Abstract: > This document defines an extension to the Multiprotocol Label > Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to > describe Multipath Information for Link Aggregation (LAG) member > links separately, thus allowing MPLS LSP Ping and Traceroute to > discover and exercise specific paths of layer 2 (L2) Equal-Cost > Multipath (ECMP) over LAG interfaces. >=20 > This document updates RFC4379 and RFC6424. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-ping-lag-multipat= h- > 02 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Oct 22 17:06:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8D1A87E2 for ; Wed, 22 Oct 2014 17:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q29rqixmXnB for ; Wed, 22 Oct 2014 17:06:43 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3675A1AD426 for ; Wed, 22 Oct 2014 17:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10536; q=dns/txt; s=iport; t=1414022803; x=1415232403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DaDP7JbcmpPHSOfDYmuG0kcrXS+jrxN/RxrGHvRlyek=; b=mFTdAvEW/waTsCsI6ZrMBKOgv6lDHpPjd27oMERplzrC/0JjNa1Uf0rm cckVoFKsEAoju02vd10zeUpropLOzFvVEJ01SXouCHJH+WBebo2Fkyu8S jzvNtbyevgNWpUIsuk7wm61zjWJJXsPbBs8npOOUndG1fwXBVj41+h/91 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIpFSFStJA2K/2dsb2JhbABcgmsjVFgEzFUKh00CgQsWAX2EAgEBAQQBAQE3MQMLDAICAgEIEQQBAQEKFAkHGwwLFAkIAgQBDQUIAYg4AQzFXQEBAQEBAQEBAQEBAQEBAQEBAQEBARcEilGFHxEBHzEHBoMngR4Fj2eCHoRGiEM8gw2DLYoFhAGDeGyBDzmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,772,1406592000"; d="scan'208";a="89513374" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 23 Oct 2014 00:06:42 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9N06g7V018633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 00:06:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 19:06:41 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , Mach Chen , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0IawwgEFPqICAArRj8IACsOyAgACHbwCAAI7IgIAA6lgAgAA/1KA= Date: Thu, 23 Oct 2014 00:06:40 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> <5447CA9C.2070108@pi.nu> In-Reply-To: <5447CA9C.2070108@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9bdhMPOqvWWU_57zR3LlRwdwhWI Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 00:06:47 -0000 Hi Loa, Thanks for chiming in and voicing your opinion. Thanks! -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, October 22, 2014 11:18 AM > To: Mach Chen; Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); > mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); draft-ietf-mpls-return-path- > specified-lsp-ping@tools.ietf.org; draft-ietf-mpls-lsp-ping-reply-mode- > simple@tools.ietf.org > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e- > 00.txt >=20 > Nobo, >=20 > I'm a bit behind on this, but I've read now and is OK with the change. >=20 > /Loa >=20 > On 2014-10-22 03:19, Mach Chen wrote: > > Hi Nobo, > > > > I am fine with this change. > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > >> Sent: Wednesday, October 22, 2014 5:53 AM > >> To: Mach Chen; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > >> Cc: Ross Callon (rcallon@juniper.net); > >> draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > >> draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > >> Subject: RE: [mpls] I-D Action: > >> draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > >> > >> Hi Mach, > >> > >>> -----Original Message----- > >>> From: Mach Chen [mailto:mach.chen@huawei.com] > >>> Sent: Tuesday, October 21, 2014 4:43 AM > >>> To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > >>> Cc: Ross Callon (rcallon@juniper.net); > >>> draft-ietf-mpls-lsp-ping-reply-mode- > >>> simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > >>> ping@tools.ietf.org > >>> Subject: RE: [mpls] I-D Action: > >>> draft-ietf-mpls-lsp-ping-reply-mode-simple- > >>> 00.txt > >>> > >>> Hi Nobo and Mustapha, > >>> > >>> I think this may not just require minor changes to RFC7110, it at > >>> least > >>> requires: > >>> > >>> 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and > >>> > >>> 2) deprecate the explicit way (a Reply TLV without sub-TLVs and with > >>> B bit > >>> set) to notify along reverse direction of the tested LSP; > >>> > >>> Given there may be existing implementations and the original > >>> proposal (defined in RFC7110) works and does not require too much > >>> process cost, I incline to leave it as is and suggest not to define > >>> the new dedicated reply mode as well. > >> > >> For backwards compatibility sake, we should preserve (2). Thus only > >> change required is (1) which is a fairly small change. With this > >> direction, what do you think? > >> > >> Thanks! > >> > >> -Nobo > >> > >>> > >>> Best regards, > >>> Mach > >>> > >>>> -----Original Message----- > >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > >>>> (nobo) > >>>> Sent: Monday, October 20, 2014 4:48 AM > >>>> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > >>>> Cc: Ross Callon (rcallon@juniper.net); > >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > >>>> draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > >>>> Subject: Re: [mpls] I-D Action: > >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > >>>> > >>>> MPLS WG, > >>>> > >>>> Many thanks for kicking this off Mustapha. > >>>> > >>>> I, for one, like Mustaphas suggestion and would be supportive of > >>>> making that change. I would also be happy to change > >>>> draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect this > >>>> change, if there are consensus to do so. > >>>> > >>>> I have cc'ed the authors of RFC7110 in case they can also chime in > >>>> with > >>> thoughts. > >>>> > >>>> Additionally, suggested changes should be very minimal even to > >>>> those who has already implemented RC7110. However, if anybody has > >>>> implemented and if anybody has concerns, I think this is a great > >>>> time for to > >>> speak up. > >>>> > >>>> Thanks! > >>>> > >>>> -Nobo > >>>> > >>>>> -----Original Message----- > >>>>> From: Aissaoui, Mustapha (Mustapha) > >>>>> [mailto:mustapha.aissaoui@alcatel- > >>>>> lucent.com] > >>>>> Sent: Friday, October 17, 2014 6:19 PM > >>>>> To: Nobo Akiya (nobo); mpls@ietf.org > >>>>> Cc: Ross Callon (rcallon@juniper.net) > >>>>> Subject: RE: [mpls] I-D Action: > >>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple- > >>>>> 00.txt > >>>>> > >>>>> Dear all, > >>>>> This is a follow-up to the action below from the MPLS-RT review of > >>>>> this > >>> draft. > >>>>> > >>>>> Instead of defining a new reply mode as proposed in Section 3.1 of > >>>>> the draft, I suggested to relax the rule in RFC 7110 such that if > >>>>> the echo request includes reply mode 5 "Reply via Specified Path" > >>>>> and the Reply Path TLV was not included, the responder node will > >>>>> interpret this as an implicit request to reply via the reverse > >>>>> direction of > >>> the tested LSP. > >>>>> > >>>>> This approach would address the requirement that the sender be > >>>>> able of requesting the reply via the reverse path of an LSP > >>>>> without having to include an additional TLV. > >>>>> > >>>>> I appreciate comments on this proposal. > >>>>> > >>>>> Regards, > >>>>> Mustapha. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo > Akiya > >>>>>> (nobo) > >>>>>> Sent: Saturday, September 06, 2014 9:59 AM > >>>>>> To: mpls@ietf.org > >>>>>> Cc: Ross Callon (rcallon@juniper.net) > >>>>>> Subject: Re: [mpls] I-D Action: > >>>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > >>>>>> > >>>>>> Thank you Ross and the WG. > >>>>>> > >>>>>> We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as > >>>>>> draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > >>>>>> > >>>>>> Authors would like the WG help to discuss and close off on these > >>>>>> two > >>>>> aspects: > >>>>>> > >>>>>> - From Bruno Decraene: Reply Mode for SPRING and > applicability of > >>>>> this > >>>>>> document. > >>>>>> o There's already a thread for this. > >>>>>> - From Mustapha Aissaoui: Relaxing of Reply Mode 5 > introduced by > >>>>>> RFC7110 instead of defining a new Reply Mode for Reverse LSP. > >>>>>> o Mustapha or myself will start a thread on this topic later. > >>>>>> > >>>>>> Once above are close off, then we will roll out -01 that includes: > >>>>>> > >>>>>> - Conclusion from the two aspects above. > >>>>>> - A comment received from Tarek Saad. > >>>>>> - Comments received from Lou Berger (will reply to the > review > >>>>> comments > >>>>>> from Lou soon) > >>>>>> > >>>>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > >>>>> reply-mode- > >>>>>> simple-00.txt > >>>>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > >>>>> mode- > >>>>>> simple/ > >>>>>> Htmlized: > >> http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- > >>>>> mode-simple-00 > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> -Nobo, on behalf of authors > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > >>>>>>> internet- drafts@ietf.org > >>>>>>> Sent: Saturday, September 06, 2014 3:41 AM > >>>>>>> To: i-d-announce@ietf.org > >>>>>>> Cc: mpls@ietf.org > >>>>>>> Subject: [mpls] I-D Action: > >>>>>>> draft-ietf-mpls-lsp-ping-reply-mode-simple- > >>>>>>> 00.txt > >>>>>>> > >>>>>>> > >>>>>>> A New Internet-Draft is available from the on-line > >>>>>>> Internet-Drafts directories. > >>>>>>> This draft is a work item of the Multiprotocol Label Switching > >>>>>>> Working Group of the IETF. > >>>>>>> > >>>>>>> Title : Label Switched Path (LSP) Ping/Tracero= ute > >>>> Reply Mode > >>>>>>> Simplification > >>>>>>> Authors : Nobo Akiya > >>>>>>> George Swallow > >>>>>>> Carlos Pignataro > >>>>>>> Loa Andersson > >>>>>>> Mach(Guoyi) Chen > >>>>>>> Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple- > 00.txt > >>>>>>> Pages : 11 > >>>>>>> Date : 2014-09-05 > >>>>>>> > >>>>>>> Abstract: > >>>>>>> The Multiprotocol Label Switching (MPLS) Label Switched Path > (LSP) > >>>>>>> Ping and Traceroute use the Reply Mode field to signal the > >>>>>>> method > >>> to > >>>>>>> be used in the MPLS echo reply. This document adds one > >>>>>>> value to > >>> the > >>>>>>> Reply Mode field to indicate reverse LSP. This document > >>>>>>> also adds > >>> an > >>>>>>> optional TLV which can carry ordered list of Reply Mode value= s. > >>>>>>> > >>>>>>> This document updates RFC4379. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The IETF datatracker status page for this draft is: > >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-repl > >>>>>>> y- > >>>>>>> mo > >>>>>>> de > >>>>>>> - > >>>>>>> simple/ > >>>>>>> > >>>>>>> There's also a htmlized version available at: > >>>>>>> http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode > >>>>>>> -s > >>>>>>> im > >>>>>>> pl > >>>>>>> e- > >>>>>>> 00 > >>>>>>> > >>>>>>> > >>>>>>> Please note that it may take a couple of minutes from the time > >>>>>>> of submission until the htmlized version and diff are available > >>>>>>> at > >>>>> tools.ietf.org. > >>>>>>> > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Oct 22 17:10:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24191AD42B for ; Wed, 22 Oct 2014 17:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3cCxgrM6lNB for ; Wed, 22 Oct 2014 17:10:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FD71A87C7 for ; Wed, 22 Oct 2014 17:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12928; q=dns/txt; s=iport; t=1414023014; x=1415232614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z7MZmr9Wn9oH3kqpOp9vOsD1ufVW/rf5umniSc9Wjug=; b=OJW+9QcZEMdC3gdicASqkiac7KmFxNF2BIvvwvPg/mUdBqEEhms3N1Ln i253uUZ51VpQnCDqdbswMByN/ZsEYDxHMhZOKbZdbb1jDjOUO2/HBdHev C7jBIMGYzbd5PMuQBS/XpYjGzb2mfr7XVLhiwKKf6OV/IF36UgdxUrHqY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAO9GSFStJA2E/2dsb2JhbABcgmsjVFgEzFUKh00CgQsWAX2EAgEBAQQBAQE3NAQHDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAYg4AQzFXAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKVYVQMQcGgyeBHgWPZ4IehEaIQzyDDZEzg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,772,1406592000"; d="scan'208";a="365611442" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2014 00:10:13 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9N0ACjx014179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 00:10:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 19:10:12 -0500 From: "Nobo Akiya (nobo)" To: "Aissaoui, Mustapha (Mustapha)" , Mach Chen , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0IawwgEFPqICAArRj8IACsOyAgACHbwCAAI7IgIABeaCA//+waQA= Date: Thu, 23 Oct 2014 00:10:12 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D9477F433@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D9477F433@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/maJpcxzLf-vj06YLbe7S6MWvSnU Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 00:10:24 -0000 Hi Mustapha, Thanks for clarifying that, always good to get them in writing. (1) - no change from RFC7110 (i.e. will not be deprecated). (2) - this will be added. - Reply Mode 5 with no Reply Path TLV is no longer an error. - Reply Mode 5 with no Reply Path TLV implies reverse LSP. So yes we are in sync. Thanks! -Nobo > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Wednesday, October 22, 2014 7:51 PM > To: Mach Chen; Nobo Akiya (nobo); mpls@ietf.org > Cc: Ross Callon (rcallon@juniper.net); draft-ietf-mpls-lsp-ping-reply-mod= e- > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > ping@tools.ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simpl= e- > 00.txt >=20 > Hi Mach and Nobo, > Just to be sure we are in sync. You are suggesting that the sender of the > echo request can use two methods to request that the reply use the revers= e > path of the tested LSP: > 1. The explicit one in RFC 7110 which includes the reply path TLV with th= e B- > bit but with no additional sub-TLVs and requests the reply mode 5 "Reply > via Specified Path". The echo reply message must include the reply TLV. >=20 > 2. The relaxed one, which is implicit, and which does not include the rep= ly > path TLV and requests the same reply mode 5. Since there is no path reply > TLV in the echo request, the echo reply will also not contain an reply TL= V. In > this case the sender node knows the relationship between the two > directions of the LSP and will know if the reply was successfully receive= d in > the reverse direction without the replying node explicitly stating it. >=20 > If that is the case, then I agree. >=20 > Regards, > Mustapha. >=20 > > -----Original Message----- > > From: Mach Chen [mailto:mach.chen@huawei.com] > > Sent: Tuesday, October 21, 2014 9:19 PM > > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Cc: Ross Callon (rcallon@juniper.net); > > draft-ietf-mpls-lsp-ping-reply-mode- > > simple@tools.ietf.org; > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > Subject: RE: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > Hi Nobo, > > > > I am fine with this change. > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > > Sent: Wednesday, October 22, 2014 5:53 AM > > > To: Mach Chen; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Cc: Ross Callon (rcallon@juniper.net); > > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > > Subject: RE: [mpls] I-D Action: > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > Hi Mach, > > > > > > > -----Original Message----- > > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > > Sent: Tuesday, October 21, 2014 4:43 AM > > > > To: Nobo Akiya (nobo); Aissaoui, Mustapha (Mustapha); > > > > mpls@ietf.org > > > > Cc: Ross Callon (rcallon@juniper.net); > > > > draft-ietf-mpls-lsp-ping-reply-mode- > > > > simple@tools.ietf.org; draft-ietf-mpls-return-path-specified-lsp- > > > > ping@tools.ietf.org > > > > Subject: RE: [mpls] I-D Action: > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > 00.txt > > > > > > > > Hi Nobo and Mustapha, > > > > > > > > I think this may not just require minor changes to RFC7110, it at > > > > least > > > > requires: > > > > > > > > 1) relax the rule of reply mode 5 MUST contain a Reply TLV, and > > > > > > > > 2) deprecate the explicit way (a Reply TLV without sub-TLVs and > > > > with B bit > > > > set) to notify along reverse direction of the tested LSP; > > > > > > > > Given there may be existing implementations and the original > > > > proposal (defined in RFC7110) works and does not require too much > > > > process cost, I incline to leave it as is and suggest not to > > > > define the new dedicated reply mode as well. > > > > > > For backwards compatibility sake, we should preserve (2). Thus only > > > change required is (1) which is a fairly small change. With this > > > direction, what do you think? > > > > > > Thanks! > > > > > > -Nobo > > > > > > > > > > > Best regards, > > > > Mach > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo > > > > > Akiya > > > > > (nobo) > > > > > Sent: Monday, October 20, 2014 4:48 AM > > > > > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > > Cc: Ross Callon (rcallon@juniper.net); > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > > > > Subject: Re: [mpls] I-D Action: > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > > > MPLS WG, > > > > > > > > > > Many thanks for kicking this off Mustapha. > > > > > > > > > > I, for one, like Mustaphas suggestion and would be supportive of > > > > > making that change. I would also be happy to change > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple document to reflect > > > > > this change, if there are consensus to do so. > > > > > > > > > > I have cc'ed the authors of RFC7110 in case they can also chime > > > > > in with > > > > thoughts. > > > > > > > > > > Additionally, suggested changes should be very minimal even to > > > > > those who has already implemented RC7110. However, if anybody > > > > > has implemented and if anybody has concerns, I think this is a > > > > > great time for to > > > > speak up. > > > > > > > > > > Thanks! > > > > > > > > > > -Nobo > > > > > > > > > > > -----Original Message----- > > > > > > From: Aissaoui, Mustapha (Mustapha) > > > > > > [mailto:mustapha.aissaoui@alcatel- > > > > > > lucent.com] > > > > > > Sent: Friday, October 17, 2014 6:19 PM > > > > > > To: Nobo Akiya (nobo); mpls@ietf.org > > > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > > > Subject: RE: [mpls] I-D Action: > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > > 00.txt > > > > > > > > > > > > Dear all, > > > > > > This is a follow-up to the action below from the MPLS-RT > > > > > > review of this > > > > draft. > > > > > > > > > > > > Instead of defining a new reply mode as proposed in Section > > > > > > 3.1 of the draft, I suggested to relax the rule in RFC 7110 > > > > > > such that if the echo request includes reply mode 5 "Reply via > Specified Path" > > > > > > and the Reply Path TLV was not included, the responder node > > > > > > will interpret this as an implicit request to reply via the > > > > > > reverse direction of > > > > the tested LSP. > > > > > > > > > > > > This approach would address the requirement that the sender be > > > > > > able of requesting the reply via the reverse path of an LSP > > > > > > without having to include an additional TLV. > > > > > > > > > > > > I appreciate comments on this proposal. > > > > > > > > > > > > Regards, > > > > > > Mustapha. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo > > > > > > > Akiya > > > > > > > (nobo) > > > > > > > Sent: Saturday, September 06, 2014 9:59 AM > > > > > > > To: mpls@ietf.org > > > > > > > Cc: Ross Callon (rcallon@juniper.net) > > > > > > > Subject: Re: [mpls] I-D Action: > > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > > > > > > > > > > > > > > Thank you Ross and the WG. > > > > > > > > > > > > > > We have posted > > > > > > > draft-akiya-mpls-lsp-ping-reply-mode-simple-03 > > > > > > > as > > > > > > > draft-ietf-mpls- lsp-ping-reply-mode-simple-00. > > > > > > > > > > > > > > Authors would like the WG help to discuss and close off on > > > > > > > these two > > > > > > aspects: > > > > > > > > > > > > > > - From Bruno Decraene: Reply Mode for SPRING and > applicability of > > > > > > this > > > > > > > document. > > > > > > > o There's already a thread for this. > > > > > > > - From Mustapha Aissaoui: Relaxing of Reply Mode 5 > introduced by > > > > > > > RFC7110 instead of defining a new Reply Mode for Reverse LSP. > > > > > > > o Mustapha or myself will start a thread on this topic > later. > > > > > > > > > > > > > > Once above are close off, then we will roll out -01 that incl= udes: > > > > > > > > > > > > > > - Conclusion from the two aspects above. > > > > > > > - A comment received from Tarek Saad. > > > > > > > - Comments received from Lou Berger (will reply to the > review > > > > > > comments > > > > > > > from Lou soon) > > > > > > > > > > > > > > URL: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping- > > > > > > reply-mode- > > > > > > > simple-00.txt > > > > > > > Status: > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply- > > > > > > mode- > > > > > > > simple/ > > > > > > > Htmlized: > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- > > > > > > mode-simple-00 > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > -Nobo, on behalf of authors > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > > > > > > > internet- drafts@ietf.org > > > > > > > > Sent: Saturday, September 06, 2014 3:41 AM > > > > > > > > To: i-d-announce@ietf.org > > > > > > > > Cc: mpls@ietf.org > > > > > > > > Subject: [mpls] I-D Action: > > > > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple- > > > > > > > > 00.txt > > > > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > > Internet-Drafts directories. > > > > > > > > This draft is a work item of the Multiprotocol Label > > > > > > > > Switching Working Group of the IETF. > > > > > > > > > > > > > > > > Title : Label Switched Path (LSP) Ping/Tr= aceroute > > > > > Reply Mode > > > > > > > > Simplification > > > > > > > > Authors : Nobo Akiya > > > > > > > > George Swallow > > > > > > > > Carlos Pignataro > > > > > > > > Loa Andersson > > > > > > > > Mach(Guoyi) Chen > > > > > > > > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simp= le- > 00.txt > > > > > > > > Pages : 11 > > > > > > > > Date : 2014-09-05 > > > > > > > > > > > > > > > > Abstract: > > > > > > > > The Multiprotocol Label Switching (MPLS) Label Switched = Path > (LSP) > > > > > > > > Ping and Traceroute use the Reply Mode field to signal > > > > > > > > the method > > > > to > > > > > > > > be used in the MPLS echo reply. This document adds one > > > > > > > > value to > > > > the > > > > > > > > Reply Mode field to indicate reverse LSP. This > > > > > > > > document also adds > > > > an > > > > > > > > optional TLV which can carry ordered list of Reply Mode = values. > > > > > > > > > > > > > > > > This document updates RFC4379. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping- > > > > > > > > re > > > > > > > > pl > > > > > > > > y- > > > > > > > > mo > > > > > > > > de > > > > > > > > - > > > > > > > > simple/ > > > > > > > > > > > > > > > > There's also a htmlized version available at: > > > > > > > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply- > > > > > > > > mo > > > > > > > > de > > > > > > > > -s > > > > > > > > im > > > > > > > > pl > > > > > > > > e- > > > > > > > > 00 > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the > > > > > > > > time of submission until the htmlized version and diff are > > > > > > > > available at > > > > > > tools.ietf.org. > > > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mpls mailing list > > > > > > > > mpls@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mpls mailing list > > > > > > > mpls@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 23 01:06:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3335B1A8924 for ; Thu, 23 Oct 2014 01:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNoWTgd5zKCt for ; Thu, 23 Oct 2014 01:06:40 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC651A8913 for ; Thu, 23 Oct 2014 01:06:14 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 06CD618013BE; Thu, 23 Oct 2014 10:06:12 +0200 (CEST) Message-ID: <5448B6F8.4010508@pi.nu> Date: Thu, 23 Oct 2014 10:06:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Matt Hartley (mhartley)" , "Osborne, Eric" , "Tarek Saad (tsaad)" , Lizhenbin , "mpls@ietf.org" References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D09@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D232D1D36@nkgeml506-mbx.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D717@USIDCWVEMBX08.corp.global.level3.com> <9D50FCE7413E3D4EA5E42331115FB5BC14AE05AB@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC14AE05AB@xmb-rcd-x03.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JrZQj6WMIMg2LlzJkBLlnlIvx4M Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAgUmVnYXJkaW5nIGRyYWZ0LWdhbmRoaS1tcGxz?= =?utf-8?q?-te-yang-model-00_and_draft-chen-mpls-te-yang-cfg-00?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:06:47 -0000 Folks, I tend to agree with Matt, what we need is not merging of drafts as much as merging of the effort and coordination between the drafts. /Loa On 2014-10-20 17:45, Matt Hartley (mhartley) wrote: > I’m inclined to agree. > > It strikes me that it’s probably not necessary to do all this in one > huge draft, and that it might be a good idea to explicitly break things > up. We could therefore create a base draft for the stuff that’s > standardized and will (hopefully) not be too controversial, have that > move forward as a baseline that everything else can build on, and then > have a second (or even several) drafts for the things that are likely to > require robust debate prior to arriving at consensus. Having that > baseline also allows individual vendors to use it as a base for their > own proprietary extensions if they wish. > > This also has the advantage (IMHO; YMMV) that it breaks things down into > rather more manageable chunks, rather than just having one > intimidatingly-large document at the end of a long process… > > Cheers > > Matt > > I looked at both documents. They both have some good and some bad. The > hardest part in reconciling them will be that they both have a very > vendor-specific view of the world. This is no surprise given the nature > of the technology, and I don’t think it’s unique to TE. BGP will be at > least as hard to sort out. > > I think we need to clearly delineate between standard features, common > features, and vendor-specific ones. Standard features might be scoped > to anything that is both signaled and RFC’d, e.g., [3209, 4420, 4875, > 5712, 7308]. > > Common are things that may have different names and which aren’t > signaled, but which are in use in many/most/all implementations – things > like what one vendor calls ‘autoroute announce’ and another calls ‘igp > shortcuts’. Find a common name, or a way to use both, and build a model > for the subset of things that is most common across vendors. This is a > bit of a quagmire since different vendors will have different approaches > to many details of common features, and it may be the most difficult > part of this whole exercise. > > Vendor-specific things are just that – things implemented in a > particular way by only one vendor. An example from Robert, Rakesh and > Tarek’s document might be attribute-sets, which may not have an obvious > parallel in other vendors’ gear. If nothing else there needs to be > someplace a vendor can append its own proprietary models. > > In the end it may be more productive to do it this way – starting with a > minimum set of obviouly common features and working up – than trying to > reconcile two fully baked models with very different views of the world. > > eric > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Tarek Saad (tsaad) > *Sent:* Thursday, October 16, 2014 9:34 AM > *To:* Lizhenbin; mpls@ietf.org > *Subject:* Re: [mpls] ç­”å¤: Regarding draft-gandhi-mpls-te-yang-model-00 > and draft-chen-mpls-te-yang-cfg-00 > > Hi Robin, > > Thanks for the reference to the draft. We had a look at it. We are > proposing a slightly different model that introduces clear delineation > between configuration, operational (state), RPC (executional), and > notifications for MPLS-TE tunnels, lsps, links, and global data: > > module: mpls-te > > +--rw tunnels-cfg! > > +--rw lsps-cfg! > > +--rw links-cfg! > > +--rw global-cfg! > > +--ro tunnels-oper > > +--ro lsps-oper > > +--ro links-oper > > +--ro global-oper > > rpcs: > > +---x tunnels-rpc > > +---x lsps-rpc > > +---x global-rpc > > +---x links-rpc > > notifications: > > +---n tunnels-notif > > +---n lsps-notif > > +---n links-notif > > +---n global-notif > > We also have a detailed YANG model in-the-works (as per the above) and > we’re planning to include in the next update of the draft. For example, > the tunnels YANG model looks something like below. > > As for collaboration, yes, we are willing to consolidate our efforts > with you to produce the IETF MPLS-TE Yang model. > > module: mpls-te > > +--rw tunnels-cfg! > > | +--rw tunnel* [name type] > > | +--rw name string > > | +--rw type tunnel-type > > | +--rw tunnel-id? uint16 > > | +--rw description? string > > | +--rw destination* [address] > > | | +--rw address inet:ip-address > > | | +--rw path-option* [index] > > | | +--rw index uint8 > > | | +--rw (type)? > > | | | +--:(dynamic) > > | | | | +--rw dynamic > > | | | +--:(explicit) > > | | | +--rw explicit > > | | | +--rw explicit-hoplist* [index] > > | | | +--rw index uint8 > > | | | +--rw explicit-hop-address? hop-address-type > > | | | +--rw explicit-hop-action? hop-action-type > > | | +--rw igp-constraint > > | | | +--rw igp? enumeration > > | | | +--rw area-level? uint32 > > | | +--rw verbatim? boolean > > | | +--rw lockdown? boolean > > | +--rw lsp-cfg* [index] > > | | +--rw index leafref > > | | +--rw source? inet:ip-address > > | | +--rw fast-reroute? boolean > > | | +--rw record-route? boolean > > | | +--rw signaled-name? string > > | | +--rw priority > > | | | +--rw setup? uint8 > > | | | +--rw hold? uint8 > > | | +--rw affinity > > | | | +--rw constraints* [action] > > | | | +--rw action affinity-action-type > > | | | +--rw constraint > > | | | +--rw affinity-list* [name] > > | | | +--rw name string > > | | +--rw path-selection > > | | | +--rw cost-limit? uint32 > > | | | +--rw hop-limit? uint32 > > | | | +--rw metric? path-metric-type > > | | | +--rw tiebreaker? path-tiebreaker-type > > | | +--rw bfd > > | | | +--rw type? bfd-type > > | | | +--rw bringup-timeout? uint32 > > | | | +--rw dampening? uint32 > > | | | +--rw encap-mode? bfd-encap-mode-type > > | | | +--rw fast-detect? boolean > > | | | +--rw lsp-ping > > | | | | +--rw disable? boolean > > | | | | +--rw interval? uint32 > > | | | +--rw minimum-interval? uint32 > > | | | +--rw multiplier? uint32 > > | | +--rw logging-event* [event] > > | | +--rw event logging-event-type > > | +--rw (policy-routing)? > > | | +--:(forwarding-class) > > | | | +--rw forwarding-class > > | | | +--rw class? uint8 > > | | +--:(forwarding-group) > > | | +--rw forwarding-group > > | | +--rw classes* uint8 > > | +--rw auto-bandwidth > > | | +--rw overflow-threshold? uint32 > > | | +--rw overflow-limit? uint8 > > | | +--rw underflow-threshold? uint32 > > | | +--rw underflow-limit? uint8 > > | | +--rw collect-only? boolean > > | +--rw (announce-as)? > > | | +--:(autoroute) > > | | | +--rw autoroute! > > | | | +--rw include-ipv6-unicast? boolean > > | | | +--rw (metric-type)? > > | | | +--:(metric) > > | | | | +--rw metric? uint8 > > | | | +--:(relative-metric) > > | | | | +--rw relative-metric? uint8 > > | | | +--:(absolute-metric) > > | | | +--rw absolute-metric? uint8 > > | | +--:(forwarding-adjacency) > > | | +--rw forwarding-adjacency! > > | | +--rw holdtime? uint32 > > | | +--rw include-ipv6-unicast? boolean > > | +--rw backup-bandwidth? uint32 > > | +--rw load-share? uint32 > > | +--rw bidirectional > > | +--rw association > > | +--rw id? uint32 > > | +--rw source? inet:ip-address > > | +--rw global-source? inet:ip-address > > | +--rw type? bidir-association-type > > +--rw global-cfg! > > Regards, > > Tarek > > *From: *Lizhenbin > > *Date: *Tuesday, October 14, 2014 at 11:12 AM > *To: *"mpls@ietf.org " > > *Subject: *[mpls] ç­”å¤: Regarding draft-gandhi-mpls-te-yang-model-00 and > draft-chen-mpls-te-yang-cfg-00 > > Hi MPLSer, > > I would like to remind you of the other two Yang model drafts: > draft-chen-mpls-te-yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. > Welcome comments and collaboration. > > Best Regards, > > Zhenbin(Robin) > > *å‘件人**:*mpls [mailto:mpls-bounces@ietf.org] *代表 *Lizhenbin > *å‘é€æ—¶é—´:* 2014å¹´10月14æ—¥ 22:34 > *收件人:* rgandhi@cisco.com ; tsaad@cisco.com > ; rsawaya@cisco.com > *抄é€:* mpls@ietf.org > *主题:* [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and > draft-chen-mpls-te-yang-cfg-00 > > Hi Rakesh, Tarek & Robert, > > I just saw you proposed the draft-gandhi-mpls-te-yang-model-00. I wonder > if you are aware of the draft-chen-mpls-te-yang-cfg-00 we proposed on > August 15. From our point of view, we are not experienced enough to > remind our MPLSers of the new draft to propose possible discussion and > collaboration. I compared the two drafts as follows: > > 1. The possible overlapped part > > > draft-gandhi-mpls-te-yang-model-00 > draft-chen-mpls-te-yang-cfg-00 > > 4.1. Global MPLS-TE Data Model Overview . . . . . . . . . . . . > 4 --> MPLS TE Global Configuration/RSVP-TE Global > Configuration > > 4.2. MPLS-TE Tunnel Interface Data Model Overview . . . . . . . > 6 --> RSVP-TE Tunnel Configuration > > 4.3. MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . . > 7 --> RSVP-TE Tunnel Configuration > > 4.4. MPLS-TE Link Data Model Overview . . . . . . . . . . . . . > 8 --> MPLS TE Link Configuration/RSVP-TE Interface > Configuration > > 2. draft-chen-mpls-te-yang-cfg-00 defines following configuration Yang > beyond draft-gandhi-mpls-te-yang-model-00. > > 3.4. Explicit Path Configuration . . . . . . . . . . . . . . . 5 > > 3.5. P2MP TE Leaf List Configuration . . . . . . . . . . . . . 5 > > 3.9. CSPF Configuration . . . . . . . . . . . . . . . . . . . 8 > > 3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . . 8 > > 3. draft-chen-mpls-te-yang-cfg-00 has already defined all Yang model for > these listed configuration while draft-gandhi-mpls-te-yang-model-00 > leaves many Yang Model definition as spaces. > > I think maybe you are not aware of the existing draft. If you would like > to cooperate on the MPLS TE Yang Models definition, we are very glad to > discuss with you to try to unify these Yang models. > > Best Regards, > > Zhenbin(Robin) > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 23 07:29:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365521A9139; Thu, 23 Oct 2014 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ80MRO2LiDS; Thu, 23 Oct 2014 07:29:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DBE1A8F4F; Thu, 23 Oct 2014 07:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11250; q=dns/txt; s=iport; t=1414074554; x=1415284154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rN52a089x4tIRpNU691tvrndT02P5lL1nyq+aZmWuwM=; b=TJaPWXkB4vRkDiIUspFNn485MKjyP7D7rrHD8/xkHm60IHJlE3g9m0fw ZIFwipiW4Jqr3o3kpZQbxI30xbhUiAfemvEMGngCB2iy6bTnvlunTa9HR BjjEbFwBHE/OqsST2Rsok1hZkqfbYvLrpfqtRY4q8qq+RQBG/PjGtPDST 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIwPSVStJV2Z/2dsb2JhbABcgmsjVFyDAslyCodNAht3FgF9hAIBAQEDAQEBASAROgsFBwQCAQYCDgMEAQEBAgIjAwICAh8GCxQBCAgCBA4FG4gSAwkIAQyWSJxXjhMNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEsjHeCGhsHBoJxNoEeAQSPZ4IeiUeCEYExg0mKVYJdhAGDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,775,1406592000"; d="scan'208";a="89693694" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 23 Oct 2014 14:29:13 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9NETDet031331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 14:29:13 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 09:29:13 -0500 From: "Carlos Pignataro (cpignata)" To: Lizhong Jin Thread-Topic: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 Thread-Index: Ac/sFilNAh9y4m1ARjuK37y9yFgbfABRujmAAAJMAIAAAya/gAAU84aAAABNfYAAAUPzgAAAzQuAAAM+cQAAEkwIAAABM48AADMglQA= Date: Thu, 23 Oct 2014 14:29:12 +0000 Message-ID: <2285EF10-FD10-459B-B1B5-AB1960FB257E@cisco.com> References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com> <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> <5447B18C.7050109@joelhalpern.com> <6088D699-48F9-4CE1-BA02-D65D1A4777C9@gmail.com> In-Reply-To: <6088D699-48F9-4CE1-BA02-D65D1A4777C9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.173.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/q61FCVpLA8bgewvXnZ5HjGEUw6k Cc: Joel Halpern Direct , "gen-art@ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply.all" , "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:29:17 -0000 SGkgTGl6aG9uZywNCg0KUGxlYXNlIGFsc28gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIE9w cyBEaXIgcmV2aWV3IG9mIHRoaXMgZG9jLCBpbiB3aGljaCBJIGhhdmUgc2ltaWxhciBjb25jZXJu cyBhcyB0aG9zZSBmcm9tIEpvZWwuDQoNClRoZXJlIHNlZW0gdG8gYmUgdGhyZWUgbWFqb3IgYXJl YXMgaW4gZGlzY3Vzc2lvbjoNCjEuIFRoZSBzY29wZSBvZiB0aGUgcHJvYmxlbSBiZWluZyBzb2x2 ZWQgKGkuZS4sIHdoaWNoIGNhc2VzIGFyZSBzb2x2ZWQsIHdoaWNoIGFyZSBub3QsIGFuZCB3aGlj aCBhcmUgdGhlIGNvbW1vbiBjYXNlcykNCjIuIFRoZSBtZWNoYW5pc20gaXRzZWxmIG5vdCB3b3Jr aW5nIGluIG1hbnkgY2FzZXMuDQozLiBIb3cgdGhpcyBhbGwgd29ya3Mgd2l0aCBJUHY2IGFkZHJl c3NlcyAoc2luY2UgeW91ciBmaXggc2VlbXMgdG8gY292ZXIgdGhlIG92ZXJsYXBwaW5nIElQdjQg cHJpdmF0ZSBhZGRyZXNzIGNhc2Ugb25seSkNCg0KVGhhbmtzLA0KDQpDYXJsb3MuDQoNCj4gT24g T2N0IDIyLCAyMDE0LCBhdCAxMDowNSBBTSwgbGl6aG8uamluQGdtYWlsLmNvbSB3cm90ZToNCj4g DQo+IEpvZWwsIHRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gV2Ugd2lsbCBzZW5kIG91dCBhIG5l dyB2ZXJzaW9uIHNvb24gdG8gcmVmbGVjdCB0aGUgZGlzY3Vzc2lvbi4NCj4gDQo+IFJlZ2FyZHMN Cj4gTGl6aG9uZyANCj4gDQo+IA0KPiANCj4+IOWcqCAyMDE05bm0MTDmnIgyMuaXpe+8jOS4i+WN iDk6MzDvvIxKb2VsIEhhbHBlcm4gRGlyZWN0IDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4g d3JvdGXvvJoNCj4+IA0KPj4gSXQgd291bGQgYmUgZ29vZCB0byBzZWUgYSByZXZpc2lvbiB0aGF0 IGNsZWFybHkgc3BlbGxlZCBvdXQgd2hhdCB0aGUNCj4+IGRyYWZ0IHdhcyBzb2x2aW5nLCBob3cg dGhlIGluaXRpYWwgZW5kLXBvaW50IGtuZXcgd2hhdCB0byBjcmVhdGUsIGFuZA0KPj4gaG93IHRo ZSByZXNwb25kZXIga25ldyB3aGF0IHRvIHVzZS4gIEl0IG1heSB3ZWxsIGJlIHRoYXQgdGhlcmUg aXMgYW4NCj4+IGVmZmVjdGl2ZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbXMgaGVyZS4gIEkgbG9v ayBmb3J3YXJkIHRvIHNlZWluZyBpdCBpbg0KPj4gd3JpdGluZy4NCj4+IA0KPj4gWW91cnMsDQo+ PiBKb2VsDQo+PiANCj4+PiBPbiAxMC8yMi8xNCwgMTI6NDYgQU0sIExpemhvbmcgSmluIHdyb3Rl Og0KPj4+IEhpIEpvZWwsDQo+Pj4gVGhlIHRoaW5ncyBtYXkgbm90IGJlIHRoYXQgYmFkLiBZb3Ug Y291bGQgYWRkIGEgc2Vjb25kIGFkZHJlc3MgKGFkZHJlc3MgQiBpbg0KPj4+IG91ciBleGFtcGxl KSB3aXRoIEsgYml0IHNldC4gVGhlIGFkZHJlc3MgZW50cnkgd2l0aCBLIGJpdCBzZXQgbXVzdCBi ZSBhcyBhDQo+Pj4gcmVsYXkgbm9kZSwgYW5kIGNvdWxkIG5vdCBiZSBza2lwcGVkLg0KPj4+IFNl Y3Rpb24gNC40IHNob3VsZCBiZSBjaGFuZ2VkIHRvOiBGaW5kIHRoZSBmaXJzdCByb3V0YWJsZSBh ZGRyZXNzIEEsIGFuZCB0aGUNCj4+PiBmaXJzdCBhZGRyZXNzIEIgd2l0aCBLIGJpdCBzZXQuIElm IGFkZHJlc3MgQSBpcyBiZWZvcmUgYWRkcmVzcyBCIGluIHRoZQ0KPj4+IHN0YWNrLCB0aGVuIHVz ZSBhZGRyZXNzIEIgYXMgdGhlIHJlbGF5IGFkZHJlc3MuIE90aGVyd2lzZSwgdXNlIGFkZHJlc3Mg QSBhcw0KPj4+IHRoZSByZWxheSBhZGRyZXNzLg0KPj4+IEluIHRoYXQgY2FzZSwgaWYgQSBpcyB0 aGUgcHJpdmF0ZSBhZGRyZXNzLCB0aGUgcGFja2V0IHdpbGwgYmUgZmlyc3RseQ0KPj4+IHJlbGF5 ZWQgdG8gYWRkcmVzcyBCLiBBbmQgYWRkcmVzcyBBIGFuZCBCIGJlbG9uZyB0byBvbmUgcm91dGVy LiBIZXJlIEkNCj4+PiBhc3N1bWUgb25lIHJvdXRlciBhdCBsZWFzdCBoYXMgb25lIHJvdXRhYmxl IGFkZHJlc3MgZm9yIGFub3RoZXIgQVMuDQo+Pj4gDQo+Pj4gUmVnYXJkcw0KPj4+IExpemhvbmcN Cj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogSm9lbCBN LiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+Pj4gU2VudDogMjAxNOW5 tDEw5pyIMjLml6UgMTE6MTQNCj4+Pj4gVG86IExpemhvbmcgSmluDQo+Pj4+IENjOiBnZW4tYXJ0 QGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPj4+ICdkcmFmdC1pZXRm LW1wbHMtbHNwLXBpbmctDQo+Pj4+IHJlbGF5LXJlcGx5LmFsbCcNCj4+Pj4gU3ViamVjdDogUmU6 IFttcGxzXSBbR2VuLWFydF0gcmV2aWV3Og0KPj4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1y ZWxheS1yZXBseS0wNA0KPj4+PiANCj4+Pj4gb3UgYXJlIHNheWluZyB0aGF0IHRoaXMgaXMgb25s eSBmb3IgdGhlIGNhc2Ugd2hlcmUgYW4gQVMgaXMgdXNpbmcgcHVibGljDQo+Pj4+IGFkZHJlc3Nl cyBmb3IgaXRzIGludGVybmFsIG51bWJlcmluZywgYnV0IGlzIG5vdCBkaXN0cmlidXRpbmcgdGhh dCBhZGRyZXNzDQo+Pj4gYmxvY2sNCj4+Pj4gZXh0ZXJuYWxseT8NCj4+Pj4gDQo+Pj4+IElmIHNv LCB5b3UgbmVlZCB0byBzdGF0ZSB0aGF0IHZlcnkgY2xlYXJseS4NCj4+Pj4gSSBiZWxpZXZlIGEg ZmFyIG1vcmUgY29tbW9uIGNhc2UgaXMgb25lIHdoZXJlIHRoZSBudW1iZXJpbmcgaXMgZnJvbSBh DQo+Pj4+IHBvcnRpb24gb2YgYSBwdWJsaWNseSBhbGxvY2F0ZWQgc3BhY2UsIGJ1dCBmaXJld2Fs bGVkLiAgV2hpY2ggd291bGQNCj4+PiBwcm9kdWNlDQo+Pj4+IHRoZSBzYW1lIHByb2JsZW0sIGJ1 dCB3b3VsZCBub3QgYmUgYW1lbmFibGUgdG8gdGhpcyBzb2x1dGlvbi4NCj4+Pj4gQW5kIGl0IGlz IHdlbGwga25vd24gdGhhdCBtYW55IElTUHMgZG8gaW50ZXJuYWwgbnVtYmVyIGFzc2lnbm1lbnQg ZnJvbQ0KPj4+PiBwcml2YXRlIGJsb2Nrcy4NCj4+Pj4gDQo+Pj4+IFNvIHdoYXQgeW91IGFyZSBu b3cgc2F5aW5nIGlzIHRoYXQgdGhpcyBkcmFmdCBzb2x2ZXMgYSB2ZXJ5IHNtYWxsIHBvcnRpb24N Cj4+PiBvZiB0aGUNCj4+Pj4gcHJvYmxlbT8gIEJ1dCBpdCB3b3JrcyBmb3IgdGhhdCBzbWFsbCBw b3J0aW9uPyAgSWYgc28sIGF0IHRoZSB2ZXJ5IGxlYXN0DQo+Pj4geW91DQo+Pj4+IG5lZWQgdG8g YmUgVkVSWSBjbGVhciBhYm91dCB3aGF0IGNhc2VzIHRoaXMgd29ya3MgZm9yIGFuZCB3aGF0IGNh c2VzIGl0DQo+Pj4gZG9lcw0KPj4+PiBub3QuICBBbmQgSSBmZWFyIHRoYXQgZXZlbiBpZiB5b3Ug YXJlIGNsZWFyLCBpdCBpcyBnb2luZyB0byBiZSB2ZXJ5DQo+Pj4gY29uZnVzaW5nIGZvcg0KPj4+ PiBmb2xrcyB3aG8gYXJlIHRyeWluZyB0byB1c2UgaXQuDQo+Pj4+IA0KPj4+PiBZb3VycywNCj4+ Pj4gSm9lbA0KPj4+PiANCj4+Pj4+IE9uIDEwLzIxLzE0LCAxMDo1MSBQTSwgTGl6aG9uZyBKaW4g d3JvdGU6DQo+Pj4+PiBIaSBKb2VsLA0KPj4+Pj4gSSBub3cgc2VlIHlvdXIgY29uY2Vybi4gVGhl ICJwcml2YXRlIiB3b3JkIGluIGRyYWZ0IGlzIG5vdCBjb3JyZWN0LCBJDQo+Pj4+PiB3aWxsIHJl bW92ZSBpdC4gVGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gb2YgImRyYWZ0LXJlbGF5LXJlcGx5IiBp cyBmcm9tDQo+Pj4+PiB0aGUgc2NlbmFyaW8gd2hlcmUgSVAgYWRkcmVzcyBkaXN0cmlidXRpb24g aXMgcmVzdHJpY3RlZCBhbW9uZyBBUyBvciBJR1ANCj4+Pj4gYXJlYS4NCj4+Pj4+IEFuZCB0aGUg SVAgYWRkcmVzcyBpcyBub3QgcHJpdmF0ZSBhZGRyZXNzLiBBcyBJIGtub3csIG1vc3QgZGVwbG95 ZWQNCj4+Pj4+IGludGVyLUFTIG9yIGludGVyLWFyZWEgTVBMUyBMU1AgaXMgaW4gdGhlIG5ldHdv cmsgd2l0aG91dCBwcml2YXRlIElQDQo+Pj4gYWRkcmVzcy4NCj4+Pj4+IA0KPj4+Pj4gUmVnYXJk cw0KPj4+Pj4gTGl6aG9uZw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb21dDQo+Pj4+Pj4gU2VudDogMjAxNOW5tDEw5pyIMjLml6UgMTA6MTUNCj4+Pj4+ PiBUbzogTGl6aG9uZyBKaW4NCj4+Pj4+PiBDYzogZ2VuLWFydEBpZXRmLm9yZzsgbXBsc0BpZXRm Lm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4+Pj4+ICdkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctDQo+ Pj4+Pj4gcmVsYXktcmVwbHkuYWxsJw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gW0dlbi1h cnRdIHJldmlldzoNCj4+Pj4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseS0w NA0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG9yaWdpbmFsIHNvdXJj ZSBBLCB0aGF0IHdlIGFyZSB0cnlpbmcgdG8NCj4+Pj4+PiByZWFjaA0KPj4+Pj4gd2l0aCBhDQo+ Pj4+Pj4gcmVwbHksIGhhcyBhbiBhZGRyZXNzIHRoYXQgYXBwZWFycyB0byB0aGUgcmVzcG9uZGVy IFggdG8gYmUgcm91dGFibGUuDQo+Pj4+Pj4gQnV0IHRoZSBkZXN0aW5hdGlvbiB0aGF0IGlzIHJl YWNoZWQgYnkgdGhhdCBhZGRyZXNzIGlzIGVpdGhlciBhIGJsYWNrDQo+Pj4+Pj4gaG9sZSBvcg0K Pj4+Pj4gc29tZQ0KPj4+Pj4+IG90aGVyIGVudGl0eSB1c2luZyB0aGUgc2FtZSBhZGRyZXNzLg0K Pj4+Pj4+IA0KPj4+Pj4+IFRoZSByZWFzb24gZm9yIHRoZSBkdXBsaWNhdGlvbiBpcyB0aGF0LCBh cyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LA0KPj4+Pj4+IHRoZQ0KPj4+Pj4gc291cmNlDQo+Pj4+ Pj4gYWRkcmVzcyBmb3IgQSBpcyBhIHByaXZhdGUgYWRkcmVzcy4gIFRoYXQgc2FtZSBhZGRyZXNz IG1heSB3ZWxsIGJlDQo+Pj4+PiByZWFjaGFibGUNCj4+Pj4+PiBhY2NvcmRpbmcgdG8gdGhlIHJv dXRpbmcgdGFibGUgYXQgWC4gIEJ1dCBpdCB3b24ndCBnZXQgdG8gQS4NCj4+Pj4+PiANCj4+Pj4+ PiBJZiB0aGUgcHJvYmxlbSBpcyBzb21ldGhpbmcgb3RoZXIgdGhhbiBwcml2YXRlIGFkZHJlc3Np bmcgcHJldmVudGluZw0KPj4+Pj4+IHJlYWNoYWJpbGl0eSwgaXQgaXMgbGlrZWx5IHRoZXJlIGlz IHN0aWxsIGEgbWlzdGFrZW4gcm91dGFiaWxpdHkNCj4+Pj4+PiBwcm9ibGVtLA0KPj4+Pj4gYnV0 IEkgY2FuDQo+Pj4+Pj4gbm90IGlsbHVzdHJhdGUgdGhlIGZhaWx1cmUgd2l0aG91dCBzb21lIG90 aGVyIGNhc2UgYmVpbmcgZGVzY3JpYmVkLg0KPj4+Pj4+IA0KPj4+Pj4+IFlvdXJzLA0KPj4+Pj4+ IEpvZWwNCj4+Pj4+PiANCj4+Pj4+Pj4gT24gMTAvMjEvMTQsIDEwOjA2IFBNLCBMaXpob25nIEpp biB3cm90ZToNCj4+Pj4+Pj4gSW5saW5lLCB0aGFua3MuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBb bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+Pj4+Pj4+PiBTZW50OiAyMDE05bm0MTDmnIgy MuaXpSAwOjA2DQo+Pj4+Pj4+PiBUbzogbGl6aG8uamluQGdtYWlsLmNvbQ0KPj4+Pj4+Pj4gQ2M6 IGdlbi1hcnRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7DQo+Pj4+Pj4+ IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy0NCj4+Pj4+Pj4+IHJlbGF5LXJlcGx5LmFsbA0KPj4+ Pj4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBbR2VuLWFydF0gcmV2aWV3Og0KPj4+Pj4+PiBkcmFm dC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHktMDQNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g SW4gbGluZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIDEwLzIxLzE0LCAxMDozNiBBTSwgbGl6 aG8uamluQGdtYWlsLmNvbSB3cm90ZToNCj4+Pj4+Pj4+PiBIaSBKb2VsLCBzZWUgaW5saW5lIGJl bG93LCB0aGFua3MuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTGl6aG9uZw0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAyMDE0LjEwLjIx77yMUE05OjMw77yMSm9lbCBNLiBIYWxw ZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+PiB3cm90ZSDvvJoNCj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IElmIHRoZSBwcm9jZXNzIGZvciB0aGlzIGRyYWZ0IGlzIHRvIHVzZSB0aGUgdG9w IGFkZHJlc3MgdGhhdCBjYW4NCj4+Pj4+Pj4+Pj4gYmUgcmVhY2hlZCBpbiB0aGUgcm91dGluZyB0 YWJsZSwgdGhlbiB0aGVyZSBpcyBhIHNpZ25pZmljYW50DQo+Pj4+Pj4+Pj4+IHByb2JhYmlsaXR5 IHRoYXQgdGhlIG9yaWdpbmFsIHNvdXJjZSBhZGRyZXNzLCB3aGljaCBpcyBhbHdheXMgYXQNCj4+ Pj4+Pj4+Pj4gdGhlIHRvcCBvZiB0aGUgbGlzdCwgd2lsbCBiZSB1c2VkLiAgQXMgc3VjaCwgdGhl IGludGVuZGVkIHByb2JsZW0NCj4+Pj4+Pj4+Pj4gd2lsbCBub3QgYmUgc29sdmVkLg0KPj4+Pj4+ Pj4+IFtMaXpob25nXSBsZXQgbWUgZ2l2ZSBhbiBleGFtcGxlIHRvIGV4cGxhaW46IHRoZSBzb3Vy Y2UgYWRkcmVzcyBBDQo+Pj4+Pj4+Pj4gaXMgZmlyc3RseSBhZGRlZCB0byB0aGUgc3RhY2ssIHRo ZW4gYSBzZWNvbmQgcm91dGFibGUgYWRkcmVzcyBCDQo+Pj4+Pj4+Pj4gZm9yIHJlcGx5aW5nIEFT IGlzIGFsc28gYWRkZWQuIFRoZSByZXBseSBub2RlIHdpbGwgbm90IHVzZSBhZGRyZXNzDQo+Pj4+ Pj4+Pj4gQSBzaW5jZSBpdCdzIG5vdCByb3V0YWJsZSwgdGhlbiBpdCB3aWxsIHVzZSBhZGRyZXNz IEIuIFNvIGl0IHdpbGwNCj4+Pj4+Pj4+PiB3b3JrIGFuZCBJIGRvbid0IHNlZSB0aGUgcHJvYmxl bS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhlIHdob2xlIHBvaW50IG9mIHRoaXMgcmVsYXkgbWVj aGFuaXNtLCBhcyBJIHVuZGVyc3RhbmQgaXQsIGlzIHRvDQo+Pj4+Pj4+PiBjb3BlDQo+Pj4+Pj4+ IHdpdGgNCj4+Pj4+Pj4+IHRoZSBjYXNlIHdoZW4gdGhlIHJlc3BvbmRlciBYIGNhbiBub3QgYWN0 dWFsbHkgcmVhY2ggdGhlIHNvdXJjZSBBLg0KPj4+Pj4+Pj4gICBOb3cgc3VwcG9zZSB0aGF0IHRo ZSBwYWNrZXQgYXJyaXZlcyBhdCBYIHdpdGggdGhlIEFkZHJlc3Mgc3RhY2sNCj4+Pj4+Pj4+IEEs IEIsDQo+Pj4+PiAuLi4NCj4+Pj4+Pj4gWA0KPj4+Pj4+Pj4gZXhhbWluZXMgdGhlIHN0YWNrLiAg VGhlIGRvbWFpbiBvZiBBIHdhcyBudW1iZXJlZCB1c2luZyBuZXQgMTAuDQo+Pj4+Pj4+PiBUaGUg ZG9tYWluIG9mIFggaXMgbnVtYmVyZWQgdXNpbmcgbmV0IDEwLiAgQSdzIGFkZHJlc3MgaXMgcHJv YmFibHkNCj4+Pj4+Pj4gcm91dGFibGUNCj4+Pj4+Pj4+IGluIFgncyByb3V0aW5nIHRhYmxlLiAg VGhlIHByb2JsZW0gaXMsIHRoYXQgcm91dGluZyB3aWxsIG5vdCBnZXQgdG8NCj4+Pj4+Pj4+IEEu ICBYDQo+Pj4+Pj4+IGV4YW1pbmVzDQo+Pj4+Pj4+PiB0aGUgc3RhY2ssIGRldGVybWluZXMgdGhh dCBBIGlzICJyb3V0YWJsZSIsIGFuZCBzZW5kcyB0aGUgcGFja2V0Lg0KPj4+Pj4+Pj4gVGhpcw0K Pj4+Pj4+PiBmYWlscyB0bw0KPj4+Pj4+Pj4gbWVldCB0aGUgZ29hbC4NCj4+Pj4+Pj4gW0xpemhv bmddIFRoZSBzb3VyY2UgQSB5b3UgYXJlIHJlZmVycmluZyBpcyB0aGUgaW5pdGlhdG9yLCByaWdo dD8NCj4+Pj4+Pj4gVGhlIGdvYWwgb2YgcmVsYXkgbWVjaGFuaXNtIGlzIHRvIHJlYWNoIHRoZSBp bml0aWF0b3IuIElmIFggaXMNCj4+Pj4+Pj4gcm91dGFibGUgdG8gdGhlIGluaXRpYXRvciAoYWRk cmVzcyBBKSwgdGhlbiBpdCBpcyBncmVhdCwgb3RoZXIgcmVsYXkNCj4+Pj4+Pj4gbm9kZSBpbiB0 aGUgc3RhY2sgd2lsbCBiZSBza2lwcGVkLg0KPj4+Pj4+PiBJZiB0aGUgc291cmNlIEEgeW91IGFy ZSByZWZlcnJpbmcgaXMgdGhlIGludGVyZmFjZSBhZGRyZXNzIG9mIG9uZQ0KPj4+Pj4+PiBpbnRl cm1lZGlhdGUgbm9kZSwgdGhlbiBJIGRvIG5vdCB1bmRlcnN0YW5kICJyb3V0aW5nIHdpbGwgbm90 IGdldCB0bw0KPj4+Pj4+PiBBLiAgWCBleGFtaW5lcyB0aGUgc3RhY2ssIGRldGVybWluZXMgdGhh dCBBIGlzICJyb3V0YWJsZSIsIGFuZCBzZW5kcw0KPj4+Pj4+PiB0aGUNCj4+Pj4+PiBwYWNrZXQi Lg0KPj4+Pj4+PiBXaHkgcm91dGluZyB3aWxsIG5vdCBnZXQgdG8gQSwgYnV0IEEgaXMgcm91dGFi bGU/DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBSZWdhcmRzDQo+Pj4+Pj4+IExpemhvbmcNCj4+Pj4+Pj4g DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4+IEpvZWwNCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+IA0KPj4+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxp c3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg0K From nobody Thu Oct 23 13:02:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEA31AD058; Thu, 23 Oct 2014 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HToSl2QLWXxg; Thu, 23 Oct 2014 13:01:41 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1903B1AD057; Thu, 23 Oct 2014 13:01:40 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-7a-544906ee6751 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.7A.05330.EE609445; Thu, 23 Oct 2014 15:47:26 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 16:01:39 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP7vuLnXrxVtGdr0an+IEI1vxrJpw+GV8Q Date: Thu, 23 Oct 2014 20:01:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> In-Reply-To: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyuXRPiO47Ns8Qg++brS1uLV3JavH5zzZG i+MXfjM6MHssWfKTKYAxissmJTUnsyy1SN8ugSuj6XdBwTvhipdTprM1MK4R7mLk5JAQMJG4 fOIVC4QtJnHh3nq2LkYuDiGBo4wS86/+hXKWM0pc/f2QCaSKTcBI4sXGHnYQW0SgUGLh9AY2 EFtYIFCibd9eZoh4kETju/WMELaRxOU3DaxdjBwcLAKqEgdO1oOEeQV8JbZc+glWLiTgKHGn 9RaYzSngJDFzwncwmxHooO+n1oCtZRYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0rs65/O DrKKWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMHKXFqWW5 6UYGmxiBcXBMgk13B+Oel5aHGAU4GJV4eB9oeIQIsSaWFVfmHmKU5mBREuedVTsvWEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVANjeOvH7a9svS6wfJeueXP/wsNFDYuM/kzfGxSVrBI1m0+1 VNBaoq3mqX1fuvn757sc3nEeOfbbOObu6WNfEzMXqLBVLRGfWhtxfJXUptZv8svDCzSzbHhm ftSqvDKx2mbpc/N9s2cZhl67t2mt5ee1PRxLPu0VK2newbyo5OC6XWb277+aWu14qsRSnJFo qMVcVJwIALnV26ZkAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/c5SEOPQ8eavByMGskg0M1AWOFbU Subject: [mpls] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 20:01:49 -0000 RGVhciBBbGwsDQphIG5ldyBzZWN0aW9uIDMuMyBCb290c3RyYXBwaW5nIEJGRCBzZXNzaW9uIHdp dGggQkZEIFJldmVyc2UgUGF0aCBvdmVyIFNlZ21lbnQgUm91dGVkIHR1bm5lbCBiZWVuIGFkZGVk LiBBdXRob3JzIGFsd2F5cyB3ZWxjb21lIHlvdXIgY29tbWVudHMgYW5kIGdyZWF0bHkgYXBwcmVj aWF0ZSBzdWdnZXN0aW9ucy4gV2UncmUgbG9va2luZyBmb3J3YXJkIHRvIGNvbnRpbnVlIGRpc2N1 c3Npb24gYXQgV0cgbWVldGluZ3MgYXQgSUVURi05MS4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAyMywgMjAxNCAxMjo1NyBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBKZWZmIFRhbnRzdXJh OyBHcmVnb3J5IE1pcnNreTsgSmVmZiBUYW50c3VyYTsgSWx5YSBWYXJsYXNoa2luOyBJbHlhIFZh cmxhc2hraW4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWly c2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KUmV2aXNpb246 CTAxDQpUaXRsZToJCUJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGly ZWN0ZWQgUmV0dXJuIFBhdGgNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjMNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQt MDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMQ0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pcnNr eS1tcGxzLWJmZC1kaXJlY3RlZC0wMQ0KDQpBYnN0cmFjdDoNCiAgIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCiAgIGRp cmVjdGlvbmFsIHBhdGhzLiAgV2hlbiBhIEJGRCBzZXNzaW9uIG1vbml0b3JzIGluIGl0cyBmb3J3 YXJkDQogICBkaXJlY3Rpb24gYW4gZXhwbGljaXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpcyBhIG5l ZWQgdG8gYmUgYWJsZSB0bw0KICAgZGlyZWN0IGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHNwZWNp ZmljIHBhdGggYXMgcmV2ZXJzZSBkaXJlY3Rpb24gb2YNCiAgIHRoZSBCRkQgc2Vzc2lvbi4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Oct 23 15:02:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08421A6F3A for ; Thu, 23 Oct 2014 15:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_dJjGfQUokO for ; Thu, 23 Oct 2014 15:02:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14E91A1C03 for ; Thu, 23 Oct 2014 15:02:45 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 23 Oct 2014 22:02:22 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.210]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.210]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 22:02:22 +0000 From: Ronald Bonica To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-bonica-mpls-self-ping-02.txt Thread-Index: AQHP7wzZVxhl0ZkIm0SLTcqmpvQCBpw+O7MA Date: Thu, 23 Oct 2014 22:02:21 +0000 Message-ID: References: <20141023220050.16471.49241.idtracker@ietfa.amsl.com> In-Reply-To: <20141023220050.16471.49241.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(199003)(189002)(51704005)(377424004)(80022003)(74316001)(2501002)(15975445006)(19580405001)(21056001)(76176999)(54356999)(107886001)(230783001)(107046002)(76576001)(108616004)(122556002)(105586002)(106116001)(20776003)(99396003)(110136001)(19580395003)(50986999)(2351001)(101416001)(76482002)(95666004)(46102003)(77096002)(66066001)(4396001)(33646002)(15202345003)(99286002)(97736003)(85852003)(87936001)(86362001)(85306004)(40100003)(2656002)(120916001)(31966008)(106356001)(92566001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5MZAlympDasFE6wWQLJZ0mrLpcw Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:02:47 -0000 U29ycnkgZm9yIHRoZSBmcmVxdWVudCB1cGRhdGVzLiBQbGVhc2UgcmV2aWV3Lg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMywgMjAxNCA2 OjAxIFBNDQo+IFRvOiBSb25hbGQgQm9uaWNhOyBFWFQgLSBsdWlzLnRvbW90YWtpQHZlcml6b24u Y29tOyBSYXZlZW5kcmEgVG9ydmk7DQo+IE1pY2hhZWwgQ29ubjsgUmF2ZWVuZHJhIFRvcnZpOyBE YW50ZSBQYWNlbGxhOyBSb25hbGQgQm9uaWNhOyBFWFQgLQ0KPiBtYXJrLnd5Z2FudEB2ZXJpem9u LmNvbTsgRVhUIC0gbHVpcy50b21vdGFraUB2ZXJpem9uLmNvbTsgTWljaGFlbCBDb25uOw0KPiBE YW50ZSBQYWNlbGxhOyBFWFQgLSBtYXJrLnd5Z2FudEB2ZXJpem9uLmNvbQ0KPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZy0w Mi50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLW1wbHMt c2VsZi1waW5nLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJv biBCb25pY2EgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFt ZToJCWRyYWZ0LWJvbmljYS1tcGxzLXNlbGYtcGluZw0KPiBSZXZpc2lvbjoJMDINCj4gVGl0bGU6 CQlMU1AgU2VsZi1QaW5nDQo+IERvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjMNCj4gR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQk4DQo+IFVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25pY2EtbXBscy1zZWxmLXBp bmctDQo+IDAyLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nLw0KPiBIdG1saXplZDogICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9uaWNhLW1wbHMtc2VsZi1waW5nLTAy DQo+IERpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1ib25pY2EtbXBscy1zZWxmLXBpbmctMDINCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIG1l bW8gZGVzY3JpYmVzIExTUCBTZWxmLXBpbmcuICBJbmdyZXNzIExTUidzIGNhbiB1c2UgTFNQIFNl bGYtDQo+ICAgIHBpbmcgdG8gdmVyaWZ5IHRoYXQgYW4gTFNQIGlzIHJlYWR5IHRvIGNhcnJ5IHRy YWZmaWMuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Oct 23 22:15:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982EB1A88A9; Thu, 23 Oct 2014 22:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvKlVxEdYixn; Thu, 23 Oct 2014 22:15:11 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935A61A6F1E; Thu, 23 Oct 2014 22:15:11 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lj1so460154pab.38 for ; Thu, 23 Oct 2014 22:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=kLNSNHZN7xIylAYSEV3TdB8edcMNxbB2XeA/PwrdRLA=; b=LqFuibfb0JZ23v+XdU4lWVQG1LrKkOB+mkEjK0sPvR+HYglgR8VqlzpUsWW8gj6bdR vS6RVeHbtwBLG0Gidh9cresU2aDn8vihCHNz/hG9R8GuM9U29DKT8ElYolkqxEp2Ecnq 01F8bdubwHbPzzOUM20Opggh+zQv+VFV8VH9YU1WXcSrxUZ2hdU6lJpa+IuwFFFcyx/m S0Irr9VFNKyGZ6PIS3vSLeHupYZ9rqc1PGNwYBBMYuznoWKTKtiU1FWqwRScrNzj9WtX yYrdwLapV02dlixh0Cosl9U4cpwHTpwagAhTMxJDV4AbGTL03euJDABVIhea2Tx+buhE 0k8w== X-Received: by 10.70.65.37 with SMTP id u5mr2163412pds.93.1414127711174; Thu, 23 Oct 2014 22:15:11 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id qx4sm2909260pbc.14.2014.10.23.22.15.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Oct 2014 22:15:10 -0700 (PDT) From: "Lizhong Jin" To: "'Carlos Pignataro \(cpignata\)'" References: <012001cfec30$18d91920$4a8b4b60$@gmail.com> <54465FED.6030005@joelhalpern.com> <5446847D.4030500@joelhalpern.com> <00ff01cfed9c$caf88740$60e995c0$@gmail.com> <5447131F.5040709@joelhalpern.com> <010101cfeda3$0cfaf820$26f0e860$@gmail.com> <544720FD.5030703@joelhalpern.com> <010901cfedb3$3a47b2e0$aed718a0$@gmail.com> <5447B18C.7050109@joelhalpern.com> <6088D699-48F9-4CE1-BA02-D65D1A4777C9@gmail.com> <2285EF10-FD10-459B-B1B5-AB1960FB257E@cisco.com> In-Reply-To: <2285EF10-FD10-459B-B1B5-AB1960FB257E@cisco.com> Date: Fri, 24 Oct 2014 13:15:04 +0800 Message-ID: <02dd01cfef49$7b6ce960$7246bc20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoLsexpoDjeNgEXN4xVax6BLciqgI4g/XAAhLnkzMCHjdnVwJETDgiAMwAguMCSbWPXwLVKPYoARVG9nACTEiOeAIFm06bApKT4d6a2aC2gA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UOWS8qe28suv2WyNONcYimckSxs Cc: 'Joel Halpern Direct' , gen-art@ietf.org, "'draft-ietf-mpls-lsp-ping-relay-reply.all'" , ietf@ietf.org, mpls@ietf.org Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 05:15:14 -0000 Carlos, yes, and thanks for the review. Regards Lizhong > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 2014=E5=B9=B410=E6=9C=8823=E6=97=A5 22:29 > To: Lizhong Jin > Cc: Joel Halpern Direct; mpls@ietf.org; gen-art@ietf.org; = draft-ietf-mpls-lsp- > ping-relay-reply.all; ietf@ietf.org > Subject: Re: [mpls] [Gen-art] review: = draft-ietf-mpls-lsp-ping-relay-reply-04 >=20 > Hi Lizhong, >=20 > Please also take into consideration the Ops Dir review of this doc, in = which I > have similar concerns as those from Joel. >=20 > There seem to be three major areas in discussion: > 1. The scope of the problem being solved (i.e., which cases are = solved, which > are not, and which are the common cases) 2. The mechanism itself not > working in many cases. > 3. How this all works with IPv6 addresses (since your fix seems to = cover the > overlapping IPv4 private address case only) >=20 > Thanks, >=20 > Carlos. >=20 > > On Oct 22, 2014, at 10:05 AM, lizho.jin@gmail.com wrote: > > > > Joel, thank you for the review. We will send out a new version soon = to > reflect the discussion. > > > > Regards > > Lizhong > > > > > > > >> =E5=9C=A8 = 2014=E5=B9=B410=E6=9C=8822=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:30=EF=BC=8C= Joel Halpern Direct > > >> wrote=EF=BC=9A > >> > >> It would be good to see a revision that clearly spelled out what = the > >> draft was solving, how the initial end-point knew what to create, = and > >> how the responder knew what to use. It may well be that there is = an > >> effective solution to the problems here. I look forward to seeing = it > >> in writing. > >> > >> Yours, > >> Joel > >> > >>> On 10/22/14, 12:46 AM, Lizhong Jin wrote: > >>> Hi Joel, > >>> The things may not be that bad. You could add a second address > >>> (address B in our example) with K bit set. The address entry with = K > >>> bit set must be as a relay node, and could not be skipped. > >>> Section 4.4 should be changed to: Find the first routable address = A, > >>> and the first address B with K bit set. If address A is before > >>> address B in the stack, then use address B as the relay address. > >>> Otherwise, use address A as the relay address. > >>> In that case, if A is the private address, the packet will be > >>> firstly relayed to address B. And address A and B belong to one > >>> router. Here I assume one router at least has one routable address = for > another AS. > >>> > >>> Regards > >>> Lizhong > >>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Sent: 2014=E5=B9=B410=E6=9C=8822=E6=97=A5 11:14 > >>>> To: Lizhong Jin > >>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > >>> 'draft-ietf-mpls-lsp-ping- > >>>> relay-reply.all' > >>>> Subject: Re: [mpls] [Gen-art] review: > >>> draft-ietf-mpls-lsp-ping-relay-reply-04 > >>>> > >>>> ou are saying that this is only for the case where an AS is using > >>>> public addresses for its internal numbering, but is not > >>>> distributing that address > >>> block > >>>> externally? > >>>> > >>>> If so, you need to state that very clearly. > >>>> I believe a far more common case is one where the numbering is = from > >>>> a portion of a publicly allocated space, but firewalled. Which > >>>> would > >>> produce > >>>> the same problem, but would not be amenable to this solution. > >>>> And it is well known that many ISPs do internal number assignment > >>>> from private blocks. > >>>> > >>>> So what you are now saying is that this draft solves a very small > >>>> portion > >>> of the > >>>> problem? But it works for that small portion? If so, at the = very > >>>> least > >>> you > >>>> need to be VERY clear about what cases this works for and what > >>>> cases it > >>> does > >>>> not. And I fear that even if you are clear, it is going to be = very > >>> confusing for > >>>> folks who are trying to use it. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>>> On 10/21/14, 10:51 PM, Lizhong Jin wrote: > >>>>> Hi Joel, > >>>>> I now see your concern. The "private" word in draft is not > >>>>> correct, I will remove it. The original motivation of > >>>>> "draft-relay-reply" is from the scenario where IP address > >>>>> distribution is restricted among AS or IGP > >>>> area. > >>>>> And the IP address is not private address. As I know, most > >>>>> deployed inter-AS or inter-area MPLS LSP is in the network = without > >>>>> private IP > >>> address. > >>>>> > >>>>> Regards > >>>>> Lizhong > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>>>> Sent: 2014=E5=B9=B410=E6=9C=8822=E6=97=A5 10:15 > >>>>>> To: Lizhong Jin > >>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > >>>>> 'draft-ietf-mpls-lsp-ping- > >>>>>> relay-reply.all' > >>>>>> Subject: Re: [mpls] [Gen-art] review: > >>>>> draft-ietf-mpls-lsp-ping-relay-reply-04 > >>>>>> > >>>>>> The problem is that the original source A, that we are trying = to > >>>>>> reach > >>>>> with a > >>>>>> reply, has an address that appears to the responder X to be = routable. > >>>>>> But the destination that is reached by that address is either a > >>>>>> black hole or > >>>>> some > >>>>>> other entity using the same address. > >>>>>> > >>>>>> The reason for the duplication is that, as described in the > >>>>>> draft, the > >>>>> source > >>>>>> address for A is a private address. That same address may well > >>>>>> be > >>>>> reachable > >>>>>> according to the routing table at X. But it won't get to A. > >>>>>> > >>>>>> If the problem is something other than private addressing > >>>>>> preventing reachability, it is likely there is still a mistaken > >>>>>> routability problem, > >>>>> but I can > >>>>>> not illustrate the failure without some other case being = described. > >>>>>> > >>>>>> Yours, > >>>>>> Joel > >>>>>> > >>>>>>> On 10/21/14, 10:06 PM, Lizhong Jin wrote: > >>>>>>> Inline, thanks. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>>>>>> Sent: 2014=E5=B9=B410=E6=9C=8822=E6=97=A5 0:06 > >>>>>>>> To: lizho.jin@gmail.com > >>>>>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf@ietf.org; > >>>>>>> draft-ietf-mpls-lsp-ping- > >>>>>>>> relay-reply.all > >>>>>>>> Subject: Re: [mpls] [Gen-art] review: > >>>>>>> draft-ietf-mpls-lsp-ping-relay-reply-04 > >>>>>>>> > >>>>>>>> In line. > >>>>>>>> > >>>>>>>>> On 10/21/14, 10:36 AM, lizho.jin@gmail.com wrote: > >>>>>>>>> Hi Joel, see inline below, thanks. > >>>>>>>>> > >>>>>>>>> Lizhong > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> 2014.10.21=EF=BC=8CPM9:30=EF=BC=8CJoel M. Halpern = > >>>> wrote =EF=BC=9A > >>>>>>>>>> > >>>>>>>>>> If the process for this draft is to use the top address = that > >>>>>>>>>> can be reached in the routing table, then there is a > >>>>>>>>>> significant probability that the original source address, > >>>>>>>>>> which is always at the top of the list, will be used. As > >>>>>>>>>> such, the intended problem will not be solved. > >>>>>>>>> [Lizhong] let me give an example to explain: the source > >>>>>>>>> address A is firstly added to the stack, then a second > >>>>>>>>> routable address B for replying AS is also added. The reply > >>>>>>>>> node will not use address A since it's not routable, then it > >>>>>>>>> will use address B. So it will work and I don't see the = problem. > >>>>>>>> > >>>>>>>> The whole point of this relay mechanism, as I understand it, = is > >>>>>>>> to cope > >>>>>>> with > >>>>>>>> the case when the responder X can not actually reach the = source > A. > >>>>>>>> Now suppose that the packet arrives at X with the Address > >>>>>>>> stack A, B, > >>>>> ... > >>>>>>> X > >>>>>>>> examines the stack. The domain of A was numbered using net = 10. > >>>>>>>> The domain of X is numbered using net 10. A's address is > >>>>>>>> probably > >>>>>>> routable > >>>>>>>> in X's routing table. The problem is, that routing will not > >>>>>>>> get to A. X > >>>>>>> examines > >>>>>>>> the stack, determines that A is "routable", and sends the = packet. > >>>>>>>> This > >>>>>>> fails to > >>>>>>>> meet the goal. > >>>>>>> [Lizhong] The source A you are referring is the initiator, = right? > >>>>>>> The goal of relay mechanism is to reach the initiator. If X is > >>>>>>> routable to the initiator (address A), then it is great, other > >>>>>>> relay node in the stack will be skipped. > >>>>>>> If the source A you are referring is the interface address of > >>>>>>> one intermediate node, then I do not understand "routing will > >>>>>>> not get to A. X examines the stack, determines that A is > >>>>>>> "routable", and sends the > >>>>>> packet". > >>>>>>> Why routing will not get to A, but A is routable? > >>>>>>> > >>>>>>> Regards > >>>>>>> Lizhong > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Yours, > >>>>>>>> Joel > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 24 00:38:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA11AD6FC; Fri, 24 Oct 2014 00:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hib0jpT2HqBf; Fri, 24 Oct 2014 00:37:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F98F1A8912; Fri, 24 Oct 2014 00:37:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024073749.375.78423.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:37:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-zoxDNXUESP3-fkmlYTSU4TzDjQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:37:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Ross Callon David Black Filename : draft-ietf-mpls-in-udp-06.txt Pages : 17 Date : 2014-10-24 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where congestion control is not a concern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 02:13:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925E11AD93D; Fri, 24 Oct 2014 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXD_RIahaC0v; Fri, 24 Oct 2014 02:13:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 689061A19E5; Fri, 24 Oct 2014 02:13:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024091304.8771.37609.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 02:13:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/F5KLce6u-g2V6SnBiOldG2maR5s Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:13:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Ross Callon David Black Filename : draft-ietf-mpls-in-udp-07.txt Pages : 17 Date : 2014-10-24 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where congestion control is not a concern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 10:49:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E271A89A4 for ; Fri, 24 Oct 2014 10:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOCL8Qu0cXn9 for ; Fri, 24 Oct 2014 10:49:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6861A89FB for ; Fri, 24 Oct 2014 10:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7318; q=dns/txt; s=iport; t=1414172932; x=1415382532; h=from:to:subject:date:message-id:mime-version; bh=szGhJS5zB+SPor0L1M7Naj0F/z18XugSg/awHF2gOOQ=; b=QssEPlYeRbsvMffRA1tHfmm4jW7x2/k48LOvjnbFrGp8gMyB7yXR+Rvw jOVsZywuC0r9Yl2QGpOaf7w8SE+QtUa3ASKSvofMugjlwUoFaC2xKgcXy Qn44qY8R0gVpUJgWbeflIuE816TLiI+ogNqbVPUwz+fnnNhF5qS7uS4Dp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGGQSlStJV2b/2dsb2JhbABcgkhGVFgE1HcCgQgWAX2EAgEBAQQtQR0BCBEDAQEBKDkUCAEKBAESiEHLEAEBAQEBAQEDAQEBAQEBAQEBGZA0ExeETAWPZ4Iei1iBMYNJjTKEAII0gURsgUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.04,781,1406592000"; d="scan'208,217"; a="90083783" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 24 Oct 2014 17:48:51 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9OHmpl5026391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 17:48:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 12:48:51 -0500 From: "Tarek Saad (tsaad)" To: "BRUNGARD, DEBORAH A" , "mpls@ietf.org" Thread-Topic: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 Thread-Index: AQHP77LExiLyp2wahE+NoOwkhTfGUw== Date: Fri, 24 Oct 2014 17:48:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.86.244.170] Content-Type: multipart/alternative; boundary="_000_D070092A14734Etsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/q704UcHni3Vpoc8fmoKyJV-8CrQ Subject: Re: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:49:31 -0000 --_000_D070092A14734Etsaadciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, Tarek From: , DEBORAH A > Date: Monday, October 20, 2014 at 5:38 PM To: "mpls@ietf.org" > Subject: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte= -ext-associated-lsp-11 FYI - From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Monday, October 20, 2014 5:27 PM To: ccamp@ietf.org Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-11 All, This starts a two-week working group last call on draft-ietf-ccamp-mpls-tp-= rsvpte-ext-associated-lsp-11. This working group last call ends on Nov. 3rd. Please send your comments to= the CCAMP mailing list. As noted, there is one IPR disclosed. Thanks, Deborah (and Lou) --_000_D070092A14734Etsaadciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Regards,
Tarek

From: <BRUNGARD>, DEBORAH A &= lt;db3546@att.com>
Date: Monday, October 20, 2014 at 5= :38 PM
To: "mpls@ietf.org" <mpls@i= etf.org>
Subject: [mpls] FW: [CCAMP] WG Last= Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11

FYI -

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, October 20, 2014 5:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-11

 

All,

 

This starts a two-week working group last call on draft-ietf= -ccamp-mpls-tp-rsvpte-ext-associated-lsp-11.

 

This working group last call ends on Nov. 3rd. Please send your comments to the CCAMP mailing list.

 

As noted, there is one IPR disclosed.

 

Thanks,

Deborah (and Lou)

 

 --_000_D070092A14734Etsaadciscocom_-- From nobody Fri Oct 24 11:07:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C511D1A8AAF for ; Fri, 24 Oct 2014 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y5ZAybr9v5H for ; Fri, 24 Oct 2014 11:07:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72FD1A8AAC for ; Fri, 24 Oct 2014 11:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9424; q=dns/txt; s=iport; t=1414174020; x=1415383620; h=from:to:subject:date:message-id:mime-version; bh=H9ZkhFk13FdtJD7eZyXsgaNThBOOz0Z4LDg7fvu9m4M=; b=E/pHib79xn77DJKQU00+dDPSh1PvYqyYGqUTfbVaZtkKrobKugDCxhzA WX+9oC12ZOhr1I51BxTPu1G9ITh29STIX4aDflVgD8NDs76cQBqPPgsum 92svEUNBjNd0mm/0ff8WlJ0crZIs++KkvC1Ai5yqNj+4CP8ytReD98Xhx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN+USlStJV2d/2dsb2JhbABcgkhGVFgE1HcCgQgWAX2EAgEBAQQtQR0BCBEDAQEBCx05FAgBCQEEARIIiDnLIwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQJw0TF4MugR4Fj2eCHo0Jg0mNMoQAgjSBRGyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,781,1406592000"; d="scan'208,217"; a="90075668" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 24 Oct 2014 18:06:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9OI6xuC030500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 18:06:59 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.22]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 13:06:59 -0500 From: "Siva Sivabalan (msiva)" To: "BRUNGARD, DEBORAH A" , "mpls@ietf.org" Thread-Topic: FW: [mpls] [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 Thread-Index: Ac/vtUq27VYQgm5wSP+3P0LXK81UAw== Date: Fri, 24 Oct 2014 18:06:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.44] Content-Type: multipart/alternative; boundary="_000_E2529AC6415F6B4197901F2B67212E9A15BFB624xmbrcdx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S9HuvLqutG-1qxjHhjaykuVPwdk Subject: Re: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 18:07:02 -0000 --_000_E2529AC6415F6B4197901F2B67212E9A15BFB624xmbrcdx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, Siva From: , DEBORAH A > Date: Monday, October 20, 2014 at 5:38 PM To: "mpls@ietf.org" > Subject: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte= -ext-associated-lsp-11 FYI - From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Monday, October 20, 2014 5:27 PM To: ccamp@ietf.org Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-11 All, This starts a two-week working group last call on draft-ietf-ccamp-mpls-tp-= rsvpte-ext-associated-lsp-11. This working group last call ends on Nov. 3rd. Please send your comments to= the CCAMP mailing list. As noted, there is one IPR disclosed. Thanks, Deborah (and Lou) --_000_E2529AC6415F6B4197901F2B67212E9A15BFB624xmbrcdx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

Thanks,=

Siva

 <= /p>

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Monday, October 20, 2014 at 5:38 PM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: [mpls] FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp-11

 

FYI -

 

From: CCAMP [mailto:cca= mp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, October 20, 2014 5:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-11

 

All,

 

This starts a two-week work= ing group last call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-1= 1.

 

This working group last cal= l ends on Nov. 3rd. Please send your comments to the CCAMP mailing list.

 

As noted, there is one IPR = disclosed.

 

Thanks,

Deborah (and Lou)

 

--_000_E2529AC6415F6B4197901F2B67212E9A15BFB624xmbrcdx13ciscoc_-- From nobody Sun Oct 26 11:50:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC681A0393; Sun, 26 Oct 2014 11:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRwgmXtNvCQk; Sun, 26 Oct 2014 11:50:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F60B1A0395; Sun, 26 Oct 2014 11:50:34 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-5b-544cea9cad5e Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.7F.05330.C9AEC445; Sun, 26 Oct 2014 13:35:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Sun, 26 Oct 2014 14:50:32 -0400 From: Gregory Mirsky To: Loa Andersson , "lime@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8QWoq6L8YEpRpUWvu3QGOKSPx5xCtlHQ Date: Sun, 26 Oct 2014 18:50:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> References: <544CC985.9060808@pi.nu> In-Reply-To: <544CC985.9060808@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPuO7cVz4hBq/uc1p0bNvOZPFv7hxm i1tLV7Ja/H5+m9mBxWPJkp9MHrOmt7EFMEVx2aSk5mSWpRbp2yVwZdxb0ctUcIqn4lz3ddYG xsOcXYycHBICJhLHTy9jgrDFJC7cW8/WxcjFISRwhFHi0IX37BDOckaJHw+vMYJUsQkYSbzY 2MMOYosIlErsm70MKM7BwSygLHHqrgxIWFjAUqLjxS2oEiuJJz9+sYGUiAC1zmsMAgmzCKhK POw6CbaXV8BX4nvXVrDpQgIqEtvOTGEFsTmBahatucMCYjMC3fb91BqwemYBcYlbT+ZD3Swg sWTPeWYIW1Ti5eN/rBC2ksTH3/PZIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyipGjtDi1LDfdyGATIzBujkmw6e5g3PPS8hCjAAejEg/vglCfECHWxLLi ytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPQqWexjOH2egdjx/3Je axjOHLWtnt7r+/Xkkrcf3Y5UZmuoW8okbpt39vfPrTd0fARUlVSjV+hXKE57t7Ux7IxH5cpJ Nawui7bOr5gb+JHvxsGMMFaGZ5fSOLJut6qtWJrLOtOzVJeN61HJSSdFqQkbtm6SONDmdEZ2 hvXerN1hQXPzdTu/zlBiKc5INNRiLipOBAChqlCkfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6fItzqUBB2q7TRYsox-bYAJZMsw Cc: "mpls@ietf.org" Subject: Re: [mpls] [Rtg-yang-coord] hopefully a simple question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 18:50:38 -0000 Hi Loa, I think that your question is not simple at all and it would be a great to = discuss how Generic OAM proposal is related to MPLS OAM at the meeting. Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment = Routing (as far as transport layer for the latter two) OAMs but one MPLS OA= M with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing ne= tworks. Regards, Greg -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Loa Andersson Sent: Sunday, October 26, 2014 3:14 AM To: lime@ietf.org; Rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] hopefully a simple question Folks, I have what I hope is a simple question, and that it will only reveal that = I'm not up to speed on yang. I trying to figure out the relationship between the generic yang models in = e.g. draft-tissa-lime-yang-oam-model and the specific models we do for diff= erent variants of e.g. mpls oam. I guess we have a structure more or less like this mpls | |- ldp | |-ldp oam | |- rsvp-te | | | |- rsvp-te oam | |- lsp ping | | | |- lsp ping oam | |- etc Where does the generic work fit in? /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Oct 26 14:31:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF971A1AAF; Sun, 26 Oct 2014 14:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBA9P_x3SL5W; Sun, 26 Oct 2014 14:31:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18801A1A9E; Sun, 26 Oct 2014 14:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6506; q=dns/txt; s=iport; t=1414359068; x=1415568668; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XJHnI14gfJa91YgF43dYfk9D4moFpMIZNN8PkUaqB3E=; b=KlCPaR3Uz4yUfxMzcnkzxiB+C7zCgm5JzExH+aaiw/TrbrgMRiV2zOXf le+4WxGYX5x2d6mX3T3kKGKvLxTJ5A7kcmFm10gFllAJvtIgsEa50d/DS z3WduVATm5EgakKDAcT2dFZTuYPe8pgrr+X8Ko4yUIkqh/4MCH2FqwCwY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKdnTVStJV2Q/2dsb2JhbABcgmsjVFMFBMxsCoZ5VAKBCRYBfYQCAQEBBAEBATc0CQ4EAgEIEQQBAQsUCQcnCxQIAQgCBAESCAGIOAEHBcdGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXOAaDJ4EeBY9pgh6ESIhDPIMNgy2GaIMfhACCNIFEbIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,791,1406592000"; d="scan'208";a="366655403" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 26 Oct 2014 21:31:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9QLV7au029321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 21:31:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 16:31:07 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP7vuLnXrxVtGdr0an+IEI1vxrJpw+GV8QgATDqGA= Date: Sun, 26 Oct 2014 21:31:07 +0000 Message-ID: References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FJBDX8Utnk45cUa5-aolaFdkjD4 Subject: Re: [mpls] [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:31:11 -0000 Hi Greg, Jeff, et al, Please find below my comments on draft-mirsky-mpls-bfd-directed. 1) General - clarification I realize that there's no explicit code point overlap between draft-mirsky-= mpls-bfd-directed and draft-chen-mpls-bfd-enhancement: draft-mirsky-mpls-bf= d-directed is focused on Segment Routing whilst draft-chen-mpls-bfd-enhance= ment is focused on existing MPLS technologies. However, both documents are = describing how to program the reverse BFD path on the egress LSR via LSP Pi= ng. It would be nice to have one way of doing this, whether the technology = is Segment Routing or something else. Can authors of draft-mirsky-mpls-bfd-= directed and draft-chen-mpls-bfd-enhancement sync up to come up with a sing= le approach? 2) Section 1 - clarification The [RFC5880], [RFC5881], and the [RFC5883] established BFD protocol for IP networks and the [RFC5884] set rules of using BFD Asynchronous mode over IP/MPLS LSPs. The described problem is valid, but: - I don't think the same problem applies to RFC5881 (aka single-hop BFD), a= s sessions are bound to the interface being monitored. - The same problem is definitely not applicable to RFC5880 which is the bas= e protocol spec (i.e. does not define any data plane procedures). Perhaps you can list only RFC5883/RFC5884 or add some clarifications on why= RFC5880/RFC5881 are also listed. 3) Section 1 - clarification And because BFD control packets are not guaranteed to cross the same links and nodes in both directions detection of Loss of Continuity (LoC) defect in forward direction is not guaranteed or is free of positive negatives. I tripped over the words "... free of positive negatives" and had to read t= his multiple times. This is purely a nit comment, but I think what you want= to say here is "... free of false negatives"? 4) Section 2 s/BF D/BFD/ [NOTE] Remove space between 'F' and 'D'. 5) Section 2 - some text suggestion [OLD] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. [NEW] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. The head-end node in this case will detect a problem due to lack of expected BFD control packets (i.e. detection timer expiry) instead of immediately receiving BFD control packets with explicit Down messages from the far-end peer. 6) Section 3.3 - clarification [snip] Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed. " When LSP ping is used to bootstrap BFD session this document updates this and defines that LSP Ping MUST include the FEC corresponding to the destination segment and SHOULD NOT include FECs corresponding to some or all of segment imposed by the initiator. Operationally such restriction would not cause any problem or uncertainty as LSP ping with FECs corresponding to some or all segments or traceroute may preceed the LSP ping that bootstraps the BFD session. [snip] Right now draft-kumarkini-mpls-spring-lsp-ping states, "MAY include other F= ECs". draft-mirsky-mpls-bfd-directed updates this by stating, "SHOULD NOT include= other FECs". It seems to me that the both aren't very different and the proposed mechani= sm will work whether this change is made or not. Can you clarify why this d= ocument makes above update? 7) General - additional reference With Segment Routing, there can be multiple SR-TE paths between the same so= urce/destination pairs, with subset of SR-TE paths ending with same SID. Th= us, there's a strong dependency from this mechanism described to draft-grma= s-bfd-rfc5884-clarifications. It might be a good idea that implementation o= f draft-mirsky-mpls-bfd-directed will require draft-grmas-bfd-rfc5884-clari= fications. Thanks! -Nobo > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Thursday, October 23, 2014 4:02 PM > To: rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org > Subject: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd- > directed-01.txt >=20 > Dear All, > a new section 3.3 Bootstrapping BFD session with BFD Reverse Path over > Segment Routed tunnel been added. Authors always welcome your > comments and greatly appreciate suggestions. We're looking forward to > continue discussion at WG meetings at IETF-91. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 23, 2014 12:57 PM > To: Gregory Mirsky; Jeff Tantsura; Gregory Mirsky; Jeff Tantsura; Ilya > Varlashkin; Ilya Varlashkin > Subject: New Version Notification for draft-mirsky-mpls-bfd-directed-01.t= xt >=20 >=20 > A new version of I-D, draft-mirsky-mpls-bfd-directed-01.txt > has been successfully submitted by Greg Mirsky and posted to the IETF > repository. >=20 > Name: draft-mirsky-mpls-bfd-directed > Revision: 01 > Title: Bidirectional Forwarding Detection (BFD) Directed Return > Path > Document date: 2014-10-23 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd= - > directed-01.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd- > directed/ > Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed= -01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-bfd-= directed- > 01 >=20 > Abstract: > Bidirectional Forwarding Detection (BFD) is expected to monitor bi- > directional paths. When a BFD session monitors in its forward > direction an explicitly routed path there is a need to be able to > direct far-end BFD peer to use specific path as reverse direction of > the BFD session. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sun Oct 26 16:58:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B481A1B55; Sun, 26 Oct 2014 16:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGNPZ06eRhrz; Sun, 26 Oct 2014 16:58:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 692641A1B3F; Sun, 26 Oct 2014 16:58:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026235849.29463.72058.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 16:58:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2JJA5o1Qr5v94jZyXb6pOXBo1ac Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-egress-protection-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 23:58:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Zhenbin Li Ning So Autumn Liu Tarek Saad Fengman Xu Mehmet Toy Lu Huang Lei Liu Filename : draft-ietf-mpls-rsvp-egress-protection-02.txt Pages : 16 Date : 2014-10-26 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-egress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-egress-protection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-egress-protection-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 Oct 26 17:03:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC941A1B5A; Sun, 26 Oct 2014 17:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enWJQctSstET; Sun, 26 Oct 2014 17:03:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFDB1A1B6A; Sun, 26 Oct 2014 17:03:35 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03XCb002032; Mon, 27 Oct 2014 00:03:33 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R03OgR001928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 00:03:27 GMT From: "Adrian Farrel" To: "'Gregory Mirsky'" , "'Loa Andersson'" , , References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> Date: Mon, 27 Oct 2014 00:03:20 -0000 Message-ID: <000601cff179$707a8c10$516fa430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuTtmLR0JtP8jl1thBqlYiJvncbQIIekC6nHYNOxA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21056.003 X-TM-AS-Result: No--11.648-10.0-31-10 X-imss-scan-details: No--11.648-10.0-31-10 X-TMASE-MatchedRID: +f/wAVSGjujuqBuVmgcCWiZm6wdY+F8KQKuv8uQBDjobQ3XP/Jy4srQn Y6ZuVLghlJXBvk7vV78btzXOkWU9Db0Xs0pxYyWVkE7MrqaPYs0ZKp0SZ4P+dU/N5GQtssoCM+p +NpswZmrPVbpsm8zN9R6i22jnAC+aTkaqbB0m3sLM1jffIgQXhvDfYikgJILntXl9IxEPXOqKLb gZyq471ydN4fsjEEgTzZpvrLjwrYswJ6xbTjBa5nPrqnZdfJhvB4Ntzrj5dXT1gF7PCEF9bpXPK 5yaPhuRRnUgijdt6WSjT363D9PEXmFqPXSLpNdAQr2qXCJMSV91k+gP1XamtJsoi2XrUn/JyeMt MD9QOgCk8oKXKhRLPI2j49Ftap9EOwBXM346/+yTvgMUZZgtmd2rQEdDtjeyiYqTJWk6yfwxGYz ha73cl5yTUb231vQ3 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/t7CAGS5QfRz-kfPXcoMSKlEIicU Cc: mpls@ietf.org Subject: Re: [mpls] [Rtg-yang-coord] hopefully a simple question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:03:38 -0000 The intention of LIME (who knows whether it is achievable?) is to produce a single YANG module that provides a generic way in to OAM across all IETF technologies. There are certainly a number of core concepts, configurable items, and reportable things that can be stated in a technology independent way. LIME has as a deliverable a set of applicability statements showing how the generic module is applied to different IETF OAM technologies. I should not be surprised if technology-specific modules are also required. I think LIME hopes that these will build on the generic module and not reinvent. I assume this will be through augmentation. And I assume the work will be done by the WGs that own the technologies (where those WGs exist). I don't think I understand your tree. Why would "RSVP-TE OAM" live under rsvp-te under mpls? The OAM is going to be standard mpls oam, but the concepts (MIPs, MEPs, on/off, failure found, etc.) are general. Adrian > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > Gregory Mirsky > Sent: 26 October 2014 18:51 > To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question > > Hi Loa, > I think that your question is not simple at all and it would be a great to discuss > how Generic OAM proposal is related to MPLS OAM at the meeting. > Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment > Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM > with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing > networks. > > Regards, > Greg > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Sunday, October 26, 2014 3:14 AM > To: lime@ietf.org; Rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] hopefully a simple question > > Folks, > > I have what I hope is a simple question, and that it will only reveal that I'm not up > to speed on yang. > > I trying to figure out the relationship between the generic yang models in e.g. > draft-tissa-lime-yang-oam-model and the specific models we do for different > variants of e.g. mpls oam. > > I guess we have a structure more or less like this > > mpls > | > |- ldp > | |-ldp oam > | > |- rsvp-te > | | > | |- rsvp-te oam > | > |- lsp ping > | | > | |- lsp ping oam > | > |- etc > > > Where does the generic work fit in? > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Oct 26 17:12:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED1E1A1B77; Sun, 26 Oct 2014 17:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNg67sg500kq; Sun, 26 Oct 2014 17:12:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 921DE1A1B28; Sun, 26 Oct 2014 17:12:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027001217.22869.185.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 17:12:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Gg0ys6re3bv1dm_lqUsDoDfvAS8 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-ingress-protection-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:12:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-mpls-rsvp-ingress-protection-02.txt Pages : 23 Date : 2014-10-26 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-ingress-protection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-ingress-protection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 04:32:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6801A1AE6; Sun, 26 Oct 2014 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFwHClBePifY; Sun, 26 Oct 2014 17:15:45 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9B11A1B2A; Sun, 26 Oct 2014 17:15:45 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id h18so2125340igc.4 for ; Sun, 26 Oct 2014 17:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y5Ao9ZHaFWzDWnvs9LsKY/ZsPZ1molypQLxvSv67vtk=; b=hUY/VUHbuuiQWxsaDXmQKjt/kAU+SO+ufJRtkRTMGpROYuR4lSjAq02h1n0CYmwkCB 3DgRirHVjP5OBGiIVDJBIIqtxmDC5S2KKrLNaeCfLH5q/oCt2bw7EWYYatNXEI9/amCL 50uXhWVbxXW+gMumj3iw32AWlXYtODKZmV0iqy936yfBvY5+/QnJAyiQicDor4TNvSaY pAEGMAQzA7Ii4NpLpTSB9XlBqW0X2OgZsMaCUZbVbvX50WcCVFsdw0H8Afz4l4tmR1/B W6Vb+OIAAvg294bA9S1ad1YKo8ozAgTngUqd4vmOvVAsagSwKewFiQu5I5CP+I/gI/e6 mUYA== X-Received: by 10.50.114.97 with SMTP id jf1mr18185293igb.29.1414368944657; Sun, 26 Oct 2014 17:15:44 -0700 (PDT) Received: from [192.168.0.102] ([216.254.166.33]) by mx.google.com with ESMTPSA id ro6sm4224439igb.3.2014.10.26.17.15.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 17:15:44 -0700 (PDT) Message-ID: <544D8EAA.9090909@gmail.com> Date: Sun, 26 Oct 2014 20:15:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Gregory Mirsky' , 'Loa Andersson' , lime@ietf.org, Rtg-yang-coord@ietf.org References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> In-Reply-To: <000601cff179$707a8c10$516fa430$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WsVFqpMEIvlGLcKxytyhfnIVW6Q X-Mailman-Approved-At: Mon, 27 Oct 2014 04:32:00 -0700 Cc: mpls@ietf.org Subject: Re: [mpls] [Rtg-yang-coord] hopefully a simple question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:15:48 -0000 This might be a good time to remind/alert people about the liaison statement received from the MEF regarding draft-tissa-lime-yang-oam-model. It can be found at https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef-netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf Tom Taylor On 26/10/2014 8:03 PM, Adrian Farrel wrote: > The intention of LIME (who knows whether it is achievable?) is to produce a > single YANG module that provides a generic way in to OAM across all IETF > technologies. > > There are certainly a number of core concepts, configurable items, and > reportable things that can be stated in a technology independent way. > > LIME has as a deliverable a set of applicability statements showing how the > generic module is applied to different IETF OAM technologies. > > I should not be surprised if technology-specific modules are also required. I > think LIME hopes that these will build on the generic module and not reinvent. I > assume this will be through augmentation. And I assume the work will be done by > the WGs that own the technologies (where those WGs exist). > > I don't think I understand your tree. Why would "RSVP-TE OAM" live under rsvp-te > under mpls? The OAM is going to be standard mpls oam, but the concepts (MIPs, > MEPs, on/off, failure found, etc.) are general. > > Adrian > >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of >> Gregory Mirsky >> Sent: 26 October 2014 18:51 >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org >> Cc: mpls@ietf.org >> Subject: Re: [Rtg-yang-coord] hopefully a simple question >> >> Hi Loa, >> I think that your question is not simple at all and it would be a great to > discuss >> how Generic OAM proposal is related to MPLS OAM at the meeting. >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment >> Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing >> networks. >> >> Regards, >> Greg >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Sunday, October 26, 2014 3:14 AM >> To: lime@ietf.org; Rtg-yang-coord@ietf.org >> Subject: [Rtg-yang-coord] hopefully a simple question >> >> Folks, >> >> I have what I hope is a simple question, and that it will only reveal that I'm > not up >> to speed on yang. >> >> I trying to figure out the relationship between the generic yang models in > e.g. >> draft-tissa-lime-yang-oam-model and the specific models we do for different >> variants of e.g. mpls oam. >> >> I guess we have a structure more or less like this >> >> mpls >> | >> |- ldp >> | |-ldp oam >> | >> |- rsvp-te >> | | >> | |- rsvp-te oam >> | >> |- lsp ping >> | | >> | |- lsp ping oam >> | >> |- etc >> >> >> Where does the generic work fit in? >> >> /Loa >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Mon Oct 27 09:11:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516A01ACEB5; Mon, 27 Oct 2014 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syMurbke1oZy; Mon, 27 Oct 2014 09:10:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0176B1ACEB3; Mon, 27 Oct 2014 09:09:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027160938.19401.5417.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 09:09:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dhriOwN3rYhvHznC2p3pmOHyqyM Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:10:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-atlas-mpls-ldp-mrt-02.txt Pages : 16 Date : 2014-10-27 Abstract: This document specifies extensions to LDP to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-atlas-mpls-ldp-mrt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 09:31:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1791A0079 for ; Mon, 27 Oct 2014 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OL8cgy-aJ0N for ; Mon, 27 Oct 2014 09:31:18 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2B91A001E for ; Mon, 27 Oct 2014 09:31:18 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9RGVFPJ003701; Mon, 27 Oct 2014 16:31:15 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9RGVDK8003658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 16:31:14 GMT From: "Adrian Farrel" To: References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> In-Reply-To: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:31:09 -0000 Message-ID: <018a01cff203$6b153790$413fa6b0$@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: AQL7UGOfqefUWMYm4qSTFIHYjrRClpntYhUg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21058.000 X-TM-AS-Result: No--11.508-10.0-31-10 X-imss-scan-details: No--11.508-10.0-31-10 X-TMASE-MatchedRID: kNb5oX97tjixpgqXoiq0QVvKDDArelUK+o81grvwYxyp7t/yrVnxkPNX dLzkV/F10c7w/2BhylDxTwx4UJIMcsSsicU7ThvNlVHM/F6YkvTDHSNFHFxB8/Q1K5DO1u1D0L2 eqCmMq5bFsr/XDkmMDLDg+Q5pepZ7ZyOqH+Hnn7nOUnHdMlbPm96jBoJi4nZLM/dZg2GSzOVqyt XrWXR35R0Z7hCD+QiF9fM3M7D29IHw8R0saVlSVIdlc1JaOB1Te6fn5Q3HlHq/xUIBoV49Vn4c+ dUfH4R8gEBR2HjnXiv27vlZQBKDdDcpdZ3fQiLdgxsfzkNRlfJeqSmMX0XSKdRnEQCUU+jzjocz muoPCq21dEBTogvy24VN8/0ylPXq06JnX9HVSnAe21rEF9vI1oY+b9Qx4jqB Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/85GwanSBEhfGE78xjr4G-LsQh4c Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:31:21 -0000 Hi MPLS WG, The Farrel twins have been playing with the concept of opportunistic = encryption for MPLS. This is very much positioned as an experiment. We'd like to hear from people who are interested in this as an idea we = should look into further. And, of course, we'd love to discuss the ideas in the draft. Adrian and Stephen > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 26 October 2014 23:16 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for = draft-farrelll-mpls-opportunistic-encrypt- > 03.txt >=20 >=20 > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-03.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 03 > Title: Opportunistic Security in MPLS Networks > Document date: 2014-10-26 > Group: Individual Submission > Pages: 30 > URL: = http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- > encrypt-03.txt > Status: = https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- > encrypt/ > Htmlized: = http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- > 03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- > encrypt-03 >=20 > Abstract: > This document describes a way to apply opportunistic security > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be agreed > to enable encryption, and how key identifiers are exchanged in > encrypted MPLS packets. Finally, this document describes the > applicability of this approach to opportunistic security in MPLS > networks with an indication of the level of improved security as > well as the continued vulnerabilities. >=20 > This document does not describe security for MPLS control plane > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Oct 27 10:21:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843E71A700A; Mon, 27 Oct 2014 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHiCt6QvNL_4; Mon, 27 Oct 2014 10:21:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FAB1A016A; Mon, 27 Oct 2014 10:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027172113.6908.52331.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 10:21:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JLrHrSoLN4Ql0tB1fBe5gtZXI-0 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kini-mpls-spring-entropy-label-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:21:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Entropy labels for source routed stacked tunnels Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Xiaohu Xu Wim Hendrickx Jeff Tantsura Filename : draft-kini-mpls-spring-entropy-label-02.txt Pages : 11 Date : 2014-10-27 Abstract: Source routed tunnel stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed stacked tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kini-mpls-spring-entropy-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kini-mpls-spring-entropy-label-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:30:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2B01AD472; Mon, 27 Oct 2014 13:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SksqrSuf1G; Mon, 27 Oct 2014 13:29:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473671AD477; Mon, 27 Oct 2014 13:29:56 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cc-544e5354a488 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.89.05330.4535E445; Mon, 27 Oct 2014 15:14:45 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 16:29:49 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP8WQqkhU0lIa9iUGgsm0LPdqTnJxEZfrA Date: Mon, 27 Oct 2014 20:29:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B873677@eusaamb103.ericsson.se> References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPoG5osF+IwdJTjBa3lq5ktZjdEW/x +c82RovjF34zOrB4TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZf9pmsBScM684ubadsYHx p04XIweHhICJxP4dMV2MnECmmMSFe+vZQGwhgSOMErN/M3UxcgHZyxklfh7dwQySYBMwknix sYcdJCEiMJNR4uLEK2AJYYE4iflnnzKB2CIC8RI/Tq2Eso0kJtzvYAdZxiKgKnH0vThImFfA V+Luju+sEMtOMEpsnxYAYnMCxWcdXQY2khHooO+n1oCNYRYQl7j1ZD4TxKECEkv2nGeGsEUl Xj7+xwphK0lMWnqOFaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKW BYwsqxg5SotTy3LTjQw2MQKj45gEm+4Oxj0vLQ8xCnAwKvHwbnDxDRFiTSwrrsw9xCjNwaIk zjurdl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYa26RlXx4q1xQ3MRaWzkyaF5nk4C6/ kHPPwZCM2qip39++U7T7Gf4s2+PwbZFZV5jLdjadlHh276OZ7W4WIcFLnjeV/Lj99O55bPpk dO+bgteEy2u5lHJ26rr7xd84ZfSDUV6u7ODDq409mkHebJN3Se5ynf+Lt2LBR630uv2HT7jv lVTs+KLEUpyRaKjFXFScCABqg+55bwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/omeZxFJq-WRUbyCGzp-IfHOF2k4 Subject: Re: [mpls] [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:29:59 -0000 Hi Nobo, your time and thoughtful comments much appreciated. We'll work with draft-chen-mpls-bfd-enhancement authors closely after the m= eeting. I'll prepare update to the most straightforward changes and then will addre= ss those that need more discussion. Kind regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Sunday, October 26, 2014 2:31 PM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org Subject: RE: [spring] FW: New Version Notification for draft-mirsky-mpls-bf= d-directed-01.txt Hi Greg, Jeff, et al, Please find below my comments on draft-mirsky-mpls-bfd-directed. 1) General - clarification I realize that there's no explicit code point overlap between draft-mirsky-= mpls-bfd-directed and draft-chen-mpls-bfd-enhancement: draft-mirsky-mpls-bf= d-directed is focused on Segment Routing whilst draft-chen-mpls-bfd-enhance= ment is focused on existing MPLS technologies. However, both documents are = describing how to program the reverse BFD path on the egress LSR via LSP Pi= ng. It would be nice to have one way of doing this, whether the technology = is Segment Routing or something else. Can authors of draft-mirsky-mpls-bfd-= directed and draft-chen-mpls-bfd-enhancement sync up to come up with a sing= le approach? 2) Section 1 - clarification The [RFC5880], [RFC5881], and the [RFC5883] established BFD protocol for IP networks and the [RFC5884] set rules of using BFD Asynchronous mode over IP/MPLS LSPs. The described problem is valid, but: - I don't think the same problem applies to RFC5881 (aka single-hop BFD), a= s sessions are bound to the interface being monitored. - The same problem is definitely not applicable to RFC5880 which is the bas= e protocol spec (i.e. does not define any data plane procedures). Perhaps you can list only RFC5883/RFC5884 or add some clarifications on why= RFC5880/RFC5881 are also listed. 3) Section 1 - clarification And because BFD control packets are not guaranteed to cross the same links and nodes in both directions detection of Loss of Continuity (LoC) defect in forward direction is not guaranteed or is free of positive negatives. I tripped over the words "... free of positive negatives" and had to read t= his multiple times. This is purely a nit comment, but I think what you want= to say here is "... free of false negatives"? 4) Section 2 s/BF D/BFD/ [NOTE] Remove space between 'F' and 'D'. 5) Section 2 - some text suggestion [OLD] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. [NEW] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. The head-end node in this case will detect a problem due to lack of expected BFD control packets (i.e. detection timer expiry) instead of immediately receiving BFD control packets with explicit Down messages from the far-end peer. 6) Section 3.3 - clarification [snip] Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed. " When LSP ping is used to bootstrap BFD session this document updates this and defines that LSP Ping MUST include the FEC corresponding to the destination segment and SHOULD NOT include FECs corresponding to some or all of segment imposed by the initiator. Operationally such restriction would not cause any problem or uncertainty as LSP ping with FECs corresponding to some or all segments or traceroute may preceed the LSP ping that bootstraps the BFD session. [snip] Right now draft-kumarkini-mpls-spring-lsp-ping states, "MAY include other F= ECs". draft-mirsky-mpls-bfd-directed updates this by stating, "SHOULD NOT include= other FECs". It seems to me that the both aren't very different and the proposed mechani= sm will work whether this change is made or not. Can you clarify why this d= ocument makes above update? 7) General - additional reference With Segment Routing, there can be multiple SR-TE paths between the same so= urce/destination pairs, with subset of SR-TE paths ending with same SID. Th= us, there's a strong dependency from this mechanism described to draft-grma= s-bfd-rfc5884-clarifications. It might be a good idea that implementation o= f draft-mirsky-mpls-bfd-directed will require draft-grmas-bfd-rfc5884-clari= fications. Thanks! -Nobo > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gregory=20 > Mirsky > Sent: Thursday, October 23, 2014 4:02 PM > To: rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org > Subject: [spring] FW: New Version Notification for=20 > draft-mirsky-mpls-bfd- directed-01.txt >=20 > Dear All, > a new section 3.3 Bootstrapping BFD session with BFD Reverse Path over=20 > Segment Routed tunnel been added. Authors always welcome your comments=20 > and greatly appreciate suggestions. We're looking forward to continue=20 > discussion at WG meetings at IETF-91. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 23, 2014 12:57 PM > To: Gregory Mirsky; Jeff Tantsura; Gregory Mirsky; Jeff Tantsura; Ilya=20 > Varlashkin; Ilya Varlashkin > Subject: New Version Notification for=20 > draft-mirsky-mpls-bfd-directed-01.txt >=20 >=20 > A new version of I-D, draft-mirsky-mpls-bfd-directed-01.txt > has been successfully submitted by Greg Mirsky and posted to the IETF=20 > repository. >=20 > Name: draft-mirsky-mpls-bfd-directed > Revision: 01 > Title: Bidirectional Forwarding Detection (BFD) Directed Return > Path > Document date: 2014-10-23 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd= - > directed-01.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd- > directed/ > Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed= -01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-bfd-= directed- > 01 >=20 > Abstract: > Bidirectional Forwarding Detection (BFD) is expected to monitor bi- > directional paths. When a BFD session monitors in its forward > direction an explicitly routed path there is a need to be able to > direct far-end BFD peer to use specific path as reverse direction of > the BFD session. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Oct 27 15:25:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A31A1AAE; Mon, 27 Oct 2014 15:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uh3UKoeApSi; Mon, 27 Oct 2014 15:25:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B16971A1A88; Mon, 27 Oct 2014 15:25:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027222532.23922.80861.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:25:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0Dj2Tr68M1Isa57ZLd4obmXjQko Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ravisingh-mpls-el-for-seamless-mpls-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:25:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Entropy label for seamless MPLS Authors : Ravi Singh Yimin Shen John Drake Filename : draft-ravisingh-mpls-el-for-seamless-mpls-03.txt Pages : 24 Date : 2014-10-27 Abstract: This document describes certain optimizations to how entropy labels can be used for load balancing in a seamless MPLS architecture, as enabled by LSP concatenation and LSP hierarchies. The definition of the control plane and data plane behavior at LSP concatenation points; and at the ingress of an LSP in a hierarchy of LSPs, as described in this document, brings the benefits of entropy labels to certain deployment scenarios that may not have had such benefits as specified in [EL-RFC]. This document, if approved, updates RFC 6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ravisingh-mpls-el-for-seamless-mpls-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-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 Mon Oct 27 15:25:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3B91A1A88 for ; Mon, 27 Oct 2014 15:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwftYCJgUJcF; Mon, 27 Oct 2014 15:25:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA801A1AA7; Mon, 27 Oct 2014 15:25:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ravisingh-mpls-el-for-seamless-mpls.all@tools.ietf.org, "Loa Andersson" , "Loa Andersson" X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027222532.23922.58294.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:25:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dTLjxMe2n8lWmjwTYO5c90zql8M Subject: [mpls] New Version Notification - draft-ravisingh-mpls-el-for-seamless-mpls-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:25:35 -0000 A new version (-03) has been submitted for draft-ravisingh-mpls-el-for-seamless-mpls: http://www.ietf.org/internet-drafts/draft-ravisingh-mpls-el-for-seamless-mpls-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-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. IETF Secretariat. From nobody Mon Oct 27 15:35:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9A1A1B38; Mon, 27 Oct 2014 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx0zGof9ByvV; Mon, 27 Oct 2014 15:35:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 740391A1B5C; Mon, 27 Oct 2014 15:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027223422.23903.38007.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:34:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eGL9zL0_xgWR2APPytxLv-aySmE Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ravisingh-mpls-el-for-seamless-mpls-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:35:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Entropy label for seamless MPLS Authors : Ravi Singh Yimin Shen John Drake Filename : draft-ravisingh-mpls-el-for-seamless-mpls-04.txt Pages : 24 Date : 2014-10-27 Abstract: This document describes certain optimizations to how entropy labels can be used for load balancing in a seamless MPLS architecture, as enabled by LSP concatenation and LSP hierarchies. The definition of the control plane and data plane behavior at LSP concatenation points; and at the ingress of an LSP in a hierarchy of LSPs, as described in this document, brings the benefits of entropy labels to certain deployment scenarios that may not have had such benefits as specified in [EL-RFC]. This document, if approved, updates RFC 6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ravisingh-mpls-el-for-seamless-mpls-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 15:35:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4B1A1B87 for ; Mon, 27 Oct 2014 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6w0PI067Ft1; Mon, 27 Oct 2014 15:35:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 852C81A1B60; Mon, 27 Oct 2014 15:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ravisingh-mpls-el-for-seamless-mpls.all@tools.ietf.org, "Loa Andersson" , "Loa Andersson" X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027223422.23903.28072.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:34:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZHjZ0jCFazLX1CHkrha8wPWo5UM Subject: [mpls] New Version Notification - draft-ravisingh-mpls-el-for-seamless-mpls-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:35:16 -0000 A new version (-04) has been submitted for draft-ravisingh-mpls-el-for-seamless-mpls: http://www.ietf.org/internet-drafts/draft-ravisingh-mpls-el-for-seamless-mpls-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-04 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. IETF Secretariat. From nobody Tue Oct 28 11:42:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94DE1A90D8 for ; Tue, 28 Oct 2014 11:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3NB74nsMtx2 for ; Tue, 28 Oct 2014 11:42:03 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7347C1A8F44 for ; Tue, 28 Oct 2014 11:42:03 -0700 (PDT) Received: from [216.82.253.163] by server-2.bemta-7.messagelabs.com id 72/D9-03095-A73EF445; Tue, 28 Oct 2014 18:42:02 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-8.tower-166.messagelabs.com!1414521721!21075568!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5464 invoked from network); 28 Oct 2014 18:42:01 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-8.tower-166.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Oct 2014 18:42:01 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id D79252B67E; Tue, 28 Oct 2014 18:42:09 +0000 (GMT) Received: from USIDCWVEHT04.corp.global.level3.com (10.1.196.124) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 12:42:01 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT04.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 12:42:00 -0600 From: "Osborne, Eric" To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt Thread-Index: AQL7UGOfqefUWMYm4qSTFIHYjrRClpntYhUggAGGfgA= Date: Tue, 28 Oct 2014 18:41:59 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> In-Reply-To: <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8gwu4NahBBnWYqlT0K-aup8Lh0w Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 18:42:06 -0000 First, a disclaimer. I know enough about crypto to know I don't know enoug= h about crypto to say anything useful about it. I assume the magic Just Wo= rks. Second, a question on the key change frequency. The document RECOMMENDs a new key every 10^6 packets, and sets a hard limit= of 2^64. This is a huge range, and the recommended value doesn't seem use= ful on anything modern. 160Mpps with a new key every 10^6 packets is 160 k= eys per second. Even on a 10Mb Ethernet it's almost a new key every minute= [1] per interface. Are there cryptographic reasons for the 10^6 recommendation? If not, can i= t be bumped to something saner, or perhaps provide a recommend range? Prac= tically speaking this is going to be so heavy to implement that any recomme= nded numbers should be about putting as much time as possible between key e= xchanges if they can't be eliminated outright. Third, a nit. Typo: Section 4.2.1, "bidirecitonal" eric [1] because I never trust myself to do math in public: at 16kpps for 10Mbit= ethernet and 10^6 packets per key, that's 0.02 keys/sec, or 0.96 keys/minu= te. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, October 27, 2014 12:31 PM To: mpls@ietf.org Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opport= unistic-encrypt-03.txt Hi MPLS WG, The Farrel twins have been playing with the concept of opportunistic encryp= tion for MPLS. This is very much positioned as an experiment. We'd like to hear from people who are interested in this as an idea we shou= ld look into further. And, of course, we'd love to discuss the ideas in the draft. Adrian and Stephen > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 26 October 2014 23:16 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for=20 > draft-farrelll-mpls-opportunistic-encrypt- > 03.txt >=20 >=20 > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-03.txt > has been successfully submitted by Adrian Farrel and posted to the=20 > IETF repository. >=20 > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 03 > Title: Opportunistic Security in MPLS Networks > Document date: 2014-10-26 > Group: Individual Submission > Pages: 30 > URL: http://www.ietf.org/internet-drafts/draft-farrelll-mpls-o= pportunistic- > encrypt-03.txt > Status: https://datatracker.ietf.org/doc/draft-farrelll-mpls-oppo= rtunistic- > encrypt/ > Htmlized: http://tools.ietf.org/html/draft-farrelll-mpls-opportunis= tic-encrypt- > 03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-op= portunistic- > encrypt-03 >=20 > Abstract: > This document describes a way to apply opportunistic security > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be agreed > to enable encryption, and how key identifiers are exchanged in > encrypted MPLS packets. Finally, this document describes the > applicability of this approach to opportunistic security in MPLS > networks with an indication of the level of improved security as > well as the continued vulnerabilities. >=20 > This document does not describe security for MPLS control plane > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 28 12:45:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEFD1ACD50 for ; Tue, 28 Oct 2014 12:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMCdRZ6bFgYA for ; Tue, 28 Oct 2014 12:45:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2479E1ACD4F for ; Tue, 28 Oct 2014 12:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4832; q=dns/txt; s=iport; t=1414525525; x=1415735125; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3lwSldgurjs/3EKElU4sewP57hU3khIfeMRmdoIwTfQ=; b=Yh+408K0PUcEL+CZaWjTIjNYVRPwyNabWUaOD0odVLasITCeyMsEiChk eeP76pRsMsE4UONRAMNcBXEb3XS8ngsRlWy2xhp0dm31TZXC2+7QV7akk dyT7prh2q9f2WxZlcMN9/EIHPg15biWOQLPqKmdS1gOQojogZFQoa1Q3D E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4FAKHxT1StJA2L/2dsb2JhbABcgmsjgSwEgwLTCgIbgQQWAQEBAQF9hAIBAQEDARgLEUUFCwIBCBgCAiYCAgIwFRABAQQOBYg4CQGyYZUKAQEBAQEBAQEBAQEBAQEBAQEBARmBLI57EQFQB4J3NoEeBY9tgh6LXYExg0mNO4QBg3hsgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,804,1406592000"; d="scan'208";a="367244901" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 28 Oct 2014 19:45:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9SJjMLQ019166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 19:45:23 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 14:45:22 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: AD review of draft-ietf-mpls-ipv6-only-gap Thread-Index: Ac/mauYYyhokKc65RvSg1yxokjWp6AMprgKA Date: Tue, 28 Oct 2014 19:45:21 +0000 Message-ID: <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> In-Reply-To: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.172.248] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cSGObuTY3f2herWpQi5W4IApiYQ Cc: "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:45:29 -0000 QWRyaWFuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcuIA0KDQpJIGFt IGFjdHVhbGx5IGZpeGluZyBhbHNvIGEgY291cGxlIG9mIHZlcnkgc21hbGwgZWRpdG9yaWFsIG5p dHMgSSBmb3VuZC4NCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KPiBPbiBPY3QgMTIsIDIwMTQs IGF0IDY6MjEgUE0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0K PiANCj4gVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgZG9jdW1lbnQuIEkgdGhpbmsgaXQgaXMg YW4gaW1wb3J0YW50IA0KPiBwaWVjZSBvZiB3b3JrIGFuZCBJIHdpbGwgc2VuZCBpdCB0byBJRVRG IGxhc3QgY2FsbC4NCj4gDQo+IFNldCBvdXQgYmVsb3cgeW91IHdpbGwgZmluZCBjb21tZW50cyBm cm9tIG15IEFEIHJldmlldy4gSSBkb24ndCB0aGluaw0KPiBhbnkgaXMgYmxvY2tpbmcgb3IgcmVx dWlyZXMgc3BlY2lmaWMgdXBkYXRlcyBiZWZvcmUgSUVURiBsYXN0IGNhbGwsDQo+IGJ1dCBJIHdv dWxkIGJlIGdsYWQgaWYgeW91IHdvdWxkIGFkZHJlc3MgdGhlbSBhbG9uZyB0aGUgd2F5IG9yIHNl bmQgbWUNCj4gZW1haWwgdG8gZGlzY3VzcyB0aGVtLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgd29y aywNCj4gQWRyaWFuDQo+IA0KPiA9PT0NCj4gDQo+IFRoZSBjaG9pY2Ugb2YgZG9jdW1lbnRzIHRv IHJlZmVyZW5jZSBmb3IgdGhlIGRpZmZlcmVudCBjb250cm9sIHBsYW5lDQo+IHNlY3Rpb25zIHJl bGF0ZWQgdG8gUlNWUC1URSBzZWVtZWQgaWRpb3N5bmNyYXRpYyB0byBtZS4gRm9yIGV4YW1wbGUs DQo+IHRoZSBHTVBMUyBzZWN0aW9uICgzLjIuNikgcmVmZXJlbmNlcyBSRkMgNDU1OCwgUkZDIDQ5 OTAsIGFuZCBSRkMgNjM3MA0KPiBhbGwgb2Ygd2hpY2ggY2VydGFpbmx5IGFyZSBHTVBMUyBkb2N1 bWVudHMsIGJ1dCB0aGVyZSBpcyBubyByZWZlcmVuY2UNCj4gdG8gdGhlIGJhc2UgR01QTFMgcHJv dG9jb2wgZG9jdW1lbnRzIChSRkMgMzQ3MSBhbmQgMzQ3Mykgbm9yIGEgYmFjaw0KPiBwb2ludGVy IHRvIHNlY3Rpb24gMy4yLjMuIFNpbWlsYXJseSwgdGhlIFBDRSBzZWN0aW9uICgzLjIuNCkgDQo+ ICBbSW5jaWRlbnRhbGx5LCB0aGlzIGhhcyBhIHJlYWxseSB3ZWlyZCBzZWN0aW9uIHRpdGxlISBX aGVyZQ0KPiAgIGRpZCAiY29udHJvbGxlciIgY29tZSBmcm9tLCBhbmQgd2h5IGlzIHRoZSBzZWN0 aW9uIG5hbWVkIA0KPiAgIGFmdGVyIGEgY29tcG9uZW50IGFuZCBub3QgYSBwcm90b2NvbCAoUENF UCk/XQ0KPiBpbmNsdWRlcyByZWZlcmVuY2VzIHRvIGEgbnVtYmVyIG9mIHByb3RvY29sIGV4dGVu c2lvbnMsIGJ1dCBuZWl0aGVyDQo+IDMuMi4zIG5vciAzLjIuNiBzZWVtIHRvIGNhcmUgYWJvdXQg dGhlIGRldGFpbGVkIHByb3RvY29sIGV4dGVuc2lvbnMgdG8NCj4gUlNWUC1URS4NCj4gDQo+IFRo aXMgaXNzdWUgaXNuJ3QgaW4gYW55IHdheSBhIHNob3ctc3RvcHBlci4gSXQganVzdCBtYWtlcyBt ZSB3b25kZXINCj4gYWJvdXQgdGhlIHByZWNpc2lvbiBvZiB0aGUgc3VydmV5IHdydCBSU1ZQLVRF IGdpdmVuIHRoZSBhbW91bnQgb2YgDQo+IGRldGFpbCBpbiBzb21lIG9mIHRoZSBvdGhlciBzZWN0 aW9ucy4NCg0KQWxsIGdvb2QgcG9pbnRzLCBhbGwgZml4ZWQgKEkgYmVsaWV2ZSkuDQoNCj4gDQo+ IC0tLQ0KPiANCj4gU2VjdGlvbiAzLjMuMyBoYXMNCj4gDQo+ICAgTVBMUy1UUCBkb2VzIG5vdCBy ZXF1aXJlIElQIChzZWUgc2VjdGlvbiAyIG9mIFJGQyA1OTIxIFtSRkM1OTIxXSkgYW5kDQo+ICAg c2hvdWxkIG5vdCBiZSBhZmZlY3RlZCBieSBvcGVyYXRpb24gb24gYW4gSVB2Ni1vbmx5IG5ldHdv cmsuDQo+ICAgVGhlcmVmb3JlIHRoaXMgaXMgY29uc2lkZXJlZCBvdXQgb2Ygc2NvcGUgZm9yIHRo aXMgZG9jdW1lbnQsIGJ1dCBpcw0KPiAgIGluY2x1ZGVkIGZvciBjb21wbGV0ZW5lc3MuDQo+IA0K PiBUaGlzIGlzIG9kZCEgSnVzdCBiZWNhdXNlIE1QTFMtVFAgZG9lcyBub3QgcmVxdWlyZSB0aGUg cHJlc2VuY2Ugb2YgSVAsDQo+IGRvZXMgbm90IG1lYW4gaXQgbWlnaHQgbm90IGJlIHRoZXJlIGFu ZCB1c2VkLiBJbmRlZWQsIGluIFNlY3Rpb24gMy4yLjYNCj4geW91IHJlZmVyZW5jZSBSRkM2Mzcw IGFuZCB1c2UgaXQgdG8gc3RhdGUgYSBtaW5vciBHTVBMUyBkZWZpY2llbmN5Lg0KPiBZZXQgNjM3 MCBpcyBhbiBNUExTLVRQIGRvY3VtZW50ISBJdCBpcyBhbGwgYWJvdXQgaG93IGlkZW50aWZpZXJz IGFyZQ0KPiBnZW5lcmF0ZWQgYW5kIHVzZWQgaW4gTVBMUy1UUCBuZXR3b3JrcywgYW5kIChhcyB0 aGUgUkZDIHNheXMpIGluIA0KPiBkb2N1bWVudHMgd2hlcmUgSVAgaXMgcHJlc2VudCwgdGhlIGlk ZW50aWZpZXJzIGNhbiBiZSBnZW5lcmF0ZWQgdXNpbmcgdGhlDQo+IGxvY2FsIElQIGFkZHJlc3Nl cy4NCj4gDQoNCkFjay4NCg0KPiBTaW1pbGFybHksIHNlY3Rpb24gMy40LjUgaXMgYSBsaXR0bGUg YW1iaXRpb3VzIGluIGl0cyBjbGFpbXMgb2YgemVybyANCj4gZGVwZW5kZW5jZSBvbiBJUCBzaW5j ZSBpZGVudGlmaWVycyBwbGF5IGFuIGltcG9ydGFudCBwYXJ0IGluIE1QTFMtVFAgDQo+IE9BTS4N Cj4gDQo+IFRoaXMgaXNzdWUgZG9lc24ndCBjaGFuZ2UgdGhlIGVuZCByZXN1bHQgKGFsdGhvdWdo IEkgd291bGQgcHJvYmFibHkgbW92ZQ0KPiB0aGUgcGFyYWdyYXBoIG9uIDYzNzAgZnJvbSBzZWN0 aW9uIDMuMi42IHRvIHRoaXMgc2VjdGlvbi4NCj4gDQoNCkFkZGVkIGEgbmV3IHBhcmFncmFwaCBp biBlYWNoIG9mIHRoZSBzZWN0aW9ucy4NCg0KPiAtLS0NCj4gDQo+IFRocm91Z2hvdXQsIHlvdSBz aG91bGQgcHJvYmFibHkgcmVmZXIgdG8gIk1JQiBtb2R1bGVzIiBub3QgIk1JQnPigJ0NCj4gDQoN CkluZGVlZCDigJQgZml4ZWQuDQoNCj4gLS0tDQo+IA0KPiBJIGFtIHNjZXB0aWNhbCBhYm91dCBz ZWN0aW9uIDMuNS4gRWFybGllciBpbiB0aGUgZG9jdW1lbnQgeW91IGhhdmUgDQo+IG1lbnRpb25l ZCB0aGUgZmFjdCB0aGF0IFJGQyA0OTkwIGV4cGxhaW5zIGhvdyB0byB1c2UgZXhpc3RpbmcgTUlC DQo+IG1vZHVsZXMgd2l0aCBJUHY2IGFkZHJlc3NlcywgYnV0IHlvdSBkb24ndCBtZW50aW9uIHRo YXQgUkZDIGhlcmUuDQo+IENvbnZlcnNlbHksIHlvdSBkbyBtZW50aW9uIGFuIGluZGl2aWR1YWwg SS1EIHRoYXQgZG9lcyBub3QgKHlldD8pDQo+IGhhdmUgd29ya2luZyBncm91cCBzdXBwb3J0IHRv IGZpeCBhIHByb2JsZW0gdGhhdCBpdCBpcyBub3QgY2xlYXIgaXMNCj4gdGhlIHByb2JsZW0gdGhh dCBuZWVkcyB0byBiZSBmaXhlZCBpbiBhIHdheSB0aGF0IHNlZW1zIHRvIG1lIHRvIGJlDQo+IHdy b25nLg0KDQpSRkMgNDk5MCBpcyBNUExTLVRQIHNwZWNpZmljLg0KDQpBZGRlZCBpdCB0aG91Z2gu DQoNCj4gDQo+IC0tLQ0KPiANCj4gSSBuZXZlciBvYmplY3QgdG8gbXkgbmFtZSBiZWluZyBzcGVs bGVkIGNvcnJlY3RseSA6LSkNCj4gDQoNCkZpeGVkLCB3aXRoIGFwb2xvZ2llcyEhIQ0KDQpJIHdp bGwgc2VuZCB5b3UgYSBuZXcgcmV2aXNpb24gbW9tZW50YXJpbHkuDQoNCkNhcmxvcy4NCg0K From nobody Tue Oct 28 14:44:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450101AD0A1; Tue, 28 Oct 2014 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxOwj2XHpZzh; Tue, 28 Oct 2014 14:44:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7841AD0A7; Tue, 28 Oct 2014 14:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028214405.23693.91454.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 14:44:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EMn6uJ8ho-3O8Yx3WYc9Y_PjCTw Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ipv6-only-gap-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:44:25 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Gap Analysis for Operating IPv6-only MPLS Networks Author(s) : W. George, et al Filename : draft-ietf-mpls-ipv6-only-gap Pages : 26 Date : 2014-10-28 This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-mpls-ipv6-only-gap-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ipv6-only-gap"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-28144405.I-D@ietf.org> --NextPart-- From nobody Tue Oct 28 14:58:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B91AD2B2 for ; Tue, 28 Oct 2014 14:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZesuKvyz-sT for ; Tue, 28 Oct 2014 14:58:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6501AD291 for ; Tue, 28 Oct 2014 14:58:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9SLtYdA029187; Tue, 28 Oct 2014 21:55:34 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9SLtX39029174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 21:55:34 GMT From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> In-Reply-To: <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> Date: Tue, 28 Oct 2014 21:58:26 -0000 Message-ID: <035901cff2fa$4da8fd20$e8faf760$@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: AQJvixUQwakdbx63j6KCa5k5aG2m5AEtT/YAmv1vesA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21060.003 X-TM-AS-Result: No--23.375-10.0-31-10 X-imss-scan-details: No--23.375-10.0-31-10 X-TMASE-MatchedRID: 1GZI+iG+MtenykMun0J1wlu4M/xm4KZemdndBk1gfyWe9toQ6h6LEwBh cLfcIUW7Y5Y8Cw+rM2RNWxNqXF3LDSbZZYAQu9H5CFaAixm5eU++1Vx7rDn4r4fAYSb4KlgZyxD KWChexUSdE6czz+eVhWu+6YvedpO5uk3J83eS1pnx5KZMlKYS/fa/bRHEsPI3Apu/6NhbMFYSrn IaYG1ImLuPEihjbbmpVkSDE/6liA0LazoQyrpm0ru9iqQJLR0vdAB35LoCrtRrEoFtNYg0C7ma4 Fww9APGMiRhSPldc+WljtIayIq1Zn1nJGs+dXwVACs2C3nGlBhwryoe90UcsP5haBSHR9bSA11C aBMcZGEIS5UXqe5IMV+24nCsUSFNjaPj0W1qn0SQZS2ujCtcuA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/g0ixthA1pXsayM2N13u--Rug19o Cc: mpls@ietf.org, draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:58:39 -0000 Hello, Thanks for the work and I am advancing the I-D. > > I am sceptical about section 3.5. Earlier in the document you have > > mentioned the fact that RFC 4990 explains how to use existing MIB > > modules with IPv6 addresses, but you don't mention that RFC here. > > Conversely, you do mention an individual I-D that does not (yet?) > > have working group support to fix a problem that it is not clear is > > the problem that needs to be fixed in a way that seems to me to be > > wrong. >=20 > RFC 4990 is MPLS-TP specific. Well now, that comes as a surprise to someone who wrote part of the = document and edited the final version :-) RFC 4990 is most assuredly not about MPLS-TP. There is no mention of = MPLS-TP in the document.=20 It is quite true that if you were using the GMPLS MIB modules (that = build on the MPLS-TE MIB modules) to manage an MPLS-TP network what you = have written in the new revision would be perfectly true. But RFC 4990 also explains the use of IPv6 in the MPLS-TE and GMPLS MIB = modules. Section 8 is pretty specific about that and provides a = mechanism to handle IPv6 extended tunnel IDs (it's a hack, Jim, but it = might just work!). That makes me somewhat sceptical about the size of the gap you have = identified. (I'm also not convinced that obsoleting an in-use TC will be a sound way = to make backward-compatible changes if they turn out to be necessary.) And now, of course, I start to worry about the level of review applied = to section 3.5 of this document. The consequence is not good: if this = section carries a bad analysis of the gaps then it is likely to be = ignored; if one section of this document is open to be ignored, what of = the other sections? Cheers, Adrian From nobody Tue Oct 28 15:12:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF31AD3C3 for ; Tue, 28 Oct 2014 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52Enj_XY1LTD for ; Tue, 28 Oct 2014 15:12:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032461AD34C for ; Tue, 28 Oct 2014 15:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2932; q=dns/txt; s=iport; t=1414534268; x=1415743868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oxZsB32d43P5ab4QXn0z7YiK8CR6L0xNHenVHfvpkr0=; b=QOLmdeoNxUu6fdW+G014V8QkPr/bbJ7MPGpHjCW9Fovs2miIqg1hXfxZ 9IZ8suQjzsRhfc7yx64bT5DKWqsbnfRNRhOuzGIqRASnIhpTReSe66ydG iSOQpk0DOgSDFjvdLXw71jdAGm8a7UECQ12vUTi2TIkxIUtsqRtgHIlRx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMoTUFStJV2S/2dsb2JhbABcgmsjgSwE1g8CgSMWAQEBAQFyC4QCAQEBBGcSDAQCAQgRAwECLzIUCQgBAQQOBYhBAcYfAQEBAQEBAQEBAQEBAQEBAQEBARmRCQcGhEUFiyqEQ4Iei12BMYNJkTyDeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="scan'208";a="91184690" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 28 Oct 2014 22:11:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9SMB60Y006204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 22:11:06 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 17:11:06 -0500 From: "Carlos Pignataro (cpignata)" To: "adrian@olddog.co.uk" Thread-Topic: AD review of draft-ietf-mpls-ipv6-only-gap Thread-Index: Ac/mauYYyhokKc65RvSg1yxokjWp6AMprgKAAASl2wD//8B4gA== Date: Tue, 28 Oct 2014 22:11:05 +0000 Message-ID: References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> In-Reply-To: <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.82.255.151] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LLTzE_P1Wya3Uzo_HajFfBERoLw Cc: "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:12:05 -0000 Adrian, I meant to type =B3RFC 4990 is GMPLS specific=B2, and not what I wrote. Please ignore the associated consequences from my typo, I was thinking =B3MPLS-TP=B2 when I wrote the sentence in my response :-) Basically, Section 3.5 says three things: 1. Major Gap! RFC 3811 TC for MPLS (which are use in a bunch of MPLS MIB Modules) lack support for IPv6 in specific cases (Gap) and one I-D tries to resolve that gap (incidentally authored by one of our contributors) 2. Other MIB Modules had adequate support for IPv4 and IPv6 3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing how to handle IPv6. Does that clarify? We still do have a typo in Section 3.5, second paragraph though. Thanks, Carlos. -----Original Message----- From: Adrian Farrel Reply-To: Adrian Farrel Date: Tuesday, October 28, 2014 at 5:58 PM To: Carlos Pignataro Cc: "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: RE: AD review of draft-ietf-mpls-ipv6-only-gap >Hello, > >Thanks for the work and I am advancing the I-D. > >> > I am sceptical about section 3.5. Earlier in the document you have >> > mentioned the fact that RFC 4990 explains how to use existing MIB >> > modules with IPv6 addresses, but you don't mention that RFC here. >> > Conversely, you do mention an individual I-D that does not (yet?) >> > have working group support to fix a problem that it is not clear is >> > the problem that needs to be fixed in a way that seems to me to be >> > wrong. >>=20 >> RFC 4990 is MPLS-TP specific. > >Well now, that comes as a surprise to someone who wrote part of the >document and edited the final version :-) > >RFC 4990 is most assuredly not about MPLS-TP. There is no mention of >MPLS-TP in the document. >It is quite true that if you were using the GMPLS MIB modules (that build >on the MPLS-TE MIB modules) to manage an MPLS-TP network what you have >written in the new revision would be perfectly true. >But RFC 4990 also explains the use of IPv6 in the MPLS-TE and GMPLS MIB >modules. Section 8 is pretty specific about that and provides a mechanism >to handle IPv6 extended tunnel IDs (it's a hack, Jim, but it might just >work!). >That makes me somewhat sceptical about the size of the gap you have >identified. >(I'm also not convinced that obsoleting an in-use TC will be a sound way >to make backward-compatible changes if they turn out to be necessary.) > >And now, of course, I start to worry about the level of review applied to >section 3.5 of this document. The consequence is not good: if this >section carries a bad analysis of the gaps then it is likely to be >ignored; if one section of this document is open to be ignored, what of >the other sections? > >Cheers, >Adrian > From nobody Wed Oct 29 02:52:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21B81A6FF4 for ; Wed, 29 Oct 2014 02:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY77xtL3JCsQ for ; Wed, 29 Oct 2014 02:52:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A791A70E1 for ; Wed, 29 Oct 2014 02:52:25 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9T9qKmQ001524; Wed, 29 Oct 2014 09:52:20 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9T9qJlr001494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 09:52:19 GMT From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> In-Reply-To: Date: Wed, 29 Oct 2014 09:52:14 -0000 Message-ID: <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvixUQwakdbx63j6KCa5k5aG2m5AEtT/YAAgg5QcMBaxYP5prinnSw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21060.006 X-TM-AS-Result: No--26.251-10.0-31-10 X-imss-scan-details: No--26.251-10.0-31-10 X-TMASE-MatchedRID: Cc2Ao8tLfKBilY5wApBwQlcD0bFW6LXouBKKB37nRtrAzkaoCiomKmXS ofv/sdGOlTJMgm6tt2H02CyYvwGr2Dng7Vk+bDISn5GWI2N+naCUocUWkvA59bu9iqQJLR0vF0R 6C/1uGOrdeAKnvBMxfD4hXW7B+PPhAuTzZfqHAQbLxze0tR0pTDGhYyUOZAft04Rmz/agfdxCax vb+nY2EuQydRUvl3QTK8yKokLeF7yxkaKxt78AKwT8AAhvIMzhYFa6Zcuh7o1IRA38P/dwboED+ PNzPecBu/jTz8Y/kepRUm37T3QxGdcVB/dhhz3usA0SrmKf+t0xk+PbmPwK3I1nuRzhSr7jnoph rTcsI7abKItl61J/yVF8tpIBUO3KKrauXd3MZDUD/dHyT/Xh7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/41Lmjtcvpxk8-VC7KF0cPH2b-o4 Cc: mpls@ietf.org, draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: afarrel@juniper.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:52:27 -0000 Hi again Carlos, > I meant to type =B3RFC 4990 is GMPLS specific=B2, and not what I = wrote. >=20 > Please ignore the associated consequences from my typo, I was thinking > =B3MPLS-TP=B2 when I wrote the sentence in my response :-) Yeah, I know. Sometimes those fingers just won't type what you tell them = to. But, of course, and as you recognise in the new revision you just sent = me, 4990 is not GMPLS specific since section 8 clearly notes it applies to = MPLS-TE and GMPLS. > Basically, Section 3.5 says three things: > 1. Major Gap! RFC 3811 TC for MPLS (which are use in a bunch of MPLS = MIB > Modules) lack support for IPv6 in specific cases (Gap) and one I-D = tries > to resolve that gap (incidentally authored by one of our contributors) Yup. It says this. And that is what I am questioning. I agree that the 3811bis I-D tries to fix this gap, I just don't agree = that it is a "major" because 4990 shows how it can be circumvented. That is not to say that 3811bis could not be valuable (with some work), = but it would be very wrong to imply that IPv6 deployment or operation is in = some way gated by this because there are ways of handling the situation. This to me makes the issue minor, not major. > 2. Other MIB Modules had adequate support for IPv4 and IPv6 > 3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing how = to > handle IPv6. See above (and note that it's OK to include MPLS-TP in the list :-) I think we should continue to work through this discussion, but that the document as it is should go forward to the IESG. Thanks, Adrian From nobody Wed Oct 29 03:14:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D44E1A702F for ; Wed, 29 Oct 2014 03:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cuVlpyKqYBF for ; Wed, 29 Oct 2014 03:14:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096C11A7004 for ; Wed, 29 Oct 2014 03:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=217; q=dns/txt; s=iport; t=1414577684; x=1415787284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YqXmVHln930n5vn9dE+ZIXg0/YKkpZac1A6vFFxSTl0=; b=XXadjFKk2zgGPXThd8yA9kz2aczV++H509enz7FBtV4+f/tPT4SyNnbZ ZfnuFGFZk94XD0q44pNKbadPVWSK2g9UE+LVOZ2czEP7XaFC2R2ULmke4 vktLO4KJeVGuS2G8tvN5C4frXkK79PikiqnVA+CNZFBo6v8JltJ9FiB/7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAIi9UFStJV2S/2dsb2JhbABcgmsj1zoCgRgWAQEBAQF9hAMBAQMBOj8FCwIBCDYQMiUBAQQOiD0JAcVQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5EJB4MtgR4BBJILi12WOIN4gzcBAQE X-IronPort-AV: E=Sophos;i="5.04,809,1406592000"; d="scan'208";a="91286443" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 29 Oct 2014 10:14:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9TAEhof031910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 10:14:43 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 05:14:42 -0500 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: AD review of draft-ietf-mpls-ipv6-only-gap Thread-Index: Ac/mauYYyhokKc65RvSg1yxokjWp6AMprgKAAASl2wD//8B4gIABBvYA//+ydss= Date: Wed, 29 Oct 2014 10:14:42 +0000 Message-ID: <77FD4E9C-0F90-481C-9A24-174685C128B8@cisco.com> References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> , <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> In-Reply-To: <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1LKi1ww99sZP6ePCBYQQFvvFHUk Cc: "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 10:14:45 -0000 Sounds great.=20 > I think we should continue to work through this discussion, but that the > document as it is should go forward to the IESG. I'll reply later on the other discussion points.=20 Carlos.=20 From nobody Wed Oct 29 05:10:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5387A1A00A3 for ; Wed, 29 Oct 2014 05:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6zgyxrrFToO for ; Wed, 29 Oct 2014 05:10:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F89D1A0070 for ; Wed, 29 Oct 2014 05:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 895D1BE13; Wed, 29 Oct 2014 12:10:01 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8SBHgJdWDpc; Wed, 29 Oct 2014 12:10:01 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5AF46BE0D; Wed, 29 Oct 2014 12:10:01 +0000 (GMT) Message-ID: <5450D91A.2050500@cs.tcd.ie> Date: Wed, 29 Oct 2014 12:10:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Osborne, Eric" , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RDfbKbDOJoDFuY-t3WxmeQOrwRU Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 12:10:25 -0000 On 28/10/14 18:41, Osborne, Eric wrote: > First, a disclaimer. I know enough about crypto to know I don't know > enough about crypto to say anything useful about it. I assume the > magic Just Works. > > Second, a question on the key change frequency. The document > RECOMMENDs a new key every 10^6 packets, and sets a hard limit of > 2^64. This is a huge range, and the recommended value doesn't seem > useful on anything modern. 160Mpps with a new key every 10^6 packets > is 160 keys per second. Even on a 10Mb Ethernet it's almost a new > key every minute[1] per interface. > > Are there cryptographic reasons for the 10^6 recommendation? TBH, I forget, but probably not:-) Happy to look at making it longer and/or related to pps figures. (Would that last help?) Not going beyond the max (2^64) is the important one from a crypto POV. Cheers, S. > If not, > can it be bumped to something saner, or perhaps provide a recommend > range? Practically speaking this is going to be so heavy to > implement that any recommended numbers should be about putting as > much time as possible between key exchanges if they can't be > eliminated outright. > > > Third, a nit. Typo: Section 4.2.1, "bidirecitonal" > > > > > eric [1] because I never trust myself to do math in public: at 16kpps > for 10Mbit ethernet and 10^6 packets per key, that's 0.02 keys/sec, > or 0.96 keys/minute. > > > -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] > On Behalf Of Adrian Farrel Sent: Monday, October 27, 2014 12:31 PM > To: mpls@ietf.org Cc: > draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: > [mpls] FW: New Version Notification for > draft-farrelll-mpls-opportunistic-encrypt-03.txt > > Hi MPLS WG, > > The Farrel twins have been playing with the concept of opportunistic > encryption for MPLS. This is very much positioned as an experiment. > > We'd like to hear from people who are interested in this as an idea > we should look into further. > > And, of course, we'd love to discuss the ideas in the draft. > > Adrian and Stephen > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 26 October 2014 23:16 To: >> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell >> Subject: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt- 03.txt >> >> >> A new version of I-D, >> draft-farrelll-mpls-opportunistic-encrypt-03.txt has been >> successfully submitted by Adrian Farrel and posted to the IETF >> repository. >> >> Name: draft-farrelll-mpls-opportunistic-encrypt Revision: 03 >> Title: Opportunistic Security in MPLS Networks Document date: >> 2014-10-26 Group: Individual Submission Pages: 30 URL: >> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- >> >> encrypt-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >> >> encrypt/ >> Htmlized: >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- >> >> 03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic- >> >> encrypt-03 >> >> Abstract: This document describes a way to apply opportunistic >> security between adjacent nodes on an MPLS Label Switched Path >> (LSP) or between end points of an LSP. It explains how keys may be >> agreed to enable encryption, and how key identifiers are exchanged >> in encrypted MPLS packets. Finally, this document describes the >> applicability of this approach to opportunistic security in MPLS >> networks with an indication of the level of improved security as >> well as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> >> >> >> >> 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. >> >> The IETF Secretariat > > _______________________________________________ mpls mailing list > mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls > From nobody Wed Oct 29 07:32:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1FE1A0121 for ; Wed, 29 Oct 2014 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwOC_7jmrKcx for ; Wed, 29 Oct 2014 07:32:17 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.4]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545EF1A0146 for ; Wed, 29 Oct 2014 07:32:17 -0700 (PDT) Received: from [216.82.250.83] by server-4.bemta-12.messagelabs.com id AD/D3-03139-F6AF0545; Wed, 29 Oct 2014 14:32:15 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1414593135!13038284!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18838 invoked from network); 29 Oct 2014 14:32:15 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Oct 2014 14:32:15 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id A6D0D2BFA6; Wed, 29 Oct 2014 14:32:23 +0000 (GMT) Received: from USADCWVEHT03.corp.global.level3.com (10.2.36.143) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 08:32:14 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht03.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 10:32:14 -0400 From: "Osborne, Eric" To: Stephen Farrell , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt Thread-Index: AQL7UGOfqefUWMYm4qSTFIHYjrRClpntYhUggAGGfgCAAb3DAP//u5Wg Date: Wed, 29 Oct 2014 14:32:11 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> <5450D91A.2050500@cs.tcd.ie> In-Reply-To: <5450D91A.2050500@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hujQaWt2bhyI6bn5M54bAaIzFyw Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:32:19 -0000 Ij4gQXJlIHRoZXJlIGNyeXB0b2dyYXBoaWMgcmVhc29ucyBmb3IgdGhlIDEwXjYgcmVjb21tZW5k YXRpb24/ICANCg0KVEJILCBJIGZvcmdldCwgYnV0IHByb2JhYmx5IG5vdDotKSBIYXBweSB0byBs b29rIGF0IG1ha2luZyBpdCBsb25nZXIgYW5kL29yIHJlbGF0ZWQgdG8gcHBzIGZpZ3VyZXMuIChX b3VsZCB0aGF0IGxhc3QgaGVscD8pIE5vdCBnb2luZyBiZXlvbmQgdGhlIG1heCAoMl42NCkgaXMg dGhlIGltcG9ydGFudCBvbmUgZnJvbSBhIGNyeXB0byBQT1YuIg0KDQoNCktleSBleGNoYW5nZSBz aG91bGQgYmUgZG9uZSBmb3IgdHdvIHJlYXNvbnM6DQoNCjEpIHRoZSBvcGVyYXRvciBpbml0aWF0 ZXMgaXQNCjIpIHRoZSBzeXN0ZW0gcmVxdWlyZXMgaXQgYW5kIGRvZXMgaXQgYXV0b21hdGljYWxs eSwgcGVyaGFwcyB3aXRoIGEgcHJlY29uZmlndXJlZCBzZWNvbmQga2V5IG9yIHBlcmhhcHMgd2l0 aCBzb21ldGhpbmcgYXV0by1nZW5lcmF0ZWQuDQoNCiMyIHNob3VsZCBoYXBwZW4gYXMgcmFyZWx5 IGFzIHBvc3NpYmxlLCBpZiBmb3Igbm8gb3RoZXIgcmVhc29uIHRoYW4ga2V5IGV4Y2hhbmdlIGlz IGxpa2VseSB0byBiZSBwZXJpbG91cy4gIFRoZSBhY3R1YWwgY3J5cHRvIHdpbGwgYmUgaW1wbGVt ZW50ZWQgaW4gaGFyZHdhcmUgYW5kIHRoZSBleGNoYW5nZSBpbiBzb2Z0d2FyZSwgc28gdGhlcmUg bmVlZHMgdG8gYmUgc29tZSBtZXRob2QgdG8gZW5zdXJlIHRoYXQgcGFja2V0cyBhcmVuJ3QgbG9z dCBkdXJpbmcgZXhjaGFuZ2UuICBJSVJDIChmcm9tIGRpc2N1c3Npb25zIGluIGEgcHJldmlvdXMg bGlmZSwgbm90IGN1cnJlbnQgZW1wbG95ZXIpIHRoYXQncyB3aHkgdGhlcmUgd2FzIHZlcnkgbGl0 dGxlIE1ENSBhdXRoIGRlcGxveWVkLg0KDQpCdXQgdGhhdCdzIG5vdGhpbmcgdG8gZG8gd2l0aCBr ZXkgY2hhbmdlIGZyZXF1ZW5jeS4NCg0KTGV0J3MgYXNzdW1lIEkgaGF2ZSBhIDEweDEwMEdFIExB RyAtIHRoaXMgaXMgb24gdGhlIGhpZ2hlciBlbmQgb2YgdGhpbmdzIHRvZGF5LCBidXQgd2lsbCBi ZSBoZXJlIHNvb24gZW5vdWdoLiAgV2l0aCBzb21ldGhpbmcgdGhhdCBiaWcgeW91J3JlIGxvb2tp bmcgYXQgMS42KjEwXjkgcHBzLCBwZXJoYXBzIGJldHRlciB3cml0dGVuIGFzIDJeMzAuNTdwcHMu ICBUaGlzIGxlYXZlcyBtZSAyXjMzLjRzZWMgYmVmb3JlIEkgaGl0IDJeNjQgcGFja2V0cy4gIFRo YXQncyBhIGxpdHRsZSBvdmVyIDM2NSB5ZWFycy4NCg0KU2V0IHRoZSBrZXkgY2hhbmdlIHRocmVz aG9sZCB0byAyXjYzIGluc3RlYWQsIHRvIGFsbG93IHRoZSBvcGVyYXRvciBzdWZmaWNpZW50IHRp bWUgKCEhKSB0byBjaGFuZ2Uga2V5cywgYW5kIHlvdSdyZSBsb29raW5nIGF0IDE4MiB5ZWFycyBi ZWZvcmUgaXQncyBldmVuIGEgcHJvYmxlbS4gIFllcywgNjQwayBzaG91bGQgYmUgZW5vdWdoIGZv ciBldmVyeW9uZSwgYW5kIDUxMi1iaXQgY3J5cHRvIGlzIGdvaW5nIHRvIGJlIGltcG9zc2libGUg dG8gY3JhY2ssIGFuZCB5MmsgaXMgc28gZmFyIGF3YXkgbm9ib2R5IHdpbGwgY2FyZSBpZiB3ZSBk byB0d28gZGlnaXQgZGF0ZWNvZGVzIG5vdy4uLmJ1dCBzZXJpb3VzbHkuLi50aGF0J3MgYSBsb25n IHRpbWUuICANCg0KSSdkIHZvdGUgZm9yIHNldHRpbmcgdGhhdCB0aHJlc2hvbGQgYXMgaGlnaCBh cyBwb3NzaWJsZSBzaW5jZSB0aGVyZSBzZWVtcyB0byBiZSBubyByZWFzb24gdG8gZG8gb3RoZXJ3 aXNlLiAgSSBkb24ndCBzZWUgYSByZWFzb24gdG8gdGllIGFueSByZWNvbW1lbmRhdGlvbiB0byBw cHMuDQoNCg0KDQoNCmVyaWMNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSANClNl bnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyOSwgMjAxNCA4OjEwIEFNDQpUbzogT3Nib3JuZSwgRXJp YzsgYWRyaWFuQG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWZhcnJlbGxs LW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTog W21wbHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZhcnJlbGxsLW1w bHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTAzLnR4dA0KDQoNCg0KT24gMjgvMTAvMTQgMTg6NDEs IE9zYm9ybmUsIEVyaWMgd3JvdGU6DQo+IEZpcnN0LCBhIGRpc2NsYWltZXIuICBJIGtub3cgZW5v dWdoIGFib3V0IGNyeXB0byB0byBrbm93IEkgZG9uJ3Qga25vdyANCj4gZW5vdWdoIGFib3V0IGNy eXB0byB0byBzYXkgYW55dGhpbmcgdXNlZnVsIGFib3V0IGl0LiAgSSBhc3N1bWUgdGhlIA0KPiBt YWdpYyBKdXN0IFdvcmtzLg0KPiANCj4gU2Vjb25kLCBhIHF1ZXN0aW9uIG9uIHRoZSBrZXkgY2hh bmdlIGZyZXF1ZW5jeS4gVGhlIGRvY3VtZW50IA0KPiBSRUNPTU1FTkRzIGEgbmV3IGtleSBldmVy eSAxMF42IHBhY2tldHMsIGFuZCBzZXRzIGEgaGFyZCBsaW1pdCBvZiANCj4gMl42NC4gIFRoaXMg aXMgYSBodWdlIHJhbmdlLCBhbmQgdGhlIHJlY29tbWVuZGVkIHZhbHVlIGRvZXNuJ3Qgc2VlbSAN Cj4gdXNlZnVsIG9uIGFueXRoaW5nIG1vZGVybi4gIDE2ME1wcHMgd2l0aCBhIG5ldyBrZXkgZXZl cnkgMTBeNiBwYWNrZXRzIA0KPiBpcyAxNjAga2V5cyBwZXIgc2Vjb25kLiAgRXZlbiBvbiBhIDEw TWIgRXRoZXJuZXQgaXQncyBhbG1vc3QgYSBuZXcga2V5IA0KPiBldmVyeSBtaW51dGVbMV0gcGVy IGludGVyZmFjZS4NCj4gDQo+IEFyZSB0aGVyZSBjcnlwdG9ncmFwaGljIHJlYXNvbnMgZm9yIHRo ZSAxMF42IHJlY29tbWVuZGF0aW9uPyAgDQoNClRCSCwgSSBmb3JnZXQsIGJ1dCBwcm9iYWJseSBu b3Q6LSkgSGFwcHkgdG8gbG9vayBhdCBtYWtpbmcgaXQgbG9uZ2VyIGFuZC9vciByZWxhdGVkIHRv IHBwcyBmaWd1cmVzLiAoV291bGQgdGhhdCBsYXN0IGhlbHA/KSBOb3QgZ29pbmcgYmV5b25kIHRo ZSBtYXggKDJeNjQpIGlzIHRoZSBpbXBvcnRhbnQgb25lIGZyb20gYSBjcnlwdG8gUE9WLg0KDQpD aGVlcnMsDQpTLg0KDQo+IElmIG5vdCwNCj4gY2FuIGl0IGJlIGJ1bXBlZCB0byBzb21ldGhpbmcg c2FuZXIsIG9yIHBlcmhhcHMgcHJvdmlkZSBhIHJlY29tbWVuZCANCj4gcmFuZ2U/ICBQcmFjdGlj YWxseSBzcGVha2luZyB0aGlzIGlzIGdvaW5nIHRvIGJlIHNvIGhlYXZ5IHRvIGltcGxlbWVudCAN Cj4gdGhhdCBhbnkgcmVjb21tZW5kZWQgbnVtYmVycyBzaG91bGQgYmUgYWJvdXQgcHV0dGluZyBh cyBtdWNoIHRpbWUgYXMgDQo+IHBvc3NpYmxlIGJldHdlZW4ga2V5IGV4Y2hhbmdlcyBpZiB0aGV5 IGNhbid0IGJlIGVsaW1pbmF0ZWQgb3V0cmlnaHQuDQo+IA0KPiANCj4gVGhpcmQsIGEgbml0LiBU eXBvOiBTZWN0aW9uIDQuMi4xLCAiYmlkaXJlY2l0b25hbCINCj4gDQo+IA0KPiANCj4gDQo+IGVy aWMgWzFdIGJlY2F1c2UgSSBuZXZlciB0cnVzdCBteXNlbGYgdG8gZG8gbWF0aCBpbiBwdWJsaWM6 IGF0IDE2a3BwcyANCj4gZm9yIDEwTWJpdCBldGhlcm5ldCBhbmQgMTBeNiBwYWNrZXRzIHBlciBr ZXksIHRoYXQncyAwLjAyIGtleXMvc2VjLCBvciANCj4gMC45NiBrZXlzL21pbnV0ZS4NCj4gDQo+ IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSANCj4gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwgU2VudDogTW9u ZGF5LCBPY3RvYmVyIDI3LCAyMDE0IDEyOjMxIFBNDQo+IFRvOiBtcGxzQGlldGYub3JnIENjOg0K PiBkcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdEB0b29scy5pZXRmLm9y ZyBTdWJqZWN0Og0KPiBbbXBsc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ IGRyYWZ0LWZhcnJlbGxsLW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTAzLnR4dA0KPiANCj4g SGkgTVBMUyBXRywNCj4gDQo+IFRoZSBGYXJyZWwgdHdpbnMgaGF2ZSBiZWVuIHBsYXlpbmcgd2l0 aCB0aGUgY29uY2VwdCBvZiBvcHBvcnR1bmlzdGljIA0KPiBlbmNyeXB0aW9uIGZvciBNUExTLiBU aGlzIGlzIHZlcnkgbXVjaCBwb3NpdGlvbmVkIGFzIGFuIGV4cGVyaW1lbnQuDQo+IA0KPiBXZSdk IGxpa2UgdG8gaGVhciBmcm9tIHBlb3BsZSB3aG8gYXJlIGludGVyZXN0ZWQgaW4gdGhpcyBhcyBh biBpZGVhIHdlIA0KPiBzaG91bGQgbG9vayBpbnRvIGZ1cnRoZXIuDQo+IA0KPiBBbmQsIG9mIGNv dXJzZSwgd2UnZCBsb3ZlIHRvIGRpc2N1c3MgdGhlIGlkZWFzIGluIHRoZSBkcmFmdC4NCj4gDQo+ IEFkcmlhbiBhbmQgU3RlcGhlbg0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCj4+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSBTZW50OiAyNiBPY3RvYmVyIDIwMTQgMjM6MTYgVG86DQo+PiBBZHJpYW4gRmFy cmVsOyBTdGVwaGVuIEZhcnJlbGw7IEFkcmlhbiBGYXJyZWw7IFN0ZXBoZW4gRmFycmVsbA0KPj4g U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4gZHJhZnQtZmFycmVsbGwt bXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHQtIDAzLnR4dA0KPj4gDQo+PiANCj4+IEEgbmV3IHZl cnNpb24gb2YgSS1ELA0KPj4gZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5 cHQtMDMudHh0IGhhcyBiZWVuIA0KPj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZHJpYW4g RmFycmVsIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQo+PiByZXBvc2l0b3J5Lg0KPj4gDQo+PiBO YW1lOgkJZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHQgUmV2aXNpb246 CTAzIA0KPj4gVGl0bGU6CQlPcHBvcnR1bmlzdGljIFNlY3VyaXR5IGluIE1QTFMgTmV0d29ya3Mg RG9jdW1lbnQgZGF0ZToNCj4+IDIwMTQtMTAtMjYgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24gUGFnZXM6CQkzMCBVUkw6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMNCj4+IC0NCj4+DQo+PiANCmVuY3J5 cHQtMDMudHh0DQo+PiBTdGF0dXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMtDQo+Pg0KPj4gDQplbmNyeXB0Lw0K Pj4gSHRtbGl6ZWQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWxs bC1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0NCj4+DQo+PiANCjAzDQo+PiBEaWZmOg0KPj4g aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZmFycmVsbGwtbXBscy1vcHBv cnR1bmlzdGljLQ0KPj4NCj4+IA0KZW5jcnlwdC0wMw0KPj4gDQo+PiBBYnN0cmFjdDogVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSB3YXkgdG8gYXBwbHkgb3Bwb3J0dW5pc3RpYyANCj4+IHNlY3Vy aXR5IGJldHdlZW4gYWRqYWNlbnQgbm9kZXMgb24gYW4gTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRo DQo+PiAoTFNQKSBvciBiZXR3ZWVuIGVuZCBwb2ludHMgb2YgYW4gTFNQLiAgSXQgZXhwbGFpbnMg aG93IGtleXMgbWF5IGJlIA0KPj4gYWdyZWVkIHRvIGVuYWJsZSBlbmNyeXB0aW9uLCBhbmQgaG93 IGtleSBpZGVudGlmaWVycyBhcmUgZXhjaGFuZ2VkIGluIA0KPj4gZW5jcnlwdGVkIE1QTFMgcGFj a2V0cy4gIEZpbmFsbHksIHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSANCj4+IGFwcGxpY2Fi aWxpdHkgb2YgdGhpcyBhcHByb2FjaCB0byBvcHBvcnR1bmlzdGljIHNlY3VyaXR5IGluIE1QTFMg DQo+PiBuZXR3b3JrcyB3aXRoIGFuIGluZGljYXRpb24gb2YgdGhlIGxldmVsIG9mIGltcHJvdmVk IHNlY3VyaXR5IGFzIHdlbGwgDQo+PiBhcyB0aGUgY29udGludWVkIHZ1bG5lcmFiaWxpdGllcy4N Cj4+IA0KPj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZXNjcmliZSBzZWN1cml0eSBmb3IgTVBM UyBjb250cm9sIHBsYW5lIA0KPj4gcHJvdG9jb2xzLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiANCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4+IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gbXBscyBtYWlsaW5nIGxpc3QgDQo+IG1wbHNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0K From nobody Wed Oct 29 07:35:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557361A014E for ; Wed, 29 Oct 2014 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_2P9ISI02sn for ; Wed, 29 Oct 2014 07:35:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9295E1A0151 for ; Wed, 29 Oct 2014 07:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94743BDFB; Wed, 29 Oct 2014 14:35:44 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdmO2TVrLXF3; Wed, 29 Oct 2014 14:35:44 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6348DBDCC; Wed, 29 Oct 2014 14:35:44 +0000 (GMT) Message-ID: <5450FB41.5000605@cs.tcd.ie> Date: Wed, 29 Oct 2014 14:35:45 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Osborne, Eric" , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> <5450D91A.2050500@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TyyaPophr25oMOMGW2Fm7j7jxlo Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:35:51 -0000 On 29/10/14 14:32, Osborne, Eric wrote: > "> Are there cryptographic reasons for the 10^6 recommendation? > > TBH, I forget, but probably not:-) Happy to look at making it longer > and/or related to pps figures. (Would that last help?) Not going > beyond the max (2^64) is the important one from a crypto POV." > > > Key exchange should be done for two reasons: > > 1) the operator initiates it 2) the system requires it and does it > automatically, perhaps with a preconfigured second key or perhaps > with something auto-generated. Or #3, you aren't that confident that a D-H derived key won't leak out, which is a reason to minimise the symmetric key lifetime. S > > #2 should happen as rarely as possible, if for no other reason than > key exchange is likely to be perilous. The actual crypto will be > implemented in hardware and the exchange in software, so there needs > to be some method to ensure that packets aren't lost during exchange. > IIRC (from discussions in a previous life, not current employer) > that's why there was very little MD5 auth deployed. > > But that's nothing to do with key change frequency. > > Let's assume I have a 10x100GE LAG - this is on the higher end of > things today, but will be here soon enough. With something that big > you're looking at 1.6*10^9 pps, perhaps better written as 2^30.57pps. > This leaves me 2^33.4sec before I hit 2^64 packets. That's a little > over 365 years. > > Set the key change threshold to 2^63 instead, to allow the operator > sufficient time (!!) to change keys, and you're looking at 182 years > before it's even a problem. Yes, 640k should be enough for everyone, > and 512-bit crypto is going to be impossible to crack, and y2k is so > far away nobody will care if we do two digit datecodes now...but > seriously...that's a long time. > > I'd vote for setting that threshold as high as possible since there > seems to be no reason to do otherwise. I don't see a reason to tie > any recommendation to pps. > > > > > eric > > > > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, October 29, 2014 > 8:10 AM To: Osborne, Eric; adrian@olddog.co.uk; mpls@ietf.org Cc: > draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: Re: > [mpls] FW: New Version Notification for > draft-farrelll-mpls-opportunistic-encrypt-03.txt > > > > On 28/10/14 18:41, Osborne, Eric wrote: >> First, a disclaimer. I know enough about crypto to know I don't >> know enough about crypto to say anything useful about it. I assume >> the magic Just Works. >> >> Second, a question on the key change frequency. The document >> RECOMMENDs a new key every 10^6 packets, and sets a hard limit of >> 2^64. This is a huge range, and the recommended value doesn't seem >> useful on anything modern. 160Mpps with a new key every 10^6 >> packets is 160 keys per second. Even on a 10Mb Ethernet it's >> almost a new key every minute[1] per interface. >> >> Are there cryptographic reasons for the 10^6 recommendation? > > TBH, I forget, but probably not:-) Happy to look at making it longer > and/or related to pps figures. (Would that last help?) Not going > beyond the max (2^64) is the important one from a crypto POV. > > Cheers, S. > >> If not, can it be bumped to something saner, or perhaps provide a >> recommend range? Practically speaking this is going to be so heavy >> to implement that any recommended numbers should be about putting >> as much time as possible between key exchanges if they can't be >> eliminated outright. >> >> >> Third, a nit. Typo: Section 4.2.1, "bidirecitonal" >> >> >> >> >> eric [1] because I never trust myself to do math in public: at >> 16kpps for 10Mbit ethernet and 10^6 packets per key, that's 0.02 >> keys/sec, or 0.96 keys/minute. >> >> >> -----Original Message----- From: mpls >> [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: >> Monday, October 27, 2014 12:31 PM To: mpls@ietf.org Cc: >> draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: >> [mpls] FW: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt-03.txt >> >> Hi MPLS WG, >> >> The Farrel twins have been playing with the concept of >> opportunistic encryption for MPLS. This is very much positioned as >> an experiment. >> >> We'd like to hear from people who are interested in this as an idea >> we should look into further. >> >> And, of course, we'd love to discuss the ideas in the draft. >> >> Adrian and Stephen >> >>> -----Original Message----- From: internet-drafts@ietf.org >>> [mailto:internet-drafts@ietf.org] Sent: 26 October 2014 23:16 >>> To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen >>> Farrell Subject: New Version Notification for >>> draft-farrelll-mpls-opportunistic-encrypt- 03.txt >>> >>> >>> A new version of I-D, >>> draft-farrelll-mpls-opportunistic-encrypt-03.txt has been >>> successfully submitted by Adrian Farrel and posted to the IETF >>> repository. >>> >>> Name: draft-farrelll-mpls-opportunistic-encrypt Revision: 03 >>> Title: Opportunistic Security in MPLS Networks Document date: >>> 2014-10-26 Group: Individual Submission Pages: 30 URL: >>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic >>> >>> - >>> >>> > encrypt-03.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >>> >>> > >>> encrypt/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- >>> >>> > >>> 03 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic- >>> >>> > >>> encrypt-03 >>> >>> Abstract: This document describes a way to apply opportunistic >>> security between adjacent nodes on an MPLS Label Switched Path >>> (LSP) or between end points of an LSP. It explains how keys may >>> be agreed to enable encryption, and how key identifiers are >>> exchanged in encrypted MPLS packets. Finally, this document >>> describes the applicability of this approach to opportunistic >>> security in MPLS networks with an indication of the level of >>> improved security as well as the continued vulnerabilities. >>> >>> This document does not describe security for MPLS control plane >>> protocols. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >> >> _______________________________________________ mpls mailing list >> mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls >> From nobody Wed Oct 29 07:52:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74B71A017A for ; Wed, 29 Oct 2014 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gadTxl7jim-a for ; Wed, 29 Oct 2014 07:52:18 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20101A0172 for ; Wed, 29 Oct 2014 07:52:17 -0700 (PDT) Received: from [216.82.241.195] by server-15.bemta-8.messagelabs.com id 66/11-02722-02FF0545; Wed, 29 Oct 2014 14:52:16 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1414594335!30841092!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31753 invoked from network); 29 Oct 2014 14:52:16 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Oct 2014 14:52:16 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id AD67E1F8D6; Wed, 29 Oct 2014 14:52:15 +0000 (GMT) Received: from USIDCWVEHT03.corp.global.level3.com (10.1.196.123) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 08:52:08 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT03.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 08:52:07 -0600 From: "Osborne, Eric" To: Stephen Farrell , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt Thread-Index: AQL7UGOfqefUWMYm4qSTFIHYjrRClpntYhUggAGGfgCAAb3DAP//u5WggABtIoD//5ul4A== Date: Wed, 29 Oct 2014 14:52:07 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC49C@USIDCWVEMBX08.corp.global.level3.com> References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> <5450D91A.2050500@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> <5450FB41.5000605@cs.tcd.ie> In-Reply-To: <5450FB41.5000605@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xpr-Jyxru0jgRodxyRNksE-STKM Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:52:21 -0000 SW5saW5lIHdpdGggRU8jDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVw aGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAyOSwgMjAxNCAxMDozNiBBTQ0KVG86IE9zYm9ybmUsIEVyaWM7IGFk cmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCkNjOiBkcmFmdC1mYXJyZWxsbC1tcGxz LW9wcG9ydHVuaXN0aWMtZW5jcnlwdEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxz XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mYXJyZWxsbC1tcGxzLW9w cG9ydHVuaXN0aWMtZW5jcnlwdC0wMy50eHQNCg0KDQoNCk9uIDI5LzEwLzE0IDE0OjMyLCBPc2Jv cm5lLCBFcmljIHdyb3RlOg0KPiAiPiBBcmUgdGhlcmUgY3J5cHRvZ3JhcGhpYyByZWFzb25zIGZv ciB0aGUgMTBeNiByZWNvbW1lbmRhdGlvbj8NCj4gDQo+IFRCSCwgSSBmb3JnZXQsIGJ1dCBwcm9i YWJseSBub3Q6LSkgSGFwcHkgdG8gbG9vayBhdCBtYWtpbmcgaXQgbG9uZ2VyIA0KPiBhbmQvb3Ig cmVsYXRlZCB0byBwcHMgZmlndXJlcy4gKFdvdWxkIHRoYXQgbGFzdCBoZWxwPykgTm90IGdvaW5n IA0KPiBiZXlvbmQgdGhlIG1heCAoMl42NCkgaXMgdGhlIGltcG9ydGFudCBvbmUgZnJvbSBhIGNy eXB0byBQT1YuIg0KPiANCj4gDQo+IEtleSBleGNoYW5nZSBzaG91bGQgYmUgZG9uZSBmb3IgdHdv IHJlYXNvbnM6DQo+IA0KPiAxKSB0aGUgb3BlcmF0b3IgaW5pdGlhdGVzIGl0IDIpIHRoZSBzeXN0 ZW0gcmVxdWlyZXMgaXQgYW5kIGRvZXMgaXQgDQo+IGF1dG9tYXRpY2FsbHksIHBlcmhhcHMgd2l0 aCBhIHByZWNvbmZpZ3VyZWQgc2Vjb25kIGtleSBvciBwZXJoYXBzIHdpdGggDQo+IHNvbWV0aGlu ZyBhdXRvLWdlbmVyYXRlZC4NCg0KT3IgIzMsIHlvdSBhcmVuJ3QgdGhhdCBjb25maWRlbnQgdGhh dCBhIEQtSCBkZXJpdmVkIGtleSB3b24ndCBsZWFrIG91dCwgd2hpY2ggaXMgYSByZWFzb24gdG8g bWluaW1pc2UgdGhlIHN5bW1ldHJpYyBrZXkgbGlmZXRpbWUuDQoNCg0KRU8jICBUaGF0IHNlZW1z IGxpa2UgYW5vdGhlciBmbGF2b3Igb2YgZWl0aGVyICMxIG9yICMyLiAgDQpQZXJoYXBzIHRoaXMg c2hvdWxkIGJlIGNvdmVyZWQgaW4gYW4gb3BlcmF0aW9ucyBzZWN0aW9uIC0gInRoZSBvcGVyYXRv ciBzaG91bGQgYmUgYWJsZSB0byBjaGFuZ2Uga2V5cyBhcyBmcmVxdWVudGx5IGFzIGRlc2lyZWQg aW4gb3JkZXIgdG8gbWluaW1pemUgdGhlIHJpc2sgb2YgYSBsZWFrZWQga2V5LCBidXQgYXQgYSBm cmVxdWVuY3kgbm90IGRlZW1lZCB0byBiZSBvcGVyYXRpb25hbGx5IG9uZXJvdXMuICBUaGlzIHZh cmllcyBib3RoIGJ5IHBwcyBhbmQgb3BlcmF0b3IgcHJlZmVyZW5jZS4gIE9uIGEgdHlwaWNhbCAx MEdiaXQgbGluayBhIHRocmVzaG9sZCBvZiAyXjUwIHBhY2tldHMgc2hvdWxkIGFsbG93IHRoZSBv cGVyYXRvciBhIGxpdHRsZSBvdmVyIHR3byB5ZWFycyBiZWZvcmUgY2hhbmdpbmcga2V5cy4gIE9u IGEgMVRiaXQgbGluayBhIHR3by15ZWFyIGtleSBsaWZldGltZSByZXF1aXJlcyBhIDJeNjMgdGhy ZXNob2xkIi4NCg0KSWYgeW91J3JlIGdvaW5nIHRvIFJFQ09NTUVORCBhIGRlZmF1bHQsIEknZCBz YXkgc29tZXRoaW5nIGxpa2UgImRlZmF1bHQgU0hPVUxEIGJlIHNldCB0byBhIHRocmVzaG9sZCB0 aGF0IGdpdmVzIGEga2V5IGEgMS15ZWFyIGxpZmV0aW1lIGF0IGxpbmUgcmF0ZSB3aXRoIHNtYWxs IHBhY2tldHMiLg0KDQoNCg0KDQplcmljDQoNCg0KUw0KDQo+IA0KPiAjMiBzaG91bGQgaGFwcGVu IGFzIHJhcmVseSBhcyBwb3NzaWJsZSwgaWYgZm9yIG5vIG90aGVyIHJlYXNvbiB0aGFuIA0KPiBr ZXkgZXhjaGFuZ2UgaXMgbGlrZWx5IHRvIGJlIHBlcmlsb3VzLiAgVGhlIGFjdHVhbCBjcnlwdG8g d2lsbCBiZSANCj4gaW1wbGVtZW50ZWQgaW4gaGFyZHdhcmUgYW5kIHRoZSBleGNoYW5nZSBpbiBz b2Z0d2FyZSwgc28gdGhlcmUgbmVlZHMgDQo+IHRvIGJlIHNvbWUgbWV0aG9kIHRvIGVuc3VyZSB0 aGF0IHBhY2tldHMgYXJlbid0IGxvc3QgZHVyaW5nIGV4Y2hhbmdlLg0KPiBJSVJDIChmcm9tIGRp c2N1c3Npb25zIGluIGEgcHJldmlvdXMgbGlmZSwgbm90IGN1cnJlbnQgZW1wbG95ZXIpIA0KPiB0 aGF0J3Mgd2h5IHRoZXJlIHdhcyB2ZXJ5IGxpdHRsZSBNRDUgYXV0aCBkZXBsb3llZC4NCj4gDQo+ IEJ1dCB0aGF0J3Mgbm90aGluZyB0byBkbyB3aXRoIGtleSBjaGFuZ2UgZnJlcXVlbmN5Lg0KPiAN Cj4gTGV0J3MgYXNzdW1lIEkgaGF2ZSBhIDEweDEwMEdFIExBRyAtIHRoaXMgaXMgb24gdGhlIGhp Z2hlciBlbmQgb2YgDQo+IHRoaW5ncyB0b2RheSwgYnV0IHdpbGwgYmUgaGVyZSBzb29uIGVub3Vn aC4gIFdpdGggc29tZXRoaW5nIHRoYXQgYmlnIA0KPiB5b3UncmUgbG9va2luZyBhdCAxLjYqMTBe OSBwcHMsIHBlcmhhcHMgYmV0dGVyIHdyaXR0ZW4gYXMgMl4zMC41N3Bwcy4NCj4gVGhpcyBsZWF2 ZXMgbWUgMl4zMy40c2VjIGJlZm9yZSBJIGhpdCAyXjY0IHBhY2tldHMuICBUaGF0J3MgYSBsaXR0 bGUgDQo+IG92ZXIgMzY1IHllYXJzLg0KPiANCj4gU2V0IHRoZSBrZXkgY2hhbmdlIHRocmVzaG9s ZCB0byAyXjYzIGluc3RlYWQsIHRvIGFsbG93IHRoZSBvcGVyYXRvciANCj4gc3VmZmljaWVudCB0 aW1lICghISkgdG8gY2hhbmdlIGtleXMsIGFuZCB5b3UncmUgbG9va2luZyBhdCAxODIgeWVhcnMg DQo+IGJlZm9yZSBpdCdzIGV2ZW4gYSBwcm9ibGVtLiAgWWVzLCA2NDBrIHNob3VsZCBiZSBlbm91 Z2ggZm9yIGV2ZXJ5b25lLCANCj4gYW5kIDUxMi1iaXQgY3J5cHRvIGlzIGdvaW5nIHRvIGJlIGlt cG9zc2libGUgdG8gY3JhY2ssIGFuZCB5MmsgaXMgc28gDQo+IGZhciBhd2F5IG5vYm9keSB3aWxs IGNhcmUgaWYgd2UgZG8gdHdvIGRpZ2l0IGRhdGVjb2RlcyBub3cuLi5idXQgDQo+IHNlcmlvdXNs eS4uLnRoYXQncyBhIGxvbmcgdGltZS4NCj4gDQo+IEknZCB2b3RlIGZvciBzZXR0aW5nIHRoYXQg dGhyZXNob2xkIGFzIGhpZ2ggYXMgcG9zc2libGUgc2luY2UgdGhlcmUgDQo+IHNlZW1zIHRvIGJl IG5vIHJlYXNvbiB0byBkbyBvdGhlcndpc2UuICBJIGRvbid0IHNlZSBhIHJlYXNvbiB0byB0aWUg DQo+IGFueSByZWNvbW1lbmRhdGlvbiB0byBwcHMuDQo+IA0KPiANCj4gDQo+IA0KPiBlcmljDQo+ IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFN0ZXBoZW4gRmFy cmVsbCANCj4gW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSBTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMjksIDIwMTQNCj4gODoxMCBBTSBUbzogT3Nib3JuZSwgRXJpYzsgYWRyaWFu QG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9yZyBDYzoNCj4gZHJhZnQtZmFycmVsbGwtbXBscy1v cHBvcnR1bmlzdGljLWVuY3J5cHRAdG9vbHMuaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+IFttcGxz XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZmFycmVsbGwtbXBs cy1vcHBvcnR1bmlzdGljLWVuY3J5cHQtMDMudHh0DQo+IA0KPiANCj4gDQo+IE9uIDI4LzEwLzE0 IDE4OjQxLCBPc2Jvcm5lLCBFcmljIHdyb3RlOg0KPj4gRmlyc3QsIGEgZGlzY2xhaW1lci4gIEkg a25vdyBlbm91Z2ggYWJvdXQgY3J5cHRvIHRvIGtub3cgSSBkb24ndCBrbm93IA0KPj4gZW5vdWdo IGFib3V0IGNyeXB0byB0byBzYXkgYW55dGhpbmcgdXNlZnVsIGFib3V0IGl0LiAgSSBhc3N1bWUg dGhlIA0KPj4gbWFnaWMgSnVzdCBXb3Jrcy4NCj4+IA0KPj4gU2Vjb25kLCBhIHF1ZXN0aW9uIG9u IHRoZSBrZXkgY2hhbmdlIGZyZXF1ZW5jeS4gVGhlIGRvY3VtZW50IA0KPj4gUkVDT01NRU5EcyBh IG5ldyBrZXkgZXZlcnkgMTBeNiBwYWNrZXRzLCBhbmQgc2V0cyBhIGhhcmQgbGltaXQgb2YgDQo+ PiAyXjY0LiAgVGhpcyBpcyBhIGh1Z2UgcmFuZ2UsIGFuZCB0aGUgcmVjb21tZW5kZWQgdmFsdWUg ZG9lc24ndCBzZWVtICANCj4+IHVzZWZ1bCBvbiBhbnl0aGluZyBtb2Rlcm4uICAxNjBNcHBzIHdp dGggYSBuZXcga2V5IGV2ZXJ5IDEwXjYgcGFja2V0cyANCj4+IGlzIDE2MCBrZXlzIHBlciBzZWNv bmQuICBFdmVuIG9uIGEgMTBNYiBFdGhlcm5ldCBpdCdzIGFsbW9zdCBhIG5ldyANCj4+IGtleSBl dmVyeSBtaW51dGVbMV0gcGVyIGludGVyZmFjZS4NCj4+IA0KPj4gQXJlIHRoZXJlIGNyeXB0b2dy YXBoaWMgcmVhc29ucyBmb3IgdGhlIDEwXjYgcmVjb21tZW5kYXRpb24/DQo+IA0KPiBUQkgsIEkg Zm9yZ2V0LCBidXQgcHJvYmFibHkgbm90Oi0pIEhhcHB5IHRvIGxvb2sgYXQgbWFraW5nIGl0IGxv bmdlciANCj4gYW5kL29yIHJlbGF0ZWQgdG8gcHBzIGZpZ3VyZXMuIChXb3VsZCB0aGF0IGxhc3Qg aGVscD8pIE5vdCBnb2luZyANCj4gYmV5b25kIHRoZSBtYXggKDJeNjQpIGlzIHRoZSBpbXBvcnRh bnQgb25lIGZyb20gYSBjcnlwdG8gUE9WLg0KPiANCj4gQ2hlZXJzLCBTLg0KPiANCj4+IElmIG5v dCwgY2FuIGl0IGJlIGJ1bXBlZCB0byBzb21ldGhpbmcgc2FuZXIsIG9yIHBlcmhhcHMgcHJvdmlk ZSBhIA0KPj4gcmVjb21tZW5kIHJhbmdlPyAgUHJhY3RpY2FsbHkgc3BlYWtpbmcgdGhpcyBpcyBn b2luZyB0byBiZSBzbyBoZWF2eSANCj4+IHRvIGltcGxlbWVudCB0aGF0IGFueSByZWNvbW1lbmRl ZCBudW1iZXJzIHNob3VsZCBiZSBhYm91dCBwdXR0aW5nIGFzIA0KPj4gbXVjaCB0aW1lIGFzIHBv c3NpYmxlIGJldHdlZW4ga2V5IGV4Y2hhbmdlcyBpZiB0aGV5IGNhbid0IGJlIA0KPj4gZWxpbWlu YXRlZCBvdXRyaWdodC4NCj4+IA0KPj4gDQo+PiBUaGlyZCwgYSBuaXQuIFR5cG86IFNlY3Rpb24g NC4yLjEsICJiaWRpcmVjaXRvbmFsIg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBlcmljIFsxXSBi ZWNhdXNlIEkgbmV2ZXIgdHJ1c3QgbXlzZWxmIHRvIGRvIG1hdGggaW4gcHVibGljOiBhdCAxNmtw cHMgDQo+PiBmb3IgMTBNYml0IGV0aGVybmV0IGFuZCAxMF42IHBhY2tldHMgcGVyIGtleSwgdGhh dCdzIDAuMDIga2V5cy9zZWMsIA0KPj4gb3IgMC45NiBrZXlzL21pbnV0ZS4NCj4+IA0KPj4gDQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSANCj4+IE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsIFNlbnQ6DQo+PiBN b25kYXksIE9jdG9iZXIgMjcsIDIwMTQgMTI6MzEgUE0gVG86IG1wbHNAaWV0Zi5vcmcgQ2M6IA0K Pj4gZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHRAdG9vbHMuaWV0Zi5v cmcgU3ViamVjdDogDQo+PiBbbXBsc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig DQo+PiBkcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0wMy50eHQNCj4+ IA0KPj4gSGkgTVBMUyBXRywNCj4+IA0KPj4gVGhlIEZhcnJlbCB0d2lucyBoYXZlIGJlZW4gcGxh eWluZyB3aXRoIHRoZSBjb25jZXB0IG9mIG9wcG9ydHVuaXN0aWMgDQo+PiBlbmNyeXB0aW9uIGZv ciBNUExTLiBUaGlzIGlzIHZlcnkgbXVjaCBwb3NpdGlvbmVkIGFzIGFuIGV4cGVyaW1lbnQuDQo+ PiANCj4+IFdlJ2QgbGlrZSB0byBoZWFyIGZyb20gcGVvcGxlIHdobyBhcmUgaW50ZXJlc3RlZCBp biB0aGlzIGFzIGFuIGlkZWEgDQo+PiB3ZSBzaG91bGQgbG9vayBpbnRvIGZ1cnRoZXIuDQo+PiAN Cj4+IEFuZCwgb2YgY291cnNlLCB3ZSdkIGxvdmUgdG8gZGlzY3VzcyB0aGUgaWRlYXMgaW4gdGhl IGRyYWZ0Lg0KPj4gDQo+PiBBZHJpYW4gYW5kIFN0ZXBoZW4NCj4+IA0KPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCj4+PiBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gU2VudDogMjYgT2N0b2JlciAyMDE0IDIzOjE2 DQo+Pj4gVG86IEFkcmlhbiBGYXJyZWw7IFN0ZXBoZW4gRmFycmVsbDsgQWRyaWFuIEZhcnJlbDsg U3RlcGhlbiBGYXJyZWxsIA0KPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3INCj4+PiBkcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0gMDMudHh0 DQo+Pj4gDQo+Pj4gDQo+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+Pj4gZHJhZnQtZmFycmVs bGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHQtMDMudHh0IGhhcyBiZWVuIA0KPj4+IHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJlbCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IA0KPj4+IHJlcG9zaXRvcnkuDQo+Pj4gDQo+Pj4gTmFtZToJCWRyYWZ0LWZhcnJlbGxsLW1wbHMt b3Bwb3J0dW5pc3RpYy1lbmNyeXB0IFJldmlzaW9uOgkwMyANCj4+PiBUaXRsZToJCU9wcG9ydHVu aXN0aWMgU2VjdXJpdHkgaW4gTVBMUyBOZXR3b3JrcyBEb2N1bWVudCBkYXRlOiANCj4+PiAyMDE0 LTEwLTI2IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uIFBhZ2VzOgkJMzAgVVJMOiANCj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mYXJyZWxsbC1tcGxz LW9wcG9ydHVuaXN0aQ0KPj4+IGMNCj4+Pg0KPj4+IA0KLQ0KPj4+IA0KPj4+IA0KPiBlbmNyeXB0 LTAzLnR4dA0KPj4+IFN0YXR1czogDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLQ0KPj4+DQo+Pj4NCj4NCj4+PiAN CmVuY3J5cHQvDQo+Pj4gSHRtbGl6ZWQ6IA0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWZhcnJlbGxsLW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0DQo+Pj4gLQ0KPj4+DQo+ Pj4NCj4NCj4+PiANCjAzDQo+Pj4gRGlmZjogDQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLQ0KPj4+DQo+Pj4NCj4N Cj4+PiANCmVuY3J5cHQtMDMNCj4+PiANCj4+PiBBYnN0cmFjdDogVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSB3YXkgdG8gYXBwbHkgb3Bwb3J0dW5pc3RpYyANCj4+PiBzZWN1cml0eSBiZXR3ZWVu IGFkamFjZW50IG5vZGVzIG9uIGFuIE1QTFMgTGFiZWwgU3dpdGNoZWQgUGF0aA0KPj4+IChMU1Ap IG9yIGJldHdlZW4gZW5kIHBvaW50cyBvZiBhbiBMU1AuICBJdCBleHBsYWlucyBob3cga2V5cyBt YXkgYmUgDQo+Pj4gYWdyZWVkIHRvIGVuYWJsZSBlbmNyeXB0aW9uLCBhbmQgaG93IGtleSBpZGVu dGlmaWVycyBhcmUgZXhjaGFuZ2VkIA0KPj4+IGluIGVuY3J5cHRlZCBNUExTIHBhY2tldHMuICBG aW5hbGx5LCB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgDQo+Pj4gYXBwbGljYWJpbGl0eSBv ZiB0aGlzIGFwcHJvYWNoIHRvIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaW4gTVBMUyANCj4+PiBu ZXR3b3JrcyB3aXRoIGFuIGluZGljYXRpb24gb2YgdGhlIGxldmVsIG9mIGltcHJvdmVkIHNlY3Vy aXR5IGFzIA0KPj4+IHdlbGwgYXMgdGhlIGNvbnRpbnVlZCB2dWxuZXJhYmlsaXRpZXMuDQo+Pj4g DQo+Pj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZXNjcmliZSBzZWN1cml0eSBmb3IgTVBMUyBj b250cm9sIHBsYW5lIA0KPj4+IHByb3RvY29scy4NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiAgDQo+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0ICANCj4+PiB0b29scy5pZXRmLm9yZy4NCj4+PiANCj4+ PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBtcGxzIG1haWxpbmcgbGlzdCANCj4+IG1wbHNAaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiANCg== From nobody Wed Oct 29 08:05:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C1C1A023E for ; Wed, 29 Oct 2014 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdU20_nPZU6H for ; Wed, 29 Oct 2014 08:05:25 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34AA1A01EA for ; Wed, 29 Oct 2014 08:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3399; q=dns/txt; s=iport; t=1414595125; x=1415804725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TM6ztS7w8r3L3a8O/C1ErnROc9TFRZkus1FzkI3Jzaw=; b=c9NxcVqsuO+YQIbh7Ct0iH3EfuiTYS/wiX7uigaLqmsYENGyP+IA3NqX w83pNTQgS0uc2YZVDJfkaNEon+LNzvqznr9THPys/i0zn17gjLfsBtAtK 9riiG1nRII5cgPL9P7DvY8OWwfIdTtfknBqSjZqyu1gAnwL0vNtV/YsIY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOgBUVStJV2Z/2dsb2JhbABcgmsjgSwE1WYCgRsWAQEBAQFyC4QCAQEBAwF5BQsCAQgYLjIlAQEEDgWIOAkBxzIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFYzB4MtgR4BBI9tgh6LXYExg0mKGYclg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="91423114" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 29 Oct 2014 15:05:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9TF5O8X010734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 15:05:24 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 10:05:24 -0500 From: "Carlos Pignataro (cpignata)" To: "afarrel@juniper.net" Thread-Topic: AD review of draft-ietf-mpls-ipv6-only-gap Thread-Index: Ac/mauYYyhokKc65RvSg1yxokjWp6AMprgKAAASl2wD//8B4gIABBvYAgABXf4A= Date: Wed, 29 Oct 2014 15:05:24 +0000 Message-ID: <6A63E6C4-EE90-4375-AE9F-6EF0758D8629@cisco.com> References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> In-Reply-To: <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/N10gQTmoAUrO_guMZbH9B7KCoeQ Cc: "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:05:27 -0000 Hi Adrian, Continuing the discussion, please see inline. > On Oct 29, 2014, at 5:52 AM, Adrian Farrel wrote: >=20 > Hi again Carlos, >=20 >> I meant to type =B3RFC 4990 is GMPLS specific=B2, and not what I wrote. >>=20 >> Please ignore the associated consequences from my typo, I was thinking >> =B3MPLS-TP=B2 when I wrote the sentence in my response :-) >=20 > Yeah, I know. Sometimes those fingers just won't type what you tell them = to. > But, of course, and as you recognise in the new revision you just sent me= , 4990 > is not GMPLS specific since section 8 clearly notes it applies to MPLS-TE= and > GMPLS. >=20 >> Basically, Section 3.5 says three things: >> 1. Major Gap! RFC 3811 TC for MPLS (which are use in a bunch of MPLS MIB >> Modules) lack support for IPv6 in specific cases (Gap) and one I-D tries >> to resolve that gap (incidentally authored by one of our contributors) >=20 > Yup. It says this. And that is what I am questioning. > I agree that the 3811bis I-D tries to fix this gap, I just don't agree th= at it > is a "major" because 4990 shows how it can be circumvented. > That is not to say that 3811bis could not be valuable (with some work), b= ut it > would be very wrong to imply that IPv6 deployment or operation is in some= way > gated by this because there are ways of handling the situation. > This to me makes the issue minor, not major. >=20 I certainly do not disagree with this. Here=92s one quick proposal: 3.5. MIB Modules RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS TE Management Information Base (MIB) specification RFC 3812 [RFC3812], GMPLS TE MIB specification RFC 4802 [RFC4802] and Fast ReRoute (FRR) extension RFC 6445 [RFC6445]. RFC 3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking this textual convention as obsolete. The other MIB specifications for LSR RFC 3813 [RFC3813], LDP RFC 3815 [RFC3815] and TE RFC 4220 [RFC4220] have support for both IPv4 and IPv6. Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules. In particular, Section 8 of RFC 4990 [RFC4990] describes a method of defining or monitoring an LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around some of the limitations in RFC 3811 [RFC3811]. Gap: Minor. Section 8 of RFC 4990 [RFC4990] describes a method to handle IPv6 addresses in the MPLS-TE RFC 3812 [RFC3812] and GMPLS-TE RFC 4802 [RFC4802] MIB modules. Work underway to update RFC 3811 via RFC 3811bis [I-D.manral-mpls-rfc3811bis], may also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on it. Thanks, Carlos. >> 2. Other MIB Modules had adequate support for IPv4 and IPv6 >> 3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing how to >> handle IPv6. >=20 > See above (and note that it's OK to include MPLS-TP in the list :-) >=20 > I think we should continue to work through this discussion, but that the > document as it is should go forward to the IESG. >=20 > Thanks, > Adrian >=20 >=20 From nobody Wed Oct 29 09:56:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDC41A1BBB for ; Wed, 29 Oct 2014 09:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtmAjtbqtxHF for ; Wed, 29 Oct 2014 09:56:56 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4E11A1BB9 for ; Wed, 29 Oct 2014 09:56:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9TGum2v012339; Wed, 29 Oct 2014 16:56:48 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9TGufXL012211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 16:56:45 GMT From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <044501cfe66a$ee9ecc60$cbdc6520$@olddog.co.uk> <1CD4BA73-39CE-456C-A7BE-47BAA05A253F@cisco.com> <035901cff2fa$4da8fd20$e8faf760$@olddog.co.uk> <042e01cff35e$04fc9050$0ef5b0f0$@juniper.net> <6A63E6C4-EE90-4375-AE9F-6EF0758D8629@cisco.com> In-Reply-To: <6A63E6C4-EE90-4375-AE9F-6EF0758D8629@cisco.com> Date: Wed, 29 Oct 2014 16:56:36 -0000 Message-ID: <05b801cff399$50bf64a0$f23e2de0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvixUQwakdbx63j6KCa5k5aG2m5AEtT/YAAgg5QcMBaxYP5gIaRLgoAPF1CM2ayrj10A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21062.000 X-TM-AS-Result: No--27.811-10.0-31-10 X-imss-scan-details: No--27.811-10.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTmnykMun0J1wvHkpkyUphL9Ud7Bjfo+5jQHp3cP4ojBkBnA aXSBh1PM6LOKOlQRBR1tvTo2fi0oItgwSqFJytAFmlaAItiONP249IoBojnioWso23uKlCJjyJo kIIYQvMRTeDcL7rIJUNC7dxc1eSYHQhQehsXrNgYPATeqdT9BM2GNLTRnb5YtZ5yuplze9psodc qwM12bKfgWORIqPROPVOB9PdPRQ95NlZ1zEcyAY49hRjNfZeOXddm7360F1gVR6SMusLeVME0CV QB/4kCzgAxHH07BxuT+hz2wcuk4dZZtaC3mVX1vBEfU2vugRF0ZKp0SZ4P+dQDqzaYhcjeQuwhq yc+q/JD4AqzgsVQC9SpK6ECaBvJFYY3ozW+Enge+NtCxbjBfhhG7O3fs/XPLD1W+NVq+ASc3XO+ 2UG4W2P6BPic60PnK4NmLXiRL6/bckJkyFPeQPeG5dRZCgxC39CFlFEyD3YTKY//WmIj/oaJyNS wA1FcGRI3oVarEpgnjZDvcQ0T2FWgwIvLATTKBVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/g_geWvNEywLiHUicC7gfnsQbpVY Cc: mpls@ietf.org, draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:56:58 -0000 I like this proposal. Thanks for going the extra mile. Adrian > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 29 October 2014 15:05 > To: afarrel@juniper.net > Cc: Adrian Farrel; draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org; mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-ipv6-only-gap >=20 > Hi Adrian, >=20 > Continuing the discussion, please see inline. >=20 > > On Oct 29, 2014, at 5:52 AM, Adrian Farrel = wrote: > > > > Hi again Carlos, > > > >> I meant to type =B3RFC 4990 is GMPLS specific=B2, and not what I = wrote. > >> > >> Please ignore the associated consequences from my typo, I was = thinking > >> =B3MPLS-TP=B2 when I wrote the sentence in my response :-) > > > > Yeah, I know. Sometimes those fingers just won't type what you tell = them to. > > But, of course, and as you recognise in the new revision you just = sent me, 4990 > > is not GMPLS specific since section 8 clearly notes it applies to = MPLS-TE and > > GMPLS. > > > >> Basically, Section 3.5 says three things: > >> 1. Major Gap! RFC 3811 TC for MPLS (which are use in a bunch of = MPLS MIB > >> Modules) lack support for IPv6 in specific cases (Gap) and one I-D = tries > >> to resolve that gap (incidentally authored by one of our = contributors) > > > > Yup. It says this. And that is what I am questioning. > > I agree that the 3811bis I-D tries to fix this gap, I just don't = agree that it > > is a "major" because 4990 shows how it can be circumvented. > > That is not to say that 3811bis could not be valuable (with some = work), but it > > would be very wrong to imply that IPv6 deployment or operation is in = some > way > > gated by this because there are ways of handling the situation. > > This to me makes the issue minor, not major. > > >=20 > I certainly do not disagree with this. >=20 > Here=92s one quick proposal: >=20 > 3.5. MIB Modules >=20 > RFC 3811 [RFC3811] defines the textual conventions for MPLS. These > lack support for IPv6 in defining MplsExtendedTunnelId and > MplsLsrIdentifier. These textual conventions are used in the MPLS = TE > Management Information Base (MIB) specification RFC 3812 [RFC3812], > GMPLS TE MIB specification RFC 4802 [RFC4802] and Fast ReRoute = (FRR) > extension RFC 6445 [RFC6445]. RFC 3811bis > [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking > this textual convention as obsolete. >=20 > The other MIB specifications for LSR RFC 3813 [RFC3813], LDP RFC = 3815 > [RFC3815] and TE RFC 4220 [RFC4220] have support for both IPv4 and > IPv6. >=20 > Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and > destinations in the MPLS and GMPLS Traffic Engineering (TE) > Management Information Base (MIB) modules. In particular, Section = 8 > of RFC 4990 [RFC4990] describes a method of defining or monitoring = an > LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working = around > some of the limitations in RFC 3811 [RFC3811]. >=20 > Gap: Minor. Section 8 of RFC 4990 [RFC4990] describes a method to > handle IPv6 addresses in the MPLS-TE RFC 3812 [RFC3812] and = GMPLS-TE > RFC 4802 [RFC4802] MIB modules. Work underway to update RFC 3811 = via > RFC 3811bis [I-D.manral-mpls-rfc3811bis], may also need to update = RFC > 3812, RFC 4802, and RFC 6445, which depend on it. >=20 >=20 > Thanks, >=20 > Carlos. >=20 > >> 2. Other MIB Modules had adequate support for IPv4 and IPv6 > >> 3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing = how to > >> handle IPv6. > > > > See above (and note that it's OK to include MPLS-TP in the list :-) > > > > I think we should continue to work through this discussion, but that = the > > document as it is should go forward to the IESG. > > > > Thanks, > > Adrian > > > > From nobody Wed Oct 29 10:36:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A052D1A7023 for ; Wed, 29 Oct 2014 10:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUN8mDXYmqxh for ; Wed, 29 Oct 2014 10:36:36 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0922A1A8729 for ; Wed, 29 Oct 2014 10:36:25 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so1058548ier.6 for ; Wed, 29 Oct 2014 10:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YVTTDiJ7Hx49xTMSb3P8kHxPmwHKXdk1i4zVXCDPEIk=; b=jjtOur3NnBC6x03A50RfW8qhcAiw2YT57IIxmXbYaZBx5w3dMnhoe2ksvkkhcOvXBD No9MpLEve4/8KK5+ZFKsZ6jU1s23W8V4v409RjrR9kLL/w7HsQhw3Dz+lVc5EZuGzF+0 Y9KfdvwYQf2DvsjtWHuMWmcNuqOEc6T3VVEy2zlu7VQOkWQn4pmcqQaynyLyoWvagwK5 dRqupEmnuDCqS8QetBJS3tavgAliJP2KQN++byvw2WdhgM5MblyPPbzNO1S7gMfAscWs 0OaGopaNzO9xAsAFPtrLO3WeSZcKmpP6nGyLaFtfY2Ix52pmjcQdEUV7GM0HPIrZe27m lpfQ== MIME-Version: 1.0 X-Received: by 10.42.86.142 with SMTP id u14mr3810499icl.77.1414604185379; Wed, 29 Oct 2014 10:36:25 -0700 (PDT) Received: by 10.64.109.229 with HTTP; Wed, 29 Oct 2014 10:36:25 -0700 (PDT) In-Reply-To: <20141027231233.21010.5632.idtracker@ietfa.amsl.com> References: <20141027231233.21010.5632.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 10:36:25 -0700 Message-ID: From: Kireeti Kompella To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=20cf301cbd40f7ae610506933321 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NCP4VgQfrkbpqNWoxqBjQZGxfYE Subject: [mpls] Fwd: New Version Notification for draft-kompella-mpls-larp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:36:38 -0000 --20cf301cbd40f7ae610506933321 Content-Type: text/plain; charset=UTF-8 Hi All, Not sure why this didn't get copied to the MPLS WG list. In any case, this update breaks out the "Hardware Address" into two parts. The HA part contains just the MAC address of L-ARP replier. Labels are in a separate TLV that now can contain a label stack. Finally, the metric is taken out of the HA part and is separate. We also have a new co-author, George Swallow. Please comment on the draft as a whole, and on these changes in particular. Thanks, Kireeti. ---------- Forwarded message ---------- From: Date: Mon, Oct 27, 2014 at 4:12 PM Subject: New Version Notification for draft-kompella-mpls-larp-02.txt To: Kireeti Kompella , George Swallow < swallow@cisco.com>, Balaji Rajagopalan A new version of I-D, draft-kompella-mpls-larp-02.txt has been successfully submitted by Kireeti Kompella and posted to the IETF repository. Name: draft-kompella-mpls-larp Revision: 02 Title: Label Distribution Using ARP Document date: 2014-10-27 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt Status: https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/ Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-larp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kompella-mpls-larp-02 Abstract: This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is a key goal of the MPLS Fabric architecture. 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. The IETF Secretariat -- Kireeti --20cf301cbd40f7ae610506933321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Not sure why this didn't ge= t copied to the MPLS WG list.

In any case, this up= date breaks out the "Hardware Address" into two parts.=C2=A0 The = HA part contains just the MAC address of L-ARP replier.=C2=A0 Labels are in= a separate TLV that now can contain a label stack.=C2=A0 Finally, the metr= ic is taken out of the HA part and is separate.

We= also have a new co-author, George Swallow.

Please= comment on the draft as a whole, and on these changes in particular.
=

Thanks,
Kireeti.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Oct 27, = 2014 at 4:12 PM
Subject: New Version Notification for draft-kompella-mpl= s-larp-02.txt
To: Kireeti Kompella <kireeti.kompella@gmail.com>, George Swallow <swallow@cisco.com>, Balaji Rajagopalan= <balajir@juniper.net>
=


A new version of I-D, draft-kompella-mpls-larp-02.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kompella-mpls-larp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Label Distribution Using ARP
Document date:=C2=A0 2014-10-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-kompella-mpls-larp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr= aft-kompella-mpls-larp-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-larp-02

Abstract:
=C2=A0 =C2=A0This document describes extensions to the Address Resolution P= rotocol
=C2=A0 =C2=A0to distribute MPLS labels for IPv4 and IPv6 host addresses. =C2=A0 =C2=A0Distribution of labels via ARP enables simple plug-and-play op= eration
=C2=A0 =C2=A0of MPLS, which is a key goal of the MPLS Fabric architecture.<= br>




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

The IETF Secretariat




--
Kireeti
--20cf301cbd40f7ae610506933321-- From nobody Wed Oct 29 10:40:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714331A8735 for ; Wed, 29 Oct 2014 10:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-RyO7CoDHzg for ; Wed, 29 Oct 2014 10:40:49 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E4C1A8708 for ; Wed, 29 Oct 2014 10:40:43 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id l13so1887304iga.3 for ; Wed, 29 Oct 2014 10:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=r50z4PK2QH1BCnxXdnR6U5gUPBlgP1QB7fcNV+7Ywhs=; b=WCubbjEHPNPh8TiuD5Z0iZtjUtCwp+x39da7clLb+rQGGOZqnd3IpRxlQv4fWYLBxq Iz+4axKY3WI/V4dagV9XjUd/iUYsi9/a4cSlKTjCdY5B/rNnbmWUTviRGFn7lj8+qwGu CnQ7yNYWWccSS+WBWZNvdouG8cgPfxygmexvCojwQmVtck/T/Nm7gOlC48v5Ec/VlTXm 4Es8UPLnmsu5wYuXT9LmhTtOw//ev5mFE+i33i3QUKxOncKCXLcho4d+jtCkzEPbR4E1 FZpstNuXG81p8ajG1jgo6cuE90Zr5m6Qu9EcK/k0MaolXb90Iep+7dOejw1nNBFsHqeb rqsg== MIME-Version: 1.0 X-Received: by 10.42.86.142 with SMTP id u14mr3834613icl.77.1414604442901; Wed, 29 Oct 2014 10:40:42 -0700 (PDT) Received: by 10.64.109.229 with HTTP; Wed, 29 Oct 2014 10:40:42 -0700 (PDT) In-Reply-To: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 10:40:42 -0700 Message-ID: From: Kireeti Kompella To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=20cf301cbd405120b205069343f3 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4ix8CSxYNGYbA5G6ilMDeK4TYr4 Subject: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:40:51 -0000 --20cf301cbd405120b205069343f3 Content-Type: text/plain; charset=UTF-8 Hi Folks, This is a draft on making MPLS more efficient in ring networks. I have come around to understanding that: a) rings are a special topology (there was a time that I didn't appreciate that); b) MPLS is pretty inefficient in rings (that is/was quite obvious). This draft attempts to fix that, both by making protection much more efficient, and by making configuration much easier. Your comments are highly welcome! Cheers, Kireeti. ---------- Forwarded message ---------- From: Date: Sun, Oct 26, 2014 at 9:15 PM Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt To: Kireeti Kompella A new version of I-D, draft-kompella-mpls-rmr-00.txt has been successfully submitted by Kireeti Kompella and posted to the IETF repository. Name: draft-kompella-mpls-rmr Revision: 00 Title: Resilient MPLS Rings Document date: 2014-10-26 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt Status: https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/ Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-rmr-00 Abstract: This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. 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. The IETF Secretariat -- Kireeti --20cf301cbd405120b205069343f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

This is a draft on making MPL= S more efficient in ring networks.=C2=A0 I have come around to understandin= g that:
a) rings are a special topology (there was a time that I = didn't appreciate that);
b) MPLS is pretty inefficient in rin= gs (that is/was quite obvious).

This draft attempt= s to fix that, both by making protection much more efficient, and by making= configuration much easier.

Your comments are high= ly welcome!

Cheers,
Kireeti.
<= br>
---------- Forwarded message ----------
Fr= om: <internet-drafts@ietf.org>
Da= te: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for d= raft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <kireeti.kompella@gmail.com>


=
A new version of I-D, draft-kompella-mpls-rmr-00.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kompella-mpls-rmr
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resilient MPLS Rings
Document date:=C2=A0 2014-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://= www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.i= etf.org/doc/draft-kompella-mpls-rmr/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dra= ft-kompella-mpls-rmr-00


Abstract:
=C2=A0 =C2=A0This document describes the use of the MPLS control and data p= lanes
=C2=A0 =C2=A0on ring topologies.=C2=A0 It describes the special nature of r= ings, and
=C2=A0 =C2=A0proceeds to show how MPLS can be effectively used in such topo= logies.
=C2=A0 =C2=A0It describes how MPLS rings are configured, auto-discovered an= d
=C2=A0 =C2=A0signaled, as well as how the data plane works.=C2=A0 Companion= documents
=C2=A0 =C2=A0describe the details of discovery and signaling for specific =C2=A0 =C2=A0protocols.





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

The IETF Secretariat




--
Kireeti
--20cf301cbd405120b205069343f3-- From nobody Wed Oct 29 10:59:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB31A872A for ; Wed, 29 Oct 2014 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE6MDnNQUTLV for ; Wed, 29 Oct 2014 10:59:23 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id DDE6F1A01EA for ; Wed, 29 Oct 2014 10:59:22 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.07,278,1413270000"; d="scan'208,217"; a="49656041" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 29 Oct 2014 12:26:02 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 29 Oct 2014 10:59:22 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 10:59:23 -0700 From: Shahram Davari To: Kireeti Kompella , "mpls@ietf.org" Thread-Topic: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt Thread-Index: AQHP85+FAvZmw6tXWEmbKp10Lmg7npxHWySQ Date: Wed, 29 Oct 2014 17:59:23 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_4A6CE49E6084B141B15C0713B8993F2831D6528CSJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sSV_YDXpatdwV4_3ksa5yJSP6fQ Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:59:25 -0000 --_000_4A6CE49E6084B141B15C0713B8993F2831D6528CSJEXCHMB12corpa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2lyZWV0aSwNCg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIGFkZCBhIHNlY3Rpb24g dG8gZGVzY3JpYmUgd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHlvdXIgZHJhZnQgYW5k IHRoZSBmb2xsb3dpbmcgUkZDL2RyYWZ0cywgYW5kIHdoeSBpdCBpcyBiZXR0ZXIuDQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTc0DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWNoZW5nLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi0wMw0KDQpUaGFu a3MNClNoYWhyYW0NCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEtpcmVldGkgS29tcGVsbGENClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAy OSwgMjAxNCAxMDo0MSBBTQ0KVG86IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta29tcGVsbGEtbXBscy1ybXItMDAu dHh0DQoNCkhpIEZvbGtzLA0KDQpUaGlzIGlzIGEgZHJhZnQgb24gbWFraW5nIE1QTFMgbW9yZSBl ZmZpY2llbnQgaW4gcmluZyBuZXR3b3Jrcy4gIEkgaGF2ZSBjb21lIGFyb3VuZCB0byB1bmRlcnN0 YW5kaW5nIHRoYXQ6DQphKSByaW5ncyBhcmUgYSBzcGVjaWFsIHRvcG9sb2d5ICh0aGVyZSB3YXMg YSB0aW1lIHRoYXQgSSBkaWRuJ3QgYXBwcmVjaWF0ZSB0aGF0KTsNCmIpIE1QTFMgaXMgcHJldHR5 IGluZWZmaWNpZW50IGluIHJpbmdzICh0aGF0IGlzL3dhcyBxdWl0ZSBvYnZpb3VzKS4NCg0KVGhp cyBkcmFmdCBhdHRlbXB0cyB0byBmaXggdGhhdCwgYm90aCBieSBtYWtpbmcgcHJvdGVjdGlvbiBt dWNoIG1vcmUgZWZmaWNpZW50LCBhbmQgYnkgbWFraW5nIGNvbmZpZ3VyYXRpb24gbXVjaCBlYXNp ZXIuDQoNCllvdXIgY29tbWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lIQ0KDQpDaGVlcnMsDQpLaXJl ZXRpLg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+ DQpEYXRlOiBTdW4sIE9jdCAyNiwgMjAxNCBhdCA5OjE1IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dA0KVG86IEtp cmVldGkgS29tcGVsbGEgPGtpcmVldGkua29tcGVsbGFAZ21haWwuY29tPG1haWx0bzpraXJlZXRp LmtvbXBlbGxhQGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt a29tcGVsbGEtbXBscy1ybXItMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEtpcmVldGkgS29tcGVsbGEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yDQpSZXZpc2lvbjogICAg ICAgMDANClRpdGxlOiAgICAgICAgICBSZXNpbGllbnQgTVBMUyBSaW5ncw0KRG9jdW1lbnQgZGF0 ZTogIDIwMTQtMTAtMjYNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOiAgICAgICAgICA3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta29tcGVsbGEtbXBscy1ybXItMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta29tcGVsbGEtbXBscy1y bXIvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta29t cGVsbGEtbXBscy1ybXItMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSB1c2Ugb2YgdGhlIE1QTFMgY29udHJvbCBhbmQgZGF0YSBwbGFuZXMNCiAgIG9uIHJp bmcgdG9wb2xvZ2llcy4gIEl0IGRlc2NyaWJlcyB0aGUgc3BlY2lhbCBuYXR1cmUgb2YgcmluZ3Ms IGFuZA0KICAgcHJvY2VlZHMgdG8gc2hvdyBob3cgTVBMUyBjYW4gYmUgZWZmZWN0aXZlbHkgdXNl ZCBpbiBzdWNoIHRvcG9sb2dpZXMuDQogICBJdCBkZXNjcmliZXMgaG93IE1QTFMgcmluZ3MgYXJl IGNvbmZpZ3VyZWQsIGF1dG8tZGlzY292ZXJlZCBhbmQNCiAgIHNpZ25hbGVkLCBhcyB3ZWxsIGFz IGhvdyB0aGUgZGF0YSBwbGFuZSB3b3Jrcy4gIENvbXBhbmlvbiBkb2N1bWVudHMNCiAgIGRlc2Ny aWJlIHRoZSBkZXRhaWxzIG9mIGRpc2NvdmVyeSBhbmQgc2lnbmFsaW5nIGZvciBzcGVjaWZpYw0K ICAgcHJvdG9jb2xzLg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCi0t DQpLaXJlZXRpDQo= --_000_4A6CE49E6084B141B15C0713B8993F2831D6528CSJEXCHMB12corpa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBLaXJlZXRpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIGFk ZCBhIHNlY3Rpb24gdG8gZGVzY3JpYmUgd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHlv dXIgZHJhZnQgYW5kIHRoZSBmb2xsb3dpbmcgUkZDL2RyYWZ0cywgYW5kIHdoeSBpdCBpcyBiZXR0 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk3 NCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NzQ8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJl ZC1yaW5nLXByb3RlY3Rpb24tMDMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNo ZW5nLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi0wMzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGFocmFtPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LaXJlZXRpIEtvbXBlbGxhPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgT2N0b2JlciAyOSwgMjAxNCAxMDo0MSBBTTxicj4NCjxiPlRvOjwvYj4g bXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbXBsc10gRndkOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZvbGtzLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIGRyYWZ0IG9uIG1ha2luZyBN UExTIG1vcmUgZWZmaWNpZW50IGluIHJpbmcgbmV0d29ya3MuJm5ic3A7IEkgaGF2ZSBjb21lIGFy b3VuZCB0byB1bmRlcnN0YW5kaW5nIHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hKSByaW5ncyBhcmUgYSBzcGVjaWFsIHRvcG9sb2d5ICh0 aGVyZSB3YXMgYSB0aW1lIHRoYXQgSSBkaWRuJ3QgYXBwcmVjaWF0ZSB0aGF0KTs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIpIE1QTFMgaXMgcHJl dHR5IGluZWZmaWNpZW50IGluIHJpbmdzICh0aGF0IGlzL3dhcyBxdWl0ZSBvYnZpb3VzKS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBk cmFmdCBhdHRlbXB0cyB0byBmaXggdGhhdCwgYm90aCBieSBtYWtpbmcgcHJvdGVjdGlvbiBtdWNo IG1vcmUgZWZmaWNpZW50LCBhbmQgYnkgbWFraW5nIGNvbmZpZ3VyYXRpb24gbXVjaCBlYXNpZXIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv dXIgY29tbWVudHMgYXJlIGhpZ2hseSB3ZWxjb21lITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaXJlZXRpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBTdW4sIE9jdCAyNiwgMjAxNCBhdCA5OjE1IFBN PGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rb21wZWxs YS1tcGxzLXJtci0wMC50eHQ8YnI+DQpUbzogS2lyZWV0aSBLb21wZWxsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtpcmVldGkua29tcGVsbGFAZ21haWwuY29tIj5raXJlZXRpLmtvbXBlbGxhQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgS2lyZWV0aSBLb21wZWxsYSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQta29tcGVsbGEtbXBscy1ybXI8YnI+DQpSZXZpc2lvbjombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgUmVzaWxpZW50IE1QTFMgUmluZ3M8YnI+DQpEb2N1bWVudCBkYXRlOiZu YnNwOyAyMDE0LTEwLTI2PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDc8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQta29tcGVsbGEtbXBscy1ybXItMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rb21wZWxsYS1tcGxzLXJtci0wMC50 eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rb21wZWxsYS1tcGxz LXJtci8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rb21wZWxsYS1tcGxzLXJtci88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta29t cGVsbGEtbXBscy1ybXItMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1rb21wZWxsYS1tcGxzLXJtci0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBv ZiB0aGUgTVBMUyBjb250cm9sIGFuZCBkYXRhIHBsYW5lczxicj4NCiZuYnNwOyAmbmJzcDtvbiBy aW5nIHRvcG9sb2dpZXMuJm5ic3A7IEl0IGRlc2NyaWJlcyB0aGUgc3BlY2lhbCBuYXR1cmUgb2Yg cmluZ3MsIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtwcm9jZWVkcyB0byBzaG93IGhvdyBNUExTIGNh biBiZSBlZmZlY3RpdmVseSB1c2VkIGluIHN1Y2ggdG9wb2xvZ2llcy48YnI+DQombmJzcDsgJm5i c3A7SXQgZGVzY3JpYmVzIGhvdyBNUExTIHJpbmdzIGFyZSBjb25maWd1cmVkLCBhdXRvLWRpc2Nv dmVyZWQgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO3NpZ25hbGVkLCBhcyB3ZWxsIGFzIGhvdyB0aGUg ZGF0YSBwbGFuZSB3b3Jrcy4mbmJzcDsgQ29tcGFuaW9uIGRvY3VtZW50czxicj4NCiZuYnNwOyAm bmJzcDtkZXNjcmliZSB0aGUgZGV0YWlscyBvZiBkaXNjb3ZlcnkgYW5kIHNpZ25hbGluZyBmb3Ig c3BlY2lmaWM8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2xzLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxi cj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpLaXJlZXRpIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A6CE49E6084B141B15C0713B8993F2831D6528CSJEXCHMB12corpa_-- From nobody Wed Oct 29 11:59:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886C1A88C1 for ; Wed, 29 Oct 2014 11:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IURwJEIFwPZJ for ; Wed, 29 Oct 2014 11:59:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3FE1A88B3 for ; Wed, 29 Oct 2014 11:59:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8F86BE0E; Wed, 29 Oct 2014 18:59:41 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShzdpC9cwtde; Wed, 29 Oct 2014 18:59:39 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.19.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 64C28BE04; Wed, 29 Oct 2014 18:59:39 +0000 (GMT) Message-ID: <54513917.1090403@cs.tcd.ie> Date: Wed, 29 Oct 2014 18:59:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Osborne, Eric" , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> <5450D91A.2050500@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> <5450FB41.5000605@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC49C@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC49C@USIDCWVEMBX08.corp.global.level3.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_rK6RUSxq8g-fiUcw-1Ls307E1g Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:59:47 -0000 Hiya, On 29/10/14 14:52, Osborne, Eric wrote: > Inline with EO# > > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, October 29, 2014 > 10:36 AM To: Osborne, Eric; adrian@olddog.co.uk; mpls@ietf.org Cc: > draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: Re: > [mpls] FW: New Version Notification for > draft-farrelll-mpls-opportunistic-encrypt-03.txt > > > > On 29/10/14 14:32, Osborne, Eric wrote: >> "> Are there cryptographic reasons for the 10^6 recommendation? >> >> TBH, I forget, but probably not:-) Happy to look at making it >> longer and/or related to pps figures. (Would that last help?) Not >> going beyond the max (2^64) is the important one from a crypto >> POV." >> >> >> Key exchange should be done for two reasons: >> >> 1) the operator initiates it 2) the system requires it and does it >> automatically, perhaps with a preconfigured second key or perhaps >> with something auto-generated. > > Or #3, you aren't that confident that a D-H derived key won't leak > out, which is a reason to minimise the symmetric key lifetime. > > > EO# That seems like another flavor of either #1 or #2. Perhaps this > should be covered in an operations section - "the operator should be > able to change keys as frequently as desired in order to minimize the > risk of a leaked key, but at a frequency not deemed to be > operationally onerous. This varies both by pps and operator > preference. Something like that sounds reasonable, yes. > On a typical 10Gbit link a threshold of 2^50 packets > should allow the operator a little over two years before changing > keys. On a 1Tbit link a two-year key lifetime requires a 2^63 > threshold". > > If you're going to RECOMMEND a default, I'd say something like > "default SHOULD be set to a threshold that gives a key a 1-year > lifetime at line rate with small packets". I guess it depends on threat models. If you're worried about [1] then one might consider that 1 or two years for a symmetric key is too long. And re-keying had better be smooth anyway or else it'll just not be done. Both of those would argue for shorter key life-cycles, but I do agree that "not operationally onerous" is the top level requirement. S. [1] http://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969-3.html > > > > > eric > > > S > >> >> #2 should happen as rarely as possible, if for no other reason than >> key exchange is likely to be perilous. The actual crypto will be >> implemented in hardware and the exchange in software, so there >> needs to be some method to ensure that packets aren't lost during >> exchange. IIRC (from discussions in a previous life, not current >> employer) that's why there was very little MD5 auth deployed. >> >> But that's nothing to do with key change frequency. >> >> Let's assume I have a 10x100GE LAG - this is on the higher end of >> things today, but will be here soon enough. With something that >> big you're looking at 1.6*10^9 pps, perhaps better written as >> 2^30.57pps. This leaves me 2^33.4sec before I hit 2^64 packets. >> That's a little over 365 years. >> >> Set the key change threshold to 2^63 instead, to allow the operator >> sufficient time (!!) to change keys, and you're looking at 182 >> years before it's even a problem. Yes, 640k should be enough for >> everyone, and 512-bit crypto is going to be impossible to crack, >> and y2k is so far away nobody will care if we do two digit >> datecodes now...but seriously...that's a long time. >> >> I'd vote for setting that threshold as high as possible since there >> seems to be no reason to do otherwise. I don't see a reason to >> tie any recommendation to pps. >> >> >> >> >> eric >> >> >> >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, October 29, >> 2014 8:10 AM To: Osborne, Eric; adrian@olddog.co.uk; mpls@ietf.org >> Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org >> Subject: Re: [mpls] FW: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt-03.txt >> >> >> >> On 28/10/14 18:41, Osborne, Eric wrote: >>> First, a disclaimer. I know enough about crypto to know I don't >>> know enough about crypto to say anything useful about it. I >>> assume the magic Just Works. >>> >>> Second, a question on the key change frequency. The document >>> RECOMMENDs a new key every 10^6 packets, and sets a hard limit of >>> 2^64. This is a huge range, and the recommended value doesn't >>> seem useful on anything modern. 160Mpps with a new key every >>> 10^6 packets is 160 keys per second. Even on a 10Mb Ethernet >>> it's almost a new key every minute[1] per interface. >>> >>> Are there cryptographic reasons for the 10^6 recommendation? >> >> TBH, I forget, but probably not:-) Happy to look at making it >> longer and/or related to pps figures. (Would that last help?) Not >> going beyond the max (2^64) is the important one from a crypto >> POV. >> >> Cheers, S. >> >>> If not, can it be bumped to something saner, or perhaps provide a >>> recommend range? Practically speaking this is going to be so >>> heavy to implement that any recommended numbers should be about >>> putting as much time as possible between key exchanges if they >>> can't be eliminated outright. >>> >>> >>> Third, a nit. Typo: Section 4.2.1, "bidirecitonal" >>> >>> >>> >>> >>> eric [1] because I never trust myself to do math in public: at >>> 16kpps for 10Mbit ethernet and 10^6 packets per key, that's 0.02 >>> keys/sec, or 0.96 keys/minute. >>> >>> >>> -----Original Message----- From: mpls >>> [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: >>> Monday, October 27, 2014 12:31 PM To: mpls@ietf.org Cc: >>> draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org Subject: >>> [mpls] FW: New Version Notification for >>> draft-farrelll-mpls-opportunistic-encrypt-03.txt >>> >>> Hi MPLS WG, >>> >>> The Farrel twins have been playing with the concept of >>> opportunistic encryption for MPLS. This is very much positioned >>> as an experiment. >>> >>> We'd like to hear from people who are interested in this as an >>> idea we should look into further. >>> >>> And, of course, we'd love to discuss the ideas in the draft. >>> >>> Adrian and Stephen >>> >>>> -----Original Message----- From: internet-drafts@ietf.org >>>> [mailto:internet-drafts@ietf.org] Sent: 26 October 2014 23:16 >>>> To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen >>>> Farrell Subject: New Version Notification for >>>> draft-farrelll-mpls-opportunistic-encrypt- 03.txt >>>> >>>> >>>> A new version of I-D, >>>> draft-farrelll-mpls-opportunistic-encrypt-03.txt has been >>>> successfully submitted by Adrian Farrel and posted to the IETF >>>> repository. >>>> >>>> Name: draft-farrelll-mpls-opportunistic-encrypt Revision: 03 >>>> Title: Opportunistic Security in MPLS Networks Document date: >>>> 2014-10-26 Group: Individual Submission Pages: 30 URL: >>>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunisti >>>> >>>> c >>>> >>>> > - >>>> >>>> >> encrypt-03.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >>>> >>>> >> >>>> > >>>> encrypt/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt >>>> >>>> - >>>> >>>> >> >>>> > 03 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic- >>>> >>>> >> >>>> > >>>> encrypt-03 >>>> >>>> Abstract: This document describes a way to apply opportunistic >>>> security between adjacent nodes on an MPLS Label Switched >>>> Path (LSP) or between end points of an LSP. It explains how >>>> keys may be agreed to enable encryption, and how key >>>> identifiers are exchanged in encrypted MPLS packets. Finally, >>>> this document describes the applicability of this approach to >>>> opportunistic security in MPLS networks with an indication of >>>> the level of improved security as well as the continued >>>> vulnerabilities. >>>> >>>> This document does not describe security for MPLS control plane >>>> protocols. >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>> >>> _______________________________________________ mpls mailing list >>> mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls >>> From nobody Wed Oct 29 12:28:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8D1A897E for ; Wed, 29 Oct 2014 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33Kd_T4kqrrc for ; Wed, 29 Oct 2014 12:28:39 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CE11A897D for ; Wed, 29 Oct 2014 12:28:39 -0700 (PDT) Received: from [216.82.242.147] by server-5.bemta-8.messagelabs.com id B9/57-03664-4EF31545; Wed, 29 Oct 2014 19:28:36 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-14.tower-95.messagelabs.com!1414610916!39387098!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29937 invoked from network); 29 Oct 2014 19:28:36 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-14.tower-95.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Oct 2014 19:28:36 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id E934433EC1; Wed, 29 Oct 2014 19:18:58 +0000 (GMT) Received: from USIDCWVEHT04.corp.global.level3.com (10.1.196.124) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 13:18:51 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT04.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 13:18:43 -0600 From: "Osborne, Eric" To: Stephen Farrell , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt Thread-Index: AQL7UGOfqefUWMYm4qSTFIHYjrRClpntYhUggAGGfgCAAb3DAP//u5WggABtIoD//5ul4IAArhGA//+gB9A= Date: Wed, 29 Oct 2014 19:18:42 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDFACAD6@USIDCWVEMBX08.corp.global.level3.com> References: <20141026231606.32240.5984.idtracker@ietfa.amsl.com> <018a01cff203$6b153790$413fa6b0$@olddog.co.uk> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAB7E5@USIDCWVEMBX08.corp.global.level3.com> <5450D91A.2050500@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC3C5@USIDCWVEMBX08.corp.global.level3.com> <5450FB41.5000605@cs.tcd.ie> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAC49C@USIDCWVEMBX08.corp.global.level3.com> <54513917.1090403@cs.tcd.ie> In-Reply-To: <54513917.1090403@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XAyYCzLshNGlzO2Kbj2HWk2beUs Cc: "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:28:42 -0000 SW5saW5lDQoNCi4uLg0KDQo+ID4gT24gYSB0eXBpY2FsIDEwR2JpdCBsaW5rIGEgdGhyZXNob2xk IG9mIDJeNTAgcGFja2V0cyBzaG91bGQgYWxsb3cgdGhlDQo+ID4gb3BlcmF0b3IgYSBsaXR0bGUg b3ZlciB0d28geWVhcnMgYmVmb3JlIGNoYW5naW5nIGtleXMuICBPbiBhIDFUYml0DQo+ID4gbGlu ayBhIHR3by15ZWFyIGtleSBsaWZldGltZSByZXF1aXJlcyBhIDJeNjMgdGhyZXNob2xkIi4NCj4g Pg0KPiA+IElmIHlvdSdyZSBnb2luZyB0byBSRUNPTU1FTkQgYSBkZWZhdWx0LCBJJ2Qgc2F5IHNv bWV0aGluZyBsaWtlDQo+ID4gImRlZmF1bHQgU0hPVUxEIGJlIHNldCB0byBhIHRocmVzaG9sZCB0 aGF0IGdpdmVzIGEga2V5IGEgMS15ZWFyDQo+ID4gbGlmZXRpbWUgYXQgbGluZSByYXRlIHdpdGgg c21hbGwgcGFja2V0cyIuDQo+IA0KPiBJIGd1ZXNzIGl0IGRlcGVuZHMgb24gdGhyZWF0IG1vZGVs cy4gSWYgeW91J3JlIHdvcnJpZWQgYWJvdXQgWzFdIHRoZW4gb25lDQo+IG1pZ2h0IGNvbnNpZGVy IHRoYXQgMSBvciB0d28geWVhcnMgZm9yIGEgc3ltbWV0cmljIGtleSBpcyB0b28gbG9uZy4NCg0K QWdyZWVkLiAgU28gbWF5YmUgMSB5ZWFyIGlzIGFzIGFyYml0cmFyeSBhIHJlY29tbWVuZGF0aW9u IGFzIDE2MCB0aW1lcyBhIHNlY29uZC4gDQpUaGVyZSBvdWdodCB0byBiZSBzb21lIHJlY29tbWVu ZGVkIGRlZmF1bHQganVzdCBzbyB0aGluZ3Mgd29yayBuaWNlbHkgb3V0IG9mIHRoZSBib3gsIGJ1 dCB0aGUgcmlnaHQgdmFsdWUgaXMgZ29pbmcgdG8gZGVwZW5kIG1vc3RseSBvbiB0aGUgYWN0dWFs IGludGVyZmFjZSBsb2FkLCB3aGljaCBzZWVtcyB3ZWlyZC4gIE1heWJlIHRoZSByaWdodCB3YXkg dG8gZG8gaXQgaXMgdG8gc3BlY2lmeSBhIGZhaXJseSBoaWdoIHBhY2tldCB0cmlnZ2VyIHRocmVz aG9sZCAoMl42MykgYnV0IGFsc28gcHJvdmlkZSBhIHNlcGFyYXRlLCB0aW1lLWJhc2VkIHRocmVz aG9sZCB0aGF0IHNheXMgImdlbmVyYXRlIGFuZCBzZW5kIGEgbmV3IGtleSBldmVyeSBYIGhvdXJz L2RheXMvd2Vla3MiLCBhbmQgdGhlbiBpc3N1ZSBhIG5ldyBrZXkgd2hlbiB3ZSB0cmlwIGVpdGhl ciBvZiB0aGVzZS4NCg0KDQoNCg0KZXJpYw0KDQoNCg0KPiBBbmQgcmUtDQo+IGtleWluZyBoYWQg YmV0dGVyIGJlIHNtb290aCBhbnl3YXkgb3IgZWxzZSBpdCdsbCBqdXN0IG5vdCBiZSBkb25lLiBC b3RoIG9mDQo+IHRob3NlIHdvdWxkIGFyZ3VlIGZvciBzaG9ydGVyIGtleSBsaWZlLWN5Y2xlcywg YnV0IEkgZG8gYWdyZWUgdGhhdCAibm90DQo+IG9wZXJhdGlvbmFsbHkgb25lcm91cyIgaXMgdGhl IHRvcCBsZXZlbCByZXF1aXJlbWVudC4NCj4gDQo+IFMuDQo+IA0KPiBbMV0NCj4gaHR0cDovL3d3 dy5zcGllZ2VsLmRlL2ludGVybmF0aW9uYWwvd29ybGQvdGhlLW5zYS11c2VzLXBvd2VyZnVsLQ0K PiB0b29sYm94LWluLWVmZm9ydC10by1zcHktb24tZ2xvYmFsLW5ldHdvcmtzLWEtOTQwOTY5LTMu aHRtbA0KPiANCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IGVyaWMNCj4gPg0KPiA+DQo+ID4gUw0K PiA+DQo+ID4+DQo+ID4+ICMyIHNob3VsZCBoYXBwZW4gYXMgcmFyZWx5IGFzIHBvc3NpYmxlLCBp ZiBmb3Igbm8gb3RoZXIgcmVhc29uIHRoYW4NCj4gPj4ga2V5IGV4Y2hhbmdlIGlzIGxpa2VseSB0 byBiZSBwZXJpbG91cy4gIFRoZSBhY3R1YWwgY3J5cHRvIHdpbGwgYmUNCj4gPj4gaW1wbGVtZW50 ZWQgaW4gaGFyZHdhcmUgYW5kIHRoZSBleGNoYW5nZSBpbiBzb2Z0d2FyZSwgc28gdGhlcmUgbmVl ZHMNCj4gPj4gdG8gYmUgc29tZSBtZXRob2QgdG8gZW5zdXJlIHRoYXQgcGFja2V0cyBhcmVuJ3Qg bG9zdCBkdXJpbmcgZXhjaGFuZ2UuDQo+ID4+IElJUkMgKGZyb20gZGlzY3Vzc2lvbnMgaW4gYSBw cmV2aW91cyBsaWZlLCBub3QgY3VycmVudA0KPiA+PiBlbXBsb3llcikgdGhhdCdzIHdoeSB0aGVy ZSB3YXMgdmVyeSBsaXR0bGUgTUQ1IGF1dGggZGVwbG95ZWQuDQo+ID4+DQo+ID4+IEJ1dCB0aGF0 J3Mgbm90aGluZyB0byBkbyB3aXRoIGtleSBjaGFuZ2UgZnJlcXVlbmN5Lg0KPiA+Pg0KPiA+PiBM ZXQncyBhc3N1bWUgSSBoYXZlIGEgMTB4MTAwR0UgTEFHIC0gdGhpcyBpcyBvbiB0aGUgaGlnaGVy IGVuZCBvZg0KPiA+PiB0aGluZ3MgdG9kYXksIGJ1dCB3aWxsIGJlIGhlcmUgc29vbiBlbm91Z2gu ICBXaXRoIHNvbWV0aGluZyB0aGF0IGJpZw0KPiA+PiB5b3UncmUgbG9va2luZyBhdCAxLjYqMTBe OSBwcHMsIHBlcmhhcHMgYmV0dGVyIHdyaXR0ZW4gYXMgMl4zMC41N3Bwcy4NCj4gPj4gVGhpcyBs ZWF2ZXMgbWUgMl4zMy40c2VjIGJlZm9yZSBJIGhpdCAyXjY0IHBhY2tldHMuDQo+ID4+IFRoYXQn cyBhIGxpdHRsZSBvdmVyIDM2NSB5ZWFycy4NCj4gPj4NCj4gPj4gU2V0IHRoZSBrZXkgY2hhbmdl IHRocmVzaG9sZCB0byAyXjYzIGluc3RlYWQsIHRvIGFsbG93IHRoZSBvcGVyYXRvcg0KPiA+PiBz dWZmaWNpZW50IHRpbWUgKCEhKSB0byBjaGFuZ2Uga2V5cywgYW5kIHlvdSdyZSBsb29raW5nIGF0 IDE4MiB5ZWFycw0KPiA+PiBiZWZvcmUgaXQncyBldmVuIGEgcHJvYmxlbS4gIFllcywgNjQwayBz aG91bGQgYmUgZW5vdWdoIGZvciBldmVyeW9uZSwNCj4gPj4gYW5kIDUxMi1iaXQgY3J5cHRvIGlz IGdvaW5nIHRvIGJlIGltcG9zc2libGUgdG8gY3JhY2ssIGFuZCB5MmsgaXMgc28NCj4gPj4gZmFy IGF3YXkgbm9ib2R5IHdpbGwgY2FyZSBpZiB3ZSBkbyB0d28gZGlnaXQgZGF0ZWNvZGVzIG5vdy4u LmJ1dA0KPiA+PiBzZXJpb3VzbHkuLi50aGF0J3MgYSBsb25nIHRpbWUuDQo+ID4+DQo+ID4+IEkn ZCB2b3RlIGZvciBzZXR0aW5nIHRoYXQgdGhyZXNob2xkIGFzIGhpZ2ggYXMgcG9zc2libGUgc2lu Y2UgdGhlcmUNCj4gPj4gc2VlbXMgdG8gYmUgbm8gcmVhc29uIHRvIGRvIG90aGVyd2lzZS4gIEkg ZG9uJ3Qgc2VlIGEgcmVhc29uIHRvIHRpZQ0KPiA+PiBhbnkgcmVjb21tZW5kYXRpb24gdG8gcHBz Lg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBlcmljDQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFN0ZXBoZW4gRmFycmVsbA0KPiA+ PiBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIFNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAyOSwNCj4gPj4gMjAxNCA4OjEwIEFNIFRvOiBPc2Jvcm5lLCBFcmljOyBhZHJpYW5Ab2xk ZG9nLmNvLnVrOyBtcGxzQGlldGYub3JnDQo+ID4+IENjOiBkcmFmdC1mYXJyZWxsbC1tcGxzLW9w cG9ydHVuaXN0aWMtZW5jcnlwdEB0b29scy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21w bHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+IGRyYWZ0LWZhcnJlbGxs LW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTAzLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ PiBPbiAyOC8xMC8xNCAxODo0MSwgT3Nib3JuZSwgRXJpYyB3cm90ZToNCj4gPj4+IEZpcnN0LCBh IGRpc2NsYWltZXIuICBJIGtub3cgZW5vdWdoIGFib3V0IGNyeXB0byB0byBrbm93IEkgZG9uJ3QN Cj4gPj4+IGtub3cgZW5vdWdoIGFib3V0IGNyeXB0byB0byBzYXkgYW55dGhpbmcgdXNlZnVsIGFi b3V0IGl0LiAgSSBhc3N1bWUNCj4gPj4+IHRoZSBtYWdpYyBKdXN0IFdvcmtzLg0KPiA+Pj4NCj4g Pj4+IFNlY29uZCwgYSBxdWVzdGlvbiBvbiB0aGUga2V5IGNoYW5nZSBmcmVxdWVuY3kuIFRoZSBk b2N1bWVudA0KPiA+Pj4gUkVDT01NRU5EcyBhIG5ldyBrZXkgZXZlcnkgMTBeNiBwYWNrZXRzLCBh bmQgc2V0cyBhIGhhcmQgbGltaXQgb2YNCj4gPj4+IDJeNjQuICBUaGlzIGlzIGEgaHVnZSByYW5n ZSwgYW5kIHRoZSByZWNvbW1lbmRlZCB2YWx1ZSBkb2Vzbid0IHNlZW0NCj4gPj4+IHVzZWZ1bCBv biBhbnl0aGluZyBtb2Rlcm4uICAxNjBNcHBzIHdpdGggYSBuZXcga2V5IGV2ZXJ5DQo+ID4+PiAx MF42IHBhY2tldHMgaXMgMTYwIGtleXMgcGVyIHNlY29uZC4gIEV2ZW4gb24gYSAxME1iIEV0aGVy bmV0IGl0J3MNCj4gPj4+IGFsbW9zdCBhIG5ldyBrZXkgZXZlcnkgbWludXRlWzFdIHBlciBpbnRl cmZhY2UuDQo+ID4+Pg0KPiA+Pj4gQXJlIHRoZXJlIGNyeXB0b2dyYXBoaWMgcmVhc29ucyBmb3Ig dGhlIDEwXjYgcmVjb21tZW5kYXRpb24/DQo+ID4+DQo+ID4+IFRCSCwgSSBmb3JnZXQsIGJ1dCBw cm9iYWJseSBub3Q6LSkgSGFwcHkgdG8gbG9vayBhdCBtYWtpbmcgaXQgbG9uZ2VyDQo+ID4+IGFu ZC9vciByZWxhdGVkIHRvIHBwcyBmaWd1cmVzLiAoV291bGQgdGhhdCBsYXN0IGhlbHA/KSBOb3Qg Z29pbmcNCj4gPj4gYmV5b25kIHRoZSBtYXggKDJeNjQpIGlzIHRoZSBpbXBvcnRhbnQgb25lIGZy b20gYSBjcnlwdG8gUE9WLg0KPiA+Pg0KPiA+PiBDaGVlcnMsIFMuDQo+ID4+DQo+ID4+PiBJZiBu b3QsIGNhbiBpdCBiZSBidW1wZWQgdG8gc29tZXRoaW5nIHNhbmVyLCBvciBwZXJoYXBzIHByb3Zp ZGUgYQ0KPiA+Pj4gcmVjb21tZW5kIHJhbmdlPyAgUHJhY3RpY2FsbHkgc3BlYWtpbmcgdGhpcyBp cyBnb2luZyB0byBiZSBzbyBoZWF2eQ0KPiA+Pj4gdG8gaW1wbGVtZW50IHRoYXQgYW55IHJlY29t bWVuZGVkIG51bWJlcnMgc2hvdWxkIGJlIGFib3V0IHB1dHRpbmcNCj4gYXMNCj4gPj4+IG11Y2gg dGltZSBhcyBwb3NzaWJsZSBiZXR3ZWVuIGtleSBleGNoYW5nZXMgaWYgdGhleSBjYW4ndCBiZQ0K PiA+Pj4gZWxpbWluYXRlZCBvdXRyaWdodC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gVGhpcmQsIGEg bml0LiBUeXBvOiBTZWN0aW9uIDQuMi4xLCAiYmlkaXJlY2l0b25hbCINCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiBlcmljIFsxXSBiZWNhdXNlIEkgbmV2ZXIgdHJ1c3QgbXlzZWxm IHRvIGRvIG1hdGggaW4gcHVibGljOiBhdA0KPiA+Pj4gMTZrcHBzIGZvciAxME1iaXQgZXRoZXJu ZXQgYW5kIDEwXjYgcGFja2V0cyBwZXIga2V5LCB0aGF0J3MgMC4wMg0KPiA+Pj4ga2V5cy9zZWMs IG9yIDAuOTYga2V5cy9taW51dGUuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ ID4+PiBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbCBTZW50Og0KPiA+Pj4gTW9uZGF5LCBPY3Rv YmVyIDI3LCAyMDE0IDEyOjMxIFBNIFRvOiBtcGxzQGlldGYub3JnIENjOg0KPiA+Pj4gZHJhZnQt ZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHRAdG9vbHMuaWV0Zi5vcmcgU3ViamVj dDoNCj4gPj4+ICBbbXBsc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4+ IGRyYWZ0LWZhcnJlbGxsLW1wbHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTAzLnR4dA0KPiA+Pj4N Cj4gPj4+IEhpIE1QTFMgV0csDQo+ID4+Pg0KPiA+Pj4gVGhlIEZhcnJlbCB0d2lucyBoYXZlIGJl ZW4gcGxheWluZyB3aXRoIHRoZSBjb25jZXB0IG9mIG9wcG9ydHVuaXN0aWMNCj4gPj4+IGVuY3J5 cHRpb24gZm9yIE1QTFMuIFRoaXMgaXMgdmVyeSBtdWNoIHBvc2l0aW9uZWQgYXMgYW4gZXhwZXJp bWVudC4NCj4gPj4+DQo+ID4+PiBXZSdkIGxpa2UgdG8gaGVhciBmcm9tIHBlb3BsZSB3aG8gYXJl IGludGVyZXN0ZWQgaW4gdGhpcyBhcyBhbiBpZGVhDQo+ID4+PiB3ZSBzaG91bGQgbG9vayBpbnRv IGZ1cnRoZXIuDQo+ID4+Pg0KPiA+Pj4gQW5kLCBvZiBjb3Vyc2UsIHdlJ2QgbG92ZSB0byBkaXNj dXNzIHRoZSBpZGVhcyBpbiB0aGUgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gQWRyaWFuIGFuZCBTdGVw aGVuDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+Pj4+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXSBTZW50OiAyNiBPY3RvYmVyIDIwMTQgMjM6MTYNCj4gPj4+PiBUbzogQWRyaWFuIEZhcnJl bDsgU3RlcGhlbiBGYXJyZWxsOyBBZHJpYW4gRmFycmVsOyBTdGVwaGVuIEZhcnJlbGwNCj4gPj4+ PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+Pj4gZHJhZnQtZmFy cmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLWVuY3J5cHQtIDAzLnR4dA0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCj4gPj4+PiBkcmFmdC1mYXJyZWxsbC1tcGxz LW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0wMy50eHQgaGFzIGJlZW4NCj4gPj4+PiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiA+ Pj4+IHJlcG9zaXRvcnkuDQo+ID4+Pj4NCj4gPj4+PiBOYW1lOgkJZHJhZnQtZmFycmVsbGwtbXBs cy1vcHBvcnR1bmlzdGljLWVuY3J5cHQgUmV2aXNpb246DQo+IAkwMw0KPiA+Pj4+IFRpdGxlOgkJ T3Bwb3J0dW5pc3RpYyBTZWN1cml0eSBpbiBNUExTIE5ldHdvcmtzIERvY3VtZW50DQo+IGRhdGU6 DQo+ID4+Pj4gIDIwMTQtMTAtMjYgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24gUGFnZXM6 DQo+IAkzMCBVUkw6DQo+ID4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdA0KPiA+Pj4+IGkNCj4gPj4+Pg0KPiA+Pj4+ DQo+IGMNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4gLQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4gZW5jcnlw dC0wMy50eHQNCj4gPj4+PiBTdGF0dXM6DQo+ID4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmFycmVsbGwtbXBscy1vcHBvcnR1bmlzdGljLQ0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4NCj4gPj4+Pg0KPiA+DQo+ID4+Pj4NCj4gZW5jcnlwdC8NCj4gPj4+PiBIdG1saXpl ZDoNCj4gPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWxsbC1tcGxz LW9wcG9ydHVuaXN0aWMtZW5jcnlwDQo+ID4+Pj4gdA0KPiA+Pj4+DQo+ID4+Pj4NCj4gLQ0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4NCj4gPj4+Pg0KPiA+IDAzDQo+ID4+Pj4gRGlmZjoNCj4gPj4+PiBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9y dHVuaXN0aWMtDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pg0KPiA+Pj4+DQo+ID4NCj4gPj4+Pg0KPiBl bmNyeXB0LTAzDQo+ID4+Pj4NCj4gPj4+PiBBYnN0cmFjdDogVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSB3YXkgdG8gYXBwbHkgb3Bwb3J0dW5pc3RpYw0KPiA+Pj4+IHNlY3VyaXR5IGJldHdlZW4g YWRqYWNlbnQgbm9kZXMgb24gYW4gTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRoDQo+ID4+Pj4gKExT UCkgb3IgYmV0d2VlbiBlbmQgcG9pbnRzIG9mIGFuIExTUC4gIEl0IGV4cGxhaW5zIGhvdyBrZXlz IG1heSBiZQ0KPiA+Pj4+IGFncmVlZCB0byBlbmFibGUgZW5jcnlwdGlvbiwgYW5kIGhvdyBrZXkg aWRlbnRpZmllcnMgYXJlIGV4Y2hhbmdlZA0KPiA+Pj4+IGluIGVuY3J5cHRlZCBNUExTIHBhY2tl dHMuICBGaW5hbGx5LCB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUNCj4gPj4+PiBhcHBsaWNh YmlsaXR5IG9mIHRoaXMgYXBwcm9hY2ggdG8gb3Bwb3J0dW5pc3RpYyBzZWN1cml0eSBpbiBNUExT DQo+ID4+Pj4gbmV0d29ya3Mgd2l0aCBhbiBpbmRpY2F0aW9uIG9mIHRoZSBsZXZlbCBvZiBpbXBy b3ZlZCBzZWN1cml0eSBhcw0KPiA+Pj4+IHdlbGwgYXMgdGhlIGNvbnRpbnVlZCB2dWxuZXJhYmls aXRpZXMuDQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGRlc2NyaWJlIHNl Y3VyaXR5IGZvciBNUExTIGNvbnRyb2wgcGxhbmUNCj4gPj4+PiBwcm90b2NvbHMuDQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+Pj4+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0K PiA+Pj4+IHRvb2xzLmlldGYub3JnLg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBtcGxzDQo+IG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZyBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+DQo= From nobody Thu Oct 30 03:15:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3491AD0A2; Thu, 30 Oct 2014 03:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hknjsRygGNUm; Thu, 30 Oct 2014 03:15:40 -0700 (PDT) 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 6137C1AD09E; Thu, 30 Oct 2014 03:15:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC32436; Thu, 30 Oct 2014 10:15:37 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Oct 2014 10:15:33 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 30 Oct 2014 18:15:29 +0800 From: Xuxiaohu To: "sfc@ietf.org" , "mpls@ietf.org" , "" Thread-Topic: About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Thread-Index: AQHP4WkpFJPaLJGjIUWt43ZhzuIOrJwl4oHQgCCrkLCAAKOpgIABXyHg Date: Thu, 30 Oct 2014 10:15:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C80A7@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HhenU2XEDfQFVpDHELqouz9Qv6o Subject: [mpls] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:15:45 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, There are many drafts which mentioned the possibility of using the MPLS sou= rce routing (i.e., MPLS-SPRING) mechanism for service function chain purpos= e. However, we do need a detailed evaluation of such possibility so as to f= igure out whether any potential extensions to the MPLS architecture is requ= ired. For instance, 1) although an MPLS label stack could be used to indicate an SFP, however, = when an SFF-proxy receives such a MPLS packet, it must know the payload typ= e of the MPLS packet before sending the original packet to the correspondin= g legacy SF. How? In fact, even in the non-legacy SF case, should the SFF d= irectly forward the MPLS packet to the corresponding SF directly or strip t= he MPLS header before sending the packet to the corresponding SF? In the fo= rmer case, the corresponding SF should know the payload type of the MPLS pa= cket. In the latter case, the SFF should know the payload type. To identify= the payload type, one way is to allocate a separate local label for each p= ayload type (is this a scalable way?), another way is to allocate an SPL or= an ESPL for each payload type (is this the normal purpose of the SPL or ES= PL), a third way is to introduce a SPL or ESPL which is followed by a proto= col id header (is this a significant change to the MPLS architecture?). 2) assume an SFF needs to strip the "whole" MPLS header before sending the = packet to the corresponding SF, does it mean a big change to the current MP= LS forwarding plane? 3) when using an MPLS label stack to indicate an SFC rather than an SFP, ea= ch SF would have to be identified by a domain-wide label. One way is to res= erve the same label range for SF SID purpose by all the SFFs. Another way i= s to rely on the context label concept (i.e., each SF of an SFC would have = to be represented by two labels in the label stack, one is the context indi= cation label, the other is the label allocated from that context label spac= e for that SF ). However, it seems that the domain-wide label usage is stil= l a controversial topic in the IETF community. 4) how to convey metadata in an MPLS packet? This issue may be the same as = issue 1. Any comments? Best regards, Xiaohu From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, October 29, 2014 8:15 PM To: Xuxiaohu; Thomas Narten Subject: Re: SFC Honolulu meeting agenda Hi Xiaohu, Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our im= mediate deliverables. For this reason we are unable to allocate time for di= scussion of your draft in HI. Please feel free to continue to solicit disc= ussion on the SFC mailing list. Jim & Thomas From: Xuxiaohu > Date: Tuesday, October 28, 2014 at 11:30 PM To: Jim Guichard >, Thomas Na= rten > Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I found there are still available time on the SFC agenda. Hence I wonder wh= ether you could allocate a 15-min slot for presenting this draft. Best regards, Xiaohu From: Xuxiaohu Sent: Wednesday, October 08, 2014 4:50 PM To: 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I would like to request a 15-min slot for presenting the following draft (h= ttps://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since "Gener= ic SFC Encapsulation" is one of the WG charter deliverables and the charter= states that "...The working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found..."= I would like the WG to help evaluating whether the MPLS-SPRING-based SFC e= ncapsulation approach as described in the above draft could be considered a= s one of the candidates. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, October 06, 2014 9:27 PM To: sfc@ietf.org Subject: [sfc] SFC Honolulu meeting agenda Greetings WG: Our meeting at the upcoming Honolulu venue is fast approaching. As always,= the goal of the meeting will be to make the best use of limited face-to-fa= ce time. As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and t= hat generally means focussing on key charter deliverables and topics with i= mportant open issues to resolve. In the case of individual IDs, the goal is= n't necessarily to present what is in the draft but rather to help the WG d= ecide what to do with the ID. With that in mind, when making an agenda requ= est please consider what you think the WG should do with its content. For e= xample: * Does the document have useful content that should be moved into anoth= er WG document or progress on it's own merit * Does the content have a good basis for one of the WG documents per th= e charter (in order for that to happen the document needs to be the most ap= propriate out of the collection of related documents) * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

There are many drafts which = mentioned the possibility of using the MPLS source routing (i.e., MPLS-SPRI= NG) mechanism for service function chain purpose. However, we do need a det= ailed evaluation of such possibility so as to figure out whether any potential extensions to the MPLS architect= ure is required. For instance,

 

1) although an MPLS label st= ack could be used to indicate an SFP, however, when an SFF-proxy receives s= uch a MPLS packet, it must know the payload type of the MPLS packet before = sending the original packet to the corresponding legacy SF. How? In fact, even in the non-legacy SF case, should the SFF di= rectly forward the MPLS packet to the corresponding SF directly or strip th= e MPLS header before sending the packet to the corresponding SF? In the for= mer case, the corresponding SF should know the payload type of the MPLS packet. In the latter case, the SFF shou= ld know the payload type. To identify the payload type, one way is to alloc= ate a separate local label for each payload type (is this a scalable way?),= another way is to allocate an SPL or an ESPL for each payload type (is this the normal purpose of the SPL or= ESPL), a third way is to introduce a SPL or ESPL which is followed by a pr= otocol id header (is this a significant change to the MPLS architecture?).<= o:p>

 

2) assume an SFF needs to st= rip the “<= /span>whole” MPLS hea= der before sending the packet to the corresponding SF, does it mean a big c= hange to the current MPLS forwarding plane?

 

3) when using an MPLS label = stack to indicate an SFC rather than an SFP, each SF would have to be ident= ified by a domain-wide label. One way is to reserve the same label range fo= r SF SID purpose by all the SFFs. Another way is to rely on the context label concept (i.e., each SF of an SFC would= have to be represented by two labels in the label stack, one is the contex= t indication label, the other is the label allocated from that context labe= l space for that SF ). However, it seems that the domain-wide label usage is still a controversial topic i= n the IETF community.

 

4) how to convey metadata in= an MPLS packet? This issue may be the same as issue 1.

 

Any comments?

 

Best regards,

Xiaohu

 = ;

 = ;

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda

 

Hi Xiaohu,

 <= /o:p>

Our agenda i= s not yet finalized but we will only be allowing slots for drafts that have= had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to allocate time for= discussion of your draft in HI.  Please feel free to continue to soli= cit discussion on the SFC mailing list.

 <= /o:p>

Jim & Th= omas

 <= /o:p>

From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda

 <= /o:p>

Hi co-chai= rs,

 

I found th= ere are still available time on the SFC agenda. Hence I wonder whether you = could allocate a 15-min slot for presenting this draft.

 

Best regar= ds,

Xiaohu

 

From: Xuxiaohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc@i= etf.org
Subject: RE: SFC Honolulu meeting agenda

 

Hi co-chai= rs,

 

I would li= ke to request a 15-min slot for presenting the following draft (https://tools.ietf.org/html/draft-x= u-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter del= iverables and the charter states that “…The working group will = consider using an existing encapsulation (with extensions as appropriate) i= f a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approac= h as described in the above draft could be considered as one of the candida= tes.

 

Best regar= ds,

Xiaohu

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc@ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

Greetings WG= :

 

Our meeting = at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-= to-face time.<= /span>

 

As we build = the meeting agenda we welcome requests for agenda time. As always, the goal= of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables and topics = with important open issues to resolve. In the case of individual IDs, the g= oal isn’t necessarily to present what is in the draft but rather to h= elp the WG decide what to do with the ID. With that in mind, when making an agenda request please consider what = you think the WG should do with its content. For example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on it’s own merit
  • Does the content have a good basis for one of t= he WG documents per the charter (in order for that to happen the document n= eeds to be the most appropriate out of the collection of related documents)
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644NKGEML512MBSchi_-- From nobody Thu Oct 30 03:47:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA41AD0B7 for ; Thu, 30 Oct 2014 03:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjUKadEid2Qq for ; Thu, 30 Oct 2014 03:47:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589431AD0B6 for ; Thu, 30 Oct 2014 03:47:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 51EC5BB8AF732 for ; Thu, 30 Oct 2014 10:47:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9UAlOTv018100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Oct 2014 11:47:26 +0100 Received: from [172.27.205.239] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 11:47:26 +0100 Message-ID: <5452173D.3050605@alcatel-lucent.com> Date: Thu, 30 Oct 2014 11:47:25 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JNr0Mj3RaihgiORCOd7qPR1N0r0 Subject: [mpls] IETF91 - MPLS - Agenda available - Please send your presentation material X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:47:31 -0000 All, the agenda is on-line: http://www.ietf.org/proceedings/91/agenda/agenda-91-mpls Please have a look at it. Speakers, please start sending me your presentation material, and please do so before Sunday 9th at noon, local time. Thank you Martin From nobody Thu Oct 30 03:48:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D87D1AD0C2 for ; Thu, 30 Oct 2014 03:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxa7h7aJEngY for ; Thu, 30 Oct 2014 03:48:33 -0700 (PDT) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1A61AD0BC for ; Thu, 30 Oct 2014 03:48:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1XjnHD-0003jG-MQ; Thu, 30 Oct 2014 12:48:23 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Thu, 30 Oct 2014 12:48:21 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart30763676.BKTITGRIWZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201410301248.22044.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Sw5N1Ylm0DPfZGGyhvVQGRBAYkI Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:48:36 -0000 --nextPart30763676.BKTITGRIWZ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, October 29, 2014 07:59:23 PM Shahram Davari=20 wrote: > It would be good if you can add a section to describe > what is the difference between your draft and the > following RFC/drafts, and why it is better. >=20 > https://tools.ietf.org/html/rfc6974 >=20 > http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-rin > g-protection-03 I'd also like to understand, better, from Kireeti, why he=20 think the current IP/MPLS implementations are not suitable=20 for ring architectures. That said, I'm keen on getting a better handle on this=20 draft, if it has the ability to make MPLS cheaper enough to=20 roll out on far less expensive devices that can be deployed=20 en masse in rings, in a way specific to ring architectures=20 and their cost structures. Mark. --nextPart30763676.BKTITGRIWZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJUUhd1AAoJEGcZuYTeKm+GUggQAI3mEQsiYQkQZabGFOJYa78d 1/68QZZXPsLwqqd4D7a4m4122mbQKKK/EfDbVfOdfPCV995mWpt1Cubpb6Q9gsfB 8sWASc9ZQhwkF7FVWPhsJRhl6/J0/INDGZxXLbK2lHcTIggosrsZOVv1v2ykQVK9 XoAcORnRZylM3prI7uCh0bKzBak/eQql1PGuoINUPw4Pn9/wax7jdZPfeBGxbe3s Rp2F+WfWEBMxwW9FlWEoRaWQICCzOycpnSXydE6btqUtynDAvO9UwH4yM9KETCml DrBBAUC0iQeLEPGWmWKEc4iOQd8LoaTDwzoCPHtwGs+p+1clvV94q1XHaQsaDnsJ kaqANExlJRPEUBSefXhjqIOCpuP7ed9uxbSzeW2QFoIVcPM6WQkoSthmzCucanI2 pOiYYLD5ZWUZgB7Y5Uvm97Wvu+HaZPA9BrhOsKJY93YONniRjLlCvqI4TNU8/zdQ 332c++V3p1qGyktRQGm/m4BCespkgzEc03t9AEftR3bbmsuLH8ImKWiU/cBxDxeO c2C8RYVwscfnEpCLLDSCWhAx9PLfLYcsmEg/bgfslUu9pmXlEbWYsRRQCTJYyjdU XGAB2ITuA/73vKekVk/RrIQ2ZEOsv8cEYVmRHKYh1I2TbCNSPUYQ/b9ivP5NAu5c z5N8Gl12woT40ucCxbMM =v3xS -----END PGP SIGNATURE----- --nextPart30763676.BKTITGRIWZ-- From nobody Thu Oct 30 05:14:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBE1A002A for ; Thu, 30 Oct 2014 05:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TAEz5MMFpKt for ; Thu, 30 Oct 2014 05:14:22 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C381A0022 for ; Thu, 30 Oct 2014 05:14:17 -0700 (PDT) Received: from [216.82.253.163] by server-10.bemta-7.messagelabs.com id BE/B1-02700-99B22545; Thu, 30 Oct 2014 12:14:17 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-5.tower-166.messagelabs.com!1414671256!8172392!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16517 invoked from network); 30 Oct 2014 12:14:16 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-5.tower-166.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Oct 2014 12:14:16 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id 038742DE47; Thu, 30 Oct 2014 12:14:28 +0000 (GMT) Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT02.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 06:14:16 -0600 From: "Osborne, Eric" To: Shahram Davari , Kireeti Kompella , "mpls@ietf.org" Thread-Topic: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt Thread-Index: AQHP86IYQxI0lEOeIkKthW4AGIOudJxIjiTA Date: Thu, 30 Oct 2014 12:14:15 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAD57A@USIDCWVEMBX08.corp.global.level3.com> References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.207] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TkTiOTeI77Nb02hklwe7bXUe4Hs Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:14:25 -0000 SSd2ZSBvbmx5IGp1c3Qgc2tpbW1lZCBLaXJlZXRpJ3MgZHJhZnQsIGJ1dCB0aGUgZGlmZmVyZW5j ZXMgYXJlIG9idmlvdXMgdG8gbWUuICBUaGUgdHdvIGRvY3MgeW91IGNpdGUgYXJlIFRQLXNwZWNp ZmljLiAgcmZjNjk3NCB0cmllcyB0byBzaG93IGhvdyBvbmUgY2FuIHVzZSBzdGFuZGFyZCBsaW5l YXIgcHJvdGVjdGlvbiB3aGlsc3Qgc2ltdWx0YW5lb3VzbHkgZ29pbmcgaW4gYSBjaXJjbGUgKHRo dXMsIEFwcGxpY2FiaWxpdHkpIGFuZCB0aGUgZHJhZnQgY2xhaW1zIHlvdSBuZWVkIHNwZWNpYWwg bm9uLXByb3RvY29sIHByb3RvY29scyB0byBkbyB0aGUgc2FtZSB0aGluZy4gIEtpcmVldGkncyBk b2Mgc2F5cyAiQm90aCBSU1ZQLVRFIGFuZCBMRFAsIHdpdGggYXBwcm9wcmlhdGUgZXh0ZW5zaW9u cywgY2FuIGJlIHVzZWQgdG8gIHNpZ25hbCByaW5nIExTUHMiOyBhbHRob3VnaCB0aGlzIGlzIHRo ZSBleHRlbnQgb2YgdGhlIG1lYXQgb2YgdGhlIGRvY3VtZW50LCBpdCdzIG9idmlvdXNseSBkaWZm ZXJlbnQgZnJvbSB0aGUgb3RoZXIgdHdvIHlvdSBjaXRlLg0KDQoNCg0KDQoNCmVyaWMNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFyaQ0KPiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMjksIDIwMTQgMTo1OSBQTQ0KPiBUbzogS2lyZWV0aSBLb21wZWxsYTsg bXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1rb21wZWxsYS1tcGxzLQ0KPiBybXItMDAudHh0DQo+IA0KPiBI aSBLaXJlZXRpLA0KPiANCj4gDQo+IA0KPiBJdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gYWRk IGEgc2VjdGlvbiB0byBkZXNjcmliZSB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlDQo+IGJldHdlZW4g eW91ciBkcmFmdCBhbmQgdGhlIGZvbGxvd2luZyBSRkMvZHJhZnRzLCBhbmQgd2h5IGl0IGlzIGJl dHRlci4NCj4gDQo+IA0KPiANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NzQN Cj4gDQo+IA0KPiANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbmctbXBs cy10cC1zaGFyZWQtcmluZy1wcm90ZWN0aW9uLTAzDQo+IA0KPiANCj4gDQo+IFRoYW5rcw0KPiAN Cj4gU2hhaHJhbQ0KPiANCj4gDQo+IA0KPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2lyZWV0aSBLb21wZWxsYQ0KPiBTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMjksIDIwMTQgMTA6NDEgQU0NCj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogW21wbHNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rb21w ZWxsYS1tcGxzLXJtci0NCj4gMDAudHh0DQo+IA0KPiANCj4gDQo+IEhpIEZvbGtzLA0KPiANCj4g DQo+IA0KPiBUaGlzIGlzIGEgZHJhZnQgb24gbWFraW5nIE1QTFMgbW9yZSBlZmZpY2llbnQgaW4g cmluZyBuZXR3b3Jrcy4gIEkgaGF2ZSBjb21lDQo+IGFyb3VuZCB0byB1bmRlcnN0YW5kaW5nIHRo YXQ6DQo+IA0KPiBhKSByaW5ncyBhcmUgYSBzcGVjaWFsIHRvcG9sb2d5ICh0aGVyZSB3YXMgYSB0 aW1lIHRoYXQgSSBkaWRuJ3QgYXBwcmVjaWF0ZSB0aGF0KTsNCj4gDQo+IGIpIE1QTFMgaXMgcHJl dHR5IGluZWZmaWNpZW50IGluIHJpbmdzICh0aGF0IGlzL3dhcyBxdWl0ZSBvYnZpb3VzKS4NCj4g DQo+IA0KPiANCj4gVGhpcyBkcmFmdCBhdHRlbXB0cyB0byBmaXggdGhhdCwgYm90aCBieSBtYWtp bmcgcHJvdGVjdGlvbiBtdWNoIG1vcmUNCj4gZWZmaWNpZW50LCBhbmQgYnkgbWFraW5nIGNvbmZp Z3VyYXRpb24gbXVjaCBlYXNpZXIuDQo+IA0KPiANCj4gDQo+IFlvdXIgY29tbWVudHMgYXJlIGhp Z2hseSB3ZWxjb21lIQ0KPiANCj4gDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBLaXJlZXRpLg0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gRnJv bTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4gPg0KPiBEYXRlOiBTdW4sIE9jdCAyNiwgMjAxNCBhdCA5OjE1IFBNDQo+IFN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta29tcGVsbGEtbXBscy1ybXItMDAu dHh0DQo+IFRvOiBLaXJlZXRpIEtvbXBlbGxhIDxraXJlZXRpLmtvbXBlbGxhQGdtYWlsLmNvbQ0K PiA8bWFpbHRvOmtpcmVldGkua29tcGVsbGFAZ21haWwuY29tPiA+DQo+IA0KPiANCj4gDQo+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rb21wZWxsYS1tcGxzLXJtci0wMC50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5DQo+IHN1Ym1pdHRlZCBieSBLaXJlZXRpIEtvbXBlbGxhIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1r b21wZWxsYS1tcGxzLXJtcg0KPiBSZXZpc2lvbjogICAgICAgMDANCj4gVGl0bGU6ICAgICAgICAg IFJlc2lsaWVudCBNUExTIFJpbmdzDQo+IERvY3VtZW50IGRhdGU6ICAyMDE0LTEwLTI2DQo+IEdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICAgIDcN Cj4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWtvbXBlbGxhLW1wbHMtcm1yLQ0KPiAwMC50eHQgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLQ0KPiAwMC50eHQ+DQo+IFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rb21wZWxs YS1tcGxzLXJtci8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhlIE1QTFMgY29udHJvbCBhbmQgZGF0 YSBwbGFuZXMNCj4gICAgb24gcmluZyB0b3BvbG9naWVzLiAgSXQgZGVzY3JpYmVzIHRoZSBzcGVj aWFsIG5hdHVyZSBvZiByaW5ncywgYW5kDQo+ICAgIHByb2NlZWRzIHRvIHNob3cgaG93IE1QTFMg Y2FuIGJlIGVmZmVjdGl2ZWx5IHVzZWQgaW4gc3VjaCB0b3BvbG9naWVzLg0KPiAgICBJdCBkZXNj cmliZXMgaG93IE1QTFMgcmluZ3MgYXJlIGNvbmZpZ3VyZWQsIGF1dG8tZGlzY292ZXJlZCBhbmQN Cj4gICAgc2lnbmFsZWQsIGFzIHdlbGwgYXMgaG93IHRoZSBkYXRhIHBsYW5lIHdvcmtzLiAgQ29t cGFuaW9uIGRvY3VtZW50cw0KPiAgICBkZXNjcmliZSB0aGUgZGV0YWlscyBvZiBkaXNjb3Zlcnkg YW5kIHNpZ25hbGluZyBmb3Igc3BlY2lmaWMNCj4gICAgcHJvdG9jb2xzLg0KPiANCj4gDQo+IA0K PiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZw0KPiA8aHR0cDovL3Rv b2xzLmlldGYub3JnPiAuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gLS0NCj4gS2lyZWV0aQ0KDQo= From nobody Thu Oct 30 07:17:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE211AD389 for ; Thu, 30 Oct 2014 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ycsfkEQxdp for ; Thu, 30 Oct 2014 07:17:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E051AD0BB for ; Thu, 30 Oct 2014 07:17:21 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so4318795wgh.38 for ; Thu, 30 Oct 2014 07:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u8pG3bfft5NERgELoN9lmU1UwLC27GbD31Nrd0tbA3k=; b=BZYYziNh7x9bfJkennv6srDDsFH6povMwAkmwJkv0wkPObMhmfrKGD9kodnqKOxNq4 b8WUjWjopUJbhPUpohTelJsNXkNOGDxExLXSCNk2DJPFIWZZZOTKZhrVVWEN/8bW4HfY Sx2bM+CtVFPViLnNq2AHXzl388XwEIr+8SPCVZktvvyTK33Yqp06aQGT3Z4mhCRfL7UX Y2GwUyXNhkgdmNKJtHRazPd6oIZsIbMlqUztGqaxHTtMugvkucvxScLB3IMKzel+pwdA dTltvi8BUcFhI4ScrqICZvykorMa6fz7evBfo/+ebs7HQhrxAJ9tJunGFzDoRfg+fuNJ nDxw== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr44725743wic.79.1414678640135; Thu, 30 Oct 2014 07:17:20 -0700 (PDT) Received: by 10.194.83.164 with HTTP; Thu, 30 Oct 2014 07:17:20 -0700 (PDT) In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDFAD57A@USIDCWVEMBX08.corp.global.level3.com> References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDFAD57A@USIDCWVEMBX08.corp.global.level3.com> Date: Thu, 30 Oct 2014 16:17:20 +0200 Message-ID: From: Yaacov Weingarten To: "Osborne, Eric" Content-Type: multipart/alternative; boundary=001a11c37d44d117cb0506a4898a Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SOWNcBzOMlgeafCyS60-haAaH50 Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:17:28 -0000 --001a11c37d44d117cb0506a4898a Content-Type: text/plain; charset=UTF-8 Hi, I tend to support Shahram's request regarding the issues of protection - not sure what Kireeti is proposing in this draft that is different from the proposals in the RFC or in the extreme case the shared ring protection draft. I think that there may be some justification in extending this new draft to cover the questions of configuring the ring LSP, as this is a topic that is not covered by either of the two documents that Shahram cites, and was assumed to pre-exist by both of those documents. Eric - there is one comment that you made that I cannot agree with - that the RFC is TP-specific! I am of the belief that there is nothing intrinsically TP specific in either the Linear Protection or the Ring Protection RFCs except for the use of the Generic Associated Channel - which to the best of my understanding is Generic to any MPLS application. BR, yaacov On Thu, Oct 30, 2014 at 2:14 PM, Osborne, Eric wrote: > I've only just skimmed Kireeti's draft, but the differences are obvious to > me. The two docs you cite are TP-specific. rfc6974 tries to show how one > can use standard linear protection whilst simultaneously going in a circle > (thus, Applicability) and the draft claims you need special non-protocol > protocols to do the same thing. Kireeti's doc says "Both RSVP-TE and LDP, > with appropriate extensions, can be used to signal ring LSPs"; although > this is the extent of the meat of the document, it's obviously different > from the other two you cite. > > > > > > eric > > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > > Sent: Wednesday, October 29, 2014 1:59 PM > > To: Kireeti Kompella; mpls@ietf.org > > Subject: Re: [mpls] Fwd: New Version Notification for > draft-kompella-mpls- > > rmr-00.txt > > > > Hi Kireeti, > > > > > > > > It would be good if you can add a section to describe what is the > difference > > between your draft and the following RFC/drafts, and why it is better. > > > > > > > > https://tools.ietf.org/html/rfc6974 > > > > > > > > http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-ring-protection-03 > > > > > > > > Thanks > > > > Shahram > > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella > > Sent: Wednesday, October 29, 2014 10:41 AM > > To: mpls@ietf.org > > Subject: [mpls] Fwd: New Version Notification for > draft-kompella-mpls-rmr- > > 00.txt > > > > > > > > Hi Folks, > > > > > > > > This is a draft on making MPLS more efficient in ring networks. I have > come > > around to understanding that: > > > > a) rings are a special topology (there was a time that I didn't > appreciate that); > > > > b) MPLS is pretty inefficient in rings (that is/was quite obvious). > > > > > > > > This draft attempts to fix that, both by making protection much more > > efficient, and by making configuration much easier. > > > > > > > > Your comments are highly welcome! > > > > > > > > Cheers, > > > > Kireeti. > > > > > > > > ---------- Forwarded message ---------- > > From: > > > Date: Sun, Oct 26, 2014 at 9:15 PM > > Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt > > To: Kireeti Kompella > > > > > > > > > > A new version of I-D, draft-kompella-mpls-rmr-00.txt has been > successfully > > submitted by Kireeti Kompella and posted to the IETF repository. > > > > Name: draft-kompella-mpls-rmr > > Revision: 00 > > Title: Resilient MPLS Rings > > Document date: 2014-10-26 > > Group: Individual Submission > > Pages: 7 > > URL: > http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr- > > 00.txt > 00.txt> > > Status: > https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/ > > Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-rmr-00 > > > > > > Abstract: > > This document describes the use of the MPLS control and data planes > > on ring topologies. It describes the special nature of rings, and > > proceeds to show how MPLS can be effectively used in such topologies. > > It describes how MPLS rings are configured, auto-discovered and > > signaled, as well as how the data plane works. Companion documents > > describe the details of discovery and signaling for specific > > protocols. > > > > > > > > > > > > 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 > > . > > > > The IETF Secretariat > > > > > > > > > > > > > > > > -- > > Kireeti > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity* --001a11c37d44d117cb0506a4898a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I tend to support Shahram's req= uest regarding the issues of protection - not sure what Kireeti is proposin= g in this draft that is different from the proposals in the RFC or in the e= xtreme case the shared ring protection draft. I think that there may be som= e justification in extending this new draft to cover the questions of confi= guring the ring LSP, as this is a topic that is not covered by either of th= e two documents that Shahram cites, and was assumed to pre-exist by both of= those documents.

Eric - there is one comment that= you made that I cannot agree with - that the RFC is TP-specific! I am of t= he belief that there is nothing intrinsically TP specific in either the Lin= ear Protection or the Ring Protection RFCs except for the use of the Generi= c Associated Channel - which to the best of my understanding is Generic to = any MPLS application.

BR,
yaacov

On Thu, Oct 3= 0, 2014 at 2:14 PM, Osborne, Eric <eric.osborne@level3.com> wrote:
I've only just skimmed K= ireeti's draft, but the differences are obvious to me.=C2=A0 The two do= cs you cite are TP-specific.=C2=A0 rfc6974 tries to show how one can use st= andard linear protection whilst simultaneously going in a circle (thus, App= licability) and the draft claims you need special non-protocol protocols to= do the same thing.=C2=A0 Kireeti's doc says "Both RSVP-TE and LDP= , with appropriate extensions, can be used to=C2=A0 signal ring LSPs";= although this is the extent of the meat of the document, it's obviousl= y different from the other two you cite.





eric


> -----Original Message-----
> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Shahram Davari
> Sent: Wednesday, October 29, 2014 1:59 PM
> To: Kireeti Kompella; mpls@ietf.org
> Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-m= pls-
> rmr-00.txt
>
> Hi Kireeti,
>
>
>
> It would be good if you can add a section to describe what is the diff= erence
> between your draft and the following RFC/drafts, and why it is better.=
>
>
>
> http= s://tools.ietf.org/html/rfc6974
>
>
>
> http://tools.ietf.org/html/draft-cheng-mpl= s-tp-shared-ring-protection-03
>
>
>
> Thanks
>
> Shahram
>
>
>
> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Kireeti Kompella
> Sent: Wednesday, October 29, 2014 10:41 AM
> To: mpls@ietf.org
> Subject: [mpls] Fwd: New Version Notification for draft-kompella-mpls-= rmr-
> 00.txt
>
>
>
> Hi Folks,
>
>
>
> This is a draft on making MPLS more efficient in ring networks.=C2=A0 = I have come
> around to understanding that:
>
> a) rings are a special topology (there was a time that I didn't ap= preciate that);
>
> b) MPLS is pretty inefficient in rings (that is/was quite obvious). >
>
>
> This draft attempts to fix that, both by making protection much more > efficient, and by making configuration much easier.
>
>
>
> Your comments are highly welcome!
>
>
>
> Cheers,
>
> Kireeti.
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> >
> Date: Sun, Oct 26, 2014 at 9:15 PM
> Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt > To: Kireeti Kompella <kireeti.kompella@gmail.com
> <mailto:kireeti.kompella@gmail.com> >
>
>
>
> A new version of I-D, draft-kompella-mpls-rmr-00.txt has been successf= ully
> submitted by Kireeti Kompella and posted to the IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kompella-mpls-rmr<= br> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resilient MPLS Rings
> Document date:=C2=A0 2014-10-26
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://w= ww.ietf.org/internet-drafts/draft-kompella-mpls-rmr-
> 00.txt <http://www.ietf.org/internet-drafts/= draft-kompella-mpls-rmr-
> 00.txt>
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/htm= l/draft-kompella-mpls-rmr-00
>
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the use of the MPLS control and d= ata planes
>=C2=A0 =C2=A0 on ring topologies.=C2=A0 It describes the special nature= of rings, and
>=C2=A0 =C2=A0 proceeds to show how MPLS can be effectively used in such= topologies.
>=C2=A0 =C2=A0 It describes how MPLS rings are configured, auto-discover= ed and
>=C2=A0 =C2=A0 signaled, as well as how the data plane works.=C2=A0 Comp= anion documents
>=C2=A0 =C2=A0 describe the details of discovery and signaling for speci= fic
>=C2=A0 =C2=A0 protocols.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org
> <http://= tools.ietf.org> .
>
> The IETF Secretariat
>
>
>
>
>
>
>
> --
> Kireeti

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Still looking for= new opportunity
--001a11c37d44d117cb0506a4898a-- From nobody Thu Oct 30 08:30:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F12B1AD498 for ; Thu, 30 Oct 2014 08:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYhyPnn2gqlI for ; Thu, 30 Oct 2014 08:30:46 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (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 C35D71AD487 for ; Thu, 30 Oct 2014 08:30:46 -0700 (PDT) Received: from [65.213.193.38] (port=55570 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XjrgS-0002oT-79 for mpls@ietf.org; Thu, 30 Oct 2014 15:30:44 +0000 From: "Shamjhana" To: Date: Thu, 30 Oct 2014 11:30:49 -0400 Message-ID: <013c01cff456$7bf4a870$73ddf950$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01CFF434.F4E440F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/0TSM3ttRgjNVQQiGKCTgQiR3Zug== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/f06wY2fzxk3gcQc9WHm48TSWZnA Subject: [mpls] Cloud & Data Center, WAN and Virtualization/NFV - SDN/MPLS 2014 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:30:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013D_01CFF434.F4E440F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SDN/MPLS 2014 Conference in Washington DC starts this Sunday, November 2. There are a limited number of seats still available. Come and learn about the future of networking. Register now at: http://www.isocore.com/sdn-mpls/attendees.php The SDN/MPLS 2014 Conference program is available at: http://www.isocore.com/sdn-mpls/ Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm The hotel rooms are sold out! Thank you! ------=_NextPart_000_013D_01CFF434.F4E440F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The SDN/MPLS 2014 = Conference in Washington DC starts this Sunday, November 2. There = are a limited number of seats still available.

Come and =  learn about the future of networking.  Register now = at: http://www.isocor= e.com/sdn-mpls/attendees.php

 

The SDN/MPLS 2014 = Conference program is available at: http://www.isocore.com/sdn-mpls/Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm 
Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions= .htm

 <= /span>

The hotel rooms = are sold out!

 

Thank = you!

 =

------=_NextPart_000_013D_01CFF434.F4E440F0-- From nobody Thu Oct 30 16:22:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E4C1A88E0 for ; Thu, 30 Oct 2014 16:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZr9ILt5QAMW for ; Thu, 30 Oct 2014 16:21:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291941A8977 for ; Thu, 30 Oct 2014 16:21:21 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-bd-54526d747d81 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B3.C8.25146.47D62545; Thu, 30 Oct 2014 17:55:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 19:21:19 -0400 From: Gregory Mirsky To: Kireeti Kompella , "mpls@ietf.org" Thread-Topic: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt Thread-Index: AQHP85+A1477cza24ki/Gu2DDUu9xpxJReag Date: Thu, 30 Oct 2014 23:21:18 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B877A1F@eusaamb103.ericsson.se> References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B877A1Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPlG5JblCIwd2bZhZr9k9itLi1dCWr A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXR/3c+W8Gzmor1i+azNDDuqOxi5OSQEDCR mP5qEiOELSZx4d56ti5GLg4hgSOMEgeurGKCcJYzSjy6/JMJpIpNwEjixcYedhBbRCBEYs6B XWwgtrBAmMSX+b/ZIOLhEq+u/WCFsI0kNs98yAxiswioSrzb1c8CYvMK+Epc2jAFakE7o8Se kxPBEpwCgRL7fjWCLWAEOun7qTVgi5kFxCVuPZnPBHGqgMSSPeeZIWxRiZeP/7FC2IoS+/qn s0PU50ssOzaFFWKZoMTJmU9YJjCKzEIyahaSsllIymYxcgDFNSXW79KHKFGUmNL9kB3C1pBo nTOXHVl8ASP7KkaO0uLUstx0I8NNjMD4OSbB5riDccEny0OMAhyMSjy8BYWBIUKsiWXFlbmH GKU5WJTEeTWr5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOzedd2Hc86bdW9WZzozSBh4 zEjYUX/xk4Mw44/9M/LZf0//XqXs6TZti0b4Lvv/Pel7r90JDLu60rqrz2B75oQovzZ11+v/ ZbU5NTjiL3TFpT9sXc/9bnau/EPL2QVm6Zt3yu9wSG03aD31zKXc+FhE9IPQkxVdC21XZVbU Ka9vWprTZRUmocRSnJFoqMVcVJwIAAt+fvCAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qwi6RWq8lhTKT2Wd01WMjQBAzbc Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:21:57 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B877A1Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2lyZWV0aSwNCkkgdGhpbmsgdGhhdCBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IHByb3Rl Y3Rpb24gbWV0aG9kIGNyZWF0ZXMgc29tZSB1bnBsZWFzYW50IHNjZW5hcmlvIGlmIGZhaWx1cmUg aXMgb2YgYSBub2RlLCBub3QgYSBsaW5rLiBJZiBJIHVzZSB0aGUgc2NlbmFyaW8gcHJlc2VudGVk IGluIFNlY3Rpb24gMy42IGJ1dCBhc3N1bWUgdGhhdCB0aGUgZmFpbHVyZSBpcyBub3Qgb2YgdGhl IGxpbmsgYmV0d2VlbiBSX2ogYW5kIFJfaisxIGJ1dCBvZiB0aGUgbm9kZSBSaisxLiBUaHVzLCBh cyBSX2ogc3dpdGNoZXMgdG8gVVMgZGlyZWN0aW9uLCB0aGUgUl9qKzIgd2lsbCBzd2l0Y2ggdG8g RFMuIEFuZCB1bnRpbCBub3RpZmljYXRpb25zIGZyb20gUl9qIGFuZCBSX2orMiByZWFjaCBSX2or MiBhbmQgUl9qIHJlc3BlY3RpdmVseSB3ZSBoYXZlIHJvdXRpbmcgbG9vcCBvbiBSTF9qKzEgTFNQ LiBJZiBteSBhc3N1bXB0aW9ucyBhcmUgY29ycmVjdCwgdGhlbiBub3RpZmljYXRpb24gbWVjaGFu aXNtIE1VU1QgYmUgcmVsaWFibGUgb3IgYmUgYmFja2VkIHVwIGJ5IElHUCBzaWduYWxpbmcuIElu IGFueSBjYXNlLCB0aGUgbG9vcCBtYXkgcGVyc2lzdCBmb3IgcXVpdGUgYSB3aGlsZSBhbmQgYWZm ZWN0IGFsbCBzZXJ2aWNlcy4NCg0KQ29tbWVudHMsIHF1ZXN0aW9ucyBhcmUgYWx3YXlzIHdlbGNv bWUgYW5kIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IG1wbHMgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLaXJlZXRpIEtvbXBlbGxhDQpT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjksIDIwMTQgMTA6NDEgQU0NClRvOiBtcGxzQGlldGYu b3JnDQpTdWJqZWN0OiBbbXBsc10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dA0KDQpIaSBGb2xrcywNCg0KVGhpcyBpcyBhIGRy YWZ0IG9uIG1ha2luZyBNUExTIG1vcmUgZWZmaWNpZW50IGluIHJpbmcgbmV0d29ya3MuICBJIGhh dmUgY29tZSBhcm91bmQgdG8gdW5kZXJzdGFuZGluZyB0aGF0Og0KYSkgcmluZ3MgYXJlIGEgc3Bl Y2lhbCB0b3BvbG9neSAodGhlcmUgd2FzIGEgdGltZSB0aGF0IEkgZGlkbid0IGFwcHJlY2lhdGUg dGhhdCk7DQpiKSBNUExTIGlzIHByZXR0eSBpbmVmZmljaWVudCBpbiByaW5ncyAodGhhdCBpcy93 YXMgcXVpdGUgb2J2aW91cykuDQoNClRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gZml4IHRoYXQsIGJv dGggYnkgbWFraW5nIHByb3RlY3Rpb24gbXVjaCBtb3JlIGVmZmljaWVudCwgYW5kIGJ5IG1ha2lu ZyBjb25maWd1cmF0aW9uIG11Y2ggZWFzaWVyLg0KDQpZb3VyIGNvbW1lbnRzIGFyZSBoaWdobHkg d2VsY29tZSENCg0KQ2hlZXJzLA0KS2lyZWV0aS4NCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogU3VuLCBPY3QgMjYsIDIwMTQgYXQgOTox NSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rb21wZWxs YS1tcGxzLXJtci0wMC50eHQNClRvOiBLaXJlZXRpIEtvbXBlbGxhIDxraXJlZXRpLmtvbXBlbGxh QGdtYWlsLmNvbTxtYWlsdG86a2lyZWV0aS5rb21wZWxsYUBnbWFpbC5jb20+Pg0KDQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLaXJlZXRpIEtvbXBlbGxhIGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1rb21wZWxs YS1tcGxzLXJtcg0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgUmVzaWxpZW50 IE1QTFMgUmluZ3MNCkRvY3VtZW50IGRhdGU6ICAyMDE0LTEwLTI2DQpHcm91cDogICAgICAgICAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvbXBlbGxhLW1wbHMt cm1yLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBNUExTIGNvbnRyb2wg YW5kIGRhdGEgcGxhbmVzDQogICBvbiByaW5nIHRvcG9sb2dpZXMuICBJdCBkZXNjcmliZXMgdGhl IHNwZWNpYWwgbmF0dXJlIG9mIHJpbmdzLCBhbmQNCiAgIHByb2NlZWRzIHRvIHNob3cgaG93IE1Q TFMgY2FuIGJlIGVmZmVjdGl2ZWx5IHVzZWQgaW4gc3VjaCB0b3BvbG9naWVzLg0KICAgSXQgZGVz Y3JpYmVzIGhvdyBNUExTIHJpbmdzIGFyZSBjb25maWd1cmVkLCBhdXRvLWRpc2NvdmVyZWQgYW5k DQogICBzaWduYWxlZCwgYXMgd2VsbCBhcyBob3cgdGhlIGRhdGEgcGxhbmUgd29ya3MuICBDb21w YW5pb24gZG9jdW1lbnRzDQogICBkZXNjcmliZSB0aGUgZGV0YWlscyBvZiBkaXNjb3ZlcnkgYW5k IHNpZ25hbGluZyBmb3Igc3BlY2lmaWMNCiAgIHByb3RvY29scy4NCg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KDQotLQ0KS2lyZWV0aQ0K --_000_7347100B5761DC41A166AC17F22DF1121B877A1Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBLaXJlZXRpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRo YXQgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBwcm90ZWN0aW9uIG1ldGhvZCBjcmVhdGVzIHNv bWUgdW5wbGVhc2FudCBzY2VuYXJpbyBpZiBmYWlsdXJlIGlzIG9mIGEgbm9kZSwgbm90IGEgbGlu ay4gSWYgSSB1c2UgdGhlIHNjZW5hcmlvIHByZXNlbnRlZA0KIGluIFNlY3Rpb24gMy42IGJ1dCBh c3N1bWUgdGhhdCB0aGUgZmFpbHVyZSBpcyBub3Qgb2YgdGhlIGxpbmsgYmV0d2VlbiBSX2ogYW5k IFJfaiYjNDM7MSBidXQgb2YgdGhlIG5vZGUgUmomIzQzOzEuIFRodXMsIGFzIFJfaiBzd2l0Y2hl cyB0byBVUyBkaXJlY3Rpb24sIHRoZSBSX2omIzQzOzIgd2lsbCBzd2l0Y2ggdG8gRFMuIEFuZCB1 bnRpbCBub3RpZmljYXRpb25zIGZyb20gUl9qIGFuZCBSX2omIzQzOzIgcmVhY2ggUl9qJiM0Mzsy IGFuZCBSX2ogcmVzcGVjdGl2ZWx5IHdlIGhhdmUNCiByb3V0aW5nIGxvb3Agb24gUkxfaiYjNDM7 MSBMU1AuIElmIG15IGFzc3VtcHRpb25zIGFyZSBjb3JyZWN0LCB0aGVuIG5vdGlmaWNhdGlvbiBt ZWNoYW5pc20gTVVTVCBiZSByZWxpYWJsZSBvciBiZSBiYWNrZWQgdXAgYnkgSUdQIHNpZ25hbGlu Zy4gSW4gYW55IGNhc2UsIHRoZSBsb29wIG1heSBwZXJzaXN0IGZvciBxdWl0ZSBhIHdoaWxlIGFu ZCBhZmZlY3QgYWxsIHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMsIHF1ZXN0aW9ucyBhcmUg YWx3YXlzIHdlbGNvbWUgYW5kIGdyZWF0bHkgYXBwcmVjaWF0ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPktpcmVldGkgS29tcGVsbGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBPY3RvYmVyIDI5LCAyMDE0IDEwOjQxIEFNPGJyPg0KPGI+VG86PC9iPiBtcGxzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttcGxzXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQta29tcGVsbGEtbXBscy1ybXItMDAudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRm9sa3MsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgZHJhZnQgb24gbWFraW5nIE1QTFMgbW9yZSBl ZmZpY2llbnQgaW4gcmluZyBuZXR3b3Jrcy4mbmJzcDsgSSBoYXZlIGNvbWUgYXJvdW5kIHRvIHVu ZGVyc3RhbmRpbmcgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmEpIHJpbmdzIGFyZSBhIHNwZWNpYWwgdG9wb2xvZ3kgKHRoZXJlIHdhcyBh IHRpbWUgdGhhdCBJIGRpZG4ndCBhcHByZWNpYXRlIHRoYXQpOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgTVBMUyBpcyBwcmV0dHkgaW5lZmZp Y2llbnQgaW4gcmluZ3MgKHRoYXQgaXMvd2FzIHF1aXRlIG9idmlvdXMpLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGF0dGVt cHRzIHRvIGZpeCB0aGF0LCBib3RoIGJ5IG1ha2luZyBwcm90ZWN0aW9uIG11Y2ggbW9yZSBlZmZp Y2llbnQsIGFuZCBieSBtYWtpbmcgY29uZmlndXJhdGlvbiBtdWNoIGVhc2llci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91ciBjb21tZW50 cyBhcmUgaGlnaGx5IHdlbGNvbWUhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPktpcmVldGkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tLS0tLS0t LS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCkRhdGU6IFN1biwgT2N0IDI2LCAyMDE0IGF0IDk6MTUgUE08YnI+DQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtvbXBlbGxhLW1wbHMtcm1y LTAwLnR4dDxicj4NClRvOiBLaXJlZXRpIEtvbXBlbGxhICZsdDs8YSBocmVmPSJtYWlsdG86a2ly ZWV0aS5rb21wZWxsYUBnbWFpbC5jb20iPmtpcmVldGkua29tcGVsbGFAZ21haWwuY29tPC9hPiZn dDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta29t cGVsbGEtbXBscy1ybXItMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBLaXJlZXRpIEtvbXBlbGxhIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0 b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtkcmFmdC1rb21wZWxsYS1tcGxzLXJtcjxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBSZXNpbGllbnQgTVBMUyBSaW5nczxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTQt MTAtMjY8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2 aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgNzxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rb21w ZWxsYS1tcGxzLXJtci0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLTAwLnR4dDwvYT48YnI+ DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcm1yLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtvbXBl bGxhLW1wbHMtcm1yLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rb21wZWxsYS1tcGxz LXJtci0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWtvbXBlbGxhLW1wbHMtcm1yLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBNUExT IGNvbnRyb2wgYW5kIGRhdGEgcGxhbmVzPGJyPg0KJm5ic3A7ICZuYnNwO29uIHJpbmcgdG9wb2xv Z2llcy4mbmJzcDsgSXQgZGVzY3JpYmVzIHRoZSBzcGVjaWFsIG5hdHVyZSBvZiByaW5ncywgYW5k PGJyPg0KJm5ic3A7ICZuYnNwO3Byb2NlZWRzIHRvIHNob3cgaG93IE1QTFMgY2FuIGJlIGVmZmVj dGl2ZWx5IHVzZWQgaW4gc3VjaCB0b3BvbG9naWVzLjxicj4NCiZuYnNwOyAmbmJzcDtJdCBkZXNj cmliZXMgaG93IE1QTFMgcmluZ3MgYXJlIGNvbmZpZ3VyZWQsIGF1dG8tZGlzY292ZXJlZCBhbmQ8 YnI+DQombmJzcDsgJm5ic3A7c2lnbmFsZWQsIGFzIHdlbGwgYXMgaG93IHRoZSBkYXRhIHBsYW5l IHdvcmtzLiZuYnNwOyBDb21wYW5pb24gZG9jdW1lbnRzPGJyPg0KJm5ic3A7ICZuYnNwO2Rlc2Ny aWJlIHRoZSBkZXRhaWxzIG9mIGRpc2NvdmVyeSBhbmQgc2lnbmFsaW5nIGZvciBzcGVjaWZpYzxi cj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbHMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElF VEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIDxicj4NCktpcmVldGkgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B877A1Feusaamb103erics_-- From nobody Thu Oct 30 17:17:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B531A8A3C for ; Thu, 30 Oct 2014 17:17:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD-RWsY7e2j2 for ; Thu, 30 Oct 2014 17:17:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C457A1A8A16 for ; Thu, 30 Oct 2014 17:17:26 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.1.6.9; Fri, 31 Oct 2014 00:17:24 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.01.0006.000; Fri, 31 Oct 2014 00:17:24 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: New MPLS WG Document, draft-decraene-mpls-lsp-ping-registry Thread-Index: AQHP9KALCJJh2mOzoUy22t2pNtlQng== Date: Fri, 31 Oct 2014 00:17:24 +0000 Message-ID: <9c6efbedff0141018966bb0ebfe68ef5@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB635; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(15202345003)(15975445006)(31966008)(74316001)(4396001)(92566001)(2656002)(54356999)(80022003)(50986999)(575784001)(87936001)(86362001)(99396003)(20776003)(85852003)(64706001)(19580395003)(120916001)(66066001)(101416001)(99286002)(108616004)(95666004)(97736003)(230783001)(105586002)(106116001)(40100003)(122556002)(107046002)(110136001)(46102003)(76482002)(229853001)(33646002)(2351001)(21056001)(106356001)(76576001)(2501002)(85306004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9c6efbedff0141018966bb0ebfe68ef5CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2m9N5cwt39C1N9Z_YTlxqaJc1m8 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] New MPLS WG Document, draft-decraene-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:17:34 -0000 --_000_9c6efbedff0141018966bb0ebfe68ef5CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working group; After WG chair review by George and myself, we have decided to accept draft= -decraene-mpls-lsp-ping-registry as an MPLS WG document. This is a very sim= ple draft which creates registries which are needed for other documents, bu= t otherwise makes no technical change. As soon as the internet draft postin= g widow reopens would the authors please repost this draft as: draft-ietf-mpls-lsp-ping-registry-00 with no changes other than the draft name, date, and only if necessary upda= ted references. Because this is a very simple draft, and because there are other drafts dep= endent upon this document, we intend to progress this document quickly and = would like to encourage WG participants to review it and comment on the WG = list. Thanks, Ross (as MPLS WG chair) PS: While it seems unlikely for there to be IPR on a draft which only creat= es registries, nonetheless we intend to do the normal IPR poll prior to WG = last call. As always, WG participants are required to be aware of IETF IPR = policy, and to disclose any IPR that they are aware of that applies to IETF= contributions (including but not limited to Internet Drafts) as soon as th= ey know of such IPR, without waiting for an IPR poll. --_000_9c6efbedff0141018966bb0ebfe68ef5CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working group;
 
After WG chair review by George and myself, we have decided to accept = draft-decraene-mpls-lsp-ping-registry as an MPLS WG document. This is a ver= y simple draft which creates registries which are needed for other document= s, but otherwise makes no technical change. As soon as the internet draft posting widow reopens would the autho= rs please repost this draft as:
 
    draft-ietf-mpls-lsp-ping-registry-00
 
with no changes other than the draft name, date, and only if necessary= updated references.
 
Because this is a very simple draft, and because there are other draft= s dependent upon this document, we intend to progress this document quickly= and would like to encourage WG participants to review it and comment on th= e WG list.
 
Thanks, Ross
(as MPLS WG chair)
 
PS: While it seems unlikely for there to be IPR on a draft which only = creates registries, nonetheless we intend to do the normal IPR poll prior t= o WG last call. As always, WG participants are required to be aware of IETF= IPR policy, and to disclose any IPR that they are aware of that applies to IETF contributions (including bu= t not limited to Internet Drafts) as soon as they know of such IPR, without= waiting for an IPR poll.
 
 
 --_000_9c6efbedff0141018966bb0ebfe68ef5CO2PR05MB636namprd05pro_-- From nobody Thu Oct 30 19:28:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603B21A8A79; Thu, 30 Oct 2014 19:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Cd4wspY1lg; Thu, 30 Oct 2014 19:28:17 -0700 (PDT) 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 C2C321A8A87; Thu, 30 Oct 2014 19:28:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD00420; Fri, 31 Oct 2014 02:28:09 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 02:28:08 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 10:28:04 +0800 From: Xuxiaohu To: Ron Parker Thread-Topic: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Thread-Index: AQHP4WkpFJPaLJGjIUWt43ZhzuIOrJwl4oHQgCCrkLCAAKOpgIABXyHggAAq7QCAAOSVsA== Date: Fri, 31 Oct 2014 02:28:04 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C80A7@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644@NKGEML512-MBS.china.huawei.com> <3A2D6E6C-9AB6-4214-887A-42E7ADC2EB6B@affirmednetworks.com> In-Reply-To: <3A2D6E6C-9AB6-4214-887A-42E7ADC2EB6B@affirmednetworks.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6ENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jNBuQ_kXzx3n5AAcZFL7DTkEiM0 Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:28:24 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6ENKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Did you mean an SPL(Special Purpose Label) or an ESPL(Extended Special Purp= ose Label) by a well-known global label? If so, additional SPLs or ESPLs wo= uld need to be allocated for different MPLS payload, such as Ethernet frame= and IP packet. However I wonder whether it is the normal usage of the SPL = and ESPL space (i.e., used as a protocol type identifier)? Best regards, Xiaohu From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Friday, October 31, 2014 4:45 AM To: Xuxiaohu Cc: sfc@ietf.org; mpls@ietf.org; Subject: Re: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Xiaohu, Regarding carriage of metadata -- the MPLS would be only the transport part= . What about reserving a well known global label that means SCH/NSH header= follows. This well known label would always be at the BOS. Ron On Oct 30, 2014, at 3:15 AM, Xuxiaohu > wrote: Hi all, There are many drafts which mentioned the possibility of using the MPLS sou= rce routing (i.e., MPLS-SPRING) mechanism for service function chain purpos= e. However, we do need a detailed evaluation of such possibility so as to f= igure out whether any potential extensions to the MPLS architecture is requ= ired. For instance, 1) although an MPLS label stack could be used to indicate an SFP, however, = when an SFF-proxy receives such a MPLS packet, it must know the payload typ= e of the MPLS packet before sending the original packet to the correspondin= g legacy SF. How? In fact, even in the non-legacy SF case, should the SFF d= irectly forward the MPLS packet to the corresponding SF directly or strip t= he MPLS header before sending the packet to the corresponding SF? In the fo= rmer case, the corresponding SF should know the payload type of the MPLS pa= cket. In the latter case, the SFF should know the payload type. To identify= the payload type, one way is to allocate a separate local label for each p= ayload type (is this a scalable way?), another way is to allocate an SPL or= an ESPL for each payload type (is this the normal purpose of the SPL or ES= PL), a third way is to introduce a SPL or ESPL which is followed by a proto= col id header (is this a significant change to the MPLS architecture?). 2) assume an SFF needs to strip the "whole" MPLS header before sending the = packet to the corresponding SF, does it mean a big change to the current MP= LS forwarding plane? 3) when using an MPLS label stack to indicate an SFC rather than an SFP, ea= ch SF would have to be identified by a domain-wide label. One way is to res= erve the same label range for SF SID purpose by all the SFFs. Another way i= s to rely on the context label concept (i.e., each SF of an SFC would have = to be represented by two labels in the label stack, one is the context indi= cation label, the other is the label allocated from that context label spac= e for that SF ). However, it seems that the domain-wide label usage is stil= l a controversial topic in the IETF community. 4) how to convey metadata in an MPLS packet? This issue may be the same as = issue 1. Any comments? Best regards, Xiaohu From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, October 29, 2014 8:15 PM To: Xuxiaohu; Thomas Narten Subject: Re: SFC Honolulu meeting agenda Hi Xiaohu, Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our im= mediate deliverables. For this reason we are unable to allocate time for di= scussion of your draft in HI. Please feel free to continue to solicit disc= ussion on the SFC mailing list. Jim & Thomas From: Xuxiaohu > Date: Tuesday, October 28, 2014 at 11:30 PM To: Jim Guichard >, Thomas Na= rten > Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I found there are still available time on the SFC agenda. Hence I wonder wh= ether you could allocate a 15-min slot for presenting this draft. Best regards, Xiaohu From: Xuxiaohu Sent: Wednesday, October 08, 2014 4:50 PM To: 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I would like to request a 15-min slot for presenting the following draft (h= ttps://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since "Gener= ic SFC Encapsulation" is one of the WG charter deliverables and the charter= states that "...The working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found..."= I would like the WG to help evaluating whether the MPLS-SPRING-based SFC e= ncapsulation approach as described in the above draft could be considered a= s one of the candidates. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, October 06, 2014 9:27 PM To: sfc@ietf.org Subject: [sfc] SFC Honolulu meeting agenda Greetings WG: Our meeting at the upcoming Honolulu venue is fast approaching. As always,= the goal of the meeting will be to make the best use of limited face-to-fa= ce time. As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and t= hat generally means focussing on key charter deliverables and topics with i= mportant open issues to resolve. In the case of individual IDs, the goal is= n't necessarily to present what is in the draft but rather to help the WG d= ecide what to do with the ID. With that in mind, when making an agenda requ= est please consider what you think the WG should do with its content. For e= xample: * Does the document have useful content that should be moved into anoth= er WG document or progress on it's own merit * Does the content have a good basis for one of the WG documents per th= e charter (in order for that to happen the document needs to be the most ap= propriate out of the collection of related documents) * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6ENKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 = ;

Did you me= an an SPL(Special Purpose Label) or an ESPL(Extended Special Purpose Label)= by a well-known global label? If so, additional SPLs or ESPLs would need to be allocated for different MPLS payload, such as Ethernet fr= ame and IP packet. However I wonder whether it is the normal usage of the S= PL and ESPL space (i.e., used as a protocol type identifier)?

 = ;

Best regar= ds,

Xiaohu

 = ;

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Friday, October 31, 2014 4:45 AM
To: Xuxiaohu
Cc: sfc@ietf.org; mpls@ietf.org; <spring@ietf.org>
Subject: Re: [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

 

Xiaohu,

 

Regarding carriage of metadata = -- the MPLS would be only the transport part.  What about reserving a = well known global label that means SCH/NSH header follows.  This well = known label would always be at the BOS.  

 

   Ron

 

=
On Oct 30, 2014, at 3:15 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi all,

 

There are many drafts which = mentioned the possibility of using the MPLS source routing (i.e., MPLS-SPRI= NG) mechanism for service function chain purpose. However, we do need a det= ailed evaluation of such possibility so as to figure out whether any potential extensions to the MPLS architect= ure is required. For instance,

 

1) although an MPLS label st= ack could be used to indicate an SFP, however, when an SFF-proxy receives s= uch a MPLS packet, it must know the payload type of the MPLS packet before = sending the original packet to the corresponding legacy SF. How? In fact, even in the non-legacy SF case, should the SFF di= rectly forward the MPLS packet to the corresponding SF directly or strip th= e MPLS header before sending the packet to the corresponding SF? In the for= mer case, the corresponding SF should know the payload type of the MPLS packet. In the latter case, the SFF shou= ld know the payload type. To identify the payload type, one way is to alloc= ate a separate local label for each payload type (is this a scalable way?),= another way is to allocate an SPL or an ESPL for each payload type (is this the normal purpose of the SPL or= ESPL), a third way is to introduce a SPL or ESPL which is followed by a pr= otocol id header (is this a significant change to the MPLS architecture?).<= o:p>

 

2) assume an SFF needs to st= rip the “<= /span>whole” MPLS hea= der before sending the packet to the corresponding SF, does it mean a big c= hange to the current MPLS forwarding plane?

 

3) when using an MPLS label = stack to indicate an SFC rather than an SFP, each SF would have to be ident= ified by a domain-wide label. One way is to reserve the same label range fo= r SF SID purpose by all the SFFs. Another way is to rely on the context label concept (i.e., each SF of an SFC would= have to be represented by two labels in the label stack, one is the contex= t indication label, the other is the label allocated from that context labe= l space for that SF ). However, it seems that the domain-wide label usage is still a controversial topic i= n the IETF community.

 

4) how to convey metadata in= an MPLS packet? This issue may be the same as issue 1.

 

Any comments?

 

Best regards,

Xiaohu

 

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda=

 

Hi Xiaohu,

 

Our agenda i= s not yet finalized but we will only be allowing slots for drafts that have= had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to allocate time for= discussion of your draft in HI.  Please feel free to continue to soli= cit discussion on the SFC mailing list.

 

Jim & Th= omas

 

From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda=

 

Hi co-chai= rs,

 

I found th= ere are still available time on the SFC agenda. Hence I wonder whether you = could allocate a 15-min slot for presenting this draft.

 

Best regar= ds,

Xiaohu

 

From: Xuxiaohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc@i= etf.org
Subject: RE: SFC Honolulu meeting agenda=

 

Hi co-chai= rs,

 

I would li= ke to request a 15-min slot for presenting the following draft (https://tools.ietf.org/html/draft-x= u-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter del= iverables and the charter states that “…The working group will = consider using an existing encapsulation (with extensions as appropriate) i= f a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approac= h as described in the above draft could be considered as one of the candida= tes.

 

Best regar= ds,

Xiaohu

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc@ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

Greetings WG= :

 

Our meeting = at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-= to-face time.

 

As we build = the meeting agenda we welcome requests for agenda time. As always, the goal= of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables and topics = with important open issues to resolve. In the case of individual IDs, the g= oal isn’t necessarily to present what is in the draft but rather to h= elp the WG decide what to do with the ID. With that in mind, when making an agenda request please consider what = you think the WG should do with its content. For example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on it’s own merit
  • Does the content have a good basis for one of t= he WG documents per the charter (in order for that to happen the document n= eeds to be the most appropriate out of the collection of related documents)
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

_______________________________= ________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6ENKGEML512MBSchi_-- From nobody Thu Oct 30 23:23:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE15A1A8AC0; Thu, 30 Oct 2014 23:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpUiLvoAPewg; Thu, 30 Oct 2014 23:23:46 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5881A00E2; Thu, 30 Oct 2014 23:23:45 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-6f-5452d071d04c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 50.20.25146.170D2545; Fri, 31 Oct 2014 00:57:37 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 02:23:44 -0400 From: Gregory Mirsky To: Xuxiaohu , Ron Parker Thread-Topic: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Thread-Index: AQHP4WkpFJPaLJGjIUWt43ZhzuIOrJwl4oHQgCCrkLCAAKOpgIABXyHggAAq7QCAAOSVsIAAQdCw Date: Fri, 31 Oct 2014 06:23:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B877E62@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C80A7@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644@NKGEML512-MBS.china.huawei.com> <3A2D6E6C-9AB6-4214-887A-42E7ADC2EB6B@affirmednetworks.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6E@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B877E62eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPoG7hhaAQgzuHDS1uLV3JanHh6VRm iycPtrJbHL/wm9Fi6/lVjA6sHi+uPGP2aDnyltVjyZKfTAHMUVw2Kak5mWWpRfp2CVwZX/9v ZC/YvJepYtKGP8wNjO9mMHUxcnJICJhI/Ordzg5hi0lcuLeerYuRi0NI4AijxOWtk1ggnOWM Es8mXmMBqWITMJJ4sbEHrENEIEji75x9rF2MHBzMAtkSKyYbgdQLC/QxSvz70Qk2SUSgn1Hi 6eMmqIYoiQmPXrOB2CwCqhIrvv5kBmnmFfCVmDvBH2LZDyaJRw/+M4PUcAqESfxatBpsMSPQ ed9PrQE7m1lAXOLWk/lQLwhILNlznhnCFpV4+fgfK4StJPHx93x2iPp8iZfHvoPFeQUEJU7O fMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZ bmIERuExCTbHHYwLPlkeYhTgYFTi4f1wKChEiDWxrLgy9xCjNAeLkjivZvW8YCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MYTY85WfL3I+vmZN8xMb3aVXso6PMoZ82+sz//7HLl+/F9zci m/J5dk2amHcwdXnRaZu5qdO7WuOc5ZlCl0effZj6oGIlX/PUaecYNglrvpmqtezz11rv//p1 xct7FuyTenLjLrtADMfbx37xDSa3MizLPZjKQv6FWs94si5D68uLywdV+fc/UGIpzkg01GIu Kk4EAE2vawmjAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-BnXEVRSKnRBSiMCOYJlV5u3Nrs Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 06:23:51 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B877E62eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, Ron, et. al, what if metadata carried over SF ACH type? Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Thursday, October 30, 2014 7:28 PM To: Ron Parker Cc: mpls@ietf.org; ; sfc@ietf.org Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Ron, Did you mean an SPL(Special Purpose Label) or an ESPL(Extended Special Purp= ose Label) by a well-known global label? If so, additional SPLs or ESPLs wo= uld need to be allocated for different MPLS payload, such as Ethernet frame= and IP packet. However I wonder whether it is the normal usage of the SPL = and ESPL space (i.e., used as a protocol type identifier)? Best regards, Xiaohu From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Friday, October 31, 2014 4:45 AM To: Xuxiaohu Cc: sfc@ietf.org; mpls@ietf.org;= > Subject: Re: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Xiaohu, Regarding carriage of metadata -- the MPLS would be only the transport part= . What about reserving a well known global label that means SCH/NSH header= follows. This well known label would always be at the BOS. Ron On Oct 30, 2014, at 3:15 AM, Xuxiaohu > wrote: Hi all, There are many drafts which mentioned the possibility of using the MPLS sou= rce routing (i.e., MPLS-SPRING) mechanism for service function chain purpos= e. However, we do need a detailed evaluation of such possibility so as to f= igure out whether any potential extensions to the MPLS architecture is requ= ired. For instance, 1) although an MPLS label stack could be used to indicate an SFP, however, = when an SFF-proxy receives such a MPLS packet, it must know the payload typ= e of the MPLS packet before sending the original packet to the correspondin= g legacy SF. How? In fact, even in the non-legacy SF case, should the SFF d= irectly forward the MPLS packet to the corresponding SF directly or strip t= he MPLS header before sending the packet to the corresponding SF? In the fo= rmer case, the corresponding SF should know the payload type of the MPLS pa= cket. In the latter case, the SFF should know the payload type. To identify= the payload type, one way is to allocate a separate local label for each p= ayload type (is this a scalable way?), another way is to allocate an SPL or= an ESPL for each payload type (is this the normal purpose of the SPL or ES= PL), a third way is to introduce a SPL or ESPL which is followed by a proto= col id header (is this a significant change to the MPLS architecture?). 2) assume an SFF needs to strip the "whole" MPLS header before sending the = packet to the corresponding SF, does it mean a big change to the current MP= LS forwarding plane? 3) when using an MPLS label stack to indicate an SFC rather than an SFP, ea= ch SF would have to be identified by a domain-wide label. One way is to res= erve the same label range for SF SID purpose by all the SFFs. Another way i= s to rely on the context label concept (i.e., each SF of an SFC would have = to be represented by two labels in the label stack, one is the context indi= cation label, the other is the label allocated from that context label spac= e for that SF ). However, it seems that the domain-wide label usage is stil= l a controversial topic in the IETF community. 4) how to convey metadata in an MPLS packet? This issue may be the same as = issue 1. Any comments? Best regards, Xiaohu From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, October 29, 2014 8:15 PM To: Xuxiaohu; Thomas Narten Subject: Re: SFC Honolulu meeting agenda Hi Xiaohu, Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our im= mediate deliverables. For this reason we are unable to allocate time for di= scussion of your draft in HI. Please feel free to continue to solicit disc= ussion on the SFC mailing list. Jim & Thomas From: Xuxiaohu > Date: Tuesday, October 28, 2014 at 11:30 PM To: Jim Guichard >, Thomas Na= rten > Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I found there are still available time on the SFC agenda. Hence I wonder wh= ether you could allocate a 15-min slot for presenting this draft. Best regards, Xiaohu From: Xuxiaohu Sent: Wednesday, October 08, 2014 4:50 PM To: 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I would like to request a 15-min slot for presenting the following draft (h= ttps://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since "Gener= ic SFC Encapsulation" is one of the WG charter deliverables and the charter= states that "...The working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found..."= I would like the WG to help evaluating whether the MPLS-SPRING-based SFC e= ncapsulation approach as described in the above draft could be considered a= s one of the candidates. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, October 06, 2014 9:27 PM To: sfc@ietf.org Subject: [sfc] SFC Honolulu meeting agenda Greetings WG: Our meeting at the upcoming Honolulu venue is fast approaching. As always,= the goal of the meeting will be to make the best use of limited face-to-fa= ce time. As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and t= hat generally means focussing on key charter deliverables and topics with i= mportant open issues to resolve. In the case of individual IDs, the goal is= n't necessarily to present what is in the draft but rather to help the WG d= ecide what to do with the ID. With that in mind, when making an agenda requ= est please consider what you think the WG should do with its content. For e= xample: * Does the document have useful content that should be moved into anoth= er WG document or progress on it's own merit * Does the content have a good basis for one of the WG documents per th= e charter (in order for that to happen the document needs to be the most ap= propriate out of the collection of related documents) * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_7347100B5761DC41A166AC17F22DF1121B877E62eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xiaohu, Ron, et. al,

what if metadata carried = over SF ACH type?

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, October 30, 2014 7:28 PM
To: Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: Re: [mpls] [sfc] About the possibility of using MPLS source= routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting ag= enda

 

&nbs= p;

Xiaohu,

&nbs= p;

Regarding= carriage of metadata -- the MPLS would be only the transport part.  W= hat about reserving a well known global label that means SCH/NSH header fol= lows.  This well known label would always be at the BOS.  

&nbs= p;

  &n= bsp;Ron

&nbs= p;

Hi all= ,

 =

There = are many drafts which mentioned the possibility of using the MPLS source ro= uting (i.e., MPLS-SPRING) mechanism for service function chain purpose. How= ever, we do need a detailed evaluation of such possibility so as to figure out whether any potential extensions t= o the MPLS architecture is required. For instance,

 =

1) alt= hough an MPLS label stack could be used to indicate an SFP, however, when a= n SFF-proxy receives such a MPLS packet, it must know the payload type of t= he MPLS packet before sending the original packet to the corresponding legacy SF. How? In fact, even in the non-legac= y SF case, should the SFF directly forward the MPLS packet to the correspon= ding SF directly or strip the MPLS header before sending the packet to the = corresponding SF? In the former case, the corresponding SF should know the payload type of the MPLS packet= . In the latter case, the SFF should know the payload type. To identify the= payload type, one way is to allocate a separate local label for each paylo= ad type (is this a scalable way?), another way is to allocate an SPL or an ESPL for each payload type (is thi= s the normal purpose of the SPL or ESPL), a third way is to introduce a SPL= or ESPL which is followed by a protocol id header (is this a significant c= hange to the MPLS architecture?).

 =

2) ass= ume an SFF needs to strip the “whole” MPLS header before sending the packet to the corresponding SF, does it mean a b= ig change to the current MPLS forwarding plane?

 =

3) whe= n using an MPLS label stack to indicate an SFC rather than an SFP, each SF = would have to be identified by a domain-wide label. One way is to reserve t= he same label range for SF SID purpose by all the SFFs. Another way is to rely on the context label concept (i.e.= , each SF of an SFC would have to be represented by two labels in the label= stack, one is the context indication label, the other is the label allocat= ed from that context label space for that SF ). However, it seems that the domain-wide label usage is still= a controversial topic in the IETF community.

 =

4) how= to convey metadata in an MPLS packet? This issue may be the same as issue = 1.

 =

Any co= mments?

 =

Best r= egards,

Xiaohu=

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda

 

= Hi Xiaohu,

=  <= /p>

= Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to al= locate time for discussion of your draft in HI.  Please feel free to c= ontinue to solicit discussion on the SFC mailing list.

=  <= /p>

= Jim & Thomas

=  <= /p>

From: Xuxiaohu <= ;xuxiaohu@huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda

=  <= /p>

Xuxia= ohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc@i= etf.org
Subject: RE: SFC Honolulu meeting agenda

 

= https://tools.ietf.org/h= tml/draft-xu-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter del= iverables and the charter states that “…The working group will = consider using an existing encapsulation (with extensions as appropriate) i= f a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approac= h as described in the above draft could be considered as one of the candida= tes.

sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc@ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

= Greetings WG:<= /span>

=  <= /p>

= Our meeting at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-= to-face time.<= /span>

=  <= /p>

= As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables = and topics with important open issues to resolve. In the case of individual= IDs, the goal isn’t necessarily to present what is in the draft but = rather to help the WG decide what to do with the ID. With that in mind, when making an agenda request please consi= der what you think the WG should do with its content. For example:

  • Does the document have useful conte= nt that should be moved into another WG document or progress on it’s = own merit
  • Does the content have a good basis = for one of the WG documents per the charter (in order for that to happen th= e document needs to be the most appropriate out of the collection of related documents)
  • Should the document content be merg= ed with one or more other documents, so that a combined document could beco= me a WG document

= Jim & Thomas

_________= ______________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_7347100B5761DC41A166AC17F22DF1121B877E62eusaamb103erics_-- From nobody Thu Oct 30 23:42:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741E71A8AD4; Thu, 30 Oct 2014 23:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63eNgip1NqUx; Thu, 30 Oct 2014 23:42:12 -0700 (PDT) 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 576691A8AD1; Thu, 30 Oct 2014 23:42:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG22297; Fri, 31 Oct 2014 06:42:10 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 06:42:08 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 14:42:02 +0800 From: Xuxiaohu To: Gregory Mirsky , Ron Parker Thread-Topic: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Thread-Index: AQHP4WkpFJPaLJGjIUWt43ZhzuIOrJwl4oHQgCCrkLCAAKOpgIABXyHggAAq7QCAAOSVsIAAQdCwgAAFX4A= Date: Fri, 31 Oct 2014 06:42:01 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C80A7@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644@NKGEML512-MBS.china.huawei.com> <3A2D6E6C-9AB6-4214-887A-42E7ADC2EB6B@affirmednetworks.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6E@NKGEML512-MBS.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B877E62@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B877E62@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NREDpWELIprCrPYVr10NTOhz9os Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 06:42:18 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, However, RFC5586 explicitly states that "The G-ACh MUST NOT be used to tran= sport user traffic." Anyway, it seems that we need a way to indentify the p= ayload type of the MPLS packet (e.g., metadata, Ethernet frame, IP packet) = in the MPLS-based SFC case. Best regards Xiaohu From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 31, 2014 2:24 PM To: Xuxiaohu; Ron Parker Cc: mpls@ietf.org; ; sfc@ietf.org Subject: RE: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Xiaohu, Ron, et. al, what if metadata carried over SF ACH type? Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Thursday, October 30, 2014 7:28 PM To: Ron Parker Cc: mpls@ietf.org; >; sfc@ietf.org Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Ron, Did you mean an SPL(Special Purpose Label) or an ESPL(Extended Special Purp= ose Label) by a well-known global label? If so, additional SPLs or ESPLs wo= uld need to be allocated for different MPLS payload, such as Ethernet frame= and IP packet. However I wonder whether it is the normal usage of the SPL = and ESPL space (i.e., used as a protocol type identifier)? Best regards, Xiaohu From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Friday, October 31, 2014 4:45 AM To: Xuxiaohu Cc: sfc@ietf.org; mpls@ietf.org;= > Subject: Re: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Xiaohu, Regarding carriage of metadata -- the MPLS would be only the transport part= . What about reserving a well known global label that means SCH/NSH header= follows. This well known label would always be at the BOS. Ron On Oct 30, 2014, at 3:15 AM, Xuxiaohu > wrote: Hi all, There are many drafts which mentioned the possibility of using the MPLS sou= rce routing (i.e., MPLS-SPRING) mechanism for service function chain purpos= e. However, we do need a detailed evaluation of such possibility so as to f= igure out whether any potential extensions to the MPLS architecture is requ= ired. For instance, 1) although an MPLS label stack could be used to indicate an SFP, however, = when an SFF-proxy receives such a MPLS packet, it must know the payload typ= e of the MPLS packet before sending the original packet to the correspondin= g legacy SF. How? In fact, even in the non-legacy SF case, should the SFF d= irectly forward the MPLS packet to the corresponding SF directly or strip t= he MPLS header before sending the packet to the corresponding SF? In the fo= rmer case, the corresponding SF should know the payload type of the MPLS pa= cket. In the latter case, the SFF should know the payload type. To identify= the payload type, one way is to allocate a separate local label for each p= ayload type (is this a scalable way?), another way is to allocate an SPL or= an ESPL for each payload type (is this the normal purpose of the SPL or ES= PL), a third way is to introduce a SPL or ESPL which is followed by a proto= col id header (is this a significant change to the MPLS architecture?). 2) assume an SFF needs to strip the "whole" MPLS header before sending the = packet to the corresponding SF, does it mean a big change to the current MP= LS forwarding plane? 3) when using an MPLS label stack to indicate an SFC rather than an SFP, ea= ch SF would have to be identified by a domain-wide label. One way is to res= erve the same label range for SF SID purpose by all the SFFs. Another way i= s to rely on the context label concept (i.e., each SF of an SFC would have = to be represented by two labels in the label stack, one is the context indi= cation label, the other is the label allocated from that context label spac= e for that SF ). However, it seems that the domain-wide label usage is stil= l a controversial topic in the IETF community. 4) how to convey metadata in an MPLS packet? This issue may be the same as = issue 1. Any comments? Best regards, Xiaohu From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, October 29, 2014 8:15 PM To: Xuxiaohu; Thomas Narten Subject: Re: SFC Honolulu meeting agenda Hi Xiaohu, Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our im= mediate deliverables. For this reason we are unable to allocate time for di= scussion of your draft in HI. Please feel free to continue to solicit disc= ussion on the SFC mailing list. Jim & Thomas From: Xuxiaohu > Date: Tuesday, October 28, 2014 at 11:30 PM To: Jim Guichard >, Thomas Na= rten > Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I found there are still available time on the SFC agenda. Hence I wonder wh= ether you could allocate a 15-min slot for presenting this draft. Best regards, Xiaohu From: Xuxiaohu Sent: Wednesday, October 08, 2014 4:50 PM To: 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I would like to request a 15-min slot for presenting the following draft (h= ttps://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since "Gener= ic SFC Encapsulation" is one of the WG charter deliverables and the charter= states that "...The working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found..."= I would like the WG to help evaluating whether the MPLS-SPRING-based SFC e= ncapsulation approach as described in the above draft could be considered a= s one of the candidates. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, October 06, 2014 9:27 PM To: sfc@ietf.org Subject: [sfc] SFC Honolulu meeting agenda Greetings WG: Our meeting at the upcoming Honolulu venue is fast approaching. As always,= the goal of the meeting will be to make the best use of limited face-to-fa= ce time. As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and t= hat generally means focussing on key charter deliverables and topics with i= mportant open issues to resolve. In the case of individual IDs, the goal is= n't necessarily to present what is in the draft but rather to help the WG d= ecide what to do with the ID. With that in mind, when making an agenda requ= est please consider what you think the WG should do with its content. For e= xample: * Does the document have useful content that should be moved into anoth= er WG document or progress on it's own merit * Does the content have a good basis for one of the WG documents per th= e charter (in order for that to happen the document needs to be the most ap= propriate out of the collection of related documents) * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 = ;

However, R= FC5586 explicitly states that “The G-ACh MUST NOT be used to transpor= t user traffic.” Anyway, it seems that we need a way to indentify the payload type of the MPLS packet (e.g., metadata, Ethernet frame, IP pa= cket) in the MPLS-based SFC case.

 = ;

Best regar= ds

Xiaohu

 = ;

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, October 31, 2014 2:24 PM
To: Xuxiaohu; Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: RE: [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

 

Hi Xiaohu,= Ron, et. al,

what if me= tadata carried over SF ACH type?

 = ;

 &nbs= p;            &= nbsp; Regards,

 &nbs= p;            &= nbsp;           &nbs= p;     Greg

 = ;

From: mpls [mailto= :mpls-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, October 30, 2014 7:28 PM
To: Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: Re: [mpls] [sfc] About the possibility of using MPLS source= routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting ag= enda

 

Hi Ron,

 = ;

Did you me= an an SPL(Special Purpose Label) or an ESPL(Extended Special Purpose Label)= by a well-known global label? If so, additional SPLs or ESPLs would need to be allocated for different MPLS payload, such as Ethernet fr= ame and IP packet. However I wonder whether it is the normal usage of the S= PL and ESPL space (i.e., used as a protocol type identifier)?

 = ;

Best regar= ds,

Xiaohu

 = ;

 

Xiaohu,

 

Regarding carriage of metadata = -- the MPLS would be only the transport part.  What about reserving a = well known global label that means SCH/NSH header follows.  This well = known label would always be at the BOS.  

 

   Ron

 

Hi all,

 

There are many drafts= which mentioned the possibility of using the MPLS source routing (i.e., MP= LS-SPRING) mechanism for service function chain purpose. However, we do need a detailed evaluation of such possibility so as to figure out w= hether any potential extensions to the MPLS architecture is required. For i= nstance,

 

1) although an MPLS l= abel stack could be used to indicate an SFP, however, when an SFF-proxy rec= eives such a MPLS packet, it must know the payload type of the MPLS packet before sending the original packet to the corresponding le= gacy SF. How? In fact, even in the non-legacy SF case, should the SFF direc= tly forward the MPLS packet to the corresponding SF directly or strip the M= PLS header before sending the packet to the corresponding SF? In the former case, the corresponding SF should k= now the payload type of the MPLS packet. In the latter case, the SFF should= know the payload type. To identify the payload type, one way is to allocat= e a separate local label for each payload type (is this a scalable way?), another way is to allocate an SPL = or an ESPL for each payload type (is this the normal purpose of the SPL or = ESPL), a third way is to introduce a SPL or ESPL which is followed by a pro= tocol id header (is this a significant change to the MPLS architecture?).

 

2) assume an SFF need= s to strip the “whole” MPLS header before sending the packet to the corresponding SF, does it mea= n a big change to the current MPLS forwarding plane?

 

3) when using an MPLS= label stack to indicate an SFC rather than an SFP, each SF would have to b= e identified by a domain-wide label. One way is to reserve the same label range for SF SID purpose by all the SFFs. Another way is to= rely on the context label concept (i.e., each SF of an SFC would have to b= e represented by two labels in the label stack, one is the context indicati= on label, the other is the label allocated from that context label space for that SF ). However, it seems t= hat the domain-wide label usage is still a controversial topic in the IETF = community.

 

4) how to convey meta= data in an MPLS packet? This issue may be the same as issue 1.

 

Any comments?

 

Best regards,

Xiaohu

 

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda=

 

Hi Xiaohu,

 

Our agenda i= s not yet finalized but we will only be allowing slots for drafts that have= had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to allocate time for= discussion of your draft in HI.  Please feel free to continue to soli= cit discussion on the SFC mailing list.

 

Jim & Th= omas

 

From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda=

 

Hi co-chai= rs,

 

I found th= ere are still available time on the SFC agenda. Hence I wonder whether you = could allocate a 15-min slot for presenting this draft.

 

Best regar= ds,

Xiaohu

 

From: Xuxiaohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc@i= etf.org
Subject: RE: SFC Honolulu meeting agenda=

 

Hi co-chai= rs,

 

I would li= ke to request a 15-min slot for presenting the following draft (https://tools.ietf.org/html/draft-x= u-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter del= iverables and the charter states that “…The working group will = consider using an existing encapsulation (with extensions as appropriate) i= f a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approac= h as described in the above draft could be considered as one of the candida= tes.

 

Best regar= ds,

Xiaohu

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc@ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

Greetings WG= :

 

Our meeting = at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-= to-face time.

 

As we build = the meeting agenda we welcome requests for agenda time. As always, the goal= of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables and topics = with important open issues to resolve. In the case of individual IDs, the g= oal isn’t necessarily to present what is in the draft but rather to h= elp the WG decide what to do with the ID. With that in mind, when making an agenda request please consider what = you think the WG should do with its content. For example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on it’s own merit
  • Does the content have a good basis for one of t= he WG documents per the charter (in order for that to happen the document n= eeds to be the most appropriate out of the collection of related documents)
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

_______________________________= ________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1NKGEML512MBSchi_-- From nobody Fri Oct 31 00:13:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044431A8AE2; Fri, 31 Oct 2014 00:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQwMEwSZt39B; Fri, 31 Oct 2014 00:12:52 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE30A1A8ADB; Fri, 31 Oct 2014 00:12:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-47-5452de5193d1 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.9B.05330.15ED2545; Fri, 31 Oct 2014 01:56:50 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 03:12:41 -0400 From: Gregory Mirsky To: Xuxiaohu , Ron Parker Thread-Topic: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Thread-Index: AQHP4WkpFJPaLJGjIUWt43ZhzuIOrJwl4oHQgCCrkLCAAKOpgIABXyHggAAq7QCAAOSVsIAAQdCwgAAFX4CAAAkQgA== Date: Fri, 31 Oct 2014 07:12:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B877F01@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C80A7@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8644@NKGEML512-MBS.china.huawei.com> <3A2D6E6C-9AB6-4214-887A-42E7ADC2EB6B@affirmednetworks.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C8A6E@NKGEML512-MBS.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B877E62@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C93F1@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B877F01eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPuG7QvaAQgxXf2C1uLV3JanHh6VRm iycPtrJbHL/wm9Fi6/lVjA6sHi+uPGP2aDnyltVjyZKfTAHMUVw2Kak5mWWpRfp2CVwZCx7u YCzY+J+pYvnEV2wNjBuuMnUxcnBICJhIPPhc0MXICWSKSVy4t56ti5GLQ0jgCKPEv9s/GSGc 5YwSvz7OYgapYhMwknixsYcdxBYRCJL4O2cfK8ggZoFsiRWTjUDqhQX6gJp/dIJNEhHoZ5R4 +rgJqiFLounSb0YQm0VAVaJr/Xs2EJtXwFdiwYYnzBDbOlgkDn45AFbEKRAmcWL/O7DNjED3 fT+1hgnEZhYQl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0l8/D2fHaI+X2LDy/tQywQlTs58 wjKBUXQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxls YgRG4TEJNt0djHteWh5iFOBgVOLh3dAVFCLEmlhWXJl7iFGag0VJnHdW7bxgIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYzuG88sqPmfUvztXEPuHvekqpiNk/e0sf/6HvbSL/7yS/7ur1PV U9hWnhWzjN13KzFrxpL+igzGpVHvdJuL88TY0u09VzuY7EkVaEj0vbp6zqxwPeds9arYXYqu B07am8cq7s10v1qjErOGY2lV8Np206B97PwPX1rUOL8vDtzkwRC9/OjnBUosxRmJhlrMRcWJ AOCi6TGjAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8R6-NQ89h6sC03AuEt2qkEkMrTQ Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 07:13:00 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B877F01eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, yes, you're right but I'd refer to Residence Time Measurement draft. Consid= er OAM channel that carries SF metadata. Is that a "user traffic"? Regards, Greg From: Xuxiaohu [mailto:xuxiaohu@huawei.com] Sent: Thursday, October 30, 2014 11:42 PM To: Gregory Mirsky; Ron Parker Cc: mpls@ietf.org; ; sfc@ietf.org Subject: RE: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Greg, However, RFC5586 explicitly states that "The G-ACh MUST NOT be used to tran= sport user traffic." Anyway, it seems that we need a way to indentify the p= ayload type of the MPLS packet (e.g., metadata, Ethernet frame, IP packet) = in the MPLS-based SFC case. Best regards Xiaohu From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 31, 2014 2:24 PM To: Xuxiaohu; Ron Parker Cc: mpls@ietf.org; >; sfc@ietf.org Subject: RE: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Xiaohu, Ron, et. al, what if metadata carried over SF ACH type? Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Thursday, October 30, 2014 7:28 PM To: Ron Parker Cc: mpls@ietf.org; >; sfc@ietf.org Subject: Re: [mpls] [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Hi Ron, Did you mean an SPL(Special Purpose Label) or an ESPL(Extended Special Purp= ose Label) by a well-known global label? If so, additional SPLs or ESPLs wo= uld need to be allocated for different MPLS payload, such as Ethernet frame= and IP packet. However I wonder whether it is the normal usage of the SPL = and ESPL space (i.e., used as a protocol type identifier)? Best regards, Xiaohu From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Friday, October 31, 2014 4:45 AM To: Xuxiaohu Cc: sfc@ietf.org; mpls@ietf.org;= > Subject: Re: [sfc] About the possibility of using MPLS source routing (i.e.= , MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda Xiaohu, Regarding carriage of metadata -- the MPLS would be only the transport part= . What about reserving a well known global label that means SCH/NSH header= follows. This well known label would always be at the BOS. Ron On Oct 30, 2014, at 3:15 AM, Xuxiaohu > wrote: Hi all, There are many drafts which mentioned the possibility of using the MPLS sou= rce routing (i.e., MPLS-SPRING) mechanism for service function chain purpos= e. However, we do need a detailed evaluation of such possibility so as to f= igure out whether any potential extensions to the MPLS architecture is requ= ired. For instance, 1) although an MPLS label stack could be used to indicate an SFP, however, = when an SFF-proxy receives such a MPLS packet, it must know the payload typ= e of the MPLS packet before sending the original packet to the correspondin= g legacy SF. How? In fact, even in the non-legacy SF case, should the SFF d= irectly forward the MPLS packet to the corresponding SF directly or strip t= he MPLS header before sending the packet to the corresponding SF? In the fo= rmer case, the corresponding SF should know the payload type of the MPLS pa= cket. In the latter case, the SFF should know the payload type. To identify= the payload type, one way is to allocate a separate local label for each p= ayload type (is this a scalable way?), another way is to allocate an SPL or= an ESPL for each payload type (is this the normal purpose of the SPL or ES= PL), a third way is to introduce a SPL or ESPL which is followed by a proto= col id header (is this a significant change to the MPLS architecture?). 2) assume an SFF needs to strip the "whole" MPLS header before sending the = packet to the corresponding SF, does it mean a big change to the current MP= LS forwarding plane? 3) when using an MPLS label stack to indicate an SFC rather than an SFP, ea= ch SF would have to be identified by a domain-wide label. One way is to res= erve the same label range for SF SID purpose by all the SFFs. Another way i= s to rely on the context label concept (i.e., each SF of an SFC would have = to be represented by two labels in the label stack, one is the context indi= cation label, the other is the label allocated from that context label spac= e for that SF ). However, it seems that the domain-wide label usage is stil= l a controversial topic in the IETF community. 4) how to convey metadata in an MPLS packet? This issue may be the same as = issue 1. Any comments? Best regards, Xiaohu From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, October 29, 2014 8:15 PM To: Xuxiaohu; Thomas Narten Subject: Re: SFC Honolulu meeting agenda Hi Xiaohu, Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our im= mediate deliverables. For this reason we are unable to allocate time for di= scussion of your draft in HI. Please feel free to continue to solicit disc= ussion on the SFC mailing list. Jim & Thomas From: Xuxiaohu > Date: Tuesday, October 28, 2014 at 11:30 PM To: Jim Guichard >, Thomas Na= rten > Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I found there are still available time on the SFC agenda. Hence I wonder wh= ether you could allocate a 15-min slot for presenting this draft. Best regards, Xiaohu From: Xuxiaohu Sent: Wednesday, October 08, 2014 4:50 PM To: 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: RE: SFC Honolulu meeting agenda Hi co-chairs, I would like to request a 15-min slot for presenting the following draft (h= ttps://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since "Gener= ic SFC Encapsulation" is one of the WG charter deliverables and the charter= states that "...The working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found..."= I would like the WG to help evaluating whether the MPLS-SPRING-based SFC e= ncapsulation approach as described in the above draft could be considered a= s one of the candidates. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, October 06, 2014 9:27 PM To: sfc@ietf.org Subject: [sfc] SFC Honolulu meeting agenda Greetings WG: Our meeting at the upcoming Honolulu venue is fast approaching. As always,= the goal of the meeting will be to make the best use of limited face-to-fa= ce time. As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and t= hat generally means focussing on key charter deliverables and topics with i= mportant open issues to resolve. In the case of individual IDs, the goal is= n't necessarily to present what is in the draft but rather to help the WG d= ecide what to do with the ID. With that in mind, when making an agenda requ= est please consider what you think the WG should do with its content. For e= xample: * Does the document have useful content that should be moved into anoth= er WG document or progress on it's own merit * Does the content have a good basis for one of the WG documents per th= e charter (in order for that to happen the document needs to be the most ap= propriate out of the collection of related documents) * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_7347100B5761DC41A166AC17F22DF1121B877F01eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xiaohu,

yes, you’re right b= ut I’d refer to Residence Time Measurement draft. Consider OAM channe= l that carries SF metadata. Is that a “user traffic”?

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Xuxiaohu= [mailto:xuxiaohu@huawei.com]
Sent: Thursday, October 30, 2014 11:42 PM
To: Gregory Mirsky; Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: RE: [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, October 31, 2014 2:24 PM
To: Xuxiaohu; Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: RE: [sfc] About the possibility of using MPLS source routin= g (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

&nbs= p;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, October 30, 2014 7:28 PM
To: Ron Parker
Cc: mpls@ietf.org; <spring@ietf.org>; sfc@ietf.org
Subject: Re: [mpls] [sfc] About the possibility of using MPLS source= routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting ag= enda

&nbs= p;

&nbs= p;

Xiaohu,

&nbs= p;

Regarding= carriage of metadata -- the MPLS would be only the transport part.  W= hat about reserving a well known global label that means SCH/NSH header fol= lows.  This well known label would always be at the BOS.  

&nbs= p;

  &n= bsp;Ron

&nbs= p;

Hi all,

 

There are= many drafts which mentioned the possibility of using the MPLS source routi= ng (i.e., MPLS-SPRING) mechanism for service function chain purpose. However, we do need a detailed evaluation of such possibility so = as to figure out whether any potential extensions to the MPLS architecture = is required. For instance,

 

1) althou= gh an MPLS label stack could be used to indicate an SFP, however, when an S= FF-proxy receives such a MPLS packet, it must know the payload type of the MPLS packet before sending the original packet to the correspo= nding legacy SF. How? In fact, even in the non-legacy SF case, should the S= FF directly forward the MPLS packet to the corresponding SF directly or str= ip the MPLS header before sending the packet to the corresponding SF? In the former case, the corresponding = SF should know the payload type of the MPLS packet. In the latter case, the= SFF should know the payload type. To identify the payload type, one way is= to allocate a separate local label for each payload type (is this a scalable way?), another way is to allocat= e an SPL or an ESPL for each payload type (is this the normal purpose of th= e SPL or ESPL), a third way is to introduce a SPL or ESPL which is followed= by a protocol id header (is this a significant change to the MPLS architecture?).

 

2) assume= an SFF needs to strip the “whole” MPLS header before sending the packet to the corresponding SF, does it mea= n a big change to the current MPLS forwarding plane?

 

3) when u= sing an MPLS label stack to indicate an SFC rather than an SFP, each SF wou= ld have to be identified by a domain-wide label. One way is to reserve the same label range for SF SID purpose by all the SFFs. Ano= ther way is to rely on the context label concept (i.e., each SF of an SFC w= ould have to be represented by two labels in the label stack, one is the co= ntext indication label, the other is the label allocated from that context label space for that SF ). Howeve= r, it seems that the domain-wide label usage is still a controversial topic= in the IETF community.

 

4) how to= convey metadata in an MPLS packet? This issue may be the same as issue 1.<= o:p>

 

Any comme= nts?

 

Best rega= rds,

Xiaohu

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda

 

= Hi Xiaohu,

=  <= /p>

= Our agenda is not yet finalized but we will only be allowing slots for draf= ts that have had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to al= locate time for discussion of your draft in HI.  Please feel free to c= ontinue to solicit discussion on the SFC mailing list.

=  <= /p>

= Jim & Thomas

=  <= /p>

From: Xuxiaohu <= ;xuxiaohu@huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda

=  <= /p>

Xuxia= ohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc@i= etf.org
Subject: RE: SFC Honolulu meeting agenda

 

= https://tools.ietf.org/h= tml/draft-xu-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter del= iverables and the charter states that “…The working group will = consider using an existing encapsulation (with extensions as appropriate) i= f a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approac= h as described in the above draft could be considered as one of the candida= tes.

sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc@ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

= Greetings WG:<= /span>

=  <= /p>

= Our meeting at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-= to-face time.<= /span>

=  <= /p>

= As we build the meeting agenda we welcome requests for agenda time. As alwa= ys, the goal of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables = and topics with important open issues to resolve. In the case of individual= IDs, the goal isn’t necessarily to present what is in the draft but = rather to help the WG decide what to do with the ID. With that in mind, when making an agenda request please consi= der what you think the WG should do with its content. For example:

  • Does the document have useful conte= nt that should be moved into another WG document or progress on it’s = own merit
  • Does the content have a good basis = for one of the WG documents per the charter (in order for that to happen th= e document needs to be the most appropriate out of the collection of related documents)
  • Should the document content be merg= ed with one or more other documents, so that a combined document could beco= me a WG document

= Jim & Thomas

_________= ______________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_7347100B5761DC41A166AC17F22DF1121B877F01eusaamb103erics_-- From nobody Fri Oct 31 04:40:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01091A88BC for ; Fri, 31 Oct 2014 04:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PmgVuDPaySw for ; Fri, 31 Oct 2014 04:40:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 8628F1A885B for ; Fri, 31 Oct 2014 04:40:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id AA8CB433AE081 for ; Fri, 31 Oct 2014 11:40:05 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9VBe7X7009825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Oct 2014 12:40:07 +0100 Received: from [172.27.205.239] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 31 Oct 2014 12:40:07 +0100 Message-ID: <54537516.5070406@alcatel-lucent.com> Date: Fri, 31 Oct 2014 12:40:06 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <5452173D.3050605@alcatel-lucent.com> In-Reply-To: <5452173D.3050605@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/y8W3OFIVQWTOB0ieMMj2JsdSPLc Subject: [mpls] Agenda Change [Re: IETF91 - MPLS - Agenda available - Please send your presentation material] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 11:40:11 -0000 All, please be aware that the agenda has been updated. -m Le 30/10/2014 11:47, Martin Vigoureux a écrit : > All, > > the agenda is on-line: > http://www.ietf.org/proceedings/91/agenda/agenda-91-mpls > > Please have a look at it. > > Speakers, please start sending me your presentation material, and please > do so before Sunday 9th at noon, local time. > > Thank you > > Martin > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From nobody Fri Oct 31 07:09:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD31A0059 for ; Fri, 31 Oct 2014 07:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evI3OTGhqdDy for ; Fri, 31 Oct 2014 07:09:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955CB1A0055 for ; Fri, 31 Oct 2014 07:09:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0811A272C1420 for ; Fri, 31 Oct 2014 14:09:26 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9VE9ST8019321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Oct 2014 15:09:28 +0100 Received: from [172.27.205.239] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 31 Oct 2014 15:09:28 +0100 Message-ID: <54539817.60306@alcatel-lucent.com> Date: Fri, 31 Oct 2014 15:09:27 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <5452173D.3050605@alcatel-lucent.com> <54537516.5070406@alcatel-lucent.com> In-Reply-To: <54537516.5070406@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PdhfOUZX5weiC8JNAqYAZ-IXvCU Subject: Re: [mpls] Agenda Change [Re: IETF91 - MPLS - Agenda available - Please send your presentation material] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:09:34 -0000 and one more change as I mixed-up between the durations of our two sessions. Jeff, Rakesh, please be ready to present respectively Friday and Monday, depending on how long/short will the preceding discussions be. -m Le 31/10/2014 12:40, Martin Vigoureux a écrit : > All, > > please be aware that the agenda has been updated. > > -m > > Le 30/10/2014 11:47, Martin Vigoureux a écrit : >> All, >> >> the agenda is on-line: >> http://www.ietf.org/proceedings/91/agenda/agenda-91-mpls >> >> Please have a look at it. >> >> Speakers, please start sending me your presentation material, and please >> do so before Sunday 9th at noon, local time. >> >> Thank you >> >> Martin >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From nobody Fri Oct 31 08:04:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3112E1A87B9 for ; Thu, 30 Oct 2014 14:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdbzvu1XQVTK for ; Thu, 30 Oct 2014 14:02:10 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E1D1A87AC for ; Thu, 30 Oct 2014 14:02:09 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ge10so5150015lab.2 for ; Thu, 30 Oct 2014 14:02:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dGQYkTVeEtsIcqH53rqvSL2aRy3w//dmKn7KRPIkkeg=; b=MR3noPBvpPj+OViyby8Jrt2/vBoMKpDt7xb2ROHzgWCyUvqxWeOgdEQJHxmyuslBhV 305HNodefnsK2dxcFrHJ9Zr7u6BuEQY6HIk5i9NUSHLbZkeWGrWKz6rFkrwMl9Zv1p1t Y7RA8/JYZQMK9h3SdOEAyTxGm000Jh6iQindDfhQAPabuua/LKvWz04sJVTrs34x0U4D Wce0UzPGnzIyqpYOrH16a1Py4ACPYtxgHUxTOKX9jh6SPZMhv1inIHZV7kcwrCbxqKVd D7yzAaG7YPDUGmgAXF7htF3w8mnV0TNjv/Mpb6h0ZvljIMXjjQuJzJDIos1n8zC1yVvP xL3g== X-Gm-Message-State: ALoCoQl/yjWfY+rIAH3XsjwSTiBMppBV7hqJ9T9KgjGw2GtzklvuHwII+J1LYIw1d0NSSgtBXDya MIME-Version: 1.0 X-Received: by 10.152.120.133 with SMTP id lc5mr21830306lab.62.1414702928208; Thu, 30 Oct 2014 14:02:08 -0700 (PDT) Received: by 10.112.199.169 with HTTP; Thu, 30 Oct 2014 14:02:08 -0700 (PDT) In-Reply-To: References: <20141027231233.21010.5632.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 14:02:08 -0700 Message-ID: From: Bhupesh Kothari To: Kireeti Kompella Content-Type: multipart/alternative; boundary=089e011769197fbad20506aa31fb Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-j6x7jAmsDtMFwLacM3GhKK1UK0 X-Mailman-Approved-At: Fri, 31 Oct 2014 08:04:23 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-larp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:02:13 -0000 --089e011769197fbad20506aa31fb Content-Type: text/plain; charset=UTF-8 Hi Kireeti, Can you describe how L-ARP can be used between a DSLAM and its upstream router to form bi-directional tunnels? I want to understand what, if any, assumptions are made. Bhupesh On Wed, Oct 29, 2014 at 10:36 AM, Kireeti Kompella < kireeti.kompella@gmail.com> wrote: > Hi All, > > Not sure why this didn't get copied to the MPLS WG list. > > In any case, this update breaks out the "Hardware Address" into two > parts. The HA part contains just the MAC address of L-ARP replier. Labels > are in a separate TLV that now can contain a label stack. Finally, the > metric is taken out of the HA part and is separate. > > We also have a new co-author, George Swallow. > > Please comment on the draft as a whole, and on these changes in particular. > > Thanks, > Kireeti. > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 27, 2014 at 4:12 PM > Subject: New Version Notification for draft-kompella-mpls-larp-02.txt > To: Kireeti Kompella , George Swallow < > swallow@cisco.com>, Balaji Rajagopalan > > > > A new version of I-D, draft-kompella-mpls-larp-02.txt > has been successfully submitted by Kireeti Kompella and posted to the > IETF repository. > > Name: draft-kompella-mpls-larp > Revision: 02 > Title: Label Distribution Using ARP > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt > Status: https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/ > Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-larp-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-kompella-mpls-larp-02 > > Abstract: > This document describes extensions to the Address Resolution Protocol > to distribute MPLS labels for IPv4 and IPv6 host addresses. > Distribution of labels via ARP enables simple plug-and-play operation > of MPLS, which is a key goal of the MPLS Fabric architecture. > > > > > > 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. > > The IETF Secretariat > > > > > -- > Kireeti > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --089e011769197fbad20506aa31fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kireeti,

Can you describe how L-ARP = can be used between a DSLAM and its upstream router to form bi-directional = tunnels?=C2=A0 I want to understand what, if any, assumptions are made.

Bhupesh


On Wed, Oct 29, 2014 at 10:36 AM, Ki= reeti Kompella <kireeti.kompella@gmail.com> wrote:<= br>
Hi All,

Not sure why this didn't get copied to the MPLS WG list.
<= br>
In any case, this update breaks out the "Hardware Addres= s" into two parts.=C2=A0 The HA part contains just the MAC address of = L-ARP replier.=C2=A0 Labels are in a separate TLV that now can contain a la= bel stack.=C2=A0 Finally, the metric is taken out of the HA part and is sep= arate.

We also have a new co-author, George Swallo= w.

Please comment on the draft as a whole, and on = these changes in particular.

Thanks,
Kir= eeti.

---------- Forwarded message= ----------
From: &= lt;internet-d= rafts@ietf.org>
Date: Mon, Oct 27, 2014 at 4:12 PM
Subj= ect: New Version Notification for draft-kompella-mpls-larp-02.txt
To: Ki= reeti Kompella <kireeti.kompella@gmail.com>, George Swallow <swallow@cisco.com>, Balaj= i Rajagopalan <= balajir@juniper.net>



A new version of I-D, draft-kompella-mpls-larp-02.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kompella-mpls-larp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Label Distribution Using ARP
Document date:=C2=A0 2014-10-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-kompella-mpls-larp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr= aft-kompella-mpls-larp-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-larp-02

Abstract:
=C2=A0 =C2=A0This document describes extensions to the Address Resolution P= rotocol
=C2=A0 =C2=A0to distribute MPLS labels for IPv4 and IPv6 host addresses. =C2=A0 =C2=A0Distribution of labels via ARP enables simple plug-and-play op= eration
=C2=A0 =C2=A0of MPLS, which is a key goal of the MPLS Fabric architecture.<= br>




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

The IETF Secretariat




--
Kireeti

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--089e011769197fbad20506aa31fb-- From nobody Fri Oct 31 08:37:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F141ACCEE for ; Fri, 31 Oct 2014 08:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.152 X-Spam-Level: *** X-Spam-Status: No, score=3.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9UQDnWhiy2M for ; Fri, 31 Oct 2014 08:37:42 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853881A906E for ; Fri, 31 Oct 2014 08:37:42 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so7901743pad.7 for ; Fri, 31 Oct 2014 08:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=5jiHa87P/fULjTyVl/z5LJ2/ZR4X0t51CFOKO1sFCts=; b=zqjkydYEOm4nZzmexdOLi5OnnpRhZ44O6i60SiaOspPCE6BHIpw62gNIEXxuA9bOJP 5LzbCVlAL06XwRGGJWqM7cjXxEM7HCN4z/ALYyHJQKqqkIAUQ67H6hzTDfGebU+EWXP3 BEL6dfpJo3+hRwFtVkWY07ixnmk1hTcvRitPLiE8yTbE7jjTWapL7ou9QXYw6UUMvkcZ +Z9uExW6srT+ZXu15kpOI/uGUc7YrK/DlILDon2pxBUXMm4zT1DkUuIHewwdNrToZPPc x+FtmSyBtB0L/MWOHbw4Aq5+f14d64M/IwYT95DOyBukQ5o75zrddvTuB11x7kqeKy7G nCOg== X-Received: by 10.68.93.132 with SMTP id cu4mr25706059pbb.36.1414769862126; Fri, 31 Oct 2014 08:37:42 -0700 (PDT) Received: from Lizhong-PC ([114.62.200.9]) by mx.google.com with ESMTPSA id do7sm8234698pdb.96.2014.10.31.08.37.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 08:37:39 -0700 (PDT) Date: Fri, 31 Oct 2014 23:37:30 +0800 From: "Lizhong Jin" To: jmh , "Carlos Pignataro (cpignata)" , draft-ietf-mpls-lsp-ping-relay-reply References: <012001cfec30$18d91920$4a8b4b60$@gmail.com>, <54465FED.6030005@joelhalpern.com>, , <5446847D.4030500@joelhalpern.com>, <00ff01cfed9c$caf88740$60e995c0$@gmail.com>, <5447131F.5040709@joelhalpern.com>, <010101cfeda3$0cfaf820$26f0e860$@gmail.com>, <544720FD.5030703@joelhalpern.com>, <010901cfedb3$3a47b2e0$aed718a0$@gmail.com>, <5447B18C.7050109@joelhalpern.com>, <6088D699-48F9-4CE1-BA02-D65D1A4777C9@gmail.com>, <54490DE7.1090000@pi.nu>, <54490FC9.4040307@joelhalpern.com>, <201410250003371108192@gmail.com>, <201410292317429615254@gmail.com>, <545114A0.4050202@joelhalpern.com>, <040301cff3e9$36a36080$a3ea2180$@gmail.com>, <5451AD41.6020301@joelhalpern.com>, <201410302331072267666@gmail.com>, <545262DC.6020406@joelhalpern.com>, <04dc01cff4b8$af960cc0$0ec22640$@gmail.com>, <54539480.7020803@joelhalpern.com> X-Priority: 3 X-GUID: 7E05A7A9-3EDB-4E34-9165-4DD87C04B033 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201410312337265980489@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart276517356085_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/htbY6JQBGqey5re8fBHT-eillFI Cc: mpls , Jari Arkko Subject: Re: [mpls] update of draft-ietf-mpls-lsp-ping-relay-reply-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:37:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart276517356085_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSm9lbCwNCmNjIHRvIG1wbHMgbGlzdCBhcyBBRCByZXF1ZXN0ZWQuDQpJbiB5b3VyIGV4YW1w bGUsIG9ubHkgd2hlbiBCLCBDLCBELCBFIHdpdGggSyBiaXQgc2V0LCB0aGVuIHdpbGwgcmVsYXkg dG8gRSwgdG8gRCwgdG8gQywgdGhlbiB0byBCLg0KVGhpcyBpcyB0aGUgaW50ZW50aW9uIG9mIEsg Yml0IHdoaWNoIGlzIGluaGVyaXRlZCBmcm9tIGRyYWZ0LWlldGYtbXBscy1pbnRlcmFzLWxzcHBp bmcgKGEgbWVyZ2VkIGRyYWZ0KSwgYW5kIHdoZW4gSyBiaXQgaXMgc2V0LCB0aGUgYWRkcmVzcyB3 aWxsIGJlIGEgcmVsYXkgbm9kZS4gDQpJbiB0aGUgZHJhZnQsIGl0IHNheXMgaW4gc2VjdGlvbiAz LjINCiJUaGUgYWRkcmVzcyB3aXRoIEsgYml0IHNldCB3aWxsDQphbHdheXMgYmUgYSByZWxheSBu b2RlIGFkZHJlc3MgZm9yIHRoZSBSZWxheWVkIEVjaG8gUmVwbHkiDQoNCkJ1dCB0aGUgbmV4dCBy ZWxheSBhZGRyZXNzIHNlbGVjdGlvbiBtZWNoYW5pc20gZG9lcyBuZWVkIHRvIGJlIHVwZGF0ZWQs IHdoaWNoIGhhcyBsZWQgdG8gbWlzdW5kZXJzdGFuZGluZy4NCg0KDQoNClJlZ2FyZHMNCkxpemhv bmcgSmluDQogDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4NCkRhdGU6IDIwMTQtMTAtMzEgMjE6NTQN ClRvOiBMaXpob25nIEppbjsgJ0NhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSc7ICdkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHknDQpDQzogJ2Fkcmlhbic7ICdsb2EnOyAnSmFy aSBBcmtrbycNClN1YmplY3Q6IFJlOiB1cGRhdGUgb2YgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5n LXJlbGF5LXJlcGx5LTA0DQpUaGF0IGlzIGluZGVlZCBhIGRpZmZlcmVudCBhbGdvcml0aG0sIGFu ZCBkb2VzIG5vdCBkZXBlbmQgdXBvbiB3aGV0aGVyDQp0aGUgSyBiaXQgaXMgc2V0IG9uIHRoZSBv cmlnaW4uDQogDQpJdCBkb2VzIGhhdmUgYW4gaW1wb3J0YW50IHJlc3VsdCB0aGF0IGlzIFZFUlkg ZGlmZmVyZW50IGZyb20geW91cg0KZWFybGllciBhbGdvcml0aG0uICBJdCBpcyBhbiBhY2NlcHRh YmxlIHJlc3VsdCB0byBtZSwgYnV0IHlvdSBzaG91bGQNCm1ha2Ugc3VyZSBpdCBpcyB5b3VyIGlu dGVudGlvbi4gIFRoZSByZXBseSB3aWxsIG5vdyBnbyBiYWNrIHRvIHRoZQ0KY2xvc2VzdCByZWxp YWJsZSByZXZlcnNlLCByYXRoZXIgdGhhbiB0aGUgZnVydGhlc3QuICBTbyBpZiB0aGUgTFNQIGdv ZXMNCnRocm91Z2ggQVNCUnMgQiwgQywgRCwgYW5kIEUsIHRoZSBlYXJsaWVyIGFsZ29yaXRobSB3 b3VsZCBzZW5kIGEgcmVwbHkNCmZyb20gRiB0byBCIHRvIGJlIHJlbGF5ZWQgdG8gdGhlIG9yaWdp bmF0b3IuICBUaGUgbmV3IGFsZ29yaXRobSB3aWxsDQpzZW5kIGEgcmVwbHkgdG8gRSwgdG8gYmUg cmVsYXllZCB0byBELCB0aGVuY2UgdG8gQywgdGhlbmNlIHRvIEIsIGFuZA0KdGhlbmNlIHRvIHRo ZSBvcmlnaW5hdG9yLiAgVGhpcyBpcyBmYXIgbW9yZSByb2J1c3QuICBCdXQgaXQgaXMgYQ0KZHJh bWF0aWMgY2hhbmdlIGluIGJlaGF2aW9yLiAgSSB0aGluayB0aGF0IHN1Y2ggYSBjaGFuZ2UgcmVh bGx5IG5lZWRzDQp3b3JraW5nIGdyb3VwIHJldmlldyBhbmQgYXBwcm92YWwuDQogDQpZb3VycywN CkpvZWwNCiANCk9uIDEwLzMwLzE0LCAxMToxMyBQTSwgTGl6aG9uZyBKaW4gd3JvdGU6DQo+IEhp IEpvZWwsDQo+IEl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSB0byB1bnNldCBLIGJpdCBm b3IgdGhlIG9yaWdpbmF0b3IuIEl0IGlzDQo+IHJlcXVpcmVkIGZvciB0aGUgYm9yZGVyIG5vZGUg dG8gYWRkIGFkZHJlc3MgZW50cnkgd2l0aCBLIGJpdCBzZXQsIHRoZW4gdGhlDQo+IEVjaG8gUmVw bHkgY291bGQgYmUgcmVsYXllZCBiYWNrLg0KPiBCYWNrIHRvIHRoZSBleGFtcGxlIGluIHNlY3Rp b24gNSwgaWYgUDEgYWRkIG5vbi1yb3V0YWJsZSBhZGRyZXNzIGVudHJ5IHdpdGgNCj4gSyBiaXQg c2V0LCBpdCBpcyBPSy4gQVNCUjEgd2lsbCBhZGQgSVAxIHdpdGggSyBiaXQgdW5zZXQsIGFuZCBJ UDIgd2l0aCBLIGJpdA0KPiBzZXQgaW4gdGhlIHN0YWNrLiBUaGVuIFAyL0FTQlIyIHdpbGwgZmly c3Qgc2VuZCBFY2hvIFJlcGx5IHRvIEFTQlIxLCB0aGVuDQo+IEFTQlIxIHNlbmQgRWNobyBSZXBs eSB0byBQMS4gRXZlbiBpZiB0aGUgbm9uLXJvdXRhYmxlIFAxIGFkZHJlc3MgaXMgYWxzbw0KPiBy b3V0YWJsZSBpbiBBUzIsIHRoZSBub2RlIGluIEFTMiB3aWxsIHN0aWxsIHNlbGVjdCBBU0JSMSBh cyB0aGUgbmV4dCByZWxheQ0KPiBub2RlLg0KPiANCj4gSSByZWFkIHNlY3Rpb24gNC4zIGFnYWlu LCBhbmQgbm90IGNvcnJlY3RseSB1c2Ugd29yZCAiZmlyc3QiLCBhbmQgbGVhZCB5b3VyDQo+IG1p c3VuZGVyc3RhbmRpbmc6DQo+IE9MRDoNCj4gVG8gZmluZCBvdXQgdGhlIG5leHQgcmVsYXkgbm9k ZSBhZGRyZXNzLCB0aGUgbm9kZSBTSE9VTEQgY2hlY2sgdGhlDQo+ICAgICBhZGRyZXNzIGl0ZW1z IGluIFJlbGF5IE5vZGUgQWRkcmVzcyBTdGFjayBUTFYgaW4gc2VxdWVuY2UgZnJvbSB0b3AgdG8N Cj4gICAgIGRvd24sIGFuZCBmaW5kIHRoZSBmaXJzdCBJUCByb3V0YWJsZSBhZGRyZXNzLCBlLmcu LCBBLCBhbmQgdGhlIGZpcnN0DQo+ICAgICBhZGRyZXNzIHdpdGggSyBiaXQgc2V0LCBlLmcuLCBC Lg0KPiBORVc6DQo+IFRvIGZpbmQgb3V0IHRoZSBuZXh0IHJlbGF5IG5vZGUgYWRkcmVzcywgdGhl IG5vZGUgU0hPVUxEIGNoZWNrIHRoZQ0KPiAgICAgYWRkcmVzcyBpdGVtcyBpbiBSZWxheSBOb2Rl IEFkZHJlc3MgU3RhY2sgVExWIGluIHNlcXVlbmNlIGZyb20gdG9wIHRvDQo+ICAgICBkb3duLCBh bmQgZmluZCB0aGUgZmlyc3QgSVAgcm91dGFibGUgYWRkcmVzcywgZS5nLiwgQSwgYW5kIHRoZSBs YXN0DQo+ICAgICBhZGRyZXNzIHdpdGggSyBiaXQgc2V0LCBlLmcuLCBCLg0KPiANCj4gUmVnYXJk cw0KPiBMaXpob25nDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IEpvZWwgSGFscGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0N Cj4+IFNlbnQ6IDIwMTTE6jEw1MIzMcjVIDA6MTANCj4+IFRvOiBMaXpob25nIEppbjsgQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpOw0KPiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXkt DQo+PiByZXBseQ0KPj4gQ2M6IGFkcmlhbjsgbG9hOyBKYXJpIEFya2tvDQo+PiBTdWJqZWN0OiBS ZTogdXBkYXRlIG9mIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseS0wNA0KPj4N Cj4+IE5vdCBxdWl0ZToNCj4+DQo+PiAxKSBZb3Ugc3RpbGwgaGF2ZSBub3QgZml4ZWQgNC4yLiAg U28gaWYgdGhlIG9yaWdpbmF0b3IgcHV0cyBvbiBpdHMgYWRkcmVzcw0KPiB3aXRoIHRoZQ0KPj4g SyBiaXQgdW5zZXQsIHRoZSBlbnRyeSB3aWxsIGJlIHJlbW92ZWQuICBCdXQgaW4gb3JkZXIgdG8g bWFrZSB0aGUgcmVzdCBvZg0KPiB5b3VyDQo+PiBsb2dpYyB3b3JrLCB0aGUgb3JpZ2luYXRvciB3 aG9zZSBhZGRyZXNzIGlzIG5vdCByZWFjaGFibGUgbmVlZHMgdG8gcHV0IG9uDQo+IHRoZQ0KPj4g ZW50cnkgd2l0aCB0aGUgayBiaXQgdW5zZXQuDQo+Pg0KPj4gMikgVGhlIGNhc2UgSSB3YW50ZWQg YWRkZWQgaW4gc2VjdGlvbiA1IHdhcyB3aGVuIFAxLCB0aGUgcmVxdWVzdA0KPiBvcmlnaW5hdG9y LA0KPj4gaGFzIGEgbm9uLXJvdXRhYmxlIGFkZHJlc3MuICBUaGVuIHdoZW4gaXQgb3JpZ2luYXRl cyB0aGUgcmVxdWVzdCwgaXQgaGFzDQo+IHRvDQo+PiBwcm92aWRlIGEgc3RhY2sgd2l0aCBpdHMg b3duIGFkZHJlc3Mgd2l0aCB0aGUgSyBiaXQgdW5zZXQuICBPdGhlcndpc2UgdGhlDQo+IHJlc3QN Cj4+IG9mIHRoZSBsb2dpYyB3b24ndCB3b3JrLg0KPj4NCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4N Cj4+IE9uIDEwLzMwLzE0LCAxMTozMSBBTSwgTGl6aG9uZyBKaW4gd3JvdGU6DQo+Pj4gSGkgSm9l bCwNCj4+PiBUaGFua3MgZm9yIHRoZSBjb21tZW50cywgSSBtYWRlIHRoZSBmb2xsb3dpbmcgY2hh bmdpbmcuIFBsZWFzZSBjaGVjaw0KPj4+IGlmIHRoZXkgYXJlIGNvbmZvcnRhYmxlIGZvciB5b3Uu DQo+Pj4NCj4+PiBJbiBTZWN0aW9uIDMuMjoNCj4+PiBEZWxldGU6IEhvdyBhIG5vZGUgZGV0ZXJt aW5lcyB0byBzZXQgdGhlIEsgYml0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mDQo+Pj4gdGhpcyBk b2N1bWVudC4NCj4+PiBBZGQ6IE9uZSBhcHBsaWNhdGlvbiBzY2VuYXJpbyBvZiBLIGJpdCBpcyBn aXZlbiBvdXQgaW4gc2VjdGlvbiA1Lg0KPj4+DQo+Pj4gSW4gU2VjdGlvbiA0LjM6DQo+Pj4gQWRk OiBJZiB0aGVyZSBpcyBubyBCIGV4aXN0ZWQsIHRoZW4gdXNlIEEgYXMgdGhlIG5leHQgcmVsYXkg bm9kZQ0KPiBhZGRyZXNzLg0KPj4+DQo+Pj4gSW4gc2VjdGlvbiA1Og0KPj4+IEFkZDogSW4gdGhl IGNhc2UgdGhhdCB0aGUgaW50ZXJmYWNlIGFkZHJlc3Mgb2YgQVNCUjEgdG8gUDEgaXMgSVAxDQo+ Pj4gd2hpY2ggbWF5YmUgYW4gSVB2NCBwcml2YXRlIGFkZHJlc3MgYW5kIG5vdCBJUCByb3V0YWJs ZSBmb3IgQVMyLCBhbmQNCj4+PiB0aGUgbG9vcGJhY2sgYWRkcmVzcyBvbiBBU1JCMSBpcyBJUDIg d2hpY2ggaXMgcm91dGFibGUgZm9yIEFTMi4gVGhlbg0KPj4+IHdoZW4gQVNCUjEgc2VuZHMgYSBS ZWxheWVkIEVjaG8gUmVwbHksIGl0IHdpbGwgZmlyc3RseSBhZGQgSVAxIHdpdGhvdXQNCj4+PiBL IGJpdCBzZXQgaW4gdGhlIFJlbGF5IE5vZGUgQWRkcmVzcyBTdGFjayBUTFYsIGFuZCB0aGVuIGFk ZA0KPj4+IElQMiB3aXRoIEsgYml0IHNldCBpbiB0aGUgc3RhY2sgVExWLiBUaGVuIEFTQlIyL1Ay IGNvdWxkIHJlbGF5IHRoZQ0KPj4+IFJlbGF5ZWQgRWNobyBSZXBseSBiYWNrIGZpcnN0IHRvIElQ MiB3aGljaCBpcyByb3V0YWJsZSBmb3IgQVNCUjIvUDIsDQo+Pj4gdGhlbiBBU0JSMSB3aWxsIHNl bmQgRWNobyBSZXBseSB0byBQRTEuIFRoYW5rcyBmb3IgdGhlIEsgYml0LCB0aGUNCj4+PiBBU0JS MSB3aWxsIG5vdCBiZSBza2lwcGVkIGZvciBtZXNzYWdlIHJlbGF5Lg0KPj4+DQo+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+IC0tDQo+Pj4gUmVnYXJkcw0KPj4+IExpemhvbmcgSmluDQo+Pj4NCj4+PiAg ICAgICpGcm9tOiogSm9lbCBNLiBIYWxwZXJuIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4N Cj4+PiAgICAgICpEYXRlOiogMjAxNC0xMC0zMCAxMToxNQ0KPj4+ICAgICAgKlRvOiogTGl6aG9u ZyBKaW4gPG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPjsgJ0NhcmxvcyBQaWduYXRhcm8NCj4+ PiAgICAgIChjcGlnbmF0YSknIDxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPjsNCj4+PiAgICAg ICdkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHknDQo+Pj4gICAgICA8bWFpbHRv OmRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseUB0b29scy5pZXRmLm9yZz4NCj4+ PiAgICAgICpDQzoqICdhZHJpYW4nIDxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47ICdsb2En DQo+Pj4gICAgICA8bWFpbHRvOmxvYUBwaS5udT47IEphcmkgQXJra28gPG1haWx0bzpqYXJpLmFy a2tvQHBpdWhhLm5ldD4NCj4+PiAgICAgICpTdWJqZWN0OiogUmU6IHVwZGF0ZSBvZiBkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHktMDQNCj4+PiAgICAgIEFzIEkgdHJpZWQgdG8g c2F5IGluIG15IHByZXZpb3VzIHJlcGx5LCB5b3VyIHNvbHV0aW9uIHRvIHNvdXJjZXMgd2hvDQo+ IGFyZQ0KPj4+ICAgICAgbm90IHJlYWNoYWJsZSwgYnV0IGZvciB3aGljaCB0aGUgcm91dGluZyB0 YWJsZSBtYXkgY2xhaW0NCj4gcmVhY2hhYmlsaXR5DQo+Pj4gICAgICAoZHVlIHRvIHByaXZhdGUg YWRkcmVzcyBkdXBsaWNhdGlvbiBvciBmaXJld2FsbGluZyBvZiBzdWItYmxvY2tzDQo+IHdpdGhp bg0KPj4+ICAgICAgYW4gYWR2ZXJ0aXNlZCByZWdpb24sIG9yLi4uKSBzZWVtcyB0byBkZXBlbmQg Ym90aCB1cG9uIHN1Y2ggc291cmNlcw0KPiBub3QNCj4+PiAgICAgIHNldHRpbmcgdGhlIGsgYml0 IGluIHRoZWlyIChmaXJzdCkgZW50cnksIGFuZCBvbiBzdWNoIGVudHJpZXMNCj4gc3Vydml2aW5n DQo+Pj4gICAgICB0aGUgaW50ZXJtZWRpYXRlIHByb2Nlc3NpbmcuDQo+Pj4gICAgICBHaXZlbiB0 aGF0IHRoaXMgaXMgY2VudHJhbCB0byB0aGUgcHVycG9zZSBvZiB0aGUgZHJhZnQsIHRoZSBiaXQN Cj4gc2V0dGluZw0KPj4+ICAgICAgcmVhbGx5IG5lZWRzIHRvIGJlIGRlc2NyaWJlZC4gIEFuZCBn aXZlbiB0aGF0IHRoaXMgcHJlc2VydmF0aW9uDQo+Pj4gICAgICBjb250cmFkaWN0cyBjdXJyZW50 IHRleHQsIGl0IG11c3QgYmUgc3BlbGxlZCBvdXQuDQo+Pj4gICAgICBZb3VycywNCj4+PiAgICAg IEpvZWwNCj4+PiAgICAgIE9uIDEwLzI5LzE0LCAxMDoyOCBQTSwgTGl6aG9uZyBKaW4gd3JvdGU6 DQo+Pj4gICAgICAgPiBIaSBKb2VsLA0KPj4+ICAgICAgID4gVGhhbmsgeW91IGZvciB0aGUgcHJv bXB0IHJlcGx5Lg0KPj4+ICAgICAgID4NCj4+PiAgICAgICA+IFRoZSBzY2VuYXJpbyB5b3UgcmFp c2VkIGNvdWxkIGJlIHNvbHZlZCBieSBzZXR0aW5nIEsgYml0IGZvciBhDQo+Pj4gICAgICByb3V0 YWJsZQ0KPj4+ICAgICAgID4gYWRkcmVzcy4gTGV0IG1lIGdpdmUgeW91IHRoZSBkZXRhaWwuDQo+ Pj4gICAgICAgPiBQRTEtLS0tUDEtLS0tQVNCUjEtLS0tLUFTQlIyLS0tLS1QMi0tLS0tUEUyDQo+ Pj4gICAgICAgPiBUaGUgaW5pdGlhdG9yIGlzIFBFMSwgYW5kIHRoZSBpbnRlcmZhY2UgYWRkcmVz cyBvZiBBU0JSMSB0byBQMSBpcw0KPj4+ICAgICAgQWRkcjENCj4+PiAgICAgICA+IHdoaWNoIG1h eWJlIGEgcHJpdmF0ZSBhZGRyZXNzLCBhbmQgdGhlIHJvdXRhYmxlIGFkZHJlc3Mgb24gQVNSQjEN Cj4+PiAgICAgIGlzIEFkZHIyLg0KPj4+ICAgICAgID4gVGhlbiB3aGVuIEFTQlIxIHNlbmQgYSBy ZWxheWVkIGVjaG8gcmVwbHksIGl0IHdpbGwgZmlyc3RseSBhZGQNCj4+PiAgICAgIEFkZHIxIGlu IHRoZQ0KPj4+ICAgICAgID4gc3RhY2ssIGFuZCB0aGVuIGFkZCBBZGRyMiB3aXRoIEsgYml0IHNl dCBpbiB0aGUgc3RhY2suDQo+Pj4gICAgICAgPiBUaGVuIFAyIGNvdWxkIHJlbGF5IHRoZSBlY2hv IHJlcGx5IGJhY2sgZmlyc3QgdG8gQWRkcjIsIHRoZW4NCj4+PiAgICAgIEFkZHIxIGJ5IEFTQlIx Lg0KPj4+ICAgICAgID4NCj4+PiAgICAgICA+IEkgY29uc2lkZXIgYWJvdmUgYXMgYW4gYXBwbGlj YXRpb24gY2FzZSBvZiBLIGJpdCwgc28gSSBkaWQgbm90DQo+Pj4gICAgICBnaXZlIG91dCB0aGUN Cj4+PiAgICAgICA+IGRldGFpbC4gQnV0IEkgY291bGQgYWRkIHNvbWUgdGV4dCBhYm91dCBhYm92 ZSBleGFtcGxlIGluIHNlY3Rpb24NCj4+PiAgICAgIDUgaWYgeW91DQo+Pj4gICAgICAgPiBpbnNp c3QuDQo+Pj4gICAgICAgPiBJbiB0aGUgZG9jdW1lbnQsIGl0IHNheXM6DQo+Pj4gICAgICAgPiBT b21lIG5vZGVzIGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8gYWx3YXlzIHNldCB0aGUgSyBiaXQsDQo+ Pj4gICAgICAgPiAgICAgb3IgdGhlIG1vZHVsZSBoYW5kbGluZyBNUExTIGVjaG8gcmVxdWVzdHMg Y291bGQgZGlzY292ZXIgaXRzDQo+Pj4gICAgICBLIGJpdA0KPj4+ICAgICAgID4gICAgIHVzZSB0 aHJvdWdoIHRvcG9sb2d5IGF3YXJlbmVzcy4gIEhvdyBhIG5vZGUgZGV0ZXJtaW5lcyB0byBzZXQN Cj4+PiAgICAgIHRoZSBLDQo+Pj4gICAgICAgPiAgICAgYml0IGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4gICAgICAgPg0KPj4+ICAgICAgID4gQnV0IEkgZm9yZ2V0 IHRvIGFkZCB0aGUgc2VudGVuY2UgaW4gc2VjdGlvbiA0LjIgd2hpY2ggSSBwcm9taXNlDQo+Pj4g ICAgICB0byBDYXJsb3MgdG8NCj4+PiAgICAgICA+IGFkZDoNCj4+PiAgICAgICA+IEEgc2Vjb25k IG9yIG1vcmUgYWRkcmVzcyBlbnRyaWVzIGNvdWxkIGFsc28gYmUgYWRkZWQgaWYNCj4+PiAgICAg IG5lY2Vzc2FyeSwgd2hpY2gNCj4+PiAgICAgICA+IGRlcGVuZHMgb24gaW1wbGVtZW50YXRpb24u DQo+Pj4gICAgICAgPg0KPj4+ICAgICAgID4gUmVnYXJkcw0KPj4+ICAgICAgID4gTGl6aG9uZw0K Pj4+ICAgICAgID4NCj4+PiAgICAgICA+DQo+Pj4gICAgICAgPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+PiAgICAgICA+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tXQ0KPj4+ICAgICAgID4+IFNlbnQ6IDIwMTTE6jEw1MIzMMjVIDA6MjQN Cj4+PiAgICAgICA+PiBUbzogTGl6aG9uZyBKaW47IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRh KTsNCj4+PiAgICAgICA+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS0NCj4+PiAgICAg ICA+PiByZXBseQ0KPj4+ICAgICAgID4+IENjOiBhZHJpYW47IGxvYQ0KPj4+ICAgICAgID4+IFN1 YmplY3Q6IFJlOiB1cGRhdGUgb2YgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5 LTA0DQo+Pj4gICAgICAgPj4NCj4+PiAgICAgICA+PiBUaGlzIHJldmlzaW9uIGRvZXMgbm90IHNl ZW0gdG8gYWRkcmVzcyBteSBjb21tZW50cyBmcm9tIE9jdG9iZXINCj4+PiAgICAgIDI0LiAgVGhl DQo+Pj4gICAgICAgPj4gYXNzdW1wdGlvbiB0aGF0IHNvdXJjZXMgd2lsbCBzZXQgSyBpbiBjZXJ0 YWluIHdheXMgaXMgc3RpbGwNCj4+PiAgICAgIGltcGxpY2kgcmF0aGVyDQo+Pj4gICAgICAgPiB0 aGFuDQo+Pj4gICAgICAgPj4gZXhwbGljaXQsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLg0KPj4+ICAg ICAgID4+DQo+Pj4gICAgICAgPj4gTW9yZSBpbXBvcnRhbnRseSwgaWYgc291cmNlcyBkbyBub3Qg c2V0IHRoZSBLIGJpdCBvbiB0aGVpciBvd24NCj4gc3RhY2sNCj4+PiAgICAgICA+IGVudHJ5LCBz bw0KPj4+ICAgICAgID4+IGFzIHRvIGVuYWJsZSB0aGUgaW1wcm92ZWQgcmVsYXkgc2VsZWN0aW9u IGxvZ2ljIHRvIHdvcmssIHRoZW4NCj4+PiAgICAgIHRoZSBzb3VyZQ0KPj4+ICAgICAgID4gZW50 cnkNCj4+PiAgICAgICA+PiB3aWxsIGJlIHJlbW92ZWQgYnkgdGhlIGxvZ2ljIGluIDQuMi4NCj4+ PiAgICAgICA+Pg0KPj4+ICAgICAgID4+IFlvdXJzLA0KPj4+ICAgICAgID4+IEpvZWwNCj4+PiAg ICAgICA+Pg0KPj4+ICAgICAgID4+IFBTOiBIZXJlIGlzIHRoZSBib2R5IG9mIHdoYXQgSSB3cm90 ZSBvbiB0aGUgMjR0aDoNCj4+PiAgICAgICA+Pg0KPj4+ICAgICAgID4+IFdlIGFyZSBnZXR0aW5n IGNsb3NlLg0KPj4+ICAgICAgID4+IEkgYmVsaWV2ZSB0aGF0IHRoZSBpbnRlbnQgaXMgdGhhdCBp ZiBhIG5vZGUgaGFzIHJlYXNvbiB0bw0KPj4+ICAgICAgYmVsaWV2ZSB0aGF0IGl0cw0KPj4+ICAg ICAgID4gYWRkcmVzcw0KPj4+ICAgICAgID4+IHdpbGwgYmUgTkFUZWQgb3IgZmlyZXdhbGxlZCBh dCB0aGUgZG9tYWluIGVkZ2UsIHRoZW4gaXQgc2hvdWxkDQo+Pj4gICAgICBwdXQgaW4gaXRzDQo+ Pj4gICAgICAgPj4gYWRkcmVzcywgYnV0IG5vdCBzZXQgdGhlIEsgYml0Lg0KPj4+ICAgICAgID4+ IElmIHRoZSBvcmlnaW5hdG9yIGRvZXMgdGhpcywgdGhlbiBvdGhlciBmb2xrcyB3aXRoaW4gaGlz IGRvbWFpbg0KPiB3aWxsDQo+Pj4gICAgICAgPiByZXNwb25kDQo+Pj4gICAgICAgPj4gZGlyZWN0 bHksIHdoaWxlIGFueW9uZSBwYXN0IHRoZSBkb21haW4gZWRnZSB3aWxsIHJlbGF5IHRvIHRoZQ0K Pj4+ICAgICAgYm9yZGVyIG5vZGUsDQo+Pj4gICAgICAgPj4gd2hvIHdpbGwgc2V0IHRoZSBLIGJp dC4NCj4+PiAgICAgICA+Pg0KPj4+ICAgICAgID4+IElmIHRoYXQgaXMgdGhlIGludGVudCwgdGhl biB0aGVyZSBhcmUgdHdvIHRoaW5ncyB0aGF0IGFyZQ0KPiBuZWVkZWQ6DQo+Pj4gICAgICAgPj4g MSkgV2UgbmVlZCB0byBhY3R1YWxseSBzYXkgdGhhdCwgYW5kIG5vdCBsZWF2ZSB0aGUgaW1wbGVt ZW50b3INCj4+PiAgICAgIGd1ZXNzaW5nLg0KPj4+ICAgICAgID4+IDIpIEluIHNlY3Rpb24gNC4y IGl0IG5lZWRzIHRvIGJlIG5vdGVkIHRoYXQgdGhlIG9yaWdpbmF0b3INCj4+PiAgICAgIGFkZHJl c3MgbXVzdA0KPj4+ICAgICAgID4gbm90IGJlDQo+Pj4gICAgICAgPj4gcmVtb3ZlZCBldmVuIGlm IHRoZSBLIGJpdCBpcyBub3Qgc2V0IG9uIHRoYXQgYWRkcmVzcy4NCj4+PiAgICAgICA+Pg0KPj4+ ICAgICAgID4+IE9uIDEwLzI5LzE0LCAxMToxNyBBTSwgTGl6aG9uZyBKaW4gd3JvdGU6DQo+Pj4g ICAgICAgPj4+IEhpLCBhbGwsDQo+Pj4gICAgICAgPj4+IFRoZSBjdXQtb2ZmIHRpbWUgb2YgZHJh ZnQgc3VibWlzc2lvbiBoYXMgYmVlbiBwYXNzZWQuIEkgd2lsbA0KPiB1cGxvYWQNCj4+PiAgICAg ICA+Pj4gdGhlIG5ldyB2ZXJzaW9uIG9uY2UgaXQgaXMgcmVvcGVuZWQuDQo+Pj4gICAgICAgPj4+ IFBsZWFzZSBjaGVjayBpZiB0aGUgbmV3IHZlcnNpb24gaXMgT0sgZm9yIHlvdSBhbGwuIFRoYW5r IHlvdS4NCj4+PiAgICAgICA+Pj4NCj4+PiAgICAgICA+Pj4NCj4+Pg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gICAgICAgPj4+IC0tDQo+Pj4gICAgICAgPj4+IFJlZ2FyZHMNCj4+PiAgICAgICA+Pj4g TGl6aG9uZyBKaW4NCj4+PiAgICAgICA+Pj4NCj4+PiAgICAgICA+Pj4gICAgICAqt6K8/sjLo7oq IExpemhvbmcgSmluIDxtYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbT4NCj4+PiAgICAgICA+Pj4g ICAgICAqt6LLzcqxvOSjuiogMjAxNC0xMC0yNSAwMDowMw0KPj4+ICAgICAgID4+PiAgICAgICrK 1bz+yMujuiogam1oIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IGxvYQ0KPj4+ICAgICAg ID4+IDxtYWlsdG86bG9hQHBpLm51PjsNCj4+PiAgICAgICA+Pj4gICAgICBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkgPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+DQo+Pj4gICAgICAgPj4+ ICAgICAgKrOty82juiogZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5DQo+Pj4g ICAgICAgPj4+DQo+IDxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5 QHRvb2xzLmlldGYub3JnPg0KPj4+ICAgICAgID4+PiAgICAgICrW98zio7oqIHVwZGF0ZSBvZiBk cmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHktMDQNCj4+PiAgICAgICA+Pj4gICAg ICBIaSBKb2VsLCBDYXJsb3MNCj4+PiAgICAgICA+Pj4gICAgICBUaGUgbmV3IHZlcnNpb24gYXR0 YWNoZWQgaXMgc2VuZGluZyB0byB5b3UgZm9yDQo+Pj4gICAgICBjb25maXJtYXRpb24sIGJlZm9y ZQ0KPj4+ICAgICAgID4+PiAgICAgIHB1Ymxpc2hpbmcuIFRoYW5rIHlvdSBhZ2FpbiBmb3IgeW91 ciBjb21tZW50cy4NCj4+PiAgICAgICA+Pj4NCj4+PiAgICAgICA+Pj4NCj4+PiAgICAgICA+DQo+ Pj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gICAgICAgPj4+ICAgICAgUmVnYXJkcw0KPj4+ICAg ICAgID4+PiAgICAgIExpemhvbmcgSmluDQo+Pj4gICAgICAgPj4+DQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICq3orz+yMujuiogSm9lbCBNLiBIYWxwZXJuDQo+IDxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgKreiy83Ksbzko7oqIDIwMTQtMTAtMjMg MjI6MjUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgKsrVvP7Iy6O6KiBMb2EgQW5kZXJzc29uIDxt YWlsdG86bG9hQHBpLm51PjsNCj4+PiAgICAgIGxpemhvLmppbkBnbWFpbC5jb20NCj4+PiAgICAg ICA+Pj4gICAgICAgICAgPG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPg0KPj4+ICAgICAgID4+ PiAgICAgICAgICAq1vfM4qO6KiBSZTogW21wbHNdIFtHZW4tYXJ0XSByZXZpZXc6DQo+Pj4gICAg ICAgPj4+ICAgICAgICAgIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseS0wNA0K Pj4+ICAgICAgID4+PiAgICAgICAgICBJdCBoYXMgY29udmVyZ2VkIHRvIHRoZSBkZWdyZWUgdGhh dCBMaXpob25nIGJlbGlldmVzDQo+Pj4gICAgICBoZSBjYW4gbWFrZQ0KPj4+ICAgICAgID4gdGhl DQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGNoYW5nZXMgbmVlZGVkIHRvIGFkZHJlc3MgbXkgY29u Y2VybnMuICBJIGJlbGlldmUgaGUNCj4+PiAgICAgIHVuZGVyc3RhbmRzDQo+Pj4gICAgICAgPiB0 aGUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgY29uY2VybnMuICBJIGRvIG5vdCB1bmRlcnN0YW5k IHNvbWUgb2YgdGhlIGltcG9ydGFudA0KPj4+ICAgICAgYXNwZWN0cyBvZg0KPj4+ICAgICAgID4g aGlzDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIHByb3Bvc2FsLCBidXQgbG9vayBmb3J3YXJkIHRv IHNlZWluZyB0aGUgZHJhZnQuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIFlvdXJzLA0KPj4+ICAg ICAgID4+PiAgICAgICAgICBKb2VsDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIE9uIDEwLzIzLzE0 LCAxMDoxNyBBTSwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4+PiAgICAgICA+Pj4gICAgICAgICAg ID4gTGl6aG9uZyBhbmQgSm9lbCwNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4NCj4+PiAgICAg ICA+Pj4gICAgICAgICAgID4gU2hvdWxkIEkgaW50ZXJwcmV0IHRoaXMgYXMgdGhhdCB0aGUgZGlz Y3Vzc2lvbiBoYXMNCj4+PiAgICAgIGNvbnZlcmdlZA0KPj4+ICAgICAgID4gb24gYQ0KPj4+ICAg ICAgID4+PiAgICAgICAgICAgPiBzb2x1dGlvbiB0aGF0IHlvdSBib3RoIGFyZSBjb21mb3J0YWJs ZSB3aXRoPw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPg0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPiAvTG9hDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+DQo+Pj4gICAgICAgPj4+ICAgICAg ICAgICA+IE9uIDIwMTQtMTAtMjIgMTY6MDUsIGxpemhvLmppbkBnbWFpbC5jb20gd3JvdGU6DQo+ Pj4gICAgICAgPj4+ICAgICAgICAgICA+PiBKb2VsLCB0aGFuayB5b3UgZm9yIHRoZSByZXZpZXcu IFdlIHdpbGwgc2VuZCBvdXQgYQ0KPiBuZXcNCj4+PiAgICAgICA+Pj4gICAgICAgICAgdmVyc2lv biBzb29uIHRvIHJlZmxlY3QgdGhlIGRpc2N1c3Npb24uDQo+Pj4gICAgICAgPj4+ICAgICAgICAg ICA+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4gUmVnYXJkcw0KPj4+ICAgICAgID4+PiAg ICAgICAgICAgPj4gTGl6aG9uZw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4NCj4+PiAgICAg ICA+Pj4gICAgICAgICAgID4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pg0KPj4+ICAgICAg ID4+PiAgICAgICAgICAgPj4+INTaIDIwMTTE6jEw1MIyMsjVo6zPws7nOTozMKOsSm9lbCBIYWxw ZXJuIERpcmVjdA0KPj4+ICAgICAgID4+PiAgICAgICAgICA8am1oLmRpcmVjdEBqb2VsaGFscGVy bi5jb20+IHdyb3Rlo7oNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pg0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+IEl0IHdvdWxkIGJlIGdvb2QgdG8gc2VlIGEgcmV2aXNpb24gdGhhdCBj bGVhcmx5DQo+Pj4gICAgICBzcGVsbGVkIG91dA0KPj4+ICAgICAgID4+PiAgICAgICAgICB3aGF0 IHRoZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+IGRyYWZ0IHdhcyBzb2x2aW5nLCBob3cg dGhlIGluaXRpYWwgZW5kLXBvaW50IGtuZXcNCj4+PiAgICAgIHdoYXQgdG8NCj4+PiAgICAgICA+ Pj4gICAgICAgICAgY3JlYXRlLCBhbmQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+PiBob3cg dGhlIHJlc3BvbmRlciBrbmV3IHdoYXQgdG8gdXNlLiAgSXQgbWF5IHdlbGwNCj4+PiAgICAgIGJl IHRoYXQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgdGhlcmUgaXMgYW4NCj4+PiAgICAgICA+Pj4g ICAgICAgICAgID4+PiBlZmZlY3RpdmUgc29sdXRpb24gdG8gdGhlIHByb2JsZW1zIGhlcmUuICBJ IGxvb2sNCj4+PiAgICAgIGZvcndhcmQgdG8NCj4+PiAgICAgICA+Pj4gICAgICAgICAgc2VlaW5n IGl0IGluDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4gd3JpdGluZy4NCj4+PiAgICAgICA+ Pj4gICAgICAgICAgID4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+IFlvdXJzLA0KPj4+ ICAgICAgID4+PiAgICAgICAgICAgPj4+IEpvZWwNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+ Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBPbiAxMC8yMi8xNCwgMTI6NDYgQU0sIExp emhvbmcgSmluIHdyb3RlOg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBIaSBKb2VsLA0K Pj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBUaGUgdGhpbmdzIG1heSBub3QgYmUgdGhhdCBi YWQuIFlvdSBjb3VsZCBhZGQgYQ0KPj4+ICAgICAgc2Vjb25kDQo+Pj4gICAgICAgPj4+ICAgICAg ICAgIGFkZHJlc3MgKGFkZHJlc3MgQiBpbg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBv dXIgZXhhbXBsZSkgd2l0aCBLIGJpdCBzZXQuIFRoZSBhZGRyZXNzIGVudHJ5DQo+Pj4gICAgICB3 aXRoIEsgYml0DQo+Pj4gICAgICAgPj4+ICAgICAgICAgIHNldCBtdXN0IGJlIGFzIGENCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4gcmVsYXkgbm9kZSwgYW5kIGNvdWxkIG5vdCBiZSBza2lw cGVkLg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBTZWN0aW9uIDQuNCBzaG91bGQgYmUg Y2hhbmdlZCB0bzogRmluZCB0aGUgZmlyc3QNCj4+PiAgICAgIHJvdXRhYmxlDQo+Pj4gICAgICAg Pj4+ICAgICAgICAgIGFkZHJlc3MgQSwgYW5kIHRoZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAg Pj4+PiBmaXJzdCBhZGRyZXNzIEIgd2l0aCBLIGJpdCBzZXQuIElmIGFkZHJlc3MgQSBpcw0KPj4+ ICAgICAgYmVmb3JlDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGFkZHJlc3MgQiBpbiB0aGUNCj4+ PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4gc3RhY2ssIHRoZW4gdXNlIGFkZHJlc3MgQiBhcyB0 aGUgcmVsYXkgYWRkcmVzcy4NCj4+PiAgICAgIE90aGVyd2lzZSwNCj4+PiAgICAgICA+Pj4gICAg ICAgICAgdXNlIGFkZHJlc3MgQSBhcw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiB0aGUg cmVsYXkgYWRkcmVzcy4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4gSW4gdGhhdCBjYXNl LCBpZiBBIGlzIHRoZSBwcml2YXRlIGFkZHJlc3MsIHRoZQ0KPj4+ICAgICAgcGFja2V0IHdpbGwN Cj4+PiAgICAgICA+Pj4gICAgICAgICAgYmUgZmlyc3RseQ0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+PiByZWxheWVkIHRvIGFkZHJlc3MgQi4gQW5kIGFkZHJlc3MgQSBhbmQgQiBiZWxvbmcN Cj4+PiAgICAgIHRvIG9uZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICByb3V0ZXIuIEhlcmUgSQ0K Pj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBhc3N1bWUgb25lIHJvdXRlciBhdCBsZWFzdCBo YXMgb25lIHJvdXRhYmxlDQo+Pj4gICAgICBhZGRyZXNzIGZvcg0KPj4+ICAgICAgID4+PiAgICAg ICAgICBhbm90aGVyIEFTLg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pg0KPj4+ICAgICAg ID4+PiAgICAgICAgICAgPj4+PiBSZWdhcmRzDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+ IExpemhvbmcNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4NCj4+PiAgICAgICA+Pj4gICAg ICAgICAgID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICA+Pj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4NCj4gW21haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tXQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4gU2VudDogMjAxNMTqMTDU wjIyyNUgMTE6MTQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+IFRvOiBMaXpob25nIEpp bg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4gQ2M6IGdlbi1hcnRAaWV0Zi5vcmc7IG1w bHNAaWV0Zi5vcmc7IGlldGZAaWV0Zi4NCj4gb3JnOw0KPj4+ICAgICAgID4+PiAgICAgICAgICAg Pj4+PiAnZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAg Pj4+Pj4gcmVsYXktcmVwbHkuYWxsJw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4gU3Vi amVjdDogUmU6IFttcGxzXSBbR2VuLWFydF0gcmV2aWV3Og0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+PiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHktMDQNCj4+PiAgICAg ICA+Pj4gICAgICAgICAgID4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBvdSBh cmUgc2F5aW5nIHRoYXQgdGhpcyBpcyBvbmx5IGZvciB0aGUgY2FzZQ0KPj4+ICAgICAgd2hlcmUg YW4gQVMNCj4+PiAgICAgICA+Pj4gICAgICAgICAgaXMgdXNpbmcgcHVibGljDQo+Pj4gICAgICAg Pj4+ICAgICAgICAgICA+Pj4+PiBhZGRyZXNzZXMgZm9yIGl0cyBpbnRlcm5hbCBudW1iZXJpbmcs IGJ1dCBpcw0KPiBub3QNCj4+PiAgICAgICA+Pj4gICAgICAgICAgZGlzdHJpYnV0aW5nIHRoYXQg YWRkcmVzcw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBibG9jaw0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+Pj4gZXh0ZXJuYWxseT8NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+ Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBJZiBzbywgeW91IG5lZWQgdG8gc3Rh dGUgdGhhdCB2ZXJ5IGNsZWFybHkuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBJIGJl bGlldmUgYSBmYXIgbW9yZSBjb21tb24gY2FzZSBpcyBvbmUgd2hlcmUNCj4gdGhlDQo+Pj4gICAg ICAgPj4+ICAgICAgICAgIG51bWJlcmluZyBpcyBmcm9tIGENCj4+PiAgICAgICA+Pj4gICAgICAg ICAgID4+Pj4+IHBvcnRpb24gb2YgYSBwdWJsaWNseSBhbGxvY2F0ZWQgc3BhY2UsIGJ1dA0KPj4+ ICAgICAgZmlyZXdhbGxlZC4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgV2hpY2ggd291bGQNCj4+ PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4gcHJvZHVjZQ0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+Pj4gdGhlIHNhbWUgcHJvYmxlbSwgYnV0IHdvdWxkIG5vdCBiZSBhbWVuYWJsZSB0bw0K PiB0aGlzDQo+Pj4gICAgICAgPiBzb2x1dGlvbi4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+ Pj4+IEFuZCBpdCBpcyB3ZWxsIGtub3duIHRoYXQgbWFueSBJU1BzIGRvIGludGVybmFsDQo+Pj4g ICAgICBudW1iZXINCj4+PiAgICAgICA+Pj4gICAgICAgICAgYXNzaWdubWVudCBmcm9tDQo+Pj4g ICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBwcml2YXRlIGJsb2Nrcy4NCj4+PiAgICAgICA+Pj4g ICAgICAgICAgID4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBTbyB3aGF0IHlv dSBhcmUgbm93IHNheWluZyBpcyB0aGF0IHRoaXMgZHJhZnQNCj4+PiAgICAgIHNvbHZlcyBhDQo+ Pj4gICAgICAgPj4+ICAgICAgICAgIHZlcnkgc21hbGwgcG9ydGlvbg0KPj4+ICAgICAgID4+PiAg ICAgICAgICAgPj4+PiBvZiB0aGUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+IHByb2Js ZW0/ICBCdXQgaXQgd29ya3MgZm9yIHRoYXQgc21hbGwgcG9ydGlvbj8NCj4+PiAgICAgIElmIHNv LCBhdA0KPj4+ICAgICAgID4+PiAgICAgICAgICB0aGUgdmVyeSBsZWFzdA0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+PiB5b3UNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+IG5lZWQg dG8gYmUgVkVSWSBjbGVhciBhYm91dCB3aGF0IGNhc2VzIHRoaXMNCj4+PiAgICAgIHdvcmtzIGZv ciBhbmQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgd2hhdCBjYXNlcyBpdA0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+PiBkb2VzDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+PiBub3Qu ICBBbmQgSSBmZWFyIHRoYXQgZXZlbiBpZiB5b3UgYXJlIGNsZWFyLCBpdA0KPj4+ICAgICAgaXMg Z29pbmcNCj4+PiAgICAgICA+Pj4gICAgICAgICAgdG8gYmUgdmVyeQ0KPj4+ICAgICAgID4+PiAg ICAgICAgICAgPj4+PiBjb25mdXNpbmcgZm9yDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+ PiBmb2xrcyB3aG8gYXJlIHRyeWluZyB0byB1c2UgaXQuDQo+Pj4gICAgICAgPj4+ICAgICAgICAg ICA+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4gWW91cnMsDQo+Pj4gICAgICAg Pj4+ICAgICAgICAgICA+Pj4+PiBKb2VsDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pg0K Pj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+IE9uIDEwLzIxLzE0LCAxMDo1MSBQTSwgTGl6 aG9uZyBKaW4gd3JvdGU6DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4gSGkgSm9lbCwN Cj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+PiBJIG5vdyBzZWUgeW91ciBjb25jZXJuLiBU aGUgInByaXZhdGUiIHdvcmQgaW4NCj4+PiAgICAgIGRyYWZ0IGlzDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgIG5vdCBjb3JyZWN0LCBJDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4gd2ls bCByZW1vdmUgaXQuIFRoZSBvcmlnaW5hbCBtb3RpdmF0aW9uIG9mDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICJkcmFmdC1yZWxheS1yZXBseSIgaXMgZnJvbQ0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+Pj4+IHRoZSBzY2VuYXJpbyB3aGVyZSBJUCBhZGRyZXNzIGRpc3RyaWJ1dGlvbiBpcw0K Pj4+ICAgICAgcmVzdHJpY3RlZA0KPj4+ICAgICAgID4+PiAgICAgICAgICBhbW9uZyBBUyBvciBJ R1ANCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+IGFyZWEuDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICA+Pj4+Pj4gQW5kIHRoZSBJUCBhZGRyZXNzIGlzIG5vdCBwcml2YXRlIGFkZHJlc3Mu IEFzDQo+Pj4gICAgICBJIGtub3csDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIG1vc3QgZGVwbG95 ZWQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+PiBpbnRlci1BUyBvciBpbnRlci1hcmVh IE1QTFMgTFNQIGlzIGluIHRoZQ0KPiBuZXR3b3JrDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIHdp dGhvdXQgcHJpdmF0ZSBJUA0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+PiBhZGRyZXNzLg0K Pj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+ Pj4+Pj4gUmVnYXJkcw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+IExpemhvbmcNCj4+ PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+ Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+IEZyb206IEpvZWwgTS4gSGFs cGVybg0KPj4+ICAgICAgW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+Pj4+PiBTZW50OiAyMDE0xOoxMNTCMjLI1SAxMDoxNQ0KPj4+ICAgICAg ID4+PiAgICAgICAgICAgPj4+Pj4+PiBUbzogTGl6aG9uZyBKaW4NCj4+PiAgICAgICA+Pj4gICAg ICAgICAgID4+Pj4+Pj4gQ2M6IGdlbi1hcnRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+Pj4g ICAgICBpZXRmQGlldGYub3JnOw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+ICdkcmFm dC1pZXRmLW1wbHMtbHNwLXBpbmctDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+IHJl bGF5LXJlcGx5LmFsbCcNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4gU3ViamVjdDog UmU6IFttcGxzXSBbR2VuLWFydF0gcmV2aWV3Og0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+ Pj4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseS0wNA0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+PiBUaGUg cHJvYmxlbSBpcyB0aGF0IHRoZSBvcmlnaW5hbCBzb3VyY2UgQSwNCj4+PiAgICAgIHRoYXQgd2Ug YXJlDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIHRyeWluZyB0bw0KPj4+ICAgICAgID4+PiAgICAg ICAgICAgPj4+Pj4+PiByZWFjaA0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+IHdpdGgg YQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+PiByZXBseSwgaGFzIGFuIGFkZHJlc3Mg dGhhdCBhcHBlYXJzIHRvIHRoZQ0KPj4+ICAgICAgcmVzcG9uZGVyIFgNCj4+PiAgICAgICA+Pj4g ICAgICAgICAgdG8gYmUgcm91dGFibGUuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+ IEJ1dCB0aGUgZGVzdGluYXRpb24gdGhhdCBpcyByZWFjaGVkIGJ5IHRoYXQNCj4+PiAgICAgIGFk ZHJlc3MgaXMNCj4+PiAgICAgICA+Pj4gICAgICAgICAgZWl0aGVyIGEgYmxhY2sNCj4+PiAgICAg ICA+Pj4gICAgICAgICAgID4+Pj4+Pj4gaG9sZSBvcg0KPj4+ICAgICAgID4+PiAgICAgICAgICAg Pj4+Pj4+IHNvbWUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4gb3RoZXIgZW50aXR5 IHVzaW5nIHRoZSBzYW1lIGFkZHJlc3MuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+ DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+IFRoZSByZWFzb24gZm9yIHRoZSBkdXBs aWNhdGlvbiBpcyB0aGF0LCBhcw0KPj4+ICAgICAgZGVzY3JpYmVkIGluDQo+Pj4gICAgICAgPj4+ ICAgICAgICAgIHRoZSBkcmFmdCwNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4gdGhl DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4gc291cmNlDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICA+Pj4+Pj4+IGFkZHJlc3MgZm9yIEEgaXMgYSBwcml2YXRlIGFkZHJlc3MuICBUaGF0 DQo+Pj4gICAgICBzYW1lIGFkZHJlc3MNCj4+PiAgICAgICA+Pj4gICAgICAgICAgbWF5IHdlbGwg YmUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+PiByZWFjaGFibGUNCj4+PiAgICAgICA+ Pj4gICAgICAgICAgID4+Pj4+Pj4gYWNjb3JkaW5nIHRvIHRoZSByb3V0aW5nIHRhYmxlIGF0IFgu ICBCdXQgaXQNCj4+PiAgICAgIHdvbid0IGdldA0KPj4+ICAgICAgID4+PiAgICAgICAgICB0byBB Lg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+Pj4+PiBJZiB0aGUgcHJvYmxlbSBpcyBzb21ldGhpbmcgb3RoZXIgdGhhbg0KPiBwcml2 YXRlDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGFkZHJlc3NpbmcgcHJldmVudGluZw0KPj4+ICAg ICAgID4+PiAgICAgICAgICAgPj4+Pj4+PiByZWFjaGFiaWxpdHksIGl0IGlzIGxpa2VseSB0aGVy ZSBpcyBzdGlsbCBhDQo+Pj4gICAgICBtaXN0YWtlbg0KPj4+ICAgICAgID4+PiAgICAgICAgICBy b3V0YWJpbGl0eQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+PiBwcm9ibGVtLA0KPj4+ ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+IGJ1dCBJIGNhbg0KPj4+ICAgICAgID4+PiAgICAg ICAgICAgPj4+Pj4+PiBub3QgaWxsdXN0cmF0ZSB0aGUgZmFpbHVyZSB3aXRob3V0IHNvbWUgb3Ro ZXINCj4+PiAgICAgIGNhc2UNCj4+PiAgICAgICA+Pj4gICAgICAgICAgYmVpbmcgZGVzY3JpYmVk Lg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+Pj4+PiBZb3VycywNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4gSm9lbA0K Pj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAg Pj4+Pj4+Pj4gT24gMTAvMjEvMTQsIDEwOjA2IFBNLCBMaXpob25nIEppbiB3cm90ZToNCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IElubGluZSwgdGhhbmtzLg0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+Pj4+Pj4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+ Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybg0KPj4+ICAgICAgW21haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tXQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+IFNlbnQ6IDIwMTTE6jEw 1MIyMsjVIDA6MDYNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiBUbzogbGl6aG8u amluQGdtYWlsLmNvbQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+IENjOiBnZW4t YXJ0QGlldGYub3JnOyBtcGxzQGlldGYub3JnOw0KPj4+ICAgICAgaWV0ZkBpZXRmLm9yZzsNCj4+ PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy0N Cj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiByZWxheS1yZXBseS5hbGwNCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIFtHZW4tYXJ0 XSByZXZpZXc6DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctcmVsYXktcmVwbHktMDQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+ Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+IEluIGxpbmUuDQo+Pj4gICAg ICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+ Pj4+Pj4gT24gMTAvMjEvMTQsIDEwOjM2IEFNLCBsaXpoby5qaW5AZ21haWwuY29tDQo+Pj4gICAg ICB3cm90ZToNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+Pj4gSGkgSm9lbCwgc2Vl IGlubGluZSBiZWxvdywgdGhhbmtzLg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+ Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+PiBMaXpob25nDQo+Pj4gICAgICAg Pj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+ Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4+PiAyMDE0LjEwLjIxo6xQTTk6 MzCjrEpvZWwgTS4gSGFscGVybg0KPj4+ICAgICAgID4+PiAgICAgICAgICA8am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+IHdyb3RlIKO6DQo+Pj4gICAg ICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+ Pj4+Pj4+Pj4gSWYgdGhlIHByb2Nlc3MgZm9yIHRoaXMgZHJhZnQgaXMgdG8gdXNlDQo+Pj4gICAg ICB0aGUgdG9wDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGFkZHJlc3MgdGhhdCBjYW4NCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+Pj4+IGJlIHJlYWNoZWQgaW4gdGhlIHJvdXRpbmcg dGFibGUsIHRoZW4NCj4+PiAgICAgIHRoZXJlIGlzIGENCj4+PiAgICAgICA+Pj4gICAgICAgICAg c2lnbmlmaWNhbnQNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+Pj4+IHByb2JhYmls aXR5IHRoYXQgdGhlIG9yaWdpbmFsIHNvdXJjZQ0KPj4+ICAgICAgYWRkcmVzcywgd2hpY2gNCj4+ PiAgICAgICA+Pj4gICAgICAgICAgaXMgYWx3YXlzIGF0DQo+Pj4gICAgICAgPj4+ICAgICAgICAg ICA+Pj4+Pj4+Pj4+PiB0aGUgdG9wIG9mIHRoZSBsaXN0LCB3aWxsIGJlIHVzZWQuICBBcw0KPj4+ ICAgICAgc3VjaCwgdGhlDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGludGVuZGVkIHByb2JsZW0N Cj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+Pj4+IHdpbGwgbm90IGJlIHNvbHZlZC4N Cj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+Pj4gW0xpemhvbmddIGxldCBtZSBnaXZl IGFuIGV4YW1wbGUgdG8NCj4+PiAgICAgIGV4cGxhaW46IHRoZQ0KPj4+ICAgICAgID4+PiAgICAg ICAgICBzb3VyY2UgYWRkcmVzcyBBDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4+ IGlzIGZpcnN0bHkgYWRkZWQgdG8gdGhlIHN0YWNrLCB0aGVuIGENCj4gc2Vjb25kDQo+Pj4gICAg ICAgPj4+ICAgICAgICAgIHJvdXRhYmxlIGFkZHJlc3MgQg0KPj4+ICAgICAgID4+PiAgICAgICAg ICAgPj4+Pj4+Pj4+PiBmb3IgcmVwbHlpbmcgQVMgaXMgYWxzbyBhZGRlZC4gVGhlIHJlcGx5DQo+ Pj4gICAgICBub2RlIHdpbGwNCj4+PiAgICAgICA+Pj4gICAgICAgICAgbm90IHVzZSBhZGRyZXNz DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4+IEEgc2luY2UgaXQncyBub3Qgcm91 dGFibGUsIHRoZW4gaXQgd2lsbA0KPj4+ICAgICAgdXNlIGFkZHJlc3MNCj4+PiAgICAgICA+Pj4g ICAgICAgICAgQi4gU28gaXQgd2lsbA0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+ PiB3b3JrIGFuZCBJIGRvbid0IHNlZSB0aGUgcHJvYmxlbS4NCj4+PiAgICAgICA+Pj4gICAgICAg ICAgID4+Pj4+Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+IFRoZSB3aG9s ZSBwb2ludCBvZiB0aGlzIHJlbGF5IG1lY2hhbmlzbSwgYXMNCj4gSQ0KPj4+ICAgICAgID4+PiAg ICAgICAgICB1bmRlcnN0YW5kIGl0LCBpcyB0bw0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+ Pj4+Pj4+IGNvcGUNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IHdpdGgNCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiB0aGUgY2FzZSB3aGVuIHRoZSByZXNwb25kZXIg WCBjYW4gbm90DQo+Pj4gICAgICBhY3R1YWxseSByZWFjaA0KPj4+ICAgICAgID4+PiAgICAgICAg ICB0aGUgc291cmNlIEEuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4gICAgICBO b3cgc3VwcG9zZSB0aGF0IHRoZSBwYWNrZXQgYXJyaXZlcyBhdA0KPj4+ICAgICAgWCB3aXRoDQo+ Pj4gICAgICAgPj4+ICAgICAgICAgIHRoZSBBZGRyZXNzIHN0YWNrDQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICA+Pj4+Pj4+Pj4gQSwgQiwNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+PiAu Li4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IFgNCj4+PiAgICAgICA+Pj4gICAg ICAgICAgID4+Pj4+Pj4+PiBleGFtaW5lcyB0aGUgc3RhY2suICBUaGUgZG9tYWluIG9mIEEgd2Fz DQo+Pj4gICAgICBudW1iZXJlZA0KPj4+ICAgICAgID4+PiAgICAgICAgICB1c2luZyBuZXQgMTAu DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4gVGhlIGRvbWFpbiBvZiBYIGlzIG51 bWJlcmVkIHVzaW5nIG5ldCAxMC4NCj4gQSdzDQo+Pj4gICAgICAgPj4+ICAgICAgICAgIGFkZHJl c3MgaXMgcHJvYmFibHkNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IHJvdXRhYmxl DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pj4gaW4gWCdzIHJvdXRpbmcgdGFibGUu ICBUaGUgcHJvYmxlbSBpcywgdGhhdA0KPj4+ICAgICAgcm91dGluZw0KPj4+ICAgICAgID4+PiAg ICAgICAgICB3aWxsIG5vdCBnZXQgdG8NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+ PiBBLiAgWA0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4gZXhhbWluZXMNCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiB0aGUgc3RhY2ssIGRldGVybWluZXMgdGhhdCBB IGlzICJyb3V0YWJsZSIsDQo+Pj4gICAgICBhbmQgc2VuZHMNCj4+PiAgICAgICA+Pj4gICAgICAg ICAgdGhlIHBhY2tldC4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+PiBUaGlzDQo+ Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+PiBmYWlscyB0bw0KPj4+ICAgICAgID4+PiAg ICAgICAgICAgPj4+Pj4+Pj4+IG1lZXQgdGhlIGdvYWwuDQo+Pj4gICAgICAgPj4+ICAgICAgICAg ICA+Pj4+Pj4+PiBbTGl6aG9uZ10gVGhlIHNvdXJjZSBBIHlvdSBhcmUgcmVmZXJyaW5nIGlzDQo+ IHRoZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICBpbml0aWF0b3IsIHJpZ2h0Pw0KPj4+ICAgICAg ID4+PiAgICAgICAgICAgPj4+Pj4+Pj4gVGhlIGdvYWwgb2YgcmVsYXkgbWVjaGFuaXNtIGlzIHRv IHJlYWNoIHRoZQ0KPj4+ICAgICAgaW5pdGlhdG9yLg0KPj4+ICAgICAgID4+PiAgICAgICAgICBJ ZiBYIGlzDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+PiByb3V0YWJsZSB0byB0aGUg aW5pdGlhdG9yIChhZGRyZXNzIEEpLCB0aGVuDQo+Pj4gICAgICBpdCBpcw0KPj4+ICAgICAgID4+ PiAgICAgICAgICBncmVhdCwgb3RoZXIgcmVsYXkNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+ Pj4+Pj4+IG5vZGUgaW4gdGhlIHN0YWNrIHdpbGwgYmUgc2tpcHBlZC4NCj4+PiAgICAgICA+Pj4g ICAgICAgICAgID4+Pj4+Pj4+IElmIHRoZSBzb3VyY2UgQSB5b3UgYXJlIHJlZmVycmluZyBpcyB0 aGUNCj4+PiAgICAgIGludGVyZmFjZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICBhZGRyZXNzIG9m IG9uZQ0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4gaW50ZXJtZWRpYXRlIG5vZGUs IHRoZW4gSSBkbyBub3QgdW5kZXJzdGFuZA0KPj4+ICAgICAgInJvdXRpbmcNCj4+PiAgICAgICA+ Pj4gICAgICAgICAgd2lsbCBub3QgZ2V0IHRvDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+ Pj4+PiBBLiAgWCBleGFtaW5lcyB0aGUgc3RhY2ssIGRldGVybWluZXMgdGhhdCBBDQo+IGlzDQo+ Pj4gICAgICAgPj4+ICAgICAgICAgICJyb3V0YWJsZSIsIGFuZCBzZW5kcw0KPj4+ICAgICAgID4+ PiAgICAgICAgICAgPj4+Pj4+Pj4gdGhlDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+ IHBhY2tldCIuDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+PiBXaHkgcm91dGluZyB3 aWxsIG5vdCBnZXQgdG8gQSwgYnV0IEEgaXMNCj4+PiAgICAgIHJvdXRhYmxlPw0KPj4+ICAgICAg ID4+PiAgICAgICAgICAgPj4+Pj4+Pj4NCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+ IFJlZ2FyZHMNCj4+PiAgICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+IExpemhvbmcNCj4+PiAg ICAgICA+Pj4gICAgICAgICAgID4+Pj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+ Pj4+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAg ICAgICAgICA+Pj4+Pj4+Pj4gWW91cnMsDQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+ Pj4gSm9lbA0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+Pj4NCj4+PiAgICAgICA+Pj4g ICAgICAgICAgID4+Pj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+Pj4+Pg0KPj4+ ICAgICAgID4+PiAgICAgICAgICAgPj4+Pj4+DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pj4+ DQo+Pj4gICAgICAgPj4+ICAgICAgICAgICA+Pg0KPj4+ICAgICAgID4+PiAgICAgICAgICAgPg0K Pj4+ICAgICAgID4+Pg0KPj4+ICAgICAgID4NCj4+PiAgICAgICA+DQo+Pj4NCg== ------=_001_NextPart276517356085_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
<= span>Hi Joel,
cc to mpls list as AD requested.
= In your example, only when B, C, D, E with K bit set, then will relay to E= , to D, to C, then to B.
This is the intention of K bit which is= inherited from draft-ietf-mpls-interas-lspping (a mer= ged draft), and when K bit is set, the address will be a relay= node. 
In the draft, it says in section 3.2
"The address with K bit set will always be a relay = node address for the Relayed Echo Reply"

But the= next relay address selection mechanism does need to be updated, which has= led to misunderstanding.
=0A

=0A
=0A
=
Re= gards
Lizhong Jin
 
Date: 2014-10-31 = ;21:54
Subject: Re: update of draft-ietf-mpls-lsp-p= ing-relay-reply-04
That is indeed a different a= lgorithm, and does not depend upon whether
=0A
the K bit is set o= n the origin.
=0A
 
=0A
It does have an important r= esult that is VERY different from your
=0A
earlier algorithm.&nbs= p; It is an acceptable result to me, but you should
=0A
make sure= it is your intention.  The reply will now go back to the
=0Aclosest reliable reverse, rather than the furthest.  So if the LSP = goes
=0A
through ASBRs B, C, D, and E, the earlier algorithm woul= d send a reply
=0A
from F to B to be relayed to the originator.&n= bsp; The new algorithm will
=0A
send a reply to E, to be relayed = to D, thence to C, thence to B, and
=0A
thence to the originator.=   This is far more robust.  But it is a
=0A
dramatic ch= ange in behavior.  I think that such a change really needs
=0Aworking group review and approval.
=0A
 
=0A
You= rs,
=0A
Joel
=0A
 
=0A
On 10/30/14, 11:13 = PM, Lizhong Jin wrote:
=0A
> Hi Joel,
=0A
> It is = not necessary to require to unset K bit for the originator. It is
=0A=
> required for the border node to add address entry with K bit set= , then the
=0A
> Echo Reply could be relayed back.
=0A> Back to the example in section 5, if P1 add non-routable address en= try with=0A
> K bit set, it is OK. ASBR1 will add IP1 with K = bit unset, and IP2 with K bit
=0A
> set in the stack. Then P2/= ASBR2 will first send Echo Reply to ASBR1, then
=0A
> ASBR1 se= nd Echo Reply to P1. Even if the non-routable P1 address is also
=0A<= div>> routable in AS2, the node in AS2 will still select ASBR1 as the n= ext relay=0A
> node.
=0A
>
=0A
> I r= ead section 4.3 again, and not correctly use word "first", and lead your=0A
> misunderstanding:
=0A
> OLD:
=0A
>= ; To find out the next relay node address, the node SHOULD check the
= =0A
>     address items in Relay Node Address S= tack TLV in sequence from top to
=0A
>    = down, and find the first IP routable address, e.g., A, and the first=0A
>     address with K bit set, e.g., B.=0A
> NEW:
=0A
> To find out the next relay node addr= ess, the node SHOULD check the
=0A
>     a= ddress items in Relay Node Address Stack TLV in sequence from top to
= =0A
>     down, and find the first IP routable = address, e.g., A, and the last
=0A
>     a= ddress with K bit set, e.g., B.
=0A
>
=0A
> Regar= ds
=0A
> Lizhong
=0A
>
=0A
>> ----= -Original Message-----
=0A
>> From: Joel Halpern Direct [ma= ilto:jmh.direct@joelhalpern.com]
=0A
>> Sent: 2014=C4=EA10= =D4=C231=C8=D5 0:10
=0A
>> To: Lizhong Jin; Carlos Pignatar= o (cpignata);
=0A
> draft-ietf-mpls-lsp-ping-relay-
=0A>> reply
=0A
>> Cc: adrian; loa; Jari Arkko
= =0A
>> Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-rep= ly-04
=0A
>>
=0A
>> Not quite:
=0A
= >>
=0A
>> 1) You still have not fixed 4.2.  So i= f the originator puts on its address
=0A
> with the
=0A>> K bit unset, the entry will be removed.  But in order to = make the rest of
=0A
> your
=0A
>> logic work, = the originator whose address is not reachable needs to put on
=0A> the
=0A
>> entry with the k bit unset.
=0A
&= gt;>
=0A
>> 2) The case I wanted added in section 5 was = when P1, the request
=0A
> originator,
=0A
>> h= as a non-routable address.  Then when it originates the request, it h= as
=0A
> to
=0A
>> provide a stack with its own= address with the K bit unset.  Otherwise the
=0A
> rest<= /div>=0A
>> of the logic won't work.
=0A
>>
= =0A
>> Yours,
=0A
>> Joel
=0A
>>=0A
>> On 10/30/14, 11:31 AM, Lizhong Jin wrote:
=0A>>> Hi Joel,
=0A
>>> Thanks for the comments,= I made the following changing. Please check
=0A
>>> if = they are confortable for you.
=0A
>>>
=0A
>&= gt;> In Section 3.2:
=0A
>>> Delete: How a node deter= mines to set the K bit is outside the scope of
=0A
>>> t= his document.
=0A
>>> Add: One application scenario of K= bit is given out in section 5.
=0A
>>>
=0A
>= ;>> In Section 4.3:
=0A
>>> Add: If there is no B = existed, then use A as the next relay node
=0A
> address.=0A
>>>
=0A
>>> In section 5:
=0A>>> Add: In the case that the interface address of ASBR1 to P1 i= s IP1
=0A
>>> which maybe an IPv4 private address and no= t IP routable for AS2, and
=0A
>>> the loopback address = on ASRB1 is IP2 which is routable for AS2. Then
=0A
>>> = when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1 without=0A
>>> K bit set in the Relay Node Address Stack TLV, and = then add
=0A
>>> IP2 with K bit set in the stack TLV. Th= en ASBR2/P2 could relay the
=0A
>>> Relayed Echo Reply b= ack first to IP2 which is routable for ASBR2/P2,
=0A
>>>= then ASBR1 will send Echo Reply to PE1. Thanks for the K bit, the
= =0A
>>> ASBR1 will not be skipped for message relay.
=0A=
>>>
=0A
>>> ------------------------------= ----------------------------------------
=0A
>>> --=0A
>>> Regards
=0A
>>> Lizhong Jin
= =0A
>>>
=0A
>>>    &nbs= p; *From:* Joel M. Halpern <mailto:jmh@joelhalpern.com>
=0A>>>      *Date:* 2014-10-30 11:15
= =0A
>>>      *To:* Lizhong Jin <m= ailto:lizho.jin@gmail.com>; 'Carlos Pignataro
=0A
>>>=       (cpignata)' <mailto:cpignata@cisco.com&g= t;;
=0A
>>>      'draft-ietf-mp= ls-lsp-ping-relay-reply'
=0A
>>>    =   <mailto:draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org><= /div>=0A
>>>      *CC:* 'adrian' <= ;mailto:adrian@olddog.co.uk>; 'loa'
=0A
>>> &nbs= p;    <mailto:loa@pi.nu>; Jari Arkko <mailto:jari.= arkko@piuha.net>
=0A
>>>     = ; *Subject:* Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
= =0A
>>>      As I tried to say in my= previous reply, your solution to sources who
=0A
> are
= =0A
>>>      not reachable, but for = which the routing table may claim
=0A
> reachability
=0A<= div>>>>      (due to private address dup= lication or firewalling of sub-blocks
=0A
> within
=0A>>>      an advertised region, or...) = seems to depend both upon such sources
=0A
> not
=0A
= >>>      setting the k bit in their (fir= st) entry, and on such entries
=0A
> surviving
=0A
&g= t;>>      the intermediate processing.=0A
>>>      Given that this is cen= tral to the purpose of the draft, the bit
=0A
> setting
= =0A
>>>      really needs to be desc= ribed.  And given that this preservation
=0A
>>>&nb= sp;     contradicts current text, it must be spelled o= ut.
=0A
>>>      Yours,
= =0A
>>>      Joel
=0A
>&= gt;>      On 10/29/14, 10:28 PM, Lizhong Jin w= rote:
=0A
>>>       > H= i Joel,
=0A
>>>       >= Thank you for the prompt reply.
=0A
>>>  &nbs= p;    >
=0A
>>>    = ;   > The scenario you raised could be solved by setting K bi= t for a
=0A
>>>      routable=0A
>>>       > address.= Let me give you the detail.
=0A
>>>   &n= bsp;   > PE1----P1----ASBR1-----ASBR2-----P2-----PE2
=0A=
>>>       > The initiator i= s PE1, and the interface address of ASBR1 to P1 is
=0A
>>&g= t;      Addr1
=0A
>>> &nbs= p;     > which maybe a private address, and the rou= table address on ASRB1
=0A
>>>    &n= bsp; is Addr2.
=0A
>>>     &nbs= p; > Then when ASBR1 send a relayed echo reply, it will firstly add=0A
>>>      Addr1 in the
=0A=
>>>       > stack, and then= add Addr2 with K bit set in the stack.
=0A
>>> &nb= sp;     > Then P2 could relay the echo reply back f= irst to Addr2, then
=0A
>>>     = ; Addr1 by ASBR1.
=0A
>>>     &= nbsp; >
=0A
>>>       &= gt; I consider above as an application case of K bit, so I did not
= =0A
>>>      give out the
=0A>>>       > detail. But I cou= ld add some text about above example in section
=0A
>>>&= nbsp;     5 if you
=0A
>>> &nbs= p;     > insist.
=0A
>>> &nb= sp;     > In the document, it says:
=0A
&g= t;>>       > Some nodes could be co= nfigured to always set the K bit,
=0A
>>>  &nb= sp;    >     or the module handling = MPLS echo requests could discover its
=0A
>>>  = ;    K bit
=0A
>>>    = ;   >     use through topology awareness.=   How a node determines to set
=0A
>>>  &= nbsp;   the K
=0A
>>>    &= nbsp;  >     bit is outside the scope of this = document.
=0A
>>>       &g= t;
=0A
>>>       > But = I forget to add the sentence in section 4.2 which I promise
=0A
&= gt;>>      to Carlos to
=0A
>&g= t;>       > add:
=0A
>>= >       > A second or more address ent= ries could also be added if
=0A
>>>   &nb= sp;  necessary, which
=0A
>>>   &nbs= p;   > depends on implementation.
=0A
>>>&n= bsp;      >
=0A
>>> &nb= sp;     > Regards
=0A
>>> &n= bsp;     > Lizhong
=0A
>>> &= nbsp;     >
=0A
>>>  &n= bsp;    >
=0A
>>>   &nb= sp;   >> -----Original Message-----
=0A
>>&= gt;       >> From: Joel M. Halpern [ma= ilto:jmh@joelhalpern.com]
=0A
>>>    = ;   >> Sent: 2014=C4=EA10=D4=C230=C8=D5 0:24
=0A
= >>>       >> To: Lizhong Jin;= Carlos Pignataro (cpignata);
=0A
>>>   &= nbsp;   > draft-ietf-mpls-lsp-ping-relay-
=0A
>&g= t;>       >> reply
=0A
>= ;>>       >> Cc: adrian; loa=0A
>>>       >> Subjec= t: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
=0A
>= >>       >>
=0A
>>= ;>       >> This revision does not = seem to address my comments from October
=0A
>>> &n= bsp;    24.  The
=0A
>>>  =      >> assumption that sources will set K in ce= rtain ways is still
=0A
>>>     = ; implici rather
=0A
>>>     &n= bsp; > than
=0A
>>>     &nbs= p; >> explicit, as far as I can tell.
=0A
>>> = ;      >>
=0A
>>> &n= bsp;     >> More importantly, if sources do not = set the K bit on their own
=0A
> stack
=0A
>>&g= t;       > entry, so
=0A
>>= ;>       >> as to enable the improv= ed relay selection logic to work, then
=0A
>>> &nbs= p;    the soure
=0A
>>>   =     > entry
=0A
>>>   &= nbsp;   >> will be removed by the logic in 4.2.
=0A>>>       >>
=0A
= >>>       >> Yours,
=0A<= div>>>>       >> Joel
= =0A
>>>       >>
=0A=
>>>       >> PS: Here is= the body of what I wrote on the 24th:
=0A
>>> &nbs= p;     >>
=0A
>>>  &= nbsp;    >> We are getting close.
=0A
>&g= t;>       >> I believe that the int= ent is that if a node has reason to
=0A
>>>  &= nbsp;   believe that its
=0A
>>>  &n= bsp;    > address
=0A
>>>  &= nbsp;    >> will be NATed or firewalled at the domain= edge, then it should
=0A
>>>    &nb= sp; put in its
=0A
>>>     &nbs= p; >> address, but not set the K bit.
=0A
>>> = ;      >> If the originator does this, then= other folks within his domain
=0A
> will
=0A
>>= ;>       > respond
=0A
>&g= t;>       >> directly, while anyone= past the domain edge will relay to the
=0A
>>> &nb= sp;    border node,
=0A
>>>  &n= bsp;    >> who will set the K bit.
=0A
>&= gt;>       >>
=0A
>>= >       >> If that is the intent, t= hen there are two things that are
=0A
> needed:
=0A
&= gt;>>       >> 1) We need to act= ually say that, and not leave the implementor
=0A
>>>&nb= sp;     guessing.
=0A
>>>  = ;     >> 2) In section 4.2 it needs to be noted = that the originator
=0A
>>>     = ; address must
=0A
>>>     &nbs= p; > not be
=0A
>>>     &nbs= p; >> removed even if the K bit is not set on that address.
=0A=
>>>       >>
=0A>>>       >> On 10/29/14, 1= 1:17 AM, Lizhong Jin wrote:
=0A
>>>   &nb= sp;   >>> Hi, all,
=0A
>>>  = ;     >>> The cut-off time of draft submissio= n has been passed. I will
=0A
> upload
=0A
>>&g= t;       >>> the new version once i= t is reopened.
=0A
>>>     &nbs= p; >>> Please check if the new version is OK for you all. Thank y= ou.
=0A
>>>       >>= >
=0A
>>>       >>= ;>
=0A
>>>
=0A
> ------------------------= ----------------------------------------------
=0A
>>>&n= bsp;      >>> --
=0A
>>&g= t;       >>> Regards
=0A
&= gt;>>       >>> Lizhong Jin=0A
>>>       >>><= /div>=0A
>>>       >>>=       *=B7=A2=BC=FE=C8=CB=A3=BA* Lizhong Jin <= mailto:lizho.jin@gmail.com>
=0A
>>>   =     >>>      *=B7=A2=CB= =CD=CA=B1=BC=E4=A3=BA* 2014-10-25 00:03
=0A
>>> &nb= sp;     >>>      *= =CA=D5=BC=FE=C8=CB=A3=BA* jmh <mailto:jmh@joelhalpern.com>; loa=0A
>>>       >> <mai= lto:loa@pi.nu>;
=0A
>>>     =   >>>      Carlos Pignataro (cpigna= ta) <mailto:cpignata@cisco.com>
=0A
>>>  = ;     >>>      *=B3= =AD=CB=CD=A3=BA* draft-ietf-mpls-lsp-ping-relay-reply
=0A
>>= ;>       >>>
=0A
> &= lt;mailto:draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org>
=0A=
>>>       >>> &n= bsp;    *=D6=F7=CC=E2=A3=BA* update of draft-ietf-mpls-lsp-= ping-relay-reply-04
=0A
>>>     = ;  >>>      Hi Joel, Carlos
= =0A
>>>       >>> = ;     The new version attached is sending to you for=0A
>>>      confirmation, befor= e
=0A
>>>       >>&g= t;      publishing. Thank you again for your comm= ents.
=0A
>>>       >&g= t;>
=0A
>>>       >&= gt;>
=0A
>>>       >=
=0A
>>>
=0A
> -----------------------------= -------------------------------------------
=0A
>>> = ;      >>>     = Regards
=0A
>>>       >= ;>>      Lizhong Jin
=0A
>>&= gt;       >>>
=0A
>>= >       >>>   &nb= sp;      *=B7=A2=BC=FE=C8=CB=A3=BA* Joel M. Halpe= rn
=0A
> <mailto:jmh@joelhalpern.com>
=0A
>&= gt;>       >>>   =        *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2014= -10-23 22:25
=0A
>>>      = >>>          *=CA= =D5=BC=FE=C8=CB=A3=BA* Loa Andersson <mailto:loa@pi.nu>;
=0A>>>      lizho.jin@gmail.com
=0A<= div>>>>       >>> &nb= sp;        <mailto:lizho.jin@gmail.c= om>
=0A
>>>       >&= gt;>          *=D6=F7=CC= =E2=A3=BA* Re: [mpls] [Gen-art] review:
=0A
>>> &nb= sp;     >>>     &nbs= p;    draft-ietf-mpls-lsp-ping-relay-reply-04
=0A
= >>>       >>>  &= nbsp;       It has converged to the degree t= hat Lizhong believes
=0A
>>>    &nbs= p; he can make
=0A
>>>     &nbs= p; > the
=0A
>>>       = >>>          changes= needed to address my concerns.  I believe he
=0A
>>&g= t;      understands
=0A
>>>&nbs= p;      > the
=0A
>>> &= nbsp;     >>>     &n= bsp;    concerns.  I do not understand some of the imp= ortant
=0A
>>>      aspects of<= /div>=0A
>>>       > his=0A
>>>       >>>&nb= sp;         proposal, but look for= ward to seeing the draft.
=0A
>>>    = ;   >>>        =   Yours,
=0A
>>>      = ; >>>          Joel<= /div>=0A
>>>       >>>=           On 10/23/14, 10:17 = AM, Loa Andersson wrote:
=0A
>>>    =    >>>        &= nbsp;  > Lizhong and Joel,
=0A
>>>  &n= bsp;    >>>      &nb= sp;    >
=0A
>>>   &nbs= p;   >>>        = ;   > Should I interpret this as that the discussion has=0A
>>>      converged
=0A>>>       > on a
=0A
&= gt;>>       >>>  &n= bsp;        > solution that you both= are comfortable with?
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >
=0A
>>>     &nbs= p; >>>          = ; > /Loa
=0A
>>>       = >>>           &= gt;
=0A
>>>       >>= >           > On 2= 014-10-22 16:05, lizho.jin@gmail.com wrote:
=0A
>>> = ;      >>>     =       >> Joel, thank you for the review. We= will send out a
=0A
> new
=0A
>>> &nbs= p;     >>>      = ;    version soon to reflect the discussion.
=0A
&= gt;>>       >>>  &n= bsp;        >>
=0A
>&= gt;>       >>>   =         >> Regards
=0A
&= gt;>>       >>>  &n= bsp;        >> Lizhong
=0A>>>       >>> &nbs= p;         >>
=0A
&= gt;>>       >>>  &n= bsp;        >>
=0A
>&= gt;>       >>>   =         >>
=0A
>>&= gt;       >>>   &nbs= p;       >>> =D4=DA 2014=C4=EA10=D4= =C222=C8=D5=A3=AC=CF=C2=CE=E79:30=A3=ACJoel Halpern Direct
=0A
&g= t;>>       >>>  &nb= sp;       <jmh.direct@joelhalpern.com>= wrote=A3=BA
=0A
>>>      = >>>           = >>>
=0A
>>>      = >>>           = >>> It would be good to see a revision that clearly
=0A
= >>>      spelled out
=0A
>&g= t;>       >>>   &= nbsp;      what the
=0A
>>>&nbs= p;      >>>     = ;      >>> draft was solving, how the in= itial end-point knew
=0A
>>>    &nbs= p; what to
=0A
>>>       &= gt;>>          create, = and
=0A
>>>       >>= >           >>&= gt; how the responder knew what to use.  It may well
=0A
>= ;>>      be that
=0A
>>>&= nbsp;      >>>    &n= bsp;     there is an
=0A
>>> &n= bsp;     >>>     &nb= sp;     >>> effective solution to the problem= s here.  I look
=0A
>>>    &nbs= p; forward to
=0A
>>>      = ; >>>          seein= g it in
=0A
>>>       >= >>           >&= gt;> writing.
=0A
>>>     &n= bsp; >>>         &nb= sp; >>>
=0A
>>>     &n= bsp; >>>         &nb= sp; >>> Yours,
=0A
>>>    &= nbsp;  >>>        &n= bsp;  >>> Joel
=0A
>>>   &n= bsp;   >>>       &nb= sp;   >>>
=0A
>>>   &n= bsp;   >>>       &nb= sp;   >>>> On 10/22/14, 12:46 AM, Lizhong Jin wrote:=
=0A
>>>       >>>= ;           >>>= > Hi Joel,
=0A
>>>      = ; >>>          = >>>> The things may not be that bad. You could add a
=0A=
>>>      second
=0A
>&g= t;>       >>>   &= nbsp;      address (address B in
=0A
>= ;>>       >>>  &nbs= p;        >>>> our example)= with K bit set. The address entry
=0A
>>>  &n= bsp;   with K bit
=0A
>>>   &nb= sp;   >>>       &nbs= p;  set must be as a
=0A
>>>    = ;   >>>        =    >>>> relay node, and could not be skipped.
= =0A
>>>       >>> = ;          >>>> S= ection 4.4 should be changed to: Find the first
=0A
>>>&= nbsp;     routable
=0A
>>> &nbs= p;     >>>      = ;    address A, and the
=0A
>>> &nbs= p;     >>>      = ;     >>>> first address B with K bit set.= If address A is
=0A
>>>      b= efore
=0A
>>>       >&g= t;>          address B in = the
=0A
>>>       >>= >           >>&= gt;> stack, then use address B as the relay address.
=0A
>&= gt;>      Otherwise,
=0A
>>>=        >>>    &= nbsp;     use address A as
=0A
>>>&n= bsp;      >>>    &nb= sp;      >>>> the relay address.=0A
>>>       >>>&nbs= p;          >>>> = In that case, if A is the private address, the
=0A
>>>&n= bsp;     packet will
=0A
>>> &n= bsp;     >>>     &nb= sp;    be firstly
=0A
>>>  &nbs= p;    >>>       = ;    >>>> relayed to address B. And address A a= nd B belong
=0A
>>>      to one=
=0A
>>>       >>>= ;          router. Here I=0A
>>>       >>>&nb= sp;          >>>>= assume one router at least has one routable
=0A
>>>&nbs= p;     address for
=0A
>>> &nbs= p;     >>>      = ;    another AS.
=0A
>>>   = ;    >>>       =     >>>>
=0A
>>>  &= nbsp;    >>>      &n= bsp;    >>>> Regards
=0A
>>>&= nbsp;      >>>    &n= bsp;      >>>> Lizhong
=0A
&= gt;>>       >>>  &n= bsp;        >>>>
=0A>>>       >>> &nbs= p;         >>>>> --= ---Original Message-----
=0A
>>>    =    >>>        &= nbsp;  >>>>> From: Joel M. Halpern
=0A
> [= mailto:jmh@joelhalpern.com]
=0A
>>>   &nb= sp;   >>>       &nbs= p;   >>>>> Sent: 2014=C4=EA10=D4=C222=C8=D5 11:14=
=0A
>>>       >>>= ;           >>>= >> To: Lizhong Jin
=0A
>>>    =    >>>        &= nbsp;  >>>>> Cc: gen-art@ietf.org; mpls@ietf.org; ietf= @ietf.
=0A
> org;
=0A
>>>   &= nbsp;   >>>       &n= bsp;   >>>> 'draft-ietf-mpls-lsp-ping-
=0A
= >>>       >>>  &= nbsp;        >>>>> relay= -reply.all'
=0A
>>>       = >>>           &= gt;>>>> Subject: Re: [mpls] [Gen-art] review:
=0A
>= ;>>       >>>  &nbs= p;        >>>> draft-ietf-m= pls-lsp-ping-relay-reply-04
=0A
>>>   &nb= sp;   >>>       &nbs= p;   >>>>>
=0A
>>>  &= nbsp;    >>>      &n= bsp;    >>>>> ou are saying that this is onl= y for the case
=0A
>>>      whe= re an AS
=0A
>>>       >= ;>>          is using p= ublic
=0A
>>>       >&g= t;>           >>= ;>>> addresses for its internal numbering, but is
=0A
&g= t; not
=0A
>>>       >&= gt;>          distributing= that address
=0A
>>>      = ; >>>          = >>>> block
=0A
>>>    &= nbsp;  >>>        &n= bsp;  >>>>> externally?
=0A
>>> = ;      >>>     =       >>>>>
=0A
>>&= gt;       >>>   &nbs= p;       >>>>> If so, you nee= d to state that very clearly.
=0A
>>>   &= nbsp;   >>>       &n= bsp;   >>>>> I believe a far more common case is = one where
=0A
> the
=0A
>>>   = ;    >>>       =    numbering is from a
=0A
>>>  &nbs= p;    >>>       = ;    >>>>> portion of a publicly allocated s= pace, but
=0A
>>>      firewall= ed.
=0A
>>>       >>= >          Which would=0A
>>>       >>>&nb= sp;          >>>>= produce
=0A
>>>       >= ;>>           >= >>>> the same problem, but would not be amenable to
=0A> this
=0A
>>>      = > solution.
=0A
>>>     &nb= sp; >>>         &nbs= p; >>>>> And it is well known that many ISPs do internal=0A
>>>      number
=0A
= >>>       >>>  &= nbsp;       assignment from
=0A
>= ;>>       >>>  &nbs= p;        >>>>> private = blocks.
=0A
>>>       >= >>           >&= gt;>>>
=0A
>>>     &nb= sp; >>>         &nbs= p; >>>>> So what you are now saying is that this draft=0A
>>>      solves a
=0A
= >>>       >>>  &= nbsp;       very small portion
=0A
= >>>       >>>  &= nbsp;        >>>> of the=0A
>>>       >>>&n= bsp;          >>>>= ;> problem?  But it works for that small portion?
=0A
>= ;>>      If so, at
=0A
>>>= ;       >>>    =       the very least
=0A
>>>&nb= sp;      >>>    &nbs= p;      >>>> you
=0A
>>= ;>       >>>   &n= bsp;       >>>>> need to be V= ERY clear about what cases this
=0A
>>>   = ;   works for and
=0A
>>>   &nb= sp;   >>>       &nbs= p;  what cases it
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >>>> does
=0A
>>>   = ;    >>>       =     >>>>> not.  And I fear that even if= you are clear, it
=0A
>>>     = is going
=0A
>>>       &g= t;>>          to be ver= y
=0A
>>>       >>&g= t;           >>>= ;> confusing for
=0A
>>>     = ;  >>>         =   >>>>> folks who are trying to use it.
=0A
&= gt;>>       >>>  &n= bsp;        >>>>>
= =0A
>>>       >>> = ;          >>>>&g= t; Yours,
=0A
>>>       &g= t;>>           >= ;>>>> Joel
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >>>>>
=0A
>>>   =     >>>       &= nbsp;   >>>>>> On 10/21/14, 10:51 PM, Lizhong = Jin wrote:
=0A
>>>       &= gt;>>           &g= t;>>>>> Hi Joel,
=0A
>>>   = ;    >>>       =     >>>>>> I now see your concern. The "p= rivate" word in
=0A
>>>      dr= aft is
=0A
>>>       >&= gt;>          not correct,= I
=0A
>>>       >>&= gt;           >>&g= t;>>> will remove it. The original motivation of
=0A
>= ;>>       >>>  &nbs= p;       "draft-relay-reply" is from
= =0A
>>>       >>> = ;          >>>>&g= t;> the scenario where IP address distribution is
=0A
>>= >      restricted
=0A
>>>&nb= sp;      >>>    &nbs= p;     among AS or IGP
=0A
>>> =       >>>     &= nbsp;     >>>>> area.
=0A
>= >>       >>>   = ;        >>>>>> And t= he IP address is not private address. As
=0A
>>> &n= bsp;    I know,
=0A
>>>   =     >>>       &= nbsp;  most deployed
=0A
>>>    = ;   >>>        =    >>>>>> inter-AS or inter-area MPLS LSP is i= n the
=0A
> network
=0A
>>>   = ;    >>>       =    without private IP
=0A
>>>   = ;    >>>       =     >>>> address.
=0A
>>>&nbs= p;      >>>     = ;      >>>>>>
=0A
>= >>       >>>   = ;        >>>>>> Regar= ds
=0A
>>>       >>&= gt;           >>&g= t;>>> Lizhong
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >>>>>>
=0A
>>>  &n= bsp;    >>>      &nb= sp;    >>>>>>
=0A
>>>&n= bsp;      >>>    &nb= sp;      >>>>>>> -----Origin= al Message-----
=0A
>>>     &nb= sp; >>>         &nbs= p; >>>>>>> From: Joel M. Halpern
=0A
>>= ;>      [mailto:jmh@joelhalpern.com]
=0A<= div>>>>       >>> &nb= sp;         >>>>>&g= t;> Sent: 2014=C4=EA10=D4=C222=C8=D5 10:15
=0A
>>>&nb= sp;      >>>    &nbs= p;      >>>>>>> To: Lizhong = Jin
=0A
>>>       >>= >           >>&= gt;>>>> Cc: gen-art@ietf.org; mpls@ietf.org;
=0A
>= >>      ietf@ietf.org;
=0A
>>= ;>       >>>   &n= bsp;       >>>>>> 'draft-i= etf-mpls-lsp-ping-
=0A
>>>     =   >>>         &= nbsp; >>>>>>> relay-reply.all'
=0A
>>&= gt;       >>>   &nbs= p;       >>>>>>> Subjec= t: Re: [mpls] [Gen-art] review:
=0A
>>>   = ;    >>>       =     >>>>>> draft-ietf-mpls-lsp-ping-relay= -reply-04
=0A
>>>       &g= t;>>           >= ;>>>>>>
=0A
>>>    = ;   >>>        =    >>>>>>> The problem is that the original= source A,
=0A
>>>      that we= are
=0A
>>>       >>= ;>          trying to=0A
>>>       >>>&nbs= p;          >>>>&= gt;>> reach
=0A
>>>     &= nbsp; >>>         &n= bsp; >>>>>> with a
=0A
>>>  =      >>>      &= nbsp;    >>>>>>> reply, has an address= that appears to the
=0A
>>>    &nbs= p; responder X
=0A
>>>     &nbs= p; >>>          to b= e routable.
=0A
>>>       = >>>           &= gt;>>>>>> But the destination that is reached by that=0A
>>>      address is
=0A<= div>>>>       >>> &nb= sp;        either a black
=0A
= >>>       >>>  &= nbsp;        >>>>>>&g= t; hole or
=0A
>>>       &= gt;>>           &g= t;>>>>> some
=0A
>>>   &nb= sp;   >>>       &nbs= p;   >>>>>>> other entity using the same ad= dress.
=0A
>>>       >&= gt;>           >&g= t;>>>>>
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >>>>>>> The reason for the duplication is t= hat, as
=0A
>>>      described = in
=0A
>>>       >>&= gt;          the draft,
= =0A
>>>       >>> = ;          >>>>&g= t;>> the
=0A
>>>     &nbs= p; >>>          = ; >>>>>> source
=0A
>>>  &nb= sp;    >>>      &nbs= p;    >>>>>>> address for A is a priva= te address.  That
=0A
>>>    &n= bsp; same address
=0A
>>>     &= nbsp; >>>          m= ay well be
=0A
>>>       &= gt;>>           &g= t;>>>>> reachable
=0A
>>>  &nbs= p;    >>>       = ;    >>>>>>> according to the routing = table at X.  But it
=0A
>>>    =   won't get
=0A
>>>     &n= bsp; >>>          to= A.
=0A
>>>       >>= >           >>&= gt;>>>>
=0A
>>>     = ;  >>>         =   >>>>>>> If the problem is something other than=
=0A
> private
=0A
>>>   &nbs= p;   >>>        = ;  addressing preventing
=0A
>>>   &= nbsp;   >>>       &n= bsp;   >>>>>>> reachability, it is likely t= here is still a
=0A
>>>      mi= staken
=0A
>>>       >&= gt;>          routability<= /div>=0A
>>>       >>>=            >>>&= gt;>>> problem,
=0A
>>>    =    >>>        &= nbsp;  >>>>>> but I can
=0A
>>>&n= bsp;      >>>    &nb= sp;      >>>>>>> not illustr= ate the failure without some other
=0A
>>>  &n= bsp;   case
=0A
>>>    &nb= sp;  >>>        &nbs= p; being described.
=0A
>>>     = ;  >>>         =   >>>>>>>
=0A
>>>  &= nbsp;    >>>      &n= bsp;    >>>>>>> Yours,
=0A
&g= t;>>       >>>  &nb= sp;        >>>>>>>= Joel
=0A
>>>       >&g= t;>           >>= ;>>>>>
=0A
>>>    &nb= sp;  >>>        &nbs= p;  >>>>>>>> On 10/21/14, 10:06 PM, Lizhong J= in wrote:
=0A
>>>       &g= t;>>           >= ;>>>>>>> Inline, thanks.
=0A
>>>&nb= sp;      >>>    &nbs= p;      >>>>>>>>
=0A=
>>>       >>> &n= bsp;         >>>>>&= gt;>>> -----Original Message-----
=0A
>>> =       >>>     &= nbsp;     >>>>>>>>> From: J= oel M. Halpern
=0A
>>>      [ma= ilto:jmh@joelhalpern.com]
=0A
>>>    = ;   >>>        =    >>>>>>>>> Sent: 2014=C4=EA10=D4=C2= 22=C8=D5 0:06
=0A
>>>      = ; >>>          = >>>>>>>>> To: lizho.jin@gmail.com
=0A>>>       >>>  =          >>>>>>&= gt;>> Cc: gen-art@ietf.org; mpls@ietf.org;
=0A
>>>=       ietf@ietf.org;
=0A
>>>&nb= sp;      >>>    &nbs= p;      >>>>>>>> draft-ie= tf-mpls-lsp-ping-
=0A
>>>     &= nbsp; >>>         &n= bsp; >>>>>>>>> relay-reply.all
=0A
>= ;>>       >>>  &nbs= p;        >>>>>>>&= gt;> Subject: Re: [mpls] [Gen-art] review:
=0A
>>>&nb= sp;      >>>    &nbs= p;      >>>>>>>> draft-ie= tf-mpls-lsp-ping-relay-reply-04
=0A
>>>   = ;    >>>       =     >>>>>>>>>
=0A
>&= gt;>       >>>   =         >>>>>>>>= ;> In line.
=0A
>>>     &nbs= p; >>>          = ; >>>>>>>>>
=0A
>>> &nbs= p;     >>>      = ;     >>>>>>>>>> On 10/2= 1/14, 10:36 AM, lizho.jin@gmail.com
=0A
>>>  &= nbsp;   wrote:
=0A
>>>    =    >>>        &= nbsp;  >>>>>>>>>> Hi Joel, see inline b= elow, thanks.
=0A
>>>      = ; >>>          = >>>>>>>>>>
=0A
>>> &= nbsp;     >>>     &n= bsp;     >>>>>>>>>> Lizh= ong
=0A
>>>       >>= >           >>&= gt;>>>>>>>
=0A
>>>   = ;    >>>       =     >>>>>>>>>>
=0A
&= gt;>>       >>>  &n= bsp;        >>>>>>>= ;>>>> 2014.10.21=A3=ACPM9:30=A3=ACJoel M. Halpern
=0A>>>       >>>  =         <jmh@joelhalpern.com>=0A
>>>       >>>&nb= sp;          >>>>= > wrote =A3=BA
=0A
>>>     &= nbsp; >>>         &n= bsp; >>>>>>>>>>>
=0A
>>>= ;       >>>    =        >>>>>>>>>&= gt;> If the process for this draft is to use
=0A
>>>&= nbsp;     the top
=0A
>>>  = ;     >>>      =     address that can
=0A
>>>  &= nbsp;    >>>      &n= bsp;    >>>>>>>>>>> be rea= ched in the routing table, then
=0A
>>>   = ;   there is a
=0A
>>>    =    >>>        &= nbsp; significant
=0A
>>>     &= nbsp; >>>         &n= bsp; >>>>>>>>>>> probability that the ori= ginal source
=0A
>>>      addre= ss, which
=0A
>>>       &g= t;>>          is always= at
=0A
>>>       >>= >           >>&= gt;>>>>>>>> the top of the list, will be used.&nbs= p; As
=0A
>>>      such, the=0A
>>>       >>>&n= bsp;         intended problem=0A
>>>       >>>&nbs= p;          >>>>&= gt;>>>>>> will not be solved.
=0A
>>>&= nbsp;      >>>    &n= bsp;      >>>>>>>>>>= ; [Lizhong] let me give an example to
=0A
>>>  = ;    explain: the
=0A
>>>  &nbs= p;    >>>       = ;   source address A
=0A
>>>   =     >>>       &= nbsp;   >>>>>>>>>> is firstly adde= d to the stack, then a
=0A
> second
=0A
>>>&= nbsp;      >>>    &n= bsp;     routable address B
=0A
>>>&= nbsp;      >>>    &n= bsp;      >>>>>>>>>>= ; for replying AS is also added. The reply
=0A
>>> =      node will
=0A
>>>  &n= bsp;    >>>      &nb= sp;   not use address
=0A
>>>   = ;    >>>       =     >>>>>>>>>> A since it's n= ot routable, then it will
=0A
>>>    = ;  use address
=0A
>>>     = ;  >>>         = B. So it will
=0A
>>>     &nbs= p; >>>          = ; >>>>>>>>>> work and I don't see the proble= m.
=0A
>>>       >>&= gt;           >>&g= t;>>>>>>
=0A
>>>   &nbs= p;   >>>        = ;   >>>>>>>>> The whole point of this= relay mechanism, as
=0A
> I
=0A
>>> &n= bsp;     >>>     &nb= sp;    understand it, is to
=0A
>>> =       >>>     &= nbsp;     >>>>>>>>> cope=0A
>>>       >>>&n= bsp;          >>>>= ;>>>> with
=0A
>>>    &n= bsp;  >>>        &nb= sp;  >>>>>>>>> the case when the responder= X can not
=0A
>>>      actuall= y reach
=0A
>>>       >= >>          the source = A.
=0A
>>>       >>&= gt;           >>&g= t;>>>>>>      Now suppose that = the packet arrives at
=0A
>>>    &nb= sp; X with
=0A
>>>       &= gt;>>          the Addr= ess stack
=0A
>>>       &g= t;>>           >= ;>>>>>>>> A, B,
=0A
>>> &nb= sp;     >>>     &nbs= p;     >>>>>> ...
=0A
>&= gt;>       >>>   =         >>>>>>>>= ; X
=0A
>>>       >>= >           >>&= gt;>>>>>> examines the stack.  The domain of A was<= /div>=0A
>>>      numbered
=0A<= div>>>>       >>> &nb= sp;        using net 10.
=0A
&= gt;>>       >>>  &n= bsp;        >>>>>>>= ;>> The domain of X is numbered using net 10.
=0A
> A's<= /div>=0A
>>>       >>>=           address is probably=
=0A
>>>       >>>= ;           >>>= >>>>> routable
=0A
>>>   &= nbsp;   >>>       &n= bsp;   >>>>>>>>> in X's routing table= .  The problem is, that
=0A
>>>   &n= bsp;  routing
=0A
>>>     =   >>>          = will not get to
=0A
>>>     &nb= sp; >>>         &nbs= p; >>>>>>>>> A.  X
=0A
>>&g= t;       >>>    = ;       >>>>>>>> exa= mines
=0A
>>>       >&g= t;>           >>= ;>>>>>>> the stack, determines that A is "routable",<= /div>=0A
>>>      and sends
=0A=
>>>       >>> &n= bsp;        the packet.
=0A
&g= t;>>       >>>  &nb= sp;        >>>>>>>= >> This
=0A
>>>      = ; >>>          = >>>>>>>> fails to
=0A
>>> =       >>>     &= nbsp;     >>>>>>>>> meet th= e goal.
=0A
>>>       >= >>           >&= gt;>>>>>> [Lizhong] The source A you are referring is=0A
> the
=0A
>>>     = ;  >>>         = initiator, right?
=0A
>>>     =   >>>         &= nbsp; >>>>>>>> The goal of relay mechanism is to r= each the
=0A
>>>      initiator= .
=0A
>>>       >>&g= t;          If X is
=0A<= div>>>>       >>> &nb= sp;         >>>>>&g= t;>> routable to the initiator (address A), then
=0A
>&g= t;>      it is
=0A
>>> =       >>>     &= nbsp;    great, other relay
=0A
>>> =       >>>     &= nbsp;     >>>>>>>> node in the= stack will be skipped.
=0A
>>>    &= nbsp;  >>>        &n= bsp;  >>>>>>>> If the source A you are referr= ing is the
=0A
>>>      interfa= ce
=0A
>>>       >>&= gt;          address of one=0A
>>>       >>>&= nbsp;          >>>&g= t;>>>> intermediate node, then I do not understand
=0A>>>      "routing
=0A
>>= ;>       >>>   &n= bsp;      will not get to
=0A
>>&g= t;       >>>    = ;       >>>>>>>> A.&= nbsp; X examines the stack, determines that A
=0A
> is
= =0A
>>>       >>> = ;         "routable", and sends=0A
>>>       >>>&n= bsp;          >>>>= ;>>>> the
=0A
>>>    &nb= sp;  >>>        &nbs= p;  >>>>>>> packet".
=0A
>>>&n= bsp;      >>>    &nb= sp;      >>>>>>>> Why rou= ting will not get to A, but A is
=0A
>>>  &nbs= p;   routable?
=0A
>>>    =    >>>        &= nbsp;  >>>>>>>>
=0A
>>>&nbs= p;      >>>     = ;      >>>>>>>> Regards=0A
>>>       >>>&= nbsp;          >>>&g= t;>>>> Lizhong
=0A
>>>   &nbs= p;   >>>        = ;   >>>>>>>>
=0A
>>>&n= bsp;      >>>    &nb= sp;      >>>>>>>>
= =0A
>>>       >>> = ;          >>>>&g= t;>>>>
=0A
>>>     =   >>>         &= nbsp; >>>>>>>>> Yours,
=0A
>>>= ;       >>>    =        >>>>>>>>> = Joel
=0A
>>>       >>= ;>           >>= >>>>>>
=0A
>>>    =    >>>        &= nbsp;  >>>>>>>>
=0A
>>>&nbs= p;      >>>     = ;      >>>>>>>>
=0A<= div>>>>       >>> &nb= sp;         >>>>>&g= t;
=0A
>>>       >>&= gt;           >>&g= t;>
=0A
>>>       >&= gt;>           >&g= t;
=0A
>>>       >>&= gt;           >
= =0A
>>>       >>>=0A
>>>       >
=0A>>>       >
=0A
>&= gt;>
=0A
=0A
------=_001_NextPart276517356085_=------ From nobody Fri Oct 31 18:36:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C431A877F for ; Fri, 31 Oct 2014 18:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdXrVJ9vapLK for ; Fri, 31 Oct 2014 18:36:51 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4542E1A8781 for ; Fri, 31 Oct 2014 18:36:38 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v10so8288622pde.32 for ; Fri, 31 Oct 2014 18:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pE8+vHwI1vN6J3S6Ek6Z8eEDjPPtDsr5gK83mT8uCuo=; b=WT5rEcZaMX8TvQHTGN60FxVweuFHpPuWpSoVKIz6q4TueMRgDfkk7TcFw5xbjt4j6r juPuA+wcjENvKJkrUvR8mvB6lVpLUFWrUEqtRA8AIgl8IERw6xQsOD6/EZSVyLY+owqe 7UGtfzbEobYelkYHEEoSjhMQgfUUdizoQZNmqAechsly0Sgp+hZHjvFgSD4OquuSGXsN 4GyL8n4wyM2K31e99nJs+OBpC7MSX+lvC16dpCOZM0NbS0zXPW79K0VeErKMy6fjKbKN TamGdKEVHMKtrdwdC5zM0esMSrhtXsfj7Yo7IMLchJtrFfwfH8DUzN5C5sDkorl19OLB 0NkQ== X-Received: by 10.70.11.2 with SMTP id m2mr28303522pdb.31.1414805797820; Fri, 31 Oct 2014 18:36:37 -0700 (PDT) Received: from [192.168.1.78] (75-37-192-227.lightspeed.lsatca.sbcglobal.net. [75.37.192.227]) by mx.google.com with ESMTPSA id v4sm4381028pbs.64.2014.10.31.18.36.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 18:36:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_41400961-BE09-4D8A-B574-A7F07BA91D43" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Kireeti Kompella In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B877A1F@eusaamb103.ericsson.se> Date: Fri, 31 Oct 2014 18:36:34 -0700 Message-Id: References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B877A1F@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Bz7zBOm-NFUPn5xS5mjF25kzTs0 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 01:36:55 -0000 --Apple-Mail=_41400961-BE09-4D8A-B574-A7F07BA91D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Greg, On Oct 30, 2014, at 16:21 , Gregory Mirsky = wrote: > Hi Kireeti, > I think that proposed in this document protection method creates some = unpleasant scenario if failure is of a node, not a link. If I use the = scenario presented in Section 3.6 but assume that the failure is not of = the link between R_j and R_j+1 but of the node Rj+1. Thus, as R_j = switches to US direction, the R_j+2 will switch to DS. And until = notifications from R_j and R_j+2 reach R_j+2 and R_j respectively we = have routing loop on RL_j+1 LSP. I appreciate your careful reading! Note of course that since there is a = TTL, this is a finite loop (not saying it isn=E2=80=99t bad, but that = this has the germ of the solution.) I have three solutions for this problem. I didn=E2=80=99t put them in = the first version of the draft; I may eventually document all (and = others, as the WG chimes in), but meanwhile this discussion is perfect. My preferred solution is to always insert packets on a ring LSP with TTL = =3D 2N-1 if the ring has N nodes. This is enough for the worst case =E2=80= =94 node R_j sends a packet on RL_j+1 the =E2=80=9Clong=E2=80=9D way = around, only to encounter a failure at node R_j+2, and come all the way = back to R_j, then R_j+1. Another solution is that an ingress node sets the TTL as usual, but a = PLR sets the TTL to the smaller of the current TTL-1 and the minimum TTL = required to reach the egress. So, in the above example, R_j would set = TTL as usual, but R_j+2, on detecting a failure, would set TTL =3D N-1 = and send it the other way. In this case, when the packet gets back to = R_j, it should not in turn reset the TTL to N-1. Of course, both of the = above can be combined. Finally, a PLR (R_j+2) can push a special purpose label to indicate that = this is a failure path, then push the label to go the other way. If the = packet goes back to R_j, before R_j sends it the other way, it sees that = the label below the top of stack is this failure label, and drops the = packet rather than cycle it back around the ring. > If my assumptions are correct, then notification mechanism MUST be = reliable or be backed up by IGP signaling. In any case, the loop may = persist for quite a while and affect all services. Agreed, having a reliable notification mechanism is always a good thing. > Comments, questions are always welcome and greatly appreciated. Greg, since you worked out the problem, do you have any opinions on the = solutions above, or any of your own? Cheers, Kireeti. > Regards, > Greg > =20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti = Kompella > Sent: Wednesday, October 29, 2014 10:41 AM > To: mpls@ietf.org > Subject: [mpls] Fwd: New Version Notification for = draft-kompella-mpls-rmr-00.txt > =20 > Hi Folks, > =20 > This is a draft on making MPLS more efficient in ring networks. I = have come around to understanding that: > a) rings are a special topology (there was a time that I didn't = appreciate that); > b) MPLS is pretty inefficient in rings (that is/was quite obvious). > =20 > This draft attempts to fix that, both by making protection much more = efficient, and by making configuration much easier. > =20 > Your comments are highly welcome! > =20 > Cheers, > Kireeti. > =20 > ---------- Forwarded message ---------- > From: > > Date: Sun, Oct 26, 2014 at 9:15 PM > Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt > To: Kireeti Kompella > >=20 >=20 >=20 > A new version of I-D, draft-kompella-mpls-rmr-00.txt > has been successfully submitted by Kireeti Kompella and posted to the > IETF repository. >=20 > Name: draft-kompella-mpls-rmr > Revision: 00 > Title: Resilient MPLS Rings > Document date: 2014-10-26 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/ = > Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-rmr-00 = >=20 >=20 > Abstract: > This document describes the use of the MPLS control and data planes > on ring topologies. It describes the special nature of rings, and > proceeds to show how MPLS can be effectively used in such = topologies. > It describes how MPLS rings are configured, auto-discovered and > signaled, as well as how the data plane works. Companion documents > describe the details of discovery and signaling for specific > protocols. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 >=20 >=20 > =20 > --=20 > Kireeti --Apple-Mail=_41400961-BE09-4D8A-B574-A7F07BA91D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Greg,

On= Oct 30, 2014, at 16:21 , Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Kireeti,

I think that proposed in this document = protection method creates some unpleasant scenario if failure is of a = node, not a link. If I use the scenario presented in Section 3.6 but assume that the failure is not of the link between = R_j and R_j+1 but of the node Rj+1. Thus, as R_j switches to US = direction, the R_j+2 will switch to DS. And until notifications from R_j = and R_j+2 reach R_j+2 and R_j respectively we have routing loop on RL_j+1 = LSP.


I appreciate your careful reading!  Note of = course that since there is a TTL, this is a finite loop (not saying it = isn=E2=80=99t bad, but that this has the germ of the = solution.)

I have three solutions = for this problem. I didn=E2=80=99t put them in the first version of the = draft; I may eventually document all (and others, as the WG chimes in), = but meanwhile this discussion is perfect.

My preferred solution is to always insert packets = on a ring LSP with TTL =3D 2N-1 if the ring has N nodes.  This is = enough for the worst case =E2=80=94 node R_j sends a packet on RL_j+1 = the =E2=80=9Clong=E2=80=9D way around, only to encounter a failure at = node R_j+2, and come all the way back to R_j, then R_j+1.

Another solution is that an ingress node sets the = TTL as usual, but a PLR sets the TTL to the smaller of the current TTL-1 = and the minimum TTL required to reach the egress.    So, in = the above example, R_j would set TTL as usual, but R_j+2, on detecting a = failure, would set TTL =3D N-1 and send it the other way.  In this = case, when the packet gets back to R_j, it should not in turn reset the = TTL to N-1.  Of course, both of the above can be = combined.

Finally, a PLR (R_j+2) can = push a special purpose label to indicate that this is a failure path, = then push the label to go the other way.  If the packet goes back = to R_j, before R_j sends it the other way, it sees that the label below = the top of stack is this failure label, and drops the packet rather than = cycle it back around the ring.

If my assumptions are correct, then = notification mechanism MUST be reliable or be backed up by IGP = signaling. In any case, the loop may persist for quite a while and = affect all services.


Agreed, having a reliable notification mechanism = is always a good thing.

Comments, questions are always welcome = and greatly appreciated.


Greg, since you worked out the problem, do you = have any opinions on the solutions above, or any of your = own?

Cheers,
Kireeti.

         =        Regards,

          &nb= sp;            = ;         Greg

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella
Sent: Wednesday, October 29, 2014 10:41 AM
To: mpls@ietf.org
Subject: [mpls] Fwd: New Version Notification for = draft-kompella-mpls-rmr-00.txt

 

Hi Folks,

=

 

This is a draft on making MPLS = more efficient in ring networks.  I have come around to = understanding that:

a) rings are a special topology = (there was a time that I didn't appreciate that);

b) MPLS is pretty inefficient in = rings (that is/was quite obvious).

 

This draft attempts to fix that, = both by making protection much more efficient, and by making = configuration much easier.

 

Your comments are highly = welcome!

 

Cheers,

Kireeti.

 

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <kireeti.kompella@gmail.com>



A new version of I-D, draft-kompella-mpls-rmr-00.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:           draft-kompella-mpls-rmr
Revision:       00
Title:          Resilient MPLS Rings
Document date:  2014-10-26
Group:          Individual Submission
Pages:          7
URL:            = http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/ Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-rmr-00


Abstract:
   This document describes the use of the MPLS control and = data planes
   on ring topologies.  It describes the special nature = of rings, and
   proceeds to show how MPLS can be effectively used in such = topologies.
   It describes how MPLS rings are configured, auto-discovered = and
   signaled, as well as how the data plane works.  = Companion documents
   describe the details of discovery and signaling for = specific
   protocols.





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.

The IETF Secretariat



 

--
Kireeti


= --Apple-Mail=_41400961-BE09-4D8A-B574-A7F07BA91D43-- From nobody Fri Oct 31 18:46:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510E71A877B for ; Fri, 31 Oct 2014 18:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhjGkaVC9177 for ; Fri, 31 Oct 2014 18:46:44 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F7E1A877A for ; Fri, 31 Oct 2014 18:46:44 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so8293876pdj.29 for ; Fri, 31 Oct 2014 18:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nsZvY+kmlsOR8RA0eajmeY5IR0+FH6rdOzIJ9slz0AE=; b=NeqINWj9JiiFBKvwyjTQomFmiy7X22DQNHaTyFqMC5XhaGwUrowJm9MiKYeAFBfXq0 kgblbomwjfAVwO+fkEllvfaa7Udi6rUFzWPJe6VD9wBVH9BWMxqbV68K9L9WuTeGr7jI yBYWc06XDthrpCq5fC9e+i8aWDxmWVWe+JP2dgz0eMtajmkRz5Xa98Q1cCDrf+lMNo+T V0koL1V7hXu+mRvsV7ycMYAzHErVHqQ68FYFxtslLKcMv2GKSACwDy8PDoq2Pvk2t+CP iRAv5m8GGr3hB07jihdoOtAqVEWnCs8ZV9+EzYU5CvqvkdQEB2xrGXhIyGC1k4f2gaAd Vu2g== X-Received: by 10.70.127.169 with SMTP id nh9mr3740414pdb.115.1414806403688; Fri, 31 Oct 2014 18:46:43 -0700 (PDT) Received: from [192.168.1.78] (75-37-192-227.lightspeed.lsatca.sbcglobal.net. [75.37.192.227]) by mx.google.com with ESMTPSA id n3sm11072735pda.7.2014.10.31.18.46.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 18:46:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Kireeti Kompella In-Reply-To: <201410301248.22044.mark.tinka@seacom.mu> Date: Fri, 31 Oct 2014 18:46:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141027041512.4465.43044.idtracker@ietfa.amsl.com> <4A6CE49E6084B141B15C0713B8993F2831D6528C@SJEXCHMB12.corp.ad.broadcom.com> <201410301248.22044.mark.tinka@seacom.mu> To: mark.tinka@seacom.mu X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0hZ26KRetwJaHng2s2gbiMV7XcM Cc: mpls@ietf.org Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 01:46:46 -0000 Hi Mark, On Oct 30, 2014, at 03:48 , Mark Tinka wrote: > On Wednesday, October 29, 2014 07:59:23 PM Shahram Davari=20 > wrote: >=20 >> It would be good if you can add a section to describe >> what is the difference between your draft and the >> following RFC/drafts, and why it is better. >>=20 >> https://tools.ietf.org/html/rfc6974 >>=20 >> http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-rin >> g-protection-03 >=20 > I'd also like to understand, better, from Kireeti, why he=20 > think the current IP/MPLS implementations are not suitable=20 > for ring architectures. =E2=80=9CNot suitable=E2=80=9D may be over-stating it; inefficient may = be better. RSVP-TE needs bypass LSPs, and the failure path is = inefficient. LDP LFA=E2=80=99s worst topology is a ring. Also, provisioning N^2 LSPs for full connectivity on N nodes is a = burden, especially since there are lots of rings out there. Finally, it might be time for new approaches to bandwidth management :) > That said, I'm keen on getting a better handle on this=20 > draft, if it has the ability to make MPLS cheaper enough to=20 > roll out on far less expensive devices that can be deployed=20 > en masse in rings, in a way specific to ring architectures=20 > and their cost structures. Well, let me know what you think! I hope that is indeed the case. Cheers, Kireeti > Mark. From nobody Fri Oct 31 19:07:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6A1A879A for ; Fri, 31 Oct 2014 19:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk7xCKTSXrqt for ; Fri, 31 Oct 2014 19:06:51 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487041A878E for ; Fri, 31 Oct 2014 19:06:51 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so8306762pdj.1 for ; Fri, 31 Oct 2014 19:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lwSJNX2eMKG6zFaAoSbSW9yvp43L8E5gKpJYBJEamLo=; b=g9iGROEBk3Cye8a6e5IQw14KKWmtZf3M00LJch0XhWshdyTC9jymROEHzkSJeX9yTg trla7S7HvZ6MMVsx4bdc3DR86HHZogfBoumW0G6Bixh6dWVFh781Bc9bW3wXbDTiE6ch xApT4AcSIm70N0P5t7nlgWcR/jjHjIil/Cm4CmsMJZi5Vj+J7uUfXEMapBRnVD5iX59d T6hcWuiX1WxPqTe0YPeR11r7Tyoig4+lBB6fMf1aoAuf5h6SKYXmq0pedoEejntxmKF1 udymxEqBYBnfs8TWDacgM9zJGjzN4/P6yVDdtxH2NMNhErbiqOtgR5Mh/FqjlAdVHi7f D63A== X-Received: by 10.70.47.42 with SMTP id a10mr28334697pdn.18.1414807610865; Fri, 31 Oct 2014 19:06:50 -0700 (PDT) Received: from [192.168.1.78] (75-37-192-227.lightspeed.lsatca.sbcglobal.net. [75.37.192.227]) by mx.google.com with ESMTPSA id pc8sm11068355pdb.54.2014.10.31.19.06.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 19:06:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_53C82D07-2770-45CD-BA31-C6022B54E9F8" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Kireeti Kompella In-Reply-To: Date: Fri, 31 Oct 2014 19:06:48 -0700 Message-Id: References: <20141027231233.21010.5632.idtracker@ietfa.amsl.com> To: Bhupesh Kothari X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bYjagfzk2E8IsbSFpxIr_dV28FQ Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-larp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 02:06:57 -0000 --Apple-Mail=_53C82D07-2770-45CD-BA31-C6022B54E9F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bhupesh, > On Oct 30, 2014, at 14:02 , Bhupesh Kothari = wrote: >=20 > Hi Kireeti, >=20 > Can you describe how L-ARP can be used between a DSLAM and its = upstream router to form bi-directional tunnels? I want to understand = what, if any, assumptions are made. L-ARP is for the DSLAM (or server, or whatever) to talk to a BNG (or = remote server). For the reverse direction, one possibility is = =E2=80=9Clabeled DHCP=E2=80=9D. A quick overview is that when a DSLAM X = asks for an IP address, it also says, allocate a label for me. The = upstream node (switch/BNG/CMTS) Y then allocates a label, which it = advertises to reach X. That would establish bidirectional connectivity. To establish hierarchical tunnels, I would recommend L-BGP (RFC 3107). = Two possibilities: The X announces this label (with next hop Y); or Y = announces this label with itself as next hop. In the former case, the = L-DHCP reply needs to have a label for X to advertise. If this makes sense (and interests you), I=E2=80=99d be happy to = collaborate with you on the L-DHCP draft. Kireeti. > Bhupesh >=20 >=20 > On Wed, Oct 29, 2014 at 10:36 AM, Kireeti Kompella = > wrote: > Hi All, >=20 > Not sure why this didn't get copied to the MPLS WG list. >=20 > In any case, this update breaks out the "Hardware Address" into two = parts. The HA part contains just the MAC address of L-ARP replier. = Labels are in a separate TLV that now can contain a label stack. = Finally, the metric is taken out of the HA part and is separate. >=20 > We also have a new co-author, George Swallow. >=20 > Please comment on the draft as a whole, and on these changes in = particular. >=20 > Thanks, > Kireeti. >=20 > ---------- Forwarded message ---------- > From: > > Date: Mon, Oct 27, 2014 at 4:12 PM > Subject: New Version Notification for draft-kompella-mpls-larp-02.txt > To: Kireeti Kompella >, George Swallow >, Balaji Rajagopalan > >=20 >=20 >=20 > A new version of I-D, draft-kompella-mpls-larp-02.txt > has been successfully submitted by Kireeti Kompella and posted to the > IETF repository. >=20 > Name: draft-kompella-mpls-larp > Revision: 02 > Title: Label Distribution Using ARP > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt = > Status: = https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/ = > Htmlized: http://tools.ietf.org/html/draft-kompella-mpls-larp-02 = > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-larp-02 = >=20 > Abstract: > This document describes extensions to the Address Resolution = Protocol > to distribute MPLS labels for IPv4 and IPv6 host addresses. > Distribution of labels via ARP enables simple plug-and-play = operation > of MPLS, which is a key goal of the MPLS Fabric architecture. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > --=20 > Kireeti >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls = >=20 >=20 --Apple-Mail=_53C82D07-2770-45CD-BA31-C6022B54E9F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Bhupesh,

On = Oct 30, 2014, at 14:02 , Bhupesh Kothari <bhupesh@anvaya.net> = wrote:

Hi Kireeti,

Can you describe how L-ARP can be used = between a DSLAM and its upstream router to form bi-directional = tunnels?  I want to understand what, if any, assumptions are = made.

L-ARP = is for the DSLAM (or server, or whatever) to talk to a BNG (or remote = server).  For the reverse direction, one possibility is =E2=80=9Clabe= led DHCP=E2=80=9D.  A quick overview is that when a DSLAM X asks = for an IP address, it also says, allocate a label for me.  The = upstream node (switch/BNG/CMTS) Y then allocates a label, which it = advertises to reach X.  That would establish bidirectional = connectivity.

To establish = hierarchical tunnels, I would recommend L-BGP (RFC 3107).  Two = possibilities: The X announces this label (with next hop Y); or Y = announces this label with itself as next hop.  In the former case, = the L-DHCP reply needs to have a label for X to advertise.

If this makes sense (and interests you), I=E2=80=99d= be happy to collaborate with you on the L-DHCP draft.

Kireeti.

Bhupesh


On Wed, = Oct 29, 2014 at 10:36 AM, Kireeti Kompella <kireeti.kompella@gmail.com> = wrote:
Hi All,

Not= sure why this didn't get copied to the MPLS WG list.

In any case, this update = breaks out the "Hardware Address" into two parts.  The HA part = contains just the MAC address of L-ARP replier.  Labels are in a = separate TLV that now can contain a label stack.  Finally, the = metric is taken out of the HA part and is separate.

We also have a new = co-author, George Swallow.

Please comment on the draft as a whole, and on these changes = in particular.

Thanks,
Kireeti.

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: Mon, Oct 27, 2014 at 4:12 PM
Subject: New = Version Notification for draft-kompella-mpls-larp-02.txt
To:= Kireeti Kompella <kireeti.kompella@gmail.com>, George = Swallow <swallow@cisco.com>, Balaji Rajagopalan <balajir@juniper.net>



A new version of I-D, draft-kompella-mpls-larp-02.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:          =  draft-kompella-mpls-larp
Revision:       02
Title:          Label Distribution Using ARP
Document date:  2014-10-27
Group:          Individual Submission
Pages:          11
URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02= .txt
Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/<= br class=3D""> Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-larp-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-larp-02<= /a>

Abstract:
   This document describes extensions to the Address = Resolution Protocol
   to distribute MPLS labels for IPv4 and IPv6 host = addresses.
   Distribution of labels via ARP enables simple plug-and-play = operation
   of MPLS, which is a key goal of the MPLS Fabric = architecture.





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.

The IETF Secretariat



--
Kireeti

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



= --Apple-Mail=_53C82D07-2770-45CD-BA31-C6022B54E9F8--