Re: [RTG-DIR] [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt
Haoweiguo <haoweiguo@huawei.com> Thu, 21 January 2016 10:31 UTC
Return-Path: <haoweiguo@huawei.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 9AAAE1A6F88; Thu, 21 Jan 2016 02:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJBYXsokW5c7; Thu, 21 Jan 2016 02:31:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D094B1A6F8A; Thu, 21 Jan 2016 02:31:33 -0800 (PST)
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 CHE64529; Thu, 21 Jan 2016 10:31:30 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jan 2016 10:31:26 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 21 Jan 2016 18:31:21 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: Susan Hares <shares@ndzh.com>, "draft-ietf-trill-irb@ietf.org" <draft-ietf-trill-irb@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [RTG-DIR] [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt
Thread-Index: AQHRT470pIsPm2TqDUavyHBk4M6DkJ8CpLougAIH0gCAASFTeQ==
Date: Thu, 21 Jan 2016 10:31:21 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB551733502915DE@nkgeml513-mbx.china.huawei.com>
References: <02a301d14f4c$f60c6010$e2252030$@ndzh.com> <DD5FC8DE455C3348B94340C0AB55173350290FDE@nkgeml513-mbx.china.huawei.com>, <031901d14f8e$ea0520d0$be0f6270$@ndzh.com> <DD5FC8DE455C3348B94340C0AB55173350291373@nkgeml513-mbx.china.huawei.com>, <004f01d153e8$e4e424d0$aeac6e70$@ndzh.com>
In-Reply-To: <004f01d153e8$e4e424d0$aeac6e70$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.198.42]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB551733502915DEnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A0B383.0049, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 97c62c301372403553aa1943d88ec557
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/G4vhMqoitVxakDXsWKnVeksX82w>
Cc: 'Donald Eastlake' <d3e3e3@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, 'Alia Atlas' <akatlas@gmail.com>, 'Jon Hudson' <jon.hudson@gmail.com>
Subject: Re: [RTG-DIR] [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 21 Jan 2016 10:31:40 -0000
Hi Sue, Pls see inline with [weiguo2]. Would you like to give some reviewing for the revised text? weiguo ________________________________ From: Susan Hares [shares@ndzh.com] Sent: Thursday, January 21, 2016 9:13 To: Haoweiguo; draft-ietf-trill-irb@ietf.org; trill@ietf.org Cc: 'Donald Eastlake'; rtg-dir@ietf.org; 'Jon Hudson'; 'Alia Atlas' Subject: RE: [RTG-DIR] [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt Weiquo: See my comments in the first section. I think we’ve come to a good conclusion to our discussion. If you wish me to review the text, please just send me a copy of the text. Cheerily, Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Tuesday, January 19, 2016 5:36 AM To: Susan Hares; draft-ietf-trill-irb@ietf.org; trill@ietf.org Cc: 'Donald Eastlake'; rtg-dir@ietf.org; 'Jon Hudson'; 'Alia Atlas' Subject: Re: [RTG-DIR] [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt Hi Sue, Pls see inline with [weiguo]. weiguo ________________________________ From: Susan Hares [shares@ndzh.com] Sent: Friday, January 15, 2016 20:18 To: Haoweiguo; draft-ietf-trill-irb@ietf.org<mailto:draft-ietf-trill-irb@ietf.org>; trill@ietf.org<mailto:trill@ietf.org> Cc: 'Donald Eastlake'; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; 'Alia Atlas'; 'Jon Hudson' Subject: RE: [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt Weiquo: The minor points are technical points rather than editorial. Would you consider the technical alternatives I have asked about for #1. It is likely you will get the same questions from other reviewers. [weiguo]: I think currently distributed layer 3 gateway should ensure configuration consistency. Yes, Yang model can be provided and network automation can be achieved through SDN controller to simplify provisioning. The specific Yang model designing is out of scope. As for your TRILL protocol extension to propagate local configuration, i think it's not prefered. The Yang data model based network automation is mature. [Sue]: OK – then you simply need to indicate the configuration consistency can be done by local configuration and netconf/yang models. Can you insert an sentence about this in the text? [weiguo2]: Revised discription: Because the ESs in a subnet may be spread over multiple edge RBridges, each of these edge RBridges establishes its gateway interface for the subnet and these gateway interfaces on different edge RBridges SHOULD share the same gateway MAC and gateway IP address configuration. The configuration consistency can be done by local configuration and netconf/Yang models. On #2, see my expanded text. I am looking for a bit more detail that your suggested text. You may edit that text a bit. [weiguo]: I think we don't need to define delete type for route withdrawing, we count on re-advertisement of all prefixes, remote RBridge make comparison between current prefixs and all previous prefixs to check if there are withdrawing routes, the mechanism is similar to current IS-IS protocol. [Sue]: This is a fine solution. The point is during the period waiting for the re-advertisement you may have inconsistent routes. How long will this take? You need to add a sentence or two indicating this solution. [weiguo2]: Revised discription: If a tenant is deleted on an edge Rbridge RB1, RB1 SHOULD re-advertise the local tenant Label, tenant gateway MAC, and related IP prefixes information of the rest tenants to other edge Rbridges. It may take some time for the re-advertisement to reach all other RBridges, and it will cause transient routes inconsistency among the edge RBridges. If there are traffic in flight during this time, it will be dropped at egress RBridge due to local tenant deletion. In stable state, the traffic to the deleted tenant will be dropped in ingress RBridge. So the transient routes consistency won’t cause other issues other than some unnecessary network bandwidth wasting. From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Friday, January 15, 2016 4:09 AM To: Susan Hares; draft-ietf-trill-irb@ietf.org<mailto:draft-ietf-trill-irb@ietf.org>; trill@ietf.org<mailto:trill@ietf.org> Cc: 'Donald Eastlake'; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; 'Alia Atlas'; 'Jon Hudson' Subject: Re: [trill] Routing Directorate review of draft-ietf-trill-irb-09.txt Hi Sue, Thanks for your great comments. I will adopt all your editorial comments. As for the minor issues, pls see the text changes inline with [weiguo]. If you have no problem for the modification, will update the draft ASAP. weiguo ________________________________ From: Susan Hares [shares@ndzh.com] Sent: Friday, January 15, 2016 12:26 To: draft-ietf-trill-irb@ietf.org<mailto:draft-ietf-trill-irb@ietf.org>; trill@ietf.org<mailto:trill@ietf.org> Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; Haoweiguo; 'Donald Eastlake'; 'Jon Hudson'; 'Alia Atlas' Subject: Routing Directorate review of draft-ietf-trill-irb-09.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-trill-irb-09.txt Reviewer: Susan Hares Review Date: 1/14/2016 Type of Review: QA-Review Summary: 2 Minor issue which must be resolved before publication. A few editorial nits. Minor issues: 1. Page 11 – states that each of the edge RBridges establishes its gateway interface for the subnet and these gateway interfaces on different edge RBridges share the same gateway Mac and gateway IP address. It is unclear what specific mechanisms allow the different RBridge routers to share the same gatewayAC and IP address. If the mechanism is in section 7.1 (Tenant Label and Gateway MAC APPsub-TLV), then it needs to be referred to here. [weiguo]: It is relying on configuration to ensure the same gateway Mac and gateway IP address on different edge RBridges. So the corresponding text change is as follows: From: Because the ESs in a subnet may be spread over multiple edge RBridges, each of these edge RBridges establishes its gateway interface for the subnet and these gateway interfaces on different edge RBridges share the same gateway MAC and gateway IP address. To: Because the ESs in a subnet may be spread over multiple edge RBridges, each of these edge RBridges establishes its gateway interface for the subnet and these gateway interfaces on different edge RBridges SHOULD share the same gateway MAC and gateway IP address. Static configuration or other mechanisms can be used here. Sue 2: Static configuration is always a possibility to make things work. However, aligning the gateway MAC and gateway IP quickly via configuration implies an OAM or Yang modules to configure. You should plan to create Yang modules for this configuration. Did you consider passing the configuration within TRILL in APPsubTLV (see section 7.1) from a central location? It matches the zero configuration approach TRILL sends. It is clear in the second paragraph on p. 11, that the Ends System will ARP/ND query and provide its MAC/IP address mapping to the gateway interface. 2. p. 12 – paragraph 2 staring with “If a tenant is deleted on the edge RBridge RB1, RB1 notifies all other edge RBridges to delete the tenant Label, the gateway MAC, and related IP prefixes that were local to RB1 by withdrawing its advertisement of that information. There are two ways to withdraw advertisement: a) a specific withdraw TLV, or b) re-announce IP Address lists (section 7.3) without the information. [weiguo]: TRILL uses same mechnism as in IS-IS prototocl for route withdrawing, the mechanism is b). So the corresponding text change is as follows: From: If a tenant is deleted on an edge Rbridge RB1, RB1 notifies all other edge Rbridges to delete the tenant Label, tenant gateway MAC, and related IP prefixes that were local to RB1 by withdrawing its advertisement of that information. To: If a tenant is deleted on an edge Rbridge RB1, RB1 SHOULD re-advertise the local tenant Label, tenant gateway MAC, and related IP prefixes information of the rest tenants to other edge Rbridges. Sue: If you are counting on re-advertisement of all prefixes, this text should be more precise. If a tenant is deleted on an edge RBridge RB1, RB1 notifies all other edge RBridges to delete the tenant Label, tenant gateway MAC, and related IP Prefix associated with RB1 by withdrawing this information from TRILL APPsub-TLVs (Tenant Label and MAC, IPv4 Prefix, and IPv6 Prefix APPSub-TLVs), and re-advertising the remaining tenant’s information for local tenant Label, tenant gateway MAC, and related IP prefixes (IPv4 or IPv6). If this solution uses section 7.1 to announce Tenant ID, Tenant Labels, and Tenant MAC addresses – how are you going to delete these announcements? It is not covered any place in the draft. One way you could do this is to include a Type for announce / and a second type for delete. If this solution uses section 7.3 or 7.4 to announce IP address labels, you will need to announce all the IP addresses again. If you do not want to do this, you could duplicate the APPSub-TLVs (7.3 and 7.4) with a delete function. Sue: The IS-IS mechanism for withdrawing is to re-advertise without the prefix. The text above is fine for this These two issues are listed as “minor” because this lack in the specification can be easily solved by with APPSub-TLV. However, this lack needs to be resolved before publication. Editorial: The majority of this draft is well written. Here are a few editorial comments. The authors may utilize these editorials or decide not to use the editorial suggestions 1) p. 6 from: /ES1 to ES8 belong to one tenant, the tenant has four subnets each subnet corresponds to one VLAN indicating one individual layer 2 virtual network, each ES’S IP address, VLAN, and subnet are listed as follows:/ to / ES1 to ES8 belong to one tenant network and the tenant has four subnets with each subnet corresponding to one VLAN (which indicates one individual layer 2 virtual network). Each ES’s IP address, VLAN and subnet are listed below:/ 2) p 11, section 5.2 paragraph 2. From: /It’s implementation dependant and there is no restriction on this/ To: /It is implementation dependent and there is no restriction on this assignment of labels/ 3) p. 11 section 5.2 Put a paragraph break before “The tenant gateway MAC differentiates” 4) p. 14 section 5.4 paragraph 5 from: /the RBridge decapsulates the TRILL encapsulation and check the Inner.MacDA, if / to: /the RBridge decapsulates the TRILL encapsulation and check the Inner.MacDA. If/ 5) section 6.2 You should check your form of doing the numbered list. I believe if you use a different style of list it will read better. If the numbers “1., 2., 3. , and 4. – form the edge of the text, then this will be easier to read 1. ESI sends unicast .. Additional text after the first line should be at this indentation. 2. Ingress RBridge … 3. Transit RBridge … 4. Egress RBridge 6) Section 7 – Bullet lists in section 7.1 – 7.4 – would be more readable if you used the same form of indentation. Sue Hares (shares@ndzh.com<mailto:shares@ndzh.com>)
- [RTG-DIR] Routing Directorate review of draft-iet… Susan Hares
- Re: [RTG-DIR] [trill] Routing Directorate review … Susan Hares
- Re: [RTG-DIR] Routing Directorate review of draft… Haoweiguo
- Re: [RTG-DIR] [trill] Routing Directorate review … Haoweiguo
- Re: [RTG-DIR] [trill] Routing Directorate review … Susan Hares
- Re: [RTG-DIR] [trill] Routing Directorate review … Haoweiguo
- Re: [RTG-DIR] [trill] Routing Directorate review … Susan Hares