Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
David M Bond <dmbond@us.ibm.com> Wed, 03 August 2011 18:50 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 5A43F11E8084 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Wed, 3 Aug 2011 11:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.965
X-Spam-Level:
X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.566, 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 gQYQfu70thrh for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Wed, 3 Aug 2011 11:50:09 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08311E807D for <trill-archive-Osh9cae4@lists.ietf.org>; Wed, 3 Aug 2011 11:50:06 -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 p73IUdvc004767; Wed, 3 Aug 2011 11:30:40 -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 p73IUNTC004730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 3 Aug 2011 11:30:33 -0700 (PDT)
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p73IHGKS008345 for <rbridge@postel.org>; Wed, 3 Aug 2011 14:17:16 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p73IUHIM198104 for <rbridge@postel.org>; Wed, 3 Aug 2011 14:30:17 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p73IUCkW002291 for <rbridge@postel.org>; Wed, 3 Aug 2011 15:30:14 -0300
Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.63.8.33]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p73IUBPQ002189; Wed, 3 Aug 2011 15:30:11 -0300
In-Reply-To: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
X-KeepSent: 15377FFD:522CBB40-852578E1:005470BB; type=4; name=$KeepSent
To: Liyizhou <liyizhou@huawei.com>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
From: David M Bond <dmbond@us.ibm.com>
Date: Wed, 03 Aug 2011 14:30:09 -0400
X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 08/03/2011 14:30:10
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" <d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, "rbridge@postel.org" <rbridge@postel.org>, "vishwas.manral@hp.com" <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, 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