Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

Xiejingrong <xiejingrong@huawei.com> Fri, 12 July 2019 11:25 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892EE120471; Fri, 12 Jul 2019 04:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QKqYPwXj0JVQ; Fri, 12 Jul 2019 04:25:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90971200E3; Fri, 12 Jul 2019 04:25:13 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 22A70EB01FCC38D264BB; Fri, 12 Jul 2019 12:25:11 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 12:25:10 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Fri, 12 Jul 2019 19:19:44 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: Antoni Przygienda <prz@juniper.net>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "draft-zhang-bier-bierin6@ietf.org" <draft-zhang-bier-bierin6@ietf.org>, BIER WG <bier@ietf.org>
Thread-Topic: Questions regarding <draft-zhang-bier-bierin6-03>
Thread-Index: AdU2IrLV6PANcPQ8TJ2wzjJsYLxNqQAHa6GgAHBJYdsAJ5LssA==
Date: Fri, 12 Jul 2019 11:19:43 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8DD5B0@nkgeml514-mbx.china.huawei.com>
References: <16253F7987E4F346823E305D08F9115AAB8DC468@nkgeml514-mbx.china.huawei.com>, <DM5PR05MB3548E853C20E03CC58C7956BD4F10@DM5PR05MB3548.namprd05.prod.outlook.com> <MWHPR05MB32792FD6E09E4444B8DF45C3ACF30@MWHPR05MB3279.namprd05.prod.outlook.com>
In-Reply-To: <MWHPR05MB32792FD6E09E4444B8DF45C3ACF30@MWHPR05MB3279.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8DD5B0nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/zIMIwfR1qFTRG6YdzJSLHjYNhMU>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 11:25:16 -0000

Hi Tony,

Exactly, the whole v6 extension headers(EH) and the v6 options consideration is basically a first stab!

Once a judgement is based on the "Upper-layer Protocol", the last next header of a chain, then a walk through the chain is unavoidable, to "dig out" the right format that need to be processed in fast-path.

The difficulty with a "regular" IPv6 DA is that, normal things like TCP/UDP/ICMPv6 packet must be handled without much impact on it.

Use a "XXX specific IPv6 DA" is not only the SRv6-NetworkProgramming concept, but also the ISO NSAP address as I learned from a book and found in the WIKI https://en.wikipedia.org/wiki/NSAP_address:

The NSEL (Network-Selector) is a field in the NSAP address that identifies the network layer<https://en.wikipedia.org/wiki/Network_layer> service to which a packet should be sent.

BIER forwarding seems match very much a "network layer service" in my opinion, and the "AB37" in "2019::AB37" is very similar to a NSEL too.

Thanks
Jingrong


From: Antoni Przygienda [mailto:prz@juniper.net]
Sent: Friday, July 12, 2019 12:02 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Xiejingrong <xiejingrong@huawei.com>; draft-zhang-bier-bierin6@ietf.org; BIER WG <bier@ietf.org>
Subject: Re: Questions regarding <draft-zhang-bier-bierin6-03>



2.1.  IPv6 Options Considerations



   RFC 8200 section 4, defines the IPv6 extension headers.  Currently

   there are two defined extension headers, Hop-by-Hop and Destination

   options header, which can carry a variable number of options.  These

   extension headers are inserted by the source node.



   For directly connected BIER routers, IPv6 Hop-by-Hop or Destination

   options are irrelevant and SHOULD NOT be inserted by BFIR on the

   BIERin6 packet.  In this case IPv6 header, Next Header field should

   be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with

   multiple extension header where the last extension header has a Next

   Header field set to TBD, SHOULD be discard and the node should

   transmit an ICMP Parameter Problem message to the source of the

   packet (BFIR) with an ICMP code value of TBD10 ('invalid options for

   BIERin6').

[XJR Q6]: You have to walk the ext header chain and get the last NH to judge if this packet need to be discard, right? For example for an incoming packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to walk the whole extension header chain until you know the last NH, to execute the above "discard" action. Right?





prz> topic for discussion. The whole v6 options consideration is basically a first stab.



   This also indicates that for disjoint BIER routers using IPv6

   encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination

   options be present in a BIERin6 packet.

[XJR Q7]: What does "disjoint BIER router" mean?



prz> non-adjacent, good catch