Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
Yizhou Li <liyizhou@huawei.com> Thu, 04 August 2011 11:06 UTC
Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5221F8B40 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Thu, 4 Aug 2011 04:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.134
X-Spam-Level:
X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v78NMuGu1y9F for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Thu, 4 Aug 2011 04:06:38 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DC40D21F8B3F for <trill-archive-Osh9cae4@lists.ietf.org>; Thu, 4 Aug 2011 04:06:38 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p74Am7fq005902; Thu, 4 Aug 2011 03:48:08 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p74AlMe4005820 for <rbridge@postel.org>; Thu, 4 Aug 2011 03:47:35 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE008JCGM502@szxga03-in.huawei.com> for rbridge@postel.org; Thu, 04 Aug 2011 18:46:53 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE00GBSGM5W0@szxga03-in.huawei.com> for rbridge@postel.org; Thu, 04 Aug 2011 18:46:53 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACX35294; Thu, 04 Aug 2011 18:46:53 +0800 (CST)
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 04 Aug 2011 18:46:46 +0800
Received: from l63746 (10.138.41.133) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 04 Aug 2011 18:46:52 +0800
Date: Thu, 04 Aug 2011 18:46:51 +0800
From: Yizhou Li <liyizhou@huawei.com>
In-reply-to: <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
X-Originating-IP: [10.138.41.133]
To: 'David M Bond' <dmbond@us.ibm.com>
Message-id: <05b301cc5293$d1e2beb0$75a83c10$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AcxSC2WfpHtgD6FHQaaT8WKqnapCGQAcT4Qw
X-CFilter-Loop: Reflected
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com> <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: liyizhou@huawei.com
Cc: d3e3e3@gmail.com, 'Erik Nordmark' <nordmark@acm.org>, rbridge@postel.org, vishwas.manral@hp.com
Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
Hi David, For item 3, I am ok with your example on varying Inner.MacSA. Non-trivial part for me indeed is Inner.MacDA. draft-ietf-trill-rbridge-channel-02 section 2 says "They are identified as RBridge Channel messages by their Inner.MacDA, which is the All-Egress-RBridges multicast address, together with their Inner Ethertype, which is the RBridge-Channel Ethertype." It appears Inner.MacDA must be a fixed value. Channel draft talks about "Native RBridge Channel Frames" which may use end host's MAC as destination. So I assume we want to use this for testing different data path by varying Inner.MacDA. My feeling is some detailed description is needed to make it clearer and more useful for implementers. E.g. Can we say "egress RB should handle such echo request/reply without sending it to real destination mac"? If target(egress) RB is not connected to destination end host, certain specific oam error should be generated? Yizhou -----Original Message----- From: David M Bond [mailto:dmbond@us.ibm.com] Sent: Thursday, August 04, 2011 2:30 AM To: Liyizhou Cc: d3e3e3@gmail.com; Erik Nordmark; rbridge@postel.org; vishwas.manral@hp.com Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00 Hi Yizhou, Thanks for the detailed review and sorry for the slow response time. Comments inline below prefaced with DB>: Thanks, David From: Liyizhou <liyizhou@huawei.com> To: "rbridge@postel.org" <rbridge@postel.org> Cc: "d3e3e3@gmail.com" <d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, "Mmokon@mokon.net" <Mmokon@mokon.net>, "vishwas.manral@hp.com" <vishwas.manral@hp.com> Date: 07/27/2011 12:24 PM Subject: [rbridge] comments on draft-ietf-trill-rbridge-oam-00 Sent by: rbridge-bounces@postel.org Hi folks, Some reviewing comments on draft-ietf-trill-rbridge-oam-00, 1. pg6, table 1 gives the header format of oam frame *in response to* another data frame. We also need a header format table for self-initiating oam message like echo request. Table entry for "Inner.MacDA" says "Inner.MacDA MAY be other values as specified in subsequent sections". But there is no other value specified indeed. I believe it was prepared for ping request as inner.MacDa should be a unicast mac address of destination RB? DB> I've added that second table. In regards to the "specified in subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the values specified in Table 1. Rbridges SHOULD be configurable to change these values to assign the TRILL data frame to a flow." This however was for self-generated messages. Thanks, this has been corrected. 2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests, incrementing the hop-count by one each time until... Looks a bit ambiguitous to me. Shouldn't echo request be sent with hop-count incremented by 1 only after hop-count error notification for previous echo request being received? DB> My intention here was to leave those specific details up to the implementer. Each request has a sequence number which can be used for reordering. If someone wants to sent frames in lock step that's fine but they can also flood oam frames out quickly if their specific implementation would work better with that method. The results will be the same regardless. 3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the values specified in Table 1. RBridges SHOULD be configurable to change these values to assign the TRILL data frame to a flow. " For unicast tracert with specified two RBridges, if we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA and Ingress Nickname are all fixed values. Inner.vlan may take different value (table 1 indeed says it should be 1) but does not make much sense. Priority may have different value but very restricted. Therefore it lacks a lot of details on how to vary those values to get different flow? I suggest to remove this and leave it for future tool such as ecmp oam. Or say details could be find in future draft? If we want to keep it, better to give some explaination, e.g. explicitly say virtual internal end station inside RB possily allows to be configured for different MACs? DB> These are intended to be configuration options on say a command line implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic must mimic real data which would otherwise be coming from an end station. Each Rbridge has a single mac address but it may be attached to multiple end stations. So let's say I'm an operator and I seeing traffic destined to 00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting through. Both of these devices are on a single L2 LAN and are therefore connected to the same egress rbridge. Their flows however might be transiting through the TRILL Campus through different ECMP paths and one of those paths might be failing. If I don't have this ability to change say the inner dst mac from the egress Rbridges dst mac to a connected end station's dst mac then I lack the ability to locate the failure in the campus. Does this sentence "e.g. The Inner.MacSA might be changed to the MAC address of an end station connected to the ingress Rbridge to alter the ECMP path frames coming from that end station follow through the TRILL campus." appended to the end of that paragraph help explain the meaning better? Additionally describing how flows are classified I feel is beyond the scope of this document since the base draft does not specify that as well and it is up to each vendor to determine their transit hash method works. 4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its 16-bit port ID from the port on which.." ->"include its 16-bit port ID from the port on which...in Outgoing Port ID TLV in reply..." , "If the request is a multi-destination frame, this field..." better moves to "4.1.1.1. Multi-Destination Targets". DB> Agreed 5. pg9, para5, lack of description on timeout and re-transmission of echo request DB> This is implementation specific and does not affect interoperability. I would prefer to leave that up to the implementers specific needs. What does everyone else think in regards to this? Should we specify a re-transmission/timeout algorithm? 6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error notification" DB> Agreed 7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop Count Zero error notification", "hop count" for error is "N/A", what is the value for "N/A"? is it maximun 0x3F? DB> Agreed, changes N/A to default (aka what the base protocol spec specifies. 8. pg12, para4, lack of description on srcMac, destMac and hop count. It refers to table 1, but original table 1 is only for responding oam message. DB> Added table for self originated messages and updated reference. Thanks. 9. pg15, 4.2.1, If the request is a multi-destination frame, this field MUST be set to all zeros.... However pg9 para3 says if it is for multi-destination traceroute, next hop nickname should be "previous hop nickname"? Should have some clarification. Here it talks about normal data frame but not oam echo request frame. DB> This is a mistake. They should both be the previous hop nickname. Thanks, fixed. 10. pg18, 6.2, SPID is never used in error notification. Error notification uses channel protocol number 5 while echo use 4. Can we make SPID field here to be used for error type and make the subcode to be 16-bit long instead? DB> I have no objection to this. What do other people feel? 11. pg18, last line, typo, dup. Requests DB> Fixed 12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop Count Zero error" DB> Fixed 13. pg19, 6.2.1, "The sub-code values fall into three categories...", there are 4 error type as described in previous section bullet. It is unclear between permanent error and transient error. DB> Let me get back to you on that one. 14. pg19, error code 2. I assume it is valid that the MAC Address is not a multicast address and the M bit is one? Remember there are some discussion regarding some corner cases of this. Not too sure. Moreover, can we call this error M bit mismatch or something like it to make it more descriptive? DB> Yes this is the intent. I have updated the name as suggested. 15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero? DB> Fixed 16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one with lowest value or list one with highest value? Duplicate description on multi-destination traceroute and multi-destination hop-count errors. DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use the numerically largest nickname in the Next Hop Nickname TLV." Another general comment is we want to make sure traceroute tool sends out echo request with same header contents each time until it reaches the final destination though RB allows the different configurations for testing flow-based path. It gurantees it follows the same path for incremental trace in tracert. DB> Added this sentence "An Rbridge must keep the TRILL header contents the same for ever frame sent in a hop count traceroute." Yizhou _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] comments on draft-ietf-trill-rbridge-oa… Liyizhou
- Re: [rbridge] comments on draft-ietf-trill-rbridg… David M Bond
- Re: [rbridge] comments on draft-ietf-trill-rbridg… Yizhou Li
- Re: [rbridge] comments on draft-ietf-trill-rbridg… David M Bond
- Re: [rbridge] comments on draft-ietf-trill-rbridg… Yizhou Li