IETF Logo Mail Archive

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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 10 November 2017 04:01 UTC

Return-Path: <zzhang@juniper.net>
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 0955412943A; Thu, 9 Nov 2017 20:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level:
X-Spam-Status: No, score=-4.8 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 Ij9Vg14UkQJy; Thu, 9 Nov 2017 20:01:34 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0139.outbound.protection.outlook.com [104.47.38.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A4A12942F; Thu, 9 Nov 2017 20:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s4aoLUaoEA6MQJyPzfK9t2cGTgeOlGV6B0EOwS1uv6I=; b=eB9Gz82qvpeaJKk9I1ZB5MPqqEIka1OhuC+nh2Cry7qR9dEW60c71cG0RL9fm5nQZVTCoEdhSCnb6IfdMhXXzP7BUfoisdi/4tzUUfyNPxaG4KSv7DEZs8GHpgVJUXLZklqy8gJp/c/tBr4kAvvGwb9zs8lJxE0O7OKYddo12zQ=
Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3147.namprd05.prod.outlook.com (10.173.219.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Fri, 10 Nov 2017 04:01:31 +0000
Received: from DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) by DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) with mapi id 15.20.0239.004; Fri, 10 Nov 2017 04:01:31 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
CC: "bier@ietf.org" <bier@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [Bier] Comments on draft-zhang-bier-flooding
Thread-Index: AdNZu1qQrnBGKjw6ReC0e9uBiQtrNQACRyCAAAT8HDA=
Date: Fri, 10 Nov 2017 04:01:31 +0000
Message-ID: <DM5PR05MB31457E12C09F3E031597E9BAD4540@DM5PR05MB3145.namprd05.prod.outlook.com>
References: DM5PR05MB3145F3F771BF0977057C45FDD4540@DM5PR05MB3145.namprd05.prod.outlook.com <201711100937275877939@zte.com.cn>
In-Reply-To: <201711100937275877939@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3147; 6:lRecUT42wWM0dQvUIK1rZjkwtQbwwpsEGtXIoO0iQGabgRsFElKXT9BAZC7TYpUd8NXqna9vIbS8tym71vsSIdE5rtj1J0qu+dVqd4iSWjSeS4G1qvh/PpErXUDZEOug/HQ3FcJ7LznfLs6UDmo4WJOzTJrs5T62QVoiYl2bBBYCmLBM212NQhyvlFEvTljIVzEuKdZiWor+jPeebzupMh2rg1034xfNGxaUtkaIWY+XVHwCDF18wjCfbbhmmzBTbpGfHZo15/+rSNA7T1VnolY1PlI/vQYndWbpWoLO8i4FiBuURxhbPFYBjMl/Ru2eXHzmEwXvM/jBY27xtltZLkQrZhgECeVngyZD20qXDfg=; 5:H7ZYv/VjIEpABLouN6W36rg8IGm+Fje21c1C1x7LQ6pERbsUdDbgIBVZYA8Q/d+U+WODM2Vtn1jYq5CxCMBeMDHY+ocrUN/IiD+EHfyqwYDRKDPfBseOLXgpAv8F8VHutJwB5BtVoxrVCutPcZ1b4HCHiqrLha/uJAmCBWsTnMc=; 24:aZME4Q7+YaZU2k00+VuCKb5aLbqH9jT/cgEMcW5Fl/NqmSsx87Vnu2qRHsZO2/kMgBWzU7ntOYm+rub/dmzPZa43dmxnLbyX+DYilVPOy/k=; 7:wiKri9sis3Qi5KIxmG58eFNLNPCLi8nttwYfdM3kjoG0Kb2NczFqRlyJGDbQu+iKNoNX83WhV3n4/ADJi9eZs4/FIuAIQv3zWG2StP7+iSKb7f6oLYllIA3NHLlRcQa2IZsgl0EJ/2GwGrW1vxmMg2pmFoO5BT/5IaP0fVj8wMnBfwdhMSk5rMM039d2xe4tVcKzqk2444OvoPSkjCEPhOgYihbmtwm1rDDinfbV6PLNx4j376hGNxFXhDKrYeLR
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8aef8c3c-2ffe-4ed2-c3c4-08d527efba46
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603256); SRVR:DM5PR05MB3147;
x-ms-traffictypediagnostic: DM5PR05MB3147:
x-exchange-antispam-report-test: UriScan:(138986009662008)(21748063052155);
x-microsoft-antispam-prvs: <DM5PR05MB314774C27539DE4E72B01D9AD4540@DM5PR05MB3147.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3231021)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3147; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3147;
x-forefront-prvs: 0487C0DB7E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(376002)(346002)(199003)(189002)(53946003)(3846002)(6506006)(6116002)(55016002)(33656002)(5660300001)(25786009)(101416001)(14454004)(54356999)(6246003)(790700001)(54906003)(189998001)(316002)(7696004)(8936002)(2900100001)(68736007)(2950100002)(77096006)(53936002)(50986999)(9326002)(6916009)(102836003)(76176999)(6436002)(4326008)(236005)(97736004)(54896002)(2501003)(9686003)(81156014)(81166006)(478600001)(8676002)(86362001)(2906002)(53546010)(6306002)(99286004)(66066001)(230783001)(7736002)(74316002)(2351001)(3660700001)(105586002)(3280700002)(106356001)(5640700003)(229853002)(579004)(559001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3147; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR05MB31457E12C09F3E031597E9BAD4540DM5PR05MB3145namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8aef8c3c-2ffe-4ed2-c3c4-08d527efba46
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2017 04:01:31.8035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3147
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/p83G2lg9GvfTH9F94fDAxoo7-X0>
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 04:01:37 -0000

Hi Sandy,

If an operator is happy with configuring static routes for remote BFERs, would it be acceptable to configure the BFR-IDs for those remote BFERs along with the static routes?

Jeffrey

From: zhang.zheng@zte.com.cn [mailto:zhang.zheng@zte.com.cn]
Sent: Thursday, November 9, 2017 8:37 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bier@ietf.org; pim@ietf.org
Subject: Re: [Bier] Comments on draft-zhang-bier-flooding


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<mailto:zzhang@juniper.net>>;
收件人： <bier@ietf.org<mailto:bier@ietf.org>>; <pim@ietf.org<mailto: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

v2.23.0 | Report a Bug | By Email