Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

Stewart Bryant <stbryant@cisco.com> Thu, 20 August 2015 12:25 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE391ACDE8; Thu, 20 Aug 2015 05:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.91
X-Spam-Level:
X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_44=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 0jMLAt4DN6G7; Thu, 20 Aug 2015 05:25:45 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF601ACDE3; Thu, 20 Aug 2015 05:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38472; q=dns/txt; s=iport; t=1440073544; x=1441283144; h=reply-to:subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=LvSX1vI5Y3PV+sn49V4PgLaMi+mkeNfs1I8CvjBc4Ag=; b=OHX2YYr6TdXKkgwMZIHopc1e+ZiTcHBCjnY/VQeO3bqicMMKlmZmSHk5 A6lpcOKPkJ+4bmDoG2oxeUYEi1d64SkMw8pqgEHdmPTu4WDz1+b8g7mTN oQtjdQHuYzeDgrrOpvXPWzTU1Ce8agD3UQjNJDPzxwXLJ6MzYZMmrtqcx M=;
X-IronPort-AV: E=Sophos;i="5.15,714,1432598400"; d="scan'208,217";a="604583060"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2015 12:25:42 +0000
Received: from [64.103.106.129] (dhcp-bdlk10-data-vlan300-64-103-106-129.cisco.com [64.103.106.129]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7KCPfYq010116; Thu, 20 Aug 2015 12:25:42 GMT
References: <CAH==cJw0gYz17bWYwe6+VKVCcWjYZR=j0V5f5Ywec_jXnte62Q@mail.gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A900449@szxema506-mbs.china.huawei.com> <20150808183111884135100@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A9B3543@szxema506-mbs.china.huawei.com> <201508122345018343936@gmail.com>
To: "lizho.jin@gmail.com" <lizho.jin@gmail.com>, Jiangyuanlong <jiangyuanlong@huawei.com>, rtg-ads <rtg-ads@tools.ietf.org>, "david.i.allan" <david.i.allan@ericsson.com>, "Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.com>, "Giles Heron (giheron)" <giheron@cisco.com>, agmalis <agmalis@gmail.com>
From: Stewart Bryant <stbryant@cisco.com>
Message-ID: <55D5C74B.5020500@cisco.com>
Date: Thu, 20 Aug 2015 13:25:47 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <201508122345018343936@gmail.com>
Content-Type: multipart/alternative; boundary="------------090301050309030705060909"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/3rdO0_2P_-AifSahAbGa46lfqTU>
Cc: rtg-dir <rtg-dir@ietf.org>, draft-ietf-l2vpn-vpls-pe-etree <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, pals <pals@ietf.org>
Subject: Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2015 12:25:51 -0000

On 12/08/2015 16:45, lizho.jin@gmail.com wrote:
>
>         13.Section5.2: “For both methods, VLAN mapping parameters from
>         a remote PE can be provisioned or determined by a signaling
>         protocol as described in Section 6 when a PW is being
>         established”. For the global method, why we need signaling?
>
>         [JY] Just as the sentence says, the global VLAN method does
>         not rely on signaling for its work.
>
>         But the SPs may prefer to use one method (e.g., global VLAN
>         based) in scenario A and the other method (e.g., local VLAN
>         based) in scenario B, and they would like to keep both methods
>         work in a similar way, so the signaling protocol was designed
>         to be applicable in both methods to give them a similar
>         operation experience (if signaling is supported).
>
>         [Lizhong] I don't agree, what if deploying only global mode?
>         You are talking about the operational experience, but I am
>         talking about the technology. It is very confusing for the
>         readers.
>
>         [JY2] Firstly, signaling for global method is not mandatory.
>         Secondly, when control plane is needed, it is simple to
>         implement if the same signaling can be used in both cases.
>         BTW, even in the global mode, we may save some work in
>         configuration if we have signaling capability (thus we only
>         need to configure two VLAN values per router).
>

SB> I honestly do not understand the problem with the original text.

SB> Sure if you only use global you do not NEED signalling, but if you 
want to implement it that way it will work, and the text makes it clear 
that signalling is optional.

>         ==========
>
>         19.Section6.1: “If the PE is a leaf-only node itself, then a
>         label release message with a status code "Leaf to Leaf PW
>         released" is sent to the peer PE and exit the process;”When
>         both PE release the mapping. Then when one PE1 change the
>         setting to have both root&leaf, and send label mapping to PE2,
>         will PE2 be triggered to send label mapping to PE1? According
>         to RFC5036, I think the answer is no. You need additional
>         mechanism here.
>
>         [JY] Why PE2 cannot be triggered to send label mapping to PE1?
>         IMO, we don't need any additional mechanism here. If the
>         configuration is changed for a failed PW establishing session,
>         then a new round of PW negotiations can take place between PE1
>         and PE2. Furthermore, the PW negotiation process is
>         standardized in RFC 4447 rather than RFC 5036, and you can
>         find answers there.
>
>         [Lizhong] You should give out the technical reason. There is
>         no configuration changing on PE2, and PE1 release the mapping
>         from PE2, then the PE2 will not send mapping again since DU
>         mode is used for PW signaling. BTW, the PW signaling RFC4447
>         is based on RFC5036, and also updated by RFC6723. One method
>         is, like RFC6723, PE1 need LDP request message to reestablish
>         the PW.
>

SB> The correct document to use as the basis for this discussion is 
4447bis, since that is the description of PW signalling that has all the 
errors corrected.

SB> So is this protocol broken if the procedures in RFC4447bis are applied?

>         [JY2] this is similar to comment 20 since it deals with
>         topology and TLV parameter updates.
>

Also can I suggest that the document is updated with the changes we know 
we are going to make so we know exactly what text we are dealing with 
and can deal with the unresolved issues withing that context.  When we 
have the text technically correct we will then need to do an English 
Language pass to pick up the concerns raised by our AD. However I am 
reluctant to do this, or ask someone else to do do it before the 
outstanding technical issues are all fixed.

If you think it is useful to set up a conference call to resolve this 
please let me know.

- Stewart