Re: [Detnet] I have some question for your draft.

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 August 2016 13:08 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B0E12D53D for <detnet@ietfa.amsl.com>; Thu, 4 Aug 2016 06:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 u5qqdmRjesSP for <detnet@ietfa.amsl.com>; Thu, 4 Aug 2016 06:08:10 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808AE12B04D for <detnet@ietf.org>; Thu, 4 Aug 2016 06:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16941; q=dns/txt; s=iport; t=1470316090; x=1471525690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dNEXmXqqMn1G1jfrGUGP01XCsRAPs5NGYQKPf7Rwa1o=; b=S+S3/QI81pUhg4LbHd3LMD1ifUvNUhlBcftTIPFhZX3eU/mCyovQd6sM bh80fK6Bc0UUHoWGe9FOJduw3A3sq1e+57xW7RAxWPilJqBpcoHfrVSkK Vwcr7gVqYZkk58nUzvBVfG20ZQk6eIAwk8SQjJzWYABhwp0LOr8q1R+9Y g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BcAgBMPaNX/51dJa1dgndOVoEDqCyQaIF9hh0CHIE2OBQBAQEBAQEBXSeEXwEFLUwQAgEIRgIwJQIEAQ0NiCm+aAEBAQEBAQEBAQEBAQEBAQEBAQEBARwRhhmETYobBZNxhUMBjnqBcoRbiHqQJwEeNoN6hzx/AQEB
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208,217";a="134195244"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 13:08:09 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u74D89B7026713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Aug 2016 13:08:09 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 Aug 2016 08:08:08 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 4 Aug 2016 08:08:08 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: ??? <dbduscjf@etri.re.kr>, "Toerless Eckert (eckert)" <eckert@cisco.com>
Thread-Topic: I have some question for your draft.
Thread-Index: AQHR4aJrz2FH6jBEx0O0vFWPY92wOKA42ACg
Date: Thu, 04 Aug 2016 13:07:44 +0000
Deferred-Delivery: Thu, 4 Aug 2016 13:07:17 +0000
Message-ID: <2b428b440c3f44dcb44865e2ec12add3@XCH-RCD-001.cisco.com>
References: <98CC147D-AF3C-41AF-8BED-4FA5EC483FB0@etri.re.kr>
In-Reply-To: <98CC147D-AF3C-41AF-8BED-4FA5EC483FB0@etri.re.kr>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.243.98]
Content-Type: multipart/alternative; boundary="_000_2b428b440c3f44dcb44865e2ec12add3XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/CEoqhORiOEc2MbIQ-OrRNKG4vi0>
Cc: ??? <ryoo@etri.re.kr>, "detnet@ietf.org" <detnet@ietf.org>, "bier(mailer list)" <bier@cisco.com>, "draft-eckert-bier-te-arch@tools.ietf.org" <draft-eckert-bier-te-arch@tools.ietf.org>
Subject: Re: [Detnet] I have some question for your draft.
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 13:08:12 -0000

Hello Yeoncheol

Thanks for raising the point.

I agree that there is a discrepancy but I think the detnet dataplane draft is correct and we need to work on the BIER-TE side.

Please see below :

As we discussed yesterday evening after the DetNet session, I am sending you my comment on the example shown in detent-dp-alt draft.


In page 32 of draft-dt-detnet-dp-alt-01, replication node A sends duplicated packets to nodes B and C. The packet going to node B has BitString = 00011110 and the packet going to node C has BitString = 01001110.

But, according to the BIER-TE forwarding process (draft-eckert-bier-te-arch-03, p12), node A must reset both p2 and p4 in BitString before sending. Then, nodes B and C will receive the same bitString 00001110.


I think you are referring to the text “



   Before

   sending any copy, the BFR resets all BitPositions in the BitString of

   the packet to which it can create a copy.  This is done to inhibit

   that packets can loop.


 “ and “





   BFR3 sees a BitString of p5,p7,p8,p10,p11,p12.  It is only interested
   in p1,p7,p8.  It creates a copy of the packet to BFER1 (due to p7)
   and one to BFR4 (due to p8).  It resets p7, p8 before sending.
“

DetNet needs BIER-TE to operate as described in the DetNet dataplane draft. A bit is reset when sending on the related adjacency. This is how the DetNet draft obtains traceability: the bits setting indicate which copy this is, by whom to whom, in a unique fashion. This is also how DetNet figures the transmission failures: if the bit arrives reset at destination, it means that this transmission worked over that adjacency. So with the DetNet operation, BFR3 resets p7 in the copy to BFER1 and resets p8 in the copy to BFR4.

OTOH I think that the DetNet operation fits the needs of BIER-TE to avoid loops. Once a packet has flown over an adjacency, it will not fly there again. So I think the change should be done on the BIER-TE draft. What do the authors think?

Pascal