Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Xiejingrong <xiejingrong@huawei.com> Thu, 18 July 2019 11:34 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 AE0E71201CA; Thu, 18 Jul 2019 04:34:46 -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 NkiW3q9qOYc1; Thu, 18 Jul 2019 04:34:43 -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 F1E201201DB; Thu, 18 Jul 2019 04:34:42 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A6800FFF9756971EB2DC; Thu, 18 Jul 2019 12:34:40 +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; Thu, 18 Jul 2019 12:34:40 +0100
Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.142]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Thu, 18 Jul 2019 19:33:00 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "gjshep@gmail.com" <gjshep@gmail.com>, BIER WG <bier@ietf.org>
CC: "'draft-xie-bier-ipv6-mvpn@ietf.org'" <draft-xie-bier-ipv6-mvpn@ietf.org>, "draft-xie-bier-ipv6-isis-extension@ietf.org" <draft-xie-bier-ipv6-isis-extension@ietf.org>, "draft-geng-bier-ipv6-inter-domain@ietf.org" <draft-geng-bier-ipv6-inter-domain@ietf.org>, "draft-xie-bier-ipv6-encapsulation@ietf.org" <draft-xie-bier-ipv6-encapsulation@ietf.org>
Thread-Topic: [Bier] BIER WG, Call For Agenda, Montreal IETF 105
Thread-Index: AQHVNcSpurLRu4KtS0eNbFcj5+1c/6bBeeIQgAV8GACAANGp44AAA/ki//+JKICAAI2NUIAAChcQgAhgvJk=
Date: Thu, 18 Jul 2019 11:33:00 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8F2EAB@nkgeml514-mbs.china.huawei.com>
References: <CABFReBo=+68gyhsFwYktcc1Mr7zkax2MiYFCTSC5osod48x3Jw@mail.gmail.com> <16253F7987E4F346823E305D08F9115AAB8DC2D1@nkgeml514-mbx.china.huawei.com>, <DM5PR05MB3548731B6AE229EA12451E21D4F20@DM5PR05MB3548.namprd05.prod.outlook.com>, FB695EED-E2D2-4703-A6BE-277AB0B6101D 889A6D5B-2262-4C67-A784-C02F0C537837, <DM5PR05MB35483025AF2E360884362796D4CD0@DM5PR05MB3548.namprd05.prod.outlook.com>, <16253F7987E4F346823E305D08F9115AAB8DDBD5@nkgeml514-mbx.china.huawei.com>, <16253F7987E4F346823E305D08F9115AAB8DDC15@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB8DDC15@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.124.95.124]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8F2EABnkgeml514mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/eq7nhTUbdDduwu5Do6qIZ3fiTZU>
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105
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: Thu, 18 Jul 2019 11:34:47 -0000

Hi Jeffrey,
I haven't seen your reply since this.
Are all questions clear to you ?

Thanks
Jingrong
________________________________
From: Xiejingrong
Sent: Saturday, July 13, 2019 12:19
To: Jeffrey (Zhaohui) Zhang; gjshep@gmail.com; BIER WG
Cc: 'draft-xie-bier-ipv6-mvpn@ietf.org'; draft-xie-bier-ipv6-isis-extension@ietf.org; draft-geng-bier-ipv6-inter-domain@ietf.org; draft-xie-bier-ipv6-encapsulation@ietf.org
Subject: RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

I clean the mail. Please see the [XJR2], and [XJR2a]:

主 题:RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong, Liang,
I have some questions and comments on two of the drafts.
draft-xie-bier-ipv6-encapsulation-02
·        Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstreams.
·        [XJR] Absolutely! The use of multicast DA can't support some very common usecases that may be assumed as Architecture of BIER. I agree with you to assume using a unicast DA. I will update the draft this way in next version.
·
·        Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
·        [XJR] Yes, use of the address of the BFIR and keep it unchange when a packet fly through the BFRs is a key of the proposal. I think there is already examples of Source rooting that keep the source address unchange while change the DA in the fly. I would understand the BIER technology as a Multicast source routing!
Zzh> First of all, BIER is not source routing, even though BIER is the best multicast solution for SR because it does not have per-flow/tunnel/tree state in the core (yet BIER is independent of SR). Source routing means the source (router) determines the path of the packets. BIER is not like that. The BitString only specifies the set of BFERs.
[XJR2] Yes. source routing is specifying the path, while the BIER specifies the BFERs(target routers). But they both specify multiple things (Paths or BFERs) in the source.
What I really mean is that, there is already examples to keep the Source Address unchanged while Dest Address changes on the fly of a packet.
Zzh> As I pointed out, the IPv6 header is only to get the packet from BFR1 (vs. BFIR) to BFR2 (whether they’re directly connected or not) – one-hop or multi-hop tunneling, so it makes sense to use the BFR1’s address as SA.
[XJR2] I would prefer the unchanging of Source Address as a type of "Uniform" mode of MPLS, not the "Pipe" mode of MPLS. It may still be a kind of "tunneling", but is from the BFIR to BFERs, not segmented tunnels, say a tunnel from BFR A to BFR B, and then another tunnel from BFR B to BFR C. Also in the proposal, the TTL will decrease even on a Non-BFR router between BFR A and BFR B.
Zzh> Having said that, if you could convince everyone that the BFIR’s address should be used, then draft-zhang-bier-bierin6-03 could do the same.
[XJR2] Yes I insist on the use of BFIR's address being used. Bierin6 may also use this way, but I am not sure since there is no such exapmles. BIERv6 on the other hand has such examples since Routing Header is also a kind of EH and is assumed to be part of the network-layer(L3) behavior, and uses the same "Function specific IPv6 DA".
·        With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?
·        [XJR] there are more similarities since I (and you may also agree) want to use unicast DA only. but the difference is mainly two: one is use the address of BFIR without change in the fly as above point. one is use of a BIER specific ipv6 address in DA, which preceding any of the possible EHs and assume being the most efficient for fast path and most less impact on exist IPv6 functions.
Zzh> If you use unicast DA, what’s the BIER specific IPv6 address to use?
[XJR2] to do a "BIER specific forwarding" while doing less impact on existing IPv6 functions. Here is an example for an incoming packet(don't expect if it is a bad packet).
Result = FIB Lookup
switch (Result):
  case Local-Interface-Address:
    send to CPU
  case Non-Local-Interface-Address routable:
    forwarding it
  case BIER-specific-Address
    do BIER forwarding if packet is the good pattern.
    drop packet if packet is not the good pattern.
end-of-switch.
The first 2 cases won't be impact, or have very little impact. Because of the switch-handling can be optimized.

How would it work for multi-hop tunnel?
[XJR2] This BIER specific IPv6 address is well visual to an operator, and it can be easier to configure this address in the other side of a multi-hop endpoint.

Why would that be most efficient and least impact existing IPv6 functions?
[XJR2] See above pseudo-code which I think is the most efficient and least impact.

To me using NH=BIER would be the most straightforward and least impactful to existing IPv6 functions.

Zzh> If I could ask a rhetorical question – would you put TCP or UDP header in an IPv6 Destination Option hdr?
[XJR2] TCP/UDP header is indicated by the last NH. Well I guess your concern is that, using BIER-specific still don't optimize the forwarding when considering there is possible any kind of EHs and Upper-layer Nextheaders. I will explain this in another mail to avoid lost of this mail.
[XJR2a] inside the branch of "BIER-specific-address" case, it can be further optimized for BIER forwarding or necessary processing like ICMPv6. Other undesired packet is simply dropped (very similar to an "IPv6 DA specific" ACL).
  case BIER-specific-Address
    do BIER forwarding if packet is the good pattern.
    drop packet if packet is not the good pattern.


draft-geng-bier-ipv6-inter-domain-00
·        Can you elaborate the following?
Note: Use of the IPv6 address configured on PE1 to identify an MVPN
instance can eliminate the need for BFR-id configuration on PE1x,
which otherwise has to be configured from the space of a sub-domain.
·        For the “peering multicast”, how many BIER sub-domain do you have?
·        [XJR] haven't evaluate that so far.I initiate this idea when I found a recent rfc8313 and thought of the tenant spanning multiple DCs. Also I assume the multicast as a service draft for this case.
·        Zzh> If I understand it correctly, the draft seems to assume only a single sub-domain.
·         [XJR2] Yes, also use a single sub-domain for multicast deployment.

·        What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
·        [XJR] the hierarchical one is a P2MP case like IPTV in service provider. The peering one is an MP2MP case where the multicast source may be more unpredictable.
Zzh> From BIER point of view, there is no difference, right?
[XJR2] I can answer this later in another mail.
[XJR2a] From BIER point of view, there is still some difference.
In current BIER Architecture, BIFT is constructed per the tuple of <SD/BSL/SI>.
In the above Color case, BIFT is constructed per the tuple of <Color/SD/BSL/SI>.
There may be some consideration of supporting multiple encapsulation in one <SD/BSL>, then the BIFT may be constructed per the tuple of <SD/BSL/Encap/SI>.
Note the multicast overlay need to steering a flow to <Color/SD/BSL/SI> instead of <SD/BSL/SI>.
·
·        What’s the significance of “inter-domain” here, that requires this new draft?
·        [XJR] there is still no inter-domain BIER underlay construction, which I would think comparable to the so called non-segmented mvpn solution. It is the idea in my mind since the first presentation in ietf102 to deploy inter-domain BIER underlay. Also impressed by the points of multicast as a service you proposed.
Zzh> The reason I asked that question is that, in this single sub-domain scenario, there is really nothing new wrt inter-domain. You can use IGP signaling, BGP signaling, draft-zwzw-bier-prefix-redistribute, and draft-zzhang-bier-multicast-as-a-service procedures together to signal and build BIFTs. You can of course use static configuration, but that also applies to intra-domain and does not seem to warrant a specific spec for “inter-domain”.
[XJR2] I will use another mail too. But I can quickly figure out now one point different: in our proposal, the routers (if exist) in between PE1x and BR1 won't have to run IGP/BGP to setup the BIFT to BR1.
[XJR2a] static-configuration is not desired in intra-domain case since there is so automated IGP deployment.
For Inter-domain case (mainly about inter-AS case as this document examples), static-configuration can be used, and I am used to understand things clearly by using static-configuration first.
I will try to learn and understand how the dynamic protocol as proposed above can be used for inter-domain.

·        What’s the uniqueness of IPv6 here?
·        [XJR] I found it difficult to construct the inter-domain BIFTs since the BIER-MPLS label is dynamic. Use of a static SRGB label as BIER-MPLS of a BR(border router) is waste ful, while use the SRGB for the entire domain seems not welcome in ietf102.
Zzh> I don’t follow. BIER label is indeed completely local and dynamic, but whether it is intra or inter-domain is irrelevant? Not sure why SRGB was brought up here.
Zzh> Besides, how does IPv6 solve this problem? You still have BIFT-ID, which could be dynamic just like MPLS label or could be hardcoded but that can work without IPv6 as well.
[XJR2] I will use another mail too.
[XJR2a] AS above, I am used to understand things quickly by using static-configuration first once possible. So SRGB is a thing I could thought of to use for static-configuration.
The dynamic BIFT-ID is difficult for static-configuration. This document assume the 'SD-BSL-SI' auto-generation of BIFT-ID is used consistently in all BFRs, and there are text in the document.
Thanks
Jingrong

Zzh> Jeffrey
·        Thanks.
·        Jingrong.

Thanks!
Jeffrey
From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Xiejingrong
Sent: Monday, July 8, 2019 9:30 PM
To: gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Cc: 'draft-xie-bier-ipv6-mvpn@ietf.org' <draft-xie-bier-ipv6-mvpn@ietf.org<mailto:draft-xie-bier-ipv6-mvpn@ietf.org>>; draft-xie-bier-ipv6-isis-extension@ietf.org<mailto:draft-xie-bier-ipv6-isis-extension@ietf.org>; draft-geng-bier-ipv6-inter-domain@ietf.org<mailto:draft-geng-bier-ipv6-inter-domain@ietf.org>; draft-xie-bier-ipv6-encapsulation@ietf.org<mailto:draft-xie-bier-ipv6-encapsulation@ietf.org>
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105
We’d like to request 35-40 minutes for the presentation of the following BIERv6 drafts.  I will be the speaker (may have some adjustment before the session).
BIERv6 Encapsulation // draft-xie-bier-ipv6-encapsulation-02, 15min
BIERv6 via IS-IS // draft-xie-bier-ipv6-isis-extension-00  10min
MVPN using BIERv6 // draft-xie-bier-ipv6-mvpn-01            5min
Inter-domain Multicast Deployment using BIERv6  // draft-geng-bier-ipv6-inter-domain-00 10min
Thanks
Jingrong on behalf of the authors
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Tuesday, July 09, 2019 3:37 AM
To: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105
Please send agenda items with title, draft, speaker name, and requested time to this thread.
Thanks,
Shep
(chairs)

Juniper Business Use Only