Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
David M Bond <dmbond@us.ibm.com> Mon, 08 August 2011 19:46 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 09FDB11E8090 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Mon, 8 Aug 2011 12:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.777
X-Spam-Level:
X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrEGTtZ1ghkZ for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Mon, 8 Aug 2011 12:46:11 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AF17611E8081 for <trill-archive-Osh9cae4@lists.ietf.org>; Mon, 8 Aug 2011 12:46:08 -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 p78JTjcq018539; Mon, 8 Aug 2011 12:29:46 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p78JSNWH018358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 8 Aug 2011 12:28:32 -0700 (PDT)
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p78JFAlS024501 for <rbridge@postel.org>; Mon, 8 Aug 2011 15:15:10 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p78JSKOs2994418 for <rbridge@postel.org>; Mon, 8 Aug 2011 15:28:22 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p78JSJ0W030559 for <rbridge@postel.org>; Mon, 8 Aug 2011 15:28:19 -0400
Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.63.8.33]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p78JSHcX030419; Mon, 8 Aug 2011 15:28:17 -0400
In-Reply-To: <05b301cc5293$d1e2beb0$75a83c10$@com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com> <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com> <05b301cc5293$d1e2beb0$75a83c10$@com>
X-KeepSent: 866A7B89:08EB955A-852578E6:005C935D; type=4; name=$KeepSent
To: Yizhou Li <liyizhou@huawei.com>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OF866A7B89.08EB955A-ON852578E6.005C935D-852578E6.006AF584@us.ibm.com>
From: David M Bond <dmbond@us.ibm.com>
Date: Mon, 08 Aug 2011 15:28:14 -0400
X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 08/08/2011 15:28:16
MIME-Version: 1.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: dmbond@us.ibm.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 Yizhou, My main concern here is that the data must be able to look like real data at least up to the end of the inner ethernet header otherwise the OAM will be useless if we can't get the data to follow a path data is failing on. So I guess there are two questions here: 1) Do we allow the Inner.MacDA to be anything other than the reserved address? I think we have to otherwise we face the problem mentioned above. If we do allow this should the current channel draft be updated to allow for this exception? 2) If we allow #1 then an egress Rbridge would have to listen for the OAM Inner.ethertype and not de-encapsulate that data: rather it would need to send the frame to the OAM processing. Is this what you are asking for more explanation on below? Also, I like your idea about using the native rbridge channel frames. If I understand it correctly essentially this would be involving end stations in the oam protocol, the only problem is it would only work for ping whereas traceroute requires the hop count to be varied and the end stations can only send "untamed" native frames. Thanks, David From: Yizhou Li <liyizhou@huawei.com> To: David M Bond/Bedford/IBM@IBMUS Cc: d3e3e3@gmail.com, "'Erik Nordmark'" <nordmark@acm.org>, rbridge@postel.org, vishwas.manral@hp.com Date: 08/04/2011 06:47 AM Subject: RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00 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