Re: [Bier] Comments on draft-zhang-bier-flooding

<zhang.zheng@zte.com.cn> Fri, 10 November 2017 01:38 UTC

Return-Path: <zhang.zheng@zte.com.cn>
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 9965B127AD4; Thu, 9 Nov 2017 17:38:03 -0800 (PST)
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, UNPARSEABLE_RELAY=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 F6HeWDKJzuPd; Thu, 9 Nov 2017 17:38:02 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 A241812426E; Thu, 9 Nov 2017 17:38:00 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 90506C3A403ABD9FEB55; Fri, 10 Nov 2017 09:37:58 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 7CC31D41DAE1E5DE3A35; Fri, 10 Nov 2017 09:37:58 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse02.zte.com.cn with SMTP id vAA1bQH9022367; Fri, 10 Nov 2017 09:37:26 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Fri, 10 Nov 2017 09:37:27 +0800 (CST)
Date: Fri, 10 Nov 2017 09:37:27 +0800
X-Zmail-TransId: 2afa5a0502d7403-4241b
X-Mailer: Zmail v1.0
Message-ID: <201711100937275877939@zte.com.cn>
In-Reply-To: <DM5PR05MB3145F3F771BF0977057C45FDD4540@DM5PR05MB3145.namprd05.prod.outlook.com>
References: DM5PR05MB3145F3F771BF0977057C45FDD4540@DM5PR05MB3145.namprd05.prod.outlook.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: zzhang@juniper.net
Cc: bier@ietf.org, pim@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse02.zte.com.cn vAA1bQH9022367
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/oilGf5X_a8L2wGQ5aMsXGKWvq7w>
Subject: Re: [Bier] Comments on draft-zhang-bier-flooding
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Nov 2017 01:38:04 -0000

Hi Jeffrey,







Thanks for your comments!


The method you mentioned is like treating the border router as a BIER proxy, it works in the situation that the regions connected with border router are all running IGP/ BGP routing protocols. And I think it is a solution though it increase the complexity of border routers. 


But it doesn't work well if static configured routes are used in at least of one region. So if you have any better idea about static configured routing region?






Thanks,


Sandy











原始邮件




发件人: <zzhang@juniper.net>;
收件人: <bier@ietf.org>; <pim@ietf.org>;
日 期 :2017年11月10日 08:44
主 题 :[Bier] Comments on draft-zhang-bier-flooding






 Hi Sandy,
 During a recent offline discussion on OSPF/ISIS inter-area BIER signaling, I brought up that when an area border router re-advertise into another area, it does not need to advertise the encapsulation sub-TLV, because routers in other areas won't use that information at all. All that is needed is the BFR-IDs.
 The same could be applied to the use case you're describing:
 
                                |                |
                     .........|................|..........
                     .  ISIS  |                |        .
                     .        |                |        .
                     .       MR1--------------MR2       .
                     .        |  .          .  |        .
                     .        |    .      .    |        .
                     .        |      .  .      |        .
                     .        |       ..       |        .
                     .        |     .    .     |        .
                     .        |   .        .   |        .
                     .        | .            . |        .
                     .        MR3              MR4      .
                     .       /  \             /  \      .
                     .....................................
                            /    \           /    \
                           /      \         /      \
                          /        \       /        \
                     ...................  .................
                     .    B1--------B2 .  .B3--------B4  .
                     .                 .  .              .
                     .   Rm            .  . Rx           .
                     .       ...       .  .     ...      .
                     .            Rn   .  .         Ry   .
                     .                 .  .              .
                     .         OSPF    .  .       OSPF   .
                     ...................  .................
                       Figure 1: An typical hybrid network
 So, I don’t see a need to use BSR to flood the BIER info across those different routing domains. As long as the border routers advertise the BFR-IDs of its downstream nodes to neighboring border routers, and its neighboring border routers continue to advertise the BFR-IDs of those downstream nodes, it will work.
 For example, MR3 has to learn routes to Rm…Rn somehow – as long as that learning includes the BFR-IDs of Rm…Rn, and MR3 advertises those to its neighbors in the ISIS domain and so on, things will work.
 Jeffrey