Re: [Bier] comments for draft-xie-bier-ipv6-encapsulation

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Sun, 15 March 2020 03:33 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 619883A0D4F for <bier@ietfa.amsl.com>; Sat, 14 Mar 2020 20:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 9eGtkVwP3Il7 for <bier@ietfa.amsl.com>; Sat, 14 Mar 2020 20:33:35 -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 C02BE3A0D4E for <bier@ietf.org>; Sat, 14 Mar 2020 20:33:34 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 54954E4FEDD36FEF6B6E; Sun, 15 Mar 2020 03:33:32 +0000 (GMT)
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 15 Mar 2020 03:33:31 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 15 Mar 2020 11:33:28 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Sun, 15 Mar 2020 11:33:28 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "bier@ietf.org" <bier@ietf.org>, "tonysietf@gmail.com" <tonysietf@gmail.com>, "gjshep@gmail.com" <gjshep@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: [Bier] comments for draft-xie-bier-ipv6-encapsulation
Thread-Index: AQHV+Y1Mk8ekwv+g5kqtAwzNseD/hKhI/nyA
Date: Sun, 15 Mar 2020 03:33:28 +0000
Message-ID: <53317074a12e4772921e13cd1b1c915a@huawei.com>
References: <20200313231513.GA64126@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200313231513.GA64126@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.219.173]
Content-Type: multipart/alternative; boundary="_000_53317074a12e4772921e13cd1b1c915ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Av4jHkbS2VSvCkyVF-Siu01EVCA>
Subject: Re: [Bier] comments for draft-xie-bier-ipv6-encapsulation
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: Sun, 15 Mar 2020 03:33:38 -0000

Hi Toerless,



Thanks a lot for the higher level questions and points!

Please see below inline my answer [A1] to [A7].

Cc'ed the chairs and AD since I think it is related ---- see answer 3 [A3] to point 3.



Best regards,

Jingrong



-----Original Message-----
From: Toerless Eckert [mailto:tte@cs.fau.de]
Sent: Saturday, March 14, 2020 7:15 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: bier@ietf.org
Subject: Re: [Bier] comments for draft-xie-bier-ipv6-encapsulation



Jingrong, *:



Some higher level Q)uestions P)oints hopefully we can circle in on the probably most important issues for the details before getting back to my nitpicking on details.



Q1: Why is https://tools.ietf.org/html/draft-xie-bier-ipv6-mvpn-02 expired and not even referenced in draft-xie-bier-ipv6-encapsulation ?



If i wanted to understand why the encap does the BFIR-to-BFER IPv6 encap with option header, then the reason really is to enable 'MVPN'

over BIER, right ? So one would like to know where that is specified, which seems to be that mvpn draft of yours, right ? Aka: should be refreshed and referenced ?

[A1]: The reason it's not referenced is that, I think the layering mode of BIER-layer and Multicast-overlay-layer is quite clear as is defined in RFC8279 section 4.

The BIER-IPv6 is the basis and the BIERv6-MVPN is overlay.

I am not aware of that it could be a confusing.

Maybe an informative reference to the BIERv6-MVPN ?

BTW: the https://tools.ietf.org/html/draft-xie-bier-ipv6-mvpn-02 is not expired.



Q2: I am totally not on top of BESS, but it seems thats where the SRv6 version of e.g.: MVPN (over MPLS) is defined ? And those solutoins are called 'overlay' because there are on top of IPv6, but functionally its mostly equialent to what we've done over MPLS forever without calling it overlay, right ? (sorry, just trying to unconfuse myself, not really about your draft, but more the question what makes a soution 'overlay', and it seems just : replace MPLS with IPv6 and stuff running on top of it must be named overlay ?).

[A2] SRv6 based services(VPN,EVPN,etc) are all defined in <draft-ietf-bess-srv6-services> but MVPN is excluded.

The name of overlay seems to me more like coming from NVO3 ---- where the underlay is IP/IPv6, and overlay means VPN/EVPN/MVPN including the Tenant packet and Tenant identifier (VNI).

The name of overlay has been common in drafts and RFCS ---- RFC8279 is one example, many other BESS drafts also use the name, but no strict definition yet.

I understand the same as you that its mostly equivalent to what have done over MPLS, with distinct I understand is that the layering of overlay and underlay is not well decoupled, e.g., underlay is driven by overlay like the mLDP/RSVP-TE is driven by MVPN to build a tree.

So be relaxed about the concept of overlay and just follow the feeling:

Overlay = service (VPN/EVPN IRB/L2VPN/MVPN/etc),

Underlay = transport(IP/routing/reachability/LSP/tunnel/etc).





P3: The ability of the choosen header to pass 6man RFC8200 police seems quite important. See how long SRH draft was hold up in the discuss.

I am not aware whether there is evidence that any other destination option today does what the routing header, e.g.: RFC6554/SRH are doing, keeping the source address while changing the dest address.



If they do not like destination option header, it could become a routing header. If anyone in 6man has rfc8200 concerns, its always possible to make this doc an update to rfc8200, which shouldn't be such a blood bath as for SRv6 given how its about effectively multicast packets, and there was very little multicast expertise involved in writing these IPv6 documents.



Aka: present/discuss at 6man WG IMHO if not already done.

[A3] I haven't found any other destination option today does what the routing header either.

If we do not like destination option header, it could become a routing header, or a new extension header could also be proposed, and I have thought about that too.

It's allowed in RFC8200 to define extension header, or develop Option in DOH (recommended by 8200), and I think it's up to us BIER folks to talk about the tech aspects ----use cases, benefits, costs and impacts.



Let me cite some words of 6man chair Ole's view of point here:

"we cannot modify our documents on every occasion someone wants to do something".

"It shouldnt' matter if it contravened or not. As long as the proposed solution was technically sound standing on it's own feet."

"Any specification that changes EH processing must specify how that processing is done, and must be technically sound, in that it is shown not to break anything (interoperability, PMTUD, end to end security etc)."



BTW: I had once named the draft as draft-xie-6man-bier-encapsulation-00 and post on 6man mailing list but no feedback.

https://mailarchive.ietf.org/arch/msg/ipv6/8OGREpYjWGAHgSRKLUwE_--qfVU/



Reading the BIER charter text again, I'm not sure the coordination should be initiated by BIER WG after it becomes a WG I-D, or by the individual authors to request that ?

"7) BIER in IPv6 :  A mechanism to use BIER natively in IPv6 may be standardized if coordinated with the 6MAN WG and with understood applicability."

Maybe it's up to the chairs or AD to give guidance for this situation ?





P4: Wrt. SRv6: As soon as you embody SRv6 SID semantic into IPv6 addresses, i think you are doing SRv6 architecture. Only a minority (40% by a cisco

estimate) of SRv6 use cases ever need SRH, the rest is just SID semantics and non-LDP routing for simple IPv6 packets.

[A4] Got your point. Much or less the SRv6 ingredients, it's IETF standard-track for us to learn from: RFC8402, RFC8754.





P5: Wrt. SIDs: I was mostly worried about manual or SDN controller assignment of the SIDs (like source addresses in BIERv6), but it seems the appropriate BGP signaling mechanisms in BESS documents similar to those done in the past for MVPN with MPLS (in other WGs) would allow for automatic allocation and signaling. I think some sentences to the point that this is designed to be easily autoconfiguring the addresses it needs or the like would help to counter such concerns as i had first reading it.

[A5] Correct. The assignment of the IPv6 addresses (you called SIDs) can be easily automated by SDN.

The source address in BIERv6 only need to be allocated on an Ingress PE of MVPN, and advertise to Egress PE of MVPN using BGP-MVPN routes.

The destination address in BIERv6 only need to be allocated from the planned block of IPv6 address.

The standard-track RFC8754 sets up such paradigm, not only for data-plane optimization (below point P6), but also for security deployment to be easily automated (5.1 of 8754).





P6: The main concern by the WG seems to be how simple the lookup can be made. We already discussed this our last email round:

Ability to do a FIB lookup (because its a BIER SID) that results in an lookup entry of an unchanged BIER header doing unchanged BIER operations, followed just by a different adjacency than for MPLS. In MPLS you would swap the destination label (but keep the), here you would swap the destination IPv6 address.



Have you tried building a P4 reference implementation ?

Typically, when something is shown to be implementable in P4, then its harder for higher end NPU vendors to argue their NPU can not do this efficiently ;-)

[A6] I believe it's the simplest paradigm settled by RFC8754. It may need to compare with the alternatives to understand that.

Haven't try P4 yet.





Overall, i think it might help to think about summarizing the key parts of relevance to the WG to decide somewhere up front in the doc:



- Support for L3VPN and 'Internet' multicast services via IPv6 with BIER.

- Single FIB lookup to unchanged BIER header and processing

- Swap MPLS label replaced by swap IPv6 destination addess

- Leverages simple subset of SRv6 architecture for SID addressing,

- No SRH used.

[A7] Agreed. That's the key parts of the BIERv6 design in my opinion.





Cheers

    Toerless