Re: [Bier] WGLC - draft-ietf-bier-te-arch

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 18 February 2020 20:07 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 CD1DB120813 for <bier@ietfa.amsl.com>; Tue, 18 Feb 2020 12:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=cRBXmrgb; dkim=pass (1024-bit key) header.d=juniper.net header.b=gCQiV29X
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 wMbUodrjbUck for <bier@ietfa.amsl.com>; Tue, 18 Feb 2020 12:07:22 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7CDD3120145 for <bier@ietf.org>; Tue, 18 Feb 2020 12:07:21 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01IK0Txv024635; Tue, 18 Feb 2020 12:07:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=cRBXmrgbsPGTx34HJUB3mBBlDS9/obAzmEmUeUfRrXFajSVneebFGC9yCA6EYRBx+QVw uvCjTgrXpUN/DqLoUlGLucfhqkKzwRivG8BKyWfRbrNO9qw7qA7jv0jttMDWZaSNd+Ix 2WkWLpwCWP94KrWhX9SY/SjV19sPfx+8kIpmqGluD59xCdpdLVHCit7jQdvmfiwgXtvn IYEuVmKvkOOevLIjRy7yWJ9u+CVprpt7JqKouVBByq3Uxmh67NaTtZ8IcQFMfnCpkhE4 lamMgiKT2W0g8gACzmS7/6qvuyCqtu79O6l4yab4kpzhWAYbZmijcbLK/gF9Hd3aVqM9 Qw==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) by mx0a-00273201.pphosted.com with ESMTP id 2y86r21n0g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Feb 2020 12:07:07 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m7NomNLT57ggd2i/f47+36znZhMV2A311wCQoU8IFvCF/0N+O+rmsloBaRPJvNjcYMcVEdQVUdwjSUkude+YwHog5/BjpacEmSBce9CtCFHLtCWNalNAHkMkmm00c1gJt6e6echmlQpN+z/inUkGYj/PnTMg2NNKsyPnlKtyOIKhKOfaJAt+Y9yNU5hB2Y7IDIyX0B8wbuHCUfbHr2OijP9IX94Vz3T6J1Rtkk+sSMGqGLZ34N97wU3k+AVyz41OcquhesftZQnN4DrLmSMbvV/48NnL4XNt76yDCmIrcmrzbChiVd1UzY4LWfWSBcac8Vz1jox6873Gx3V+fiCvQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=AcPuiyVn6qLBq8CI86SwMRQq78PmHeKNDwp5nNdI+tW7uA4OlqglVu0Np/W84mUdPlfwRJwmq1xUcLFhBZ4rv3k5efH355OOKoWMPpHzOJJIHbPh7Ai+x8RdK+DZjgeioE99byleYVK1XVLUEuwun/zS2rgG30kkcGFqmMWOZS+bveQF50+NJnMQDSmR+c+LHLhdBhb2glUbh9vJx6SSROmysSc3SQBvk/9dSZW3SxTx6Ot2a1u+P8J6kF2dM3s4He3PdEebekbzaDt4VmtkX7FwnNLCoCD5m4hRqtMDHwICFc2j7k4g4Kgx5qGf0jXWUvIdmxys9SseEDHIVkgrfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
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:X-MS-Exchange-SenderADCheck; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=gCQiV29XqCxWodEUXebFwZg2evGOBbEeBjHzJAXJiNZPVPnz7C/tK9N5mEeHq+NZHFRbZjVV+BI3Df+560C2SvXHlU/x11W69m93hXWuLE9HNQfgN2qQOshgPrT+OtjE8VmTWPiVEfNvOLtqjLvaWuoPxlKRq5qTrqkXnaLDsWk=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (20.178.240.207) by MN2PR05MB6927.namprd05.prod.outlook.com (52.135.37.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.14; Tue, 18 Feb 2020 20:07:05 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d%7]) with mapi id 15.20.2750.016; Tue, 18 Feb 2020 20:07:05 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Toerless Eckert <tte@cs.fau.de>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch
Thread-Index: AdXmltqazVMKFHRdSsy5t+yost06gQ==
Date: Tue, 18 Feb 2020 20:07:04 +0000
Message-ID: <MN2PR05MB598175BB2DD63200BB91DF2CD4110@MN2PR05MB5981.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: dd632c15-19ed-486b-ac52-08d7b4ae2001
x-ms-traffictypediagnostic: MN2PR05MB6927:
x-microsoft-antispam-prvs: <MN2PR05MB692728D2637ED96AE9D9B526D4110@MN2PR05MB6927.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3276;
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(376002)(136003)(346002)(39860400002)(189003)(199004)(5660300002)(81166006)(81156014)(8676002)(86362001)(478600001)(186003)(26005)(966005)(8936002)(52536014)(316002)(66946007)(110136005)(66556008)(66446008)(66476007)(64756008)(55016002)(6506007)(71200400001)(30864003)(76116006)(33656002)(7696005)(66574012)(2906002)(9686003)(53546011)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB6927; H:MN2PR05MB5981.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ifgVj7ah/P0KmtOhifLjPf7nZ4zNn3fuEMUPEmYupksaqGceGS+3xqb142kSqe5OSsyKL1Yo6zY/mJgsAjkSuW7KE0D37l+7fLtojC4k/BAVcPEJ1PpJVsp9kxaFNGLDHk7SqBEKLZOzqRtJFYWMdES1tWgwBLc8FRr+3NtZx4kUPPbP6rSc9nLeMw2PBKUgMyLNYFcALqTx0QHCfvg4l0SKI4bRYXW7+LGlXmlHJhx1Iq8cs20Q0GABOy/CmxgAL0fWzRGg/EaY6B9sFmx88/iX6p9RYYBpts23P7Z7bFaZS+nWCT0eMWOZ1qqZ8s85PFYGOa9oHU+T+9I0bufEKM62HnfgR+uOviIzyHTFOdug4Ma9/5NucYncs4q+617bL36ZvVxaA232r8bvAJxCmmeb3MoLiFRA0Z5wIJ8jvtaVWkA1o7rbsiwgeQj1WiEgp68pgSJPIewXidNzeg+N1k9QcL92IGD8c2eZBlufRtgd0lbJbN8i4RC8SxJmBx3r4Kxx919e5QT8UY0ePRSZ2g==
x-ms-exchange-antispam-messagedata: Tiw4njcO92HCJ3QojeNvrsrgiNDRoTXAYqNN8l2LZ+dkTGdl9vCmhYCAH9m086NvYnfEIo6/x7GH7SW+lifOYJ8UjUGoUrphytuC14dIqEvgFojJ4QrsWdQiw53Gbc1z7OaBnfQf4DWoxrG89MeZCg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: dd632c15-19ed-486b-ac52-08d7b4ae2001
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 20:07:04.8905 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6T8VWkuWhhR3m6xsoL0tcciL+p1fuMNIZmY74dyi3vj8x3vQTyk99blZbLZ9DOPCwrvw8tB5iJEp+Max9Ng9qg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6927
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-18_06:2020-02-18, 2020-02-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 suspectscore=0 clxscore=1011 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002180134
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/otrdPl37-gR8LFi5a2p2DigxFeY>
Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
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: Tue, 18 Feb 2020 20:07:27 -0000

Hi Toerless,

Thanks!
I support moving this to the next stage.

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> Thanks Jeff
> 
> I have now pushed out -05 with the answers and hopefully resolution to 
> your points in email below.  Biggest addition was a section about 
> reuse of BPs (without DNR) which came out of the confusion i think the 
> reuse in the ECMP example raised. I was afraid so far to explan that 
> as it may not be easy to absorb and ultimately is stuff only 
> controller developers need to understand, but hopefully useful.
> And then of course the summary of BP optimizatins you asked for
> 
> Diff from last version i sent you:
> 
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b
> ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org*id*draft-ietf-bier-te
> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH
> OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
> 
> full -04 -> 05 diff:
> 
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:*
> *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
> ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
> 
> Comments inline below.
> 
> Cheers
>     toerless
> 
> On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR.
> > 
> > Zzh> The text in the email is seriously misaligned. Looking at the picture in the diff link, while you gave a U-turn example, though even if BFER2 is not connected to BFR2  but only connected to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said the first sentence of the above paragraph is enough to define Leaf BFER while the example itself is actually not needed.
> 
> Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand:
> 
> Consider how redundant disjoint traffic can reach BFER1/BFER2 in above 
> picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand 
> side, one traffic copy would be forwarded to BFER1 from BFR1, but the 
> other one could only reach BFER1 via BFER2, which makes BFER2 a 
> non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding 
> traffic to BFER2
> 
> > Zzh> Additionally, in left part of the picture you added, if some failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a leaf BFER. 
> 
> Added sentence:
> 
> <t>Note that the BFER in the left hand picture are only guaranteed to 
> be leaf-BFR by fitting routing configuration that prohibits transit 
> traffic to pass through a PE, which is commonly applied in these 
> topologies.</t>
> 
> > I assume you don't reassign BPs when links go up and down.
> 
> I didn't want to discuss that option in this document. Its obviously 
> perfectly feasible, but be yet a big amount of text (especially the 
> considerations how to do this make-before-break. Future doc.
> 
> > > but subsequent polarization example confuses me. It seems that BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talked about in Section 4.8).
> > 
> > Section 4.7 does not mention "routed" at all, so there are no routed adjacencies at all used in 4.7. So i am not sure what you are confused about.
> > 
> > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER-TE topology".
> 
> Correct text from the introduction. Ok.
> 
> > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" routed adjacency to R10; though I then ruled that out - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
> 
> Ah. Ok. I thought i could strip down the example to show only the 
> adjacencies relevant to the following discusion, but seemingly this 
> can introduce the confusion you have.
> 
> So i completed the example with the BP assignment acoss all nodes, but 
> added text pointing to a new section further down to discuss the 
> re-use of BP for which thi picture is also an example.
> 
> (check out the diff, new reuse text to long to copy inline).
> 
> > The whole purpose of the ECMP BPs is of course to save bits, otherwise we'd give each link a separate BP, which would be 6 BP to reach to BFR4...BFR7 from BFR1. 
> > 
> > Zzh> The trouble I am having is that the same 0:6 is assigned to different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intentional smart design but I have not wrapped my mind around it. It's apparently different from the link bundle case, so better separate it out and elaborate it (including the DNR flag that might be needed here - If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)?
> 
> Yes, there was the bug of reusing BP 0:6 across sequential BFR along 
> the path, but now the example correctly reuses separate BP at 
> different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and so on.
> 
> Thanks!
> 
> > > 4.8.  Routed adjacencies
> > > 
> > > If I understand it correctly, there is a BP assigned to L1/L2/L3 
> > > respectively (p2p link), and then there are BPs assigned to MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface addresses and loopback addresses on BFR2/3.
> > 
> > Ok that wasn't quite the read i expected. Let me clarify the text/picture:
> > 
> >                    ...............     
> >          ...BFR1--...           ...--L1-- BFR2...
> >                   ... .Routers. ...--L2--/  
> >          ...BFR4--...           ...------ BFR3...
> >                    ...............         |
> >                                           LO
> >                     Network Area 1
> > 
> > Assume the requirement in the above picture is to explicitly steer traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay "network area 1" to one of the following three next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3.
> > 
> > To achieve this, both BFR1 and BFR4 are set up with a forward_routed adjacency BitPosition towards an address of BFR2 on link L1, another forward_routed BitPosition towards an address of BFR2 on link L2 and a third forward_routed Bitposition towards a node address LO of BFR3.
> > 
> > Does this clear ip the confusion ?
> > 
> > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are cleared.
> 
> Ok.
> 
> > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs.
> > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopback interface addresses of BFR2/3 will use forward_routed(interface/loopback address). For a packet to be decapsulated on a BFER, there is a need for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for decapsulation and the latter is for getting it there).
> > 
> > This is not discussed in this section, but you are right - unless
> > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the one shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap(). 
> > 
> > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that we need a BP to get packet to a BFER and then a BP for decapsulation).
> 
> You got it.
> 
> > > If that???s the case, it???s worth point the above out.
> > 
> > Hmm... The logic of BFER BPs is totally independent of the logic of forward_routed adjacency, so i would worry that repeating the explanation of BFER BPs would conflate the forward_routed explanation.
> > 
> > Zzh> It's just that this is a place where all kinds of BPs are used so it's good to have a summary (could be a subsection 4.9).
> 
> Yes, added such a summary. Pls. check.
> 
> > > Actually, the reason that I thought this is MP2P is that 0:6 is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it can???t be MP2P (so it is not correct to have 0:6 present on those routers ??? only the p2p tunnel head/tail should have the BP present in the BIFT). The reason is that if it were MP2P, any router getting a copy will send it to the endpoint of the routed adjacency, causing lots of duplicates.
> > > 
> > > Am I getting this correct?
> > 
> > I think you are still explaining from the misunderstsanding that the ECMP explanations where about routed adjacencies.
> > 
> > I have now expanded the somewhat terse text in the BIFT table pictures, to make it clear that the ECMP is across multipe forward_connected adjacencies in the examples. For example, first BIFT picture:
> > 
> >   BIFT entry in BFR1:
> >   ------------------------------------------------------------------
> >   | Index |  Adjacencies                                           |
> >   ==================================================================
> >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                    |
> >   |       |        forward_connected(L2, BFR2),                    |
> >   |       |        forward_connected(L3, BFR2)}, seed)             |
> >   ------------------------------------------------------------------
> > 
> > Of course, an ECMP adjacency can be across any type of adjacencies, but all the text/explanations used forward_connected, and now the pictures show that explicitly.
> > 
> > Zzh> I can understand the multi-link case, but the multi-hop ECMP case (from BFR1 towards BFR10) is confusing me. It would help to give an example how it can be used, WITHOUT worrying about polarization.
> 
> Please check -05 text that has the full set of BIFT listed now:
> 
> There is  really nothing nothing unique in multi-hop ECMP for BIER-TE 
> that we do not also have in any other ECMP, except the conclusion that 
> we want to support fast HW hash mechanisms AND allow the controller to 
> set up non-polarized multi-hop ECMP AND be able to precalculate paths. 
> Hence the specification of ECMP adjacencies to have a controller 
> configurable seed.
> 
> Btw: The picture is maybe unnecessarily large because i've used it for 
> 20 years to explain the same polarization issue for unicast vs 
> multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of 
> the PIM/mLDP joins), whereas for unicast/BIER only
> BFR1...BFR7 are relevant. But being symmetric, the picture makes it 
> clear its the same problem.
> 
> > >    To inhibit looping in the face of such physical misconfiguration,
> > >    only forward_connected adjacencies are permitted to have DNR set, and
> > >    the link layer destination address of the adjacency (e.g.  MAC
> > >    address) protects against closing the loop.  Link layers without port
> > >    unique link layer addresses should not be used with the DNR flag set.
> > >
> > > It???s not clear how link layer address helps?
> > 
> > I have expanded this to
> > "link layer port unique unicast destination address"
> > 
> > Aka: MPLS or ethernet have unique link layer destination destination addresses (label or destination MAC). If you think about incorrectly plugged HDLC links (such as old T1/T3/... links), they only have 2 generic addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those p2p cables wrong, the packets would be incrrectly received by the wrong receiver node and then DNR could cause persistent loops only solved by TTL.
> > 
> > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged into the L1 interface of BFRa" - still not sure how label/mac helps here. I suppose the ring topology is discovered/verified by the control plane and when the miscalling happens then the ring will not include the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/varication is not done then perhaps we should point out that RPF based on link layer address is needed - the key is RPF (which needs unique link layer address)?
> 
> Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF 
> is just a problem for receiver originated joins like in PIM/mLDP, but 
> not unicast/bier(-te)/RSVP-TE.
> 
> Forward_connected is just like a unicast subnet adjacency to a direct 
> neighbor: Interface and L2 addresss of the destination.
> 
> The controller (could be a human) "assumes" a particular physicial 
> topology, from telemetry/knowledge/whatever. It then calculates the 
> desired BIER-TE topology and pushes it down. This topology is meant to 
> be loop free of course wrt to the configured adjacencies.
> In this BIER-TE topology, BFR3 will have a BP with the 
> forward_connected(L4, MAC-of-BFR2) adjacency.
> 
> If the cable connecting to L4 is miswired, then BFR3 would still send 
> the packets to the MAC address of BFR2, but given how the cable 
> connects to some other node, these packets will be discarded by that 
> node. because they're just L2 unicast packets.
> 
> I think this is equally true when we have normal BIER/MPLS enacp.
> Those packets too are addressed to the unicast MAC address of the 
> neighbor.
> 
> Now, if/when he controller recognizes that the physical topology has 
> changed, thats a completely different story and not addressed here. 
> Given how we assumed this was a cabling mistake, the controller would 
> probably only complain about the miswiring to operations but be happy 
> that the forwarding plane just makes packets fail instead of loop. If 
> this was a planned change process, then it will be similarily 
> convoluted as it would today be with rewiring cables in an 
> SR-MPLS/SRv6 topology and updating SIDs.
> 
> > > Because the forwarding is different from BIER forwarding (because of [1] above), we might as well introduce an optimization here ??? for each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip many bits.
> > 
> > Right. But i explicitly removed those optimizations (i had them in older draft versions) because the whole idea of this picture is solely the comparison with figure 4 of RFC8279.
> > 
> > Zzh> I think it's worth point that optimization out; you can mark it optional if you want to emphasize the similarity to BIER forwarding, but since BIER forwarding does do the maskoff step, it is very efficient while BIER-TE forwarding does not it the maskoff step so this optimization is important.
> 
> Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM 
> rules [1] and [2] and added following paragraph:
> 
> <t>In BIER, the order of BPs impacts the result of forwarding because of [1]. 
> In BIER-TE, forwarding is not impacted by the order of BPs. It is 
> therefore possible to further optimize forwarding than in BIER. For 
> example parallelizing forwarding across multiple FPE cores or 
> distributed linecards does only need to examine an arbitrary subset of 
> BP and not evaluate the dependency between BPs.</t>
> 
> > >    The following pseudocode is comprehensive:
> > > 
> > > The above sentence reads a bit strange (or lacks some segue).
> > 
> > I hope not, but maybe best left to a native english speaker (RFC-editor).
> > 
> > The first (RFC8279) pseudocode was simplified. The second one is comprehensive. If not comprehensive, whats a good opposite of simplified ?
> > 
> > Zzh> Perhaps "The above simplified pseudocode is elaborated further as following"?
> > Zzh> Jeffrey
> 
> Done.
> 
> Thanks a lot. 
> 
> 
> >    
> > > ________________________________________
> > > From: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>] 
> > > on behalf of Toerless Eckert [tte@cs.fau.de<mailto:tte@cs.fau.de>]
> > > Sent: Tuesday, July 09, 2019 23:38
> > > To: Mike McBride
> > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
> > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > > 
> > > Thanks, Mike
> > > 
> > > The authors also reviewed the document and concluded that it was 
> > > really hard to get into the document context because of too many 
> > > forward dependencies. We tried to fix this by adding two hopefully 
> > > good & basic examples into the Introduction section and using them 
> > > to also add a better definition of the term "BIER-TE Topology" in the Introduction.
> > > Hopefully this makes readin the rest of te document smoother.
> > > 
> > > Also improved text of Abstract and refined text compariing BIER-TE with SR.
> > > 
> > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81 
> > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh
> > > $
> > > <https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81 
> > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX
> > > $>
> > > 
> > > Cheers
> > >     Toerless
> > > 
> > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote:
> > > > How about three? I support.
> > > > mike
> > > >
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> wrote:
> > > > >
> > > > > We cannot take two 'yes' votes and WG consensus.
> > > > > Please, read and respond. If you don't support, then please vote as much publicly right here.
> > > > >
> > > > > Thanks,
> > > > > Greg
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On 
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd 
> > > > >> > <gjshep@gmail.com<mailto:gjshep@gmail.com>>
> > > > >> > Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
> > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > > > >> >
> > > > >> > +1
> > > > >> > Obviously support as co-author.
> > > > >> >
> > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote:
> > > > >> > > Please read and respond to this thread w/ or w/o support.
> > > > >> > >
> > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org
> > > > >> > > /doc 
> > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s
> > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$
> > > > >> > > <https://urldefense.com/v3/__https:/datatracker.ietf.org/
> > > > >> > > doc/ 
> > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx
> > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$>
> > > > >> > >
> > > > >> > > Vote ends 5 June 2019.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Shep
> > > > >> > > (chairs)
> > > > >> >
> > > > >> > > _______________________________________________
> > > > >> > > BIER mailing list
> > > > >> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE
> > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ 
> > > > >> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/
> > > > >> > > list 
> > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b
> > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > BIER mailing list
> > > > >> > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > >> > stin 
> > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4
> > > > >> > l_qd
> > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/li
> > > > >> > stin 
> > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW
> > > > >> > 4nrq
> > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >
> > > > > _______________________________________________
> > > > > BIER mailing list
> > > > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > nfo/ 
> > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX
> > > > > F0Kw
> > > > > ZD82cJLDFFNT2WVXWX$
> > > > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listi
> > > > > nfo/ 
> > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju
> > > > > 8UCL
> > > > > OgiuXc8Y_6sKn2KoAT$>
> > > 
> > > --
> > > ---
> > > tte@cs.fau.de<mailto:tte@cs.fau.de>
> > > 
> > > _______________________________________________
> > > BIER mailing list
> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > bier 
> > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82
> > > cJLD
> > > FFNT2WVXWX$
> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
> > > bier 
> > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu
> > > Xc8Y
> > > _6sKn2KoAT$>
> > 
> > --
> > ---
> > tte@cs.fau.de
> 
> --
> ---
> tte@cs.fau.de
> 
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4
> 1_jWV3YUA6D$

--
---
tte@cs.fau.de