Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Eric C Rosen <erosen@juniper.net> Tue, 13 February 2018 13:11 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A3712E897; Tue, 13 Feb 2018 05:11:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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
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 unCw0Wf4WS2d; Tue, 13 Feb 2018 05:11:24 -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 550141205D3; Tue, 13 Feb 2018 05:11:24 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1DD9kXP002218; Tue, 13 Feb 2018 05:11:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=kQswp20m1lO4GYvZrNDLnkD4rq7QBdm9uBRQYHBGrgE=; b=yLbwyi0BqdoKyNQVXf/85I+VCtHlf4lFYZ1lxLJyq/1K5viENnMzZPfJTciDC/eRHMsw oQfMEhGnEPTscojyLutXY1yhiYag6QebajYcRbcy8QCWPR17MxrSzU7RveWXiBVbfq7Y 4QO4coq8RUfKXvzdvOgeefV3vKqBDRr2669W89H8K9f6I2sijo7qgcFOuSidslsreRs+ zfzdYjCzG5Q5plCN7mtBLt5I+6LMyAhFc2LxOm/OWgNgMaLaj8UqcMwk1nl+2pXjCToJ nrNxzOPZnXNv4WQKbIv9QfwYm1qyY1b3TkKNW9fvNyaMH82P03S+phZCyFCnJt68b0Tx 4Q==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) by mx0a-00273201.pphosted.com with ESMTP id 2g3xbyg6u0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Feb 2018 05:11:20 -0800
Received: from [172.29.36.16] (66.129.241.13) by SN1PR05MB2304.namprd05.prod.outlook.com (2a01:111:e400:7a42::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Tue, 13 Feb 2018 13:11:15 +0000
To: Peter Psenak <ppsenak@cisco.com>, Tony Przygienda <tonysietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.com> <CA+wi2hNrQV+gyQS_ts-38w2OWYOkTXUy-Q3b0FAGKaztE8D+QQ@mail.gmail.com> <CABFReBoWZeQxnOCERr9EVykE5dY8p04KQT=JsDqk2eN2Q9p_2g@mail.gmail.com> <CA+wi2hPtxa_Z7VS6Hnj5Y4iQG3RUx7GP6exkf9o4ZcQr2eU_ig@mail.gmail.com> <5A81ABAC.107@cisco.com> <69EEC1F9-3077-4260-BB7A-66F0AEB3357D@cisco.com> <CA+wi2hO0ZPS=3aNY_Et1ChRhzQVJvr1dPiB-ugiC6iGDNpfyfA@mail.gmail.com> <DC7DFF2A-C986-4EA3-A701-6C80C867560B@cisco.com> <CDCE115D-C3AD-47DA-9993-6AC0BD88ED2D@cisco.com> <771dbad8841b42ac8ea3012dc73ef33b@XCH-ALN-001.cisco.com> <CC1CC82E-E134-4931-9735-07A0D0E64997@cisco.com> <e1ce91bb9d28485fbaad63252e1e0e3c@XCH-ALN-001.cisco.com> <E35F158F-2F97-47FD-8272-497B68ABDD1B@cisco.com> <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.cisco.com> <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com> <5A82A9D8.7050606@cisco.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <5153704a-843f-10de-eb74-c9c3a3ad722e@juniper.net>
Date: Tue, 13 Feb 2018 08:11:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <5A82A9D8.7050606@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: DM5PR13CA0020.namprd13.prod.outlook.com (2603:10b6:3:23::30) To SN1PR05MB2304.namprd05.prod.outlook.com (2a01:111:e400:7a42::18)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 775d418d-b3ce-44e1-6ab5-08d572e34442
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:SN1PR05MB2304;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 3:cU61C/tqzP2qZO16t7DesPpfm+llz7OH9faedbec8tKCVaDZu0qJfvL310THwxuFtNPR3JK2Luwi7a1taFL6v9OoX/pTFubPsADZIQjObP67Ckvz5jeUGAIMNEjRW5tDgNv8jse9zejqZ1Sr9CV6ERqFUrCD/jqIyvPIMJW5QtZn7RJ9Y5pWzeHEXa+aUgB9FHSHfvLQoMZ2LsGbonucFxvYfe6xRuYFGIFE3Gaalir6l6v687F6E/leLTKVLb8D; 25:uTIhgQKO4WqwiXCq7bvb0WQo4qEfsg472evrxL4jRwHglXG7338X+BJAJdedd/HKShu3K6gR0ICtRAFkGATHfCOZCsbG/l5QenEUNJm59S1YI2K3gNy7Qe/kbesBpvLxQR2kTZMEyV4MQMBg2gjMuoPW3sNUKtf4RpWSnX+IMQts247baZDzG2dvTNkd4xheyqoKZQ0KYjuwQKBR+8KFnoqXSI8gfWl/FWyP9UH8A384wq749Lq6iCEEHahOMLWXn0BdMbv4TaOl9KUa7B5cFchN19SQ1625BngRbzE+ShIVlkBdj9KURJVryVh6ZefedHIYBmmgmpqRUPbAXMX8Sg==; 31:wdqsQdsk5aeGpPWPRHkvCtkkCLkmwI85vgo/wIIJ/18afpcQirsemwJbNtzjLfyfNwb3A4/ltYoCDy+ZAI1ayboWHLna5e1/6lEAfHFZThtfthJQG+GV7F0/6Mmq6Dlm+TJH/+779NmGF0gkD2aQsAudzZueFmlHm7MCjtlAqlZsy++cgk8VmK86jQK9JSTg3NtTHSDKtincd3ZH6CPL3iGhAYcmUVkYCf4vzBlUiqw=
X-MS-TrafficTypeDiagnostic: SN1PR05MB2304:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 20:srxv4afwoi2WSC38c3fKmwvGfA0/x6nDpCENRxTsk2n0lF6gbdAyy9QVTqdUed2hA9gIAmXxx3VzepLTszxtEni+3+TJzNUQsU5cUshoebbsXRxGYXVWRMPqxTkGhrvyeg7Bp9ClMSy9OsyRShm+w9kmgb4XVEacjdMGPGd9c73veuouYE8eQz/iS9BoYT0bQGZ+3/jsvYAE3MynPNFrAIHdBgMog9Bl/o25yHzG+rMOQYgteZlBjNqXxFPRu+oIIoX8iIuZZTO7EVsGHHPT7r4pvYZ02oPvFxmXNR95h+T/c75JyXC3jLfzl7kaOAnD4C3Y7AQcXEX3YeYuMq7vOckgri5wY/6pmmuV3dtzx/UVkRZNpcgFsJGbSkl1MGob/wLr9fOkdf7wQXUZo9eI4Y9HguBF5LM1X3E37H+3t4aFRrFSJjGiG15jT+bvakR6OXs3FINhd93xf4qWdtabhC7LjzYDX/W8KTmX9ijJRUvyNn3xg6V1rxTbo4LjxbEtxv6tBI3bQEk+evi5QrtqP5fulHfjlwfIYmT4WQqPoR3ssCC5PXurqyazCuLmyv443xxXcEKQQ74ndIpNgDsIZpG3FqqdaVfz0h1K4Tb6IR0=
X-Microsoft-Antispam-PRVS: <SN1PR05MB23045A896CE0EF4D93EEB8ADD4F60@SN1PR05MB2304.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(85827821059158)(788757137089)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:SN1PR05MB2304; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2304;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 4:qSEvPiXW1xhUxVsPdPsvpOi3W2oCMu7EZl6Gw1+1TQcijQQJVANh4T3YGCbP1+5GojzR/PH3IlSox2ib0R9Mm08Vnq8E/kg0kaenFTExNQrRWv8kuZAaBh2wn1Dpd3Swj/8dYRFHvn99PyjaxlmWlX4gRnZRM9naJzi22l7vBCAlIbc7GF4ObvXj6F43g4Xljisq9h7VEu+GebKjVeGBX1fk2QEOKF+cFxwLavuqdmyhcourjWMJh6Y01Gz3nn+tA7ADCaRHNoPdc0cgHXGKPGpZ5jUNZr/c2KiidKx8gwpweszyFoS5duCbLvO0zqAqCUFTt2VBzwiAzeroARSiIiHpuf1vSH4cGhhXDK/Fzb5kwI6/lND/vMW8E7aYbiE6n+hPZSv1bvLTwm0rF7rTL3XPGS5oB38Rs4nXbUy5Xjo=
X-Forefront-PRVS: 0582641F53
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(396003)(39380400002)(346002)(366004)(39860400002)(199004)(189003)(51914003)(51414003)(2486003)(52146003)(23676004)(66066001)(83506002)(47776003)(6306002)(110136005)(65806001)(8676002)(58126008)(76176011)(2906002)(16200700003)(65956001)(67846002)(54906003)(81166006)(106356001)(39060400002)(53946003)(16576012)(81156014)(52116002)(93886005)(4326008)(6486002)(316002)(53936002)(5660300001)(2870700001)(86362001)(575784001)(31696002)(3260700006)(25786009)(16526019)(31686004)(68736007)(8936002)(966005)(50466002)(64126003)(105586002)(6246003)(478600001)(65826007)(53546011)(97736004)(386003)(3846002)(36756003)(77096007)(2950100002)(7736002)(59450400001)(6666003)(26005)(305945005)(6116002)(229853002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2304; H:[172.29.36.16]; 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)
X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2304;23:LhNvFibQdkt3XMjmkDDINoxiotNNrqgB4k/3fHqR8akH2o1Tk+AFFj510mwK7BKxldVqBJJbhRs0UcjcTB9v7j+/idtyS5hw8iEwQzo/sQu8yZjVW4aPIXYNRpD7anxOkuvhU93GL3GGREe+s8XKtt3UkrZfjFjTPy3x+yhLoNE8uwXKto3w1dQL73IS8/OmLjyjKIVY9zZQwQuwahoBLFNCXR7xHGWxSOZ5k2aE5uNEvXjYtQBwKpPwgMPZGGkzWXQFFN/IMst9p2qrOWLL1K1fvZBjawEeZU+5gLKqWHg/PdS0zGovfbE0KBNxqbYTmXM2rIC3rItRv04eX854GaYSlmqfUhrMEOArS0rsAxhVn9x4vxC3YWy5qzCWWsTAIZWS9MxKAkOBPCzONj04CmWtdz3SDcG7rC4FOvopI2be4SgtO+tu90F/HO1dKhz12Hxh2HHMw3vGiuwOKkdr5WI9qHkm8+ZexbfekE9LVkxse5EehLxRV9j9Xv3i4E71N7HRmB/0sUCiMFQ9Ranj6rSZt5/QSwYqy4yX3ZSBX0RhqgphSV9M6u7DQtEBl3ju6AUfW57tDbW0payrFks80uWeW/5RIxzK2Trd730sh8BRwQQDKbSz8jDFjPcU/5jwLnp8IfC4rTdnCuw38u6+AYk33cRmTEBjHmV4wmF6WmMbFNaFZ2BC60lEAtzsvSJ8G4peXPzqcjBD93w5+fuV4SU/D0SL0xESFm8Bxr7vFmsUOnlCmOPOsfxL/XrKNZwa/vGEUDd1pwRB3EzNG6mgKS1+3/t/zkVaolNx22wlQ2VpevrQ/Tn+YEU9LsGoQjWDxb8d2tq0OXURAZwA9Mrcjf40B8sGzbFvTdhbSKFuL1I5uunrrqclehQXSE2ERxHtC3exIbSSPrnrkJK2v9C6qOzHM2vByQP98nPXrTxeXtj+kk/iv6Pi8Us5E4ghOVarpBdB0SIujl86PUIIDou4oWbOkT0kyUIwww2Proa8nISg0V+9J+7aPGFQs+/mCe/8GV6rJpT2K+7fy58kUhdO2RVluU+PvHmsn6okOki1PpHU38azzJDmDcB0bsc6EVIgApQfKvaj+x05G1ARMRKz9itOiJ90g2XetB/y8uxtq9A2eNURJIaRMaQNO5+wZWrV0usKjONW4ekH9lCiV0iOfeUi/6PEgWz7wWIDObyIbcsp40BDCmqFsp9efitykoFpAMs4XM4PXEAJxwopDq5txgnx/clILHvz05jKtuOq0WNEgiK7x+rh3vMBqUwjX3XsNLEg/O/vDELEscHb2dWsiWJjG5EzjUE7/0x064lRaBg5XZ8NSLx2WHzPyHC0zwSEksh/ht4CrAJ9qNLAhoeHByNhXY+6tbaSPxZDafZefIA0H8/Q74fWcIxfrKx+R7c0tb8TUhqAgZw8mryewquMSwCGljWEpgJ1LXkDO4CEWe9qsfaafFZS1Rc0oB3qxfrZQWOM2TkcvgqdAhh/DVSzZhP0rHM0ocAp2UEOe/4OrZZpwLW1tLt5dazM50atiKewvG+OsSEtcgaS0lKXG48VERrqbuLy+zeMt3gXXfQjmfsV7zBdf53dEoHpUhFcHdyM9/7Ll6wUQdoo+VIuLiInpG9ijhMYqbu3D+WF70KPHPHs1ICTYIoTiTDJ+bhwy1XEl1sa4V1TR+wiGVIlcxExcg==
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 6:I46hFKm3t2t4wlRFDJ373Tp25MVPDyVtYnQkgcEA2Nak+c2zKwnCX6DoJD9SEg3bc0q4brd24VfHS+wACCKuTNMNmY6FmwrBhwrFxcxraL7EDIH9Nsvclxu1kZklhu8Ef4SLpls469SLAtdwa39cvqHXArzvfIDzMjAbf4rk8uPKkWu9OpDmQsV3/Ol1A7SKMTkrSdFsY67ROHJadA0kyxw4GnLeMH86marM6Zw/DP3pP266yW8oi4Zhtl8aPW4/VAExE30GY0bVaBoFgiBAPk8eYbhnvU77qhCNNV5hQXLaXTfdj+C3s+oASQwxXoX26mSNnq7DjLDiQvYKs/s94AeJ6udvK7kmAOjNQC7Pxus=; 5:+ToOOL+veBoay9ec9xQjttofFjIpCcqA97bukuJM1fNiH01myc4Fx+EDipIKnfTrE4m4bZJ0R754XbBunbgN83+HawtxXvkTxN3Z2tC0pTNV8zzqEsABAEtf9B+Z5kCgjBfWzl3I/zFeHRb305dCTxtfw+FRvjYm7aC5hQ454IY=; 24:FXVDvH0fXef/T07Xky3I7/7gZGtWwEjdghZR8RM1yP1VyRj2zikUO60uCMX7rg6z45ozRf/VqK3bJNyq7hPI0/fq6tQdklDE/RCdwjTVwH0=; 7:HLOb3+e4igXD6kjg5E+N/7y80PrLk3/dVtJb6RRbiqnOvGsMTvv/RGEXNEFr22M3FjUTEGlxREsADaQEoV1gSVirQJ2D100n41itnRAhZqLL5rVsTKv3BcBtAM2LiX1WkVk0Tta6RqWNIhdaPbuWsg/87RNXgeRau+QlSIG68xUyy14vCU+KnlgYnIHB0FEWevmVFUL7RGuKJQctHSM0miZeeugJSDDflsQB+fM+xZOWicccXCqfLZ0MQEwT8JsJ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2018 13:11:15.8326 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 775d418d-b3ce-44e1-6ab5-08d572e34442
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2304
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-13_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802130157
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/KWiq9Ph17SrKEjtq7AlffxDEKSY>
Subject: Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2018 13:11:30 -0000

If some folks think that there needs to be a correction or addition to 
the architecture, the best thing to do would be to write a new draft and 
post it for discussion.

This appears to be a substantive technical issue, which is not 
appropriate for an erratum.  It also doesn't seem appropriate for the 
IGP drafts.

On 2/13/2018 4:03 AM, Peter Psenak wrote:
> Hi Folks,
>
> can we add an errata to RFC 8279, instead of adding the text to both 
> IGP drafts that does not really belong there.
>
>
> thanks,
> Peter
>
> On 13/02/18 08:16 , Tony Przygienda wrote:
>> +1 what Les says as my understanding of the problem we're tackling 
>> here ...
>>
>> --- tony
>>
>> On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
>> <ginsberg@cisco.com <mailto:ginsberg@cisco.com>> wrote:
>>
>>     Ice –____
>>
>>     __ __
>>
>>     MY understanding is that – in the future – there may be additional
>>     encaps defined for BIER. When that happens, a given BFR may support
>>     multiple encaps. In such a case, it is OK if other BFRs supporting
>>     the same <MT,SD> only support one of the set of encaps – so long as
>>     we have one encap in common we can successfully forward. I believe
>>     that is the case the text change is trying to address – not encap vs
>>     no encap. The original text would have required identical sets of
>>     encaps to be supported by all BFRs for a give <MT,SD> - which is
>>     unnecessarily restrictive.____
>>
>>     __ __
>>
>>     Make sense?____
>>
>>     __ __
>>
>>        Les____
>>
>>     __ __
>>
>>     __ __
>>
>>     *From:*IJsbrand Wijnands (iwijnand)
>>     *Sent:* Monday, February 12, 2018 1:50 PM
>>
>>
>>     *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
>>     <mailto:ginsberg@cisco.com>>
>>     *Cc:* Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>;
>>     bier@ietf.org <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
>>     <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; isis-wg@ietf.org
>>     <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
>>     <mailto:isis-wg@ietf.org>>
>>     *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____
>>
>>     __ __
>>
>>     Les,____
>>
>>     __ __
>>
>>         (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
>>                being used, this means that every BFR that is advertising
>>         a label
>>                for sub-domain S is advertising a label for the
>>         combination of
>>                sub-domain S and Disposition BitStringLength L.)____
>>
>>     __ __
>>
>>     It says, if MPLS encapsulation is used, there is a Label for the
>>     {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
>>     a Label and the compatibility check will fail. Is that not the same
>>     a router that does not support MPLS BIER, and treated as a non-BIER
>>     router?____
>>
>>     __ __
>>
>>         [Les:] I don’t see how this text can be used to mean “multiple
>>         encap types can be supported on the same BFR for a given 
>> <MT,SD>”.
>>         ???____
>>
>>     __ __
>>
>>     Are these not like ships in the night? Like an Prefix can be
>>     reachable over MPLS and IP on the same interface? I do assume you
>>     want to stay with the encapsulation that you where provisioned in
>>     and not move from MPLS into non-MPLS. Why do you need to say you can
>>     support both?____
>>
>>     __ __
>>
>>     Thx,____
>>
>>     __ __
>>
>>     Ice.____
>>
>>     __ __
>>
>>     __ __
>>
>>         On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
>>         <ginsberg@cisco.com <mailto:ginsberg@cisco.com>> wrote:
>>
>>         Ice -
>>
>>         From: IJsbrand Wijnands (iwijnand)
>>         Sent: Monday, February 12, 2018 12:58 PM
>>         To: Les Ginsberg (ginsberg) <ginsberg@cisco.com
>>         <mailto:ginsberg@cisco.com>>
>>         Cc: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>;
>>         bier@ietf.org <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
>>         <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org>>
>>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>
>>         Les,
>>
>>
>>         Perhaps the thread is too long and you have gotten confused. J
>>
>>         Maybe :-), but...
>>
>>
>>         The point being discussed now is support for multiple
>>         encapsulation types (BSL conversion was mentioned in the thread
>>         – but it is NOT the subject being discussed at the moment).
>>
>>         I got that, it was removed after a long debate sometime back.
>>
>>
>>
>>         In latest IS-IS BIER draft we changed:
>>
>>              >     All routers in the flooding scope of the BIER TLVs
>>         MUST advertise the
>>              >     same encapsulation for a given <MT,SD>.  A router
>>         discovering
>>              >     encapsulation advertised that is different from its
>>         own MUST report a
>>              >     misconfiguration of a specific <MT,SD>.  All received
>>         BIER
>>              >     advertisements associated with the conflicting <MT,
>>         SD> pair MUST be
>>              >     ignored.
>>              >
>>              > "
>>              >
>>              > to
>>              >
>>              > "
>>              >
>>              >     Multiple encapsulations MAY be advertised/supported
>>         for a given
>>              >     <MT,SD>.  Clearly, however, there MUST be at least
>>         one encapsulation
>>              >     type in common in order for a BIER encapsulated
>>         packet to be
>>              >     successfully forwarded between two BFRs.
>>              >
>>
>>         Point has been made that this really belongs in the architecture
>>         RFC, but since it isn’t there it may make sense for the IGP
>>         drafts to mention it.
>>
>>         Below is taken from "6.10.1.  BitStringLength Compatibility
>>         Check” RFC 8279, does this not cover it?
>>
>>         ****
>>         The combination of sub-domain S and Imposition BitStringLength L
>>             passes the BitStringLength Compatibility Check if and only
>>         if the
>>             following condition holds:
>>
>>                Every BFR that has advertised its membership in
>>         sub-domain S has
>>                also advertised that it is using Disposition
>>         BitStringLength L
>>                (and possibly other BitStringLengths as well) in that
>>         sub-domain.
>>                (If MPLS encapsulation (Section 2.1 of 
>> [MPLS_BIER_ENCAPS]) is
>>                being used, this means that every BFR that is advertising
>>         a label
>>                for sub-domain S is advertising a label for the
>>         combination of
>>                sub-domain S and Disposition BitStringLength L.)
>>
>>         If a BFIR has been provisioned to use a particular Imposition
>>             BitStringLength and a particular sub-domain for some set of
>>         packets,
>>             and if that combination of Imposition BitStringLength and
>>         sub-domain
>>             does not pass the BitStringLength Compatibility Check, 
>> the BFIR
>>             SHOULD log this fact as an error.
>>         ****
>>
>>         [Les:] I don’t see how this text can be used to mean “multiple
>>         encap types can be supported on the same BFR for a given 
>> <MT,SD>”.
>>         ???
>>
>>             Les
>>
>>
>>         Thx,
>>
>>         Ice.
>>
>>
>>
>>         In the case of IS-IS, because earlier versions of the draft had
>>         an explicit statement which we now consider too limiting, it
>>         made sense to make an explicit statement of the more flexible
>>         behavior.
>>
>>         In the case of OSPF, the overly restrictive text was never
>>         present, so it is more debatable as to whether the clarifying
>>         statement is needed – but doing so keeps the drafts in sync.
>>
>>         Still, the “right solution” would be to have the statement in
>>         RFC 8279 – but a bit late for that.
>>
>>             Les
>>
>>
>>         From: IJsbrand Wijnands (iwijnand)
>>         Sent: Monday, February 12, 2018 12:05 PM
>>         To: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>
>>         Cc: Tony Przygienda <tonysietf@gmail.com
>>         <mailto:tonysietf@gmail.com>>; Les Ginsberg (ginsberg)
>>         <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>; bier@ietf.org
>>         <mailto:bier@ietf.org>; isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org>>; Peter Psenak (ppsenak)
>>         <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>
>>         Folks,
>>
>>         I would say its wrong to try and fix the BIER architecture by
>>         adding this into the IGP drafts. The IGP is a pass-through for
>>         the BIER information, and adding this text seems to imply that
>>         the IGP now needs to become BIER aware in order to detect and
>>         trigger notifications of encapsulation incompatibilities.
>>
>>         The BIER architecture RFC 8279 has section 6.10 "Use of
>>         Different BitStringLengths within a Domain”, what is missing in
>>         that section that would justify the IGP to become aware of
>>         BitStringLength differences? IMO everything is covered.
>>
>>         Thx,
>>
>>         Ice.
>>
>>
>>         On 12 Feb 2018, at 19:33, Acee Lindem (acee) <acee@cisco.com
>>         <mailto:acee@cisco.com>> wrote:
>>
>>         Hi Tony,
>>         I agree that since architecture has been published, it would not
>>         hurt to add the 5.2 text to the IGP documents.
>>         Thanks,
>>         Acee
>>
>>         From: Tony Przygienda <tonysietf@gmail.com
>>         <mailto:tonysietf@gmail.com>>
>>         Date: Monday, February 12, 2018 at 12:13 PM
>>         To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>
>>         Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com
>>         <mailto:ppsenak@cisco.com>>, "Les Ginsberg (ginsberg)"
>>         <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>, "bier@ietf.org
>>         <mailto:bier@ietf.org>" <bier@ietf.org <mailto:bier@ietf.org>>,
>>         "isis-wg@ietf.org list <mailto:isis-wg@ietf.org%20list>"
>>         <isis-wg@ietf.org <mailto:isis-wg@ietf.org>>
>>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>
>>         Peter, Acee, agree that this was missed in architecture and we
>>         should have talked about multiple encaps on a link there (just
>>         like we mentioned the BSL conversion). Alas, it was theoretical
>>         then and we missed. It was just a suggestion here to put it into
>>         IGP draft as we did in ISIS. I'm fine whichever way you guys
>>         feel it's better and a clarification draft can be always
>>         published later after more experience in the field albeit it
>>         seems that the issue is straight fwd' for most old hands, it's a
>>         link local decision so just use any matching encaps to transfer,
>>         however the computation has to agree to prevent blackholes  ...
>>
>>         Otherwise went through the important sections on -11 and looks
>>         good to me, no further comments. Thanks for the work
>>
>>         --- tony
>>
>>         On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee)
>>         <acee@cisco.com <mailto:acee@cisco.com>> wrote:
>>         With respect to the text in section 5.2, I agree with Peter.
>>
>>         Thanks
>>         Acee
>>
>>         On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)"
>>         <bier-bounces@ietf.org on behalf of ppsenak@cisco.com
>> <mailto:bier-bounces@ietf.org%20on%20behalf%20of%C2%A0ppsenak@cisco.com>>
>>         wrote:
>>
>>              Hi Tony,
>>
>>              OSPF does not have the original text, so it does not need
>>         the new one.
>>
>>              IMHO, the text in section 5 of ISIS BIER draft suits better
>>         to the BIER
>>              architecture draft than to the IGP extension draft.
>>
>>              thanks,
>>              Peter
>>
>>
>>              On 09/02/18 20:17 , Tony Przygienda wrote:
>>              > Sure ;-)  let me ping Peter @ the bottom then ... I don't
>>         think any of
>>              > the stuff applies to OSPF (was ISIS nits) except we can
>>         consider an
>>              > encaps paragraph. We basically suggest both to replace in
>>         ISIS the
>>              > encaps section like this
>>              >
>>              > before:
>>              >
>>              > "
>>              >     All routers in the flooding scope of the BIER TLVs
>>         MUST advertise the
>>              >     same encapsulation for a given <MT,SD>.  A router
>>         discovering
>>              >     encapsulation advertised that is different from its
>>         own MUST report a
>>              >     misconfiguration of a specific <MT,SD>.  All received
>>         BIER
>>              >     advertisements associated with the conflicting <MT,
>>         SD> pair MUST be
>>              >     ignored.
>>              >
>>              > "
>>              >
>>              > now
>>              >
>>              > "
>>              >
>>              >     Multiple encapsulations MAY be advertised/supported
>>         for a given
>>              >     <MT,SD>.  Clearly, however, there MUST be at least
>>         one encapsulation
>>              >     type in common in order for a BIER encapsulated
>>         packet to be
>>              >     successfully forwarded between two BFRs.
>>              >
>>              > "
>>              >
>>              > I do think that OSPF would benefit from adding this
>>         section to clarify
>>              > the issue which is not theoretical now that we have 
>> Ethernet.
>>              >
>>              >
>>              > So Peter, any ETA on outstanding OSPF nits now that we're
>>         tying up the
>>              > IETF LC?
>>              >
>>              > thanks
>>              >
>>              > --- tony
>>              >
>>              >
>>              > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd
>>         <gjshep@gmail.com
>>         <mailto:gjshep@gmail.com%0b%C2%A0%20>>
>>         <mailto:gjshep@gmail.com>> wrote:
>>              >
>>              >     No I didn't. Why would I? These are the changes you
>>         and Les worked
>>              >     out. I assumed you'd share them as needed. If for
>>         some reason you're
>>              >     uncomfortable engaging with the OSPF draft thread and
>>         authors with
>>              >     your proposed changes, let me know and I'll broker
>>         the conversation.
>>              >
>>              >     Greg
>>              >
>>              >     On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda
>>              >     <tonysietf@gmail.com <mailto:tonysietf@gmail.com
>> <mailto:tonysietf@gmail.com%20%3cmailto:tonysietf@gmail.com>>>
>>         wrote:
>>              >
>>              >         Les has the diff, I'd expect him to publish any
>>         minute to the
>>              >         list ... The encaps was a real defect, the rest
>>         is just
>>              >         tightening down the language/spec where it was
>>         too loose/too
>>              >         strict.
>>              >
>>              >         OSPF still needs update with conversion TLV
>>         removed, same
>>              >         paragraph on encaps could be useful. I hope Greg
>>         pinged Peter ...
>>              >
>>              >         thanks
>>              >
>>              >         tony
>>              >
>>              >         On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas
>>         <akatlas@gmail.com
>>         <mailto:akatlas@gmail.com%0b%C2%A0%20>>
>>         <mailto:akatlas@gmail.com>> wrote:
>>              >
>>              >             On Fri, Feb 9, 2018 at 12:46 PM, Tony 
>> Przygienda
>>              >             <tonysietf@gmail.com
>>         <mailto:tonysietf@gmail.com
>> <mailto:tonysietf@gmail.com%20%3cmailto:tonysietf@gmail.com>>>
>>         wrote:
>>              >
>>              >                 Went last nits with Les, we found one
>>         issue (encaps
>>              >                 section was wrong, need to look @ OSPF as
>>         well) and
>>              >                 basically tightened language in few 
>> places.
>>              >
>>              >
>>              >             K - please get that  out with the details of
>>         changes to the
>>              >             list.  I did my AD review back in Oct and
>>         looked at the
>>              >             differences before issuing
>>              >             IETF Last Call.
>>              >
>>              >             I look forward to reviewing the minor 
>> changes.
>>              >
>>              >             Regards,
>>              >             Alia
>>              >
>>              >                 tony
>>              >
>>              >                 On Tue, Feb 6, 2018 at 3:45 PM, Greg 
>> Shepherd
>>              >                 <gjshep@gmail.com
>>         <mailto:gjshep@gmail.com
>> <mailto:gjshep@gmail.com%20%3cmailto:gjshep@gmail.com>>> wrote:
>>              >
>>              >                     Thanks Les.
>>              >
>>              >                     Any other feedback? Looks like the
>>         concerns have
>>              >                     been addressed. Speak now.
>>              >
>>              >                     Cheers,
>>              >                     Greg
>>              >
>>              >                     On Thu, Feb 1, 2018 at 7:26 AM, Les
>>         Ginsberg
>>              >                     (ginsberg) <ginsberg@cisco.com
>>         <mailto:ginsberg@cisco.com%0b%C2%A0%20>>
>>         <mailto:ginsberg@cisco.com>> wrote:
>>              >
>>              >                         Greg –____
>>              >
>>              >                         __ __
>>              >
>>              >                         This thread is outdated.____
>>              >
>>              >                         In V6 of the draft we removed the
>>         restriction to
>>              >                         limit IS-IS BIER support to area
>>         boundaries – so
>>              >                         Toerless’s comment (and my
>>         proposed text) are no
>>              >                         longer relevant.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Specifically:____
>>              >
>>              >                         __ __
>>              >
>>              >                         Section 4.1:____
>>              >
>>              >                         __ __
>>              >
>>              >                         “At present, IS-IS support for a
>>         given BIER
>>              >                         domain/sub-domain is ____
>>              >
>>              > limited to a
>>         single area -
>>              >                         or to the IS-IS L2 
>> sub-domain.”____
>>              >
>>              >                         __ __
>>              >
>>              >                         The above text was removed.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Section 4.2____
>>              >
>>              >                         __ __
>>              >
>>              >                         o  BIER sub-TLVs MUST NOT be
>>         included when a
>>              >                         prefix reachability____
>>              >
>>              >                                advertisement is leaked
>>         between levels.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Was changed to____
>>              >
>>              >                         __ __
>>              >
>>              >                         o  BIER sub-TLVs MUST be included
>>         when a prefix
>>              >                         reachability____
>>              >
>>              >                                advertisement is leaked
>>         between levels.____
>>              >
>>              >                         __ __
>>              >
>>              >                         This aligns IS-IS and OSPF drafts
>>         in this
>>              >                         regard.____
>>              >
>>              >                         __ __
>>              >
>>              >                              Les____
>>              >
>>              >                         __ __
>>              >
>>              >                         *From:*Greg Shepherd
>>         [mailto:gjshep@gmail.com
>>              > <mailto:gjshep@gmail.com>
>> <mailto:gjshep@gmail.com%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:gjshep@gmail.com%3e>]
>>              >                         *Sent:* Thursday, February 01,
>>         2018 2:23 AM
>>              >                         *To:* Toerless Eckert 
>> <tte@cs.fau.de
>>         <mailto:tte@cs.fau.de%0b%C2%A0%20>>
>>         <mailto:tte@cs.fau.de>>
>>              >                         *Cc:* Les Ginsberg (ginsberg)
>>              >                         <ginsberg@cisco.com
>>         <mailto:ginsberg@cisco.com%0b%C2%A0%20>>
>>         <mailto:ginsberg@cisco.com>>; Tony Przygienda
>>              > <tonysietf@gmail.com
>>         <mailto:tonysietf@gmail.com%0b%C2%A0%20>>
>>            <mailto:tonysietf@gmail.com>>; Hannes Gredler
>>              >                         (hannes@gredler.at
>>         <mailto:hannes@gredler.at> <mailto:hannes@gredler.at
>>         <mailto:hannes@gredler.at>>)
>>              >                         <hannes@gredler.at
>>         <mailto:hannes@gredler.at
>> <mailto:hannes@gredler.at%20%3cmailto:hannes@gredler.at>>>;
>>              > bier@ietf.org
>>         <mailto:bier@ietf.org> <mailto:bier@ietf.org
>>         <mailto:bier@ietf.org>>;
>>              > isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org>> list
>>              >                         <isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org
>> <mailto:isis-wg@ietf.org%20%3cmailto:isis-wg@ietf.org>>>;
>>              >                         Christian Hopps 
>> <chopps@chopps.org
>>         <mailto:chopps@chopps.org%0b%C2%A0%20>>
>>         <mailto:chopps@chopps.org>>
>>              >
>>              >
>>              >                         *Subject:* Re: [Bier] WGLC:
>>              >
>>         draft-ietf-bier-isis-extensions-04____
>>              >
>>              >                         __ __
>>              >
>>              >                         Have these changes been reflected
>>         in the draft?
>>              >                         We're in WGLC but this discussion
>>         needs to come
>>              >                         to a conclusion so we can
>>         progress. ____
>>              >
>>              >                         __ __
>>              >
>>              >                         Greg____
>>              >
>>              >                         __ __
>>              >
>>              >                         On Tue, Jul 25, 2017 at 12:52 PM,
>>         Toerless
>>              >                         Eckert <tte@cs.fau.de
>>         <mailto:tte@cs.fau.de
>> <mailto:tte@cs.fau.de%20%3cmailto:tte@cs.fau.de>>>
>>              >                         wrote:____
>>              >
>>              >                             Thanks, Less, that would be
>>         lovely!
>>              >
>>              >                             I didn't check the OSPF
>>         draft, if its
>>              >                             similar state, explanatory
>>         text wold equally
>>              >                             be appreciated.____
>>              >
>>              >
>>              >                             On Sun, Jul 23, 2017 at
>>         11:28:08PM +0000,
>>              >                             Les Ginsberg (ginsberg) 
>> wrote:
>>              >                              > Toerless -
>>              >                              >
>>              >                              > I am thinking to add a
>>         statement in
>>              >                             Section 4.1 - something like:
>>              >                              >
>>              >                              > "At present, IS-IS support
>>         for a given
>>              >                             BIER domain/sub-domain is
>>         limited to a
>>              >                             single area - or to the IS-IS
>>         L2 sub-domain."
>>              >                              >
>>              >                              > If you believe this would
>>         be helpful I
>>              >                             will spin a new version
>>         (subject to
>>              >                             review/agreement from my
>>         co-authors).
>>              >                              >
>>              >                              >    Les
>>              >                              >
>>              >                              >
>>              >                              > > -----Original 
>> Message-----
>>              >                              > > From: Toerless Eckert
>>              > [mailto:tte@cs.fau.de
>>         <mailto:tte@cs.fau.de>
>> <mailto:tte@cs.fau.de%20%3cmailto:tte@cs.fau.de%3e>]
>>              >                              > > Sent: Saturday, July 22,
>>         2017 6:34 AM
>>              >                              > > To: Les Ginsberg 
>> (ginsberg)
>>              >                              > > Cc: Tony Przygienda;
>>         Hannes Gredler
>>              >                             (hannes@gredler.at
>>         <mailto:hannes@gredler.at>
>>              > <mailto:hannes@gredler.at>);
>>         Greg Shepherd;
>>              >                              > > bier@ietf.org
>>         <mailto:bier@ietf.org> <mailto:bier@ietf.org
>>         <mailto:bier@ietf.org>>;
>>              > isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org>>
>>              >                             list; Christian Hopps
>>              >                              > > Subject: Re: [Bier] 
>> WGLC:
>>              >
>>         draft-ietf-bier-isis-extensions-04
>>              >                              > >
>>              >                              > > Thanks Les
>>              >                              > >
>>              >                              > > When searching various
>>         terms in the doc
>>              >                             to figure out what happens i
>>         am not
>>              >                              > > sure why i missed 
>> this one.
>>              >                              > >
>>              >                              > > But: IMHO, RFCs can not
>>         only be the
>>              >                             minimum number of words to 
>> get a
>>              >                              > > running implementation.
>>         It also needs
>>              >                             to specify what this
>>         implementation
>>              >                              > > intends to achieve.
>>         Otherwise its not
>>              >                             possible to do a useful 
>> review:
>>              >                              > > The reviewer can to
>>         verify whether the
>>              >                             spec will achieve what it
>>         claims to
>>              >                              > > achieve is there no
>>         definitionn of what
>>              >                             it claims to achieve.
>>              >                              > >
>>              >                              > > If i understand ISIS
>>         correctly, my
>>              >                             reverse engineering of the
>>         intent is:
>>              >                              > >
>>              >                              > > - BIER TLVs stay within
>>         single ISIS
>>              >                             areas. BFIR and BFER must
>>         therefore be
>>              >                              > >   in the same ISIS area:
>>         There is no
>>              >                             inter-area BIER traffic 
>> possible
>>              >                              > >   with this
>>         specification. This is also
>>              >                             true for ISIS area 0.
>>              >                              > >
>>              >                              > > - The same BIER
>>         sub-domain identifiers
>>              >                             can be re-used
>>              >                              > > across different ISIS
>>         areas without
>>              >                             any current impact. If these
>>         BFR-IDs
>>              >                              > >   are non-overlapping,
>>         then this would
>>              >                             allow in the future to create
>>         a single
>>              >                              > >   cross ISIS area BIER
>>         sub-domain by
>>              >                             leaking TLVs for such a BIER
>>         sub-domain
>>              >                              > > across ISIS levels.
>>         Leakage is
>>              >                             outside the scope of this
>>         specificication.
>>              >                              > >
>>              >                              > > I actually even would
>>         like to do the
>>              >                             following:
>>              >                              > >
>>              >                              > > - If BIER sub-domains
>>         are made to span
>>              >                             multiple ISIS areas and 
>> BFR-ids
>>              >                              > > assignemtns
>>              >                              > >   are made such that all
>>         BFR-ids with
>>              >                             the same SI are in the same
>>         ISIS ara,
>>              >                              > >   then it should be in
>>         the future
>>              >                             reasonably easy to create
>>         inter-area BIER
>>              >                              > >   not by leaking of the
>>         BIER TLV but by
>>              >                             having BFIR MPLS unicastBIER
>>         packets
>>              >                              > >   for different SIs to
>>         an appropriate
>>              >                             L2L1 BFIR that is part of the
>>         destination
>>              >                              > > area/SI.
>>              >                              > >   (if you would use SI
>>         number that are
>>              >                             the same as ISIS area numbers
>>         then
>>              >                              > >    you could probably do
>>         this without
>>              >                             any new signaling. Not quite
>>         sure if
>>              >                              > >    you can today easily
>>         find L1L2
>>              >                             border router for another
>>         area via existing
>>              >                              > > TLVs).
>>              >                              > >
>>              >                              > >   Alas, this idea will
>>         probably be
>>              >                             killed because of the BIER
>>         architecture
>>              >                              > > intent not to engineer
>>         SI assignments
>>              >                             in geographical fashions to
>>              >                              > > minimize traffic
>>         duplication in the
>>              >                             presence of multiple SIs.
>>              >                              > >
>>              >                              > > Cheers
>>              >                              > > Toerless
>>              >                              > >
>>              >                              > > On Sat, Jul 22, 2017 at
>>         06:03:53AM
>>              >                             +0000, Les Ginsberg
>>         (ginsberg) wrote:
>>              >                              > > > Tony/Toerless ???
>>              >                              > > >
>>              >                              > > > There is an explicit
>>         statement as to
>>              >                             scope:
>>              >                              > > >
>>              >                              > > > <snip>
>>              >                              > > > Section 4.2
>>              >                              > > > ???
>>              >                              > > > o  BIER sub-TLVs
>>         MUST NOT be
>>              >                             included when a prefix
>>         reachability
>>              >                              > > >       advertisement is
>>         leaked between
>>              >                             levels.
>>              >                              > > > <end snip>
>>              >                              > > >
>>              >                              > > > Tony seems to have
>>         forgotten that we
>>              >                             had a discussion about how 
>> BIER
>>              >                              > > might be supported
>>         across areas and the
>>              >                             conclusion was we did not 
>> know
>>              >                              > > how to do that yet.
>>              >                              > > > (Sorry Tony)
>>              >                              > > >
>>              >                              > > > Note this is
>>         ???consistent??? with
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>>
>>              >                              > >
>>         ospf-bier-extensions-07.txt Section
>>              >
>> 2.5<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D-250b-25C2-25A0-2520&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=WUyeExz9aM6aWI40OfobGvQ-Sr1x4kuhMECczm1lBJg&e=>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=>>
>>              >                              > >
>>              >
>>         bier-ospf-bier-extensions-07.txt%20Section%202.5>
>>              >                             - which limits the
>>              >                              > > flooding scope of BIER
>>         information to a
>>              >                             single area unless it can be
>>         validated
>>              >                              > > that the best path to
>>         the prefix with
>>              >                             BIER info can be validated to
>>         be to a
>>              >                              > > router which itself
>>         advertised the BIER
>>              >                             info. This is not something
>>         IS-IS can do
>>              >                              > > since a single IS-IS
>>         instance only
>>              >                             supports one area and
>>         therefore does not
>>              >                              > > have the Level-1
>>         advertisements of the
>>              >                             originating router when that
>>         router is
>>              >                              > > in another area.
>>              >                              > > >
>>              >                              > > > A few more responses
>>         inline.
>>              >                              > > >
>>              >                              > > > From: BIER
>>              > [mailto:bier-bounces@ietf.org
>>              >
>>         <mailto:bier-bounces@ietf.org>
>> <mailto:bier-bounces@ietf.org%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:bier-bounces@ietf.org%3e>]
>>         On Behalf Of
>>              >                             Tony Przygienda
>>              >                              > > > Sent: Friday, July 21,
>>         2017 5:17 AM
>>              >                              > > > To: Toerless Eckert
>>              >                              > > > Cc: Hannes Gredler
>>         (hannes@gredler.at <mailto:hannes@gredler.at>
>>              > <mailto:hannes@gredler.at>);
>>         Greg Shepherd;
>>              > bier@ietf.org
>>         <mailto:bier@ietf.org> <mailto:bier@ietf.org
>>         <mailto:bier@ietf.org>>;
>>              >                              > > > isis-wg@ietf.org
>>         <mailto:isis-wg@ietf.org>
>>              > <mailto:isis-wg@ietf.org>
>>         list; Christian Hopps
>>              >                              > > > Subject: Re: [Bier] 
>> WGLC:
>>              >
>>         draft-ietf-bier-isis-extensions-04
>>              >                              > > >
>>              >                              > > > Terminology is a bit
>>         nits  IMO since
>>              >                             the doc is reading clear
>>         enough for
>>              >                              > > someone who read BIER &
>>         ISIS. I can
>>              >                             reread it or Les can comment
>>         whether
>>              >                              > > we should tighten
>>         glossary ...
>>              >                              > > >
>>              >                              > > > With the scope I
>>         agree, that got lost
>>              >                             and the doc should be
>>         possibly rev'ed
>>              >                              > > before closing LC. Yes,
>>         we flood AD
>>              >                             wide was the agreement but
>>         something
>>              >                              > > mentioning that this
>>         could change in
>>              >                             the future is good so we are
>>         forced to
>>              >                              > > give it some thought how
>>         that would
>>              >                             transition ...
>>              >                              > > >
>>              >                              > > > Thinking further
>>         though, in ISIS we
>>              >                             have a clean document really.
>>         The  BIER
>>              >                              > > sub-TLVs go into well
>>         defined TLVs in
>>              >                             terms of flooding scope.
>>         Normal L1-L2
>>              >                              > > redistribution can be
>>         used to get the
>>              >                             info to all needed places
>>         AFAIS. So
>>              >                              > > maybe nothing needs to
>>         be written. I
>>              >                             wait for Les to chime in.
>>              >                              > > >
>>              >                              > > > OSPF I would have to
>>         look @ scopes
>>              >                             again & think whether we 
>> need to
>>              >                              > > write something or maybe
>>         Peter can
>>              >                             comment ...
>>              >                              > > >
>>              >                              > > > --- tony
>>              >                              > > >
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > On Fri, Jul 21, 2017
>>         at 8:27 AM,
>>              >                             Toerless Eckert
>>              >                              > > <tte@cs.fau.de
>>         <mailto:tte@cs.fau.de%0b%C2%A0%20>>
>>         <mailto:tte@cs.fau.de><mailto:tte@cs.fau.de
>>         <mailto:tte@cs.fau.de%0b%C2%A0%20>>
>>         <mailto:tte@cs.fau.de>>> wrote:
>>              >                              > > > Sorry, past the two
>>         weeks, but
>>              >                             hopefully  benign textual
>>         comments:
>>              >                              > > >
>>              >                              > > > We tried to find an
>>         explicit
>>              >                             statement about the scope of
>>         BIER TLVs - eg:
>>              >                              > > > are they meant to stay
>>         within an
>>              >                             area, have some
>>         redistribution across
>>              >                              > > > areas/levels or not.
>>              >                              > > >
>>              >                              > > > Tony said WG agreement
>>         was to have
>>              >                             these TLV be flooded 
>> across the
>>              >                              > > > whole ISIS domain for
>>         now (this
>>              >                             draft). So an explicit
>>         statement to that
>>              >                              > > effect would
>>              >                              > > > be great (All BIER
>>         sub-domains TLVs
>>              >                             are flooded across all ISIS
>>         areas/levels,
>>              >                              > > so they span the whole
>>         ISIS domain).
>>              >                              > > >
>>              >                              > > > Also, if future work
>>         may/should could
>>              >                             improve on that maybe some
>>              >                              > > > sentence about that (i
>>         guess one
>>              >                             could just have ISIS
>>         intra-area BIER sub-
>>              >                              > > domains ?).
>>              >                              > > >
>>              >                              > > > Also: Do a check about
>>         possible
>>              >                             ambiguity of any generic
>>         terms like
>>              >                              > > sub-domain, level, area,
>>         topology so
>>              >                             that reader that don't 
>> know the
>>              >                              > > terminology ofall
>>         protocols (ISIS,
>>              >                             BIER) by heart can easily
>>         know which
>>              >                              > > protocol is referred to.
>>              >                              > > >
>>              >                              > > > [Les:] There is no
>>         mention of
>>              >                             ???level??? in the document.
>>              >                              > > > The use of
>>         ???sub-domain??? is
>>              >                             clearly always associated
>>         with ???BIER???.
>>              >                              > > > ???topology??? is
>>         always used as an
>>              >                             RFC 5120 topology ??? 
>> therefore
>>              >                              > > clearly an IS-IS 
>> topology.
>>              >                              > > > There is only one use
>>         of the term
>>              >                             ???area??? (in Section 5.1).
>>         That text
>>              >                              > > might deserve a bit of
>>         clarification
>>              >                             given this might be either a
>>         Level 1 area or
>>              >                              > > the Level2 sub-domain.
>>         I???ll take a
>>              >                             pass at it.
>>              >                              > > > (BTW ??? I am talking
>>         about IS-IS
>>              >                             area/L2sub-domain 
>> Toerless. ???)
>>              >                              > > >
>>              >                              > > > I don???t see that any
>>         other
>>              >                             clarification is needed ???
>>         but Toerless ??? if
>>              >                              > > you can point to any
>>         specific
>>              > sentences/paragraphs which
>>         you find confusing
>>              >                              > > - I???ll take a 
>> second look.
>>              >                              > > >
>>              >                              > > > Les
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > I guess there are no
>>         BIER level, area
>>              >                             or topologies, but still 
>> makes
>>              >                              > > > reading easier if the
>>         doc would say
>>              >                             "ISIS level", "ISIS area", 
>> or at
>>              >                              > > > least have them in the
>>         Terminology
>>              >                             section. And probably in
>>              >                              > > > terminology say
>>         "domain -> in the
>>              >                             context of this document 
>> the BIER
>>              >                              > > domain which is also the
>>         same as the
>>              >                             ISIS domain"
>>              >                              > > > (which i hope is the
>>         correct
>>              >                             statement, see above).
>>              >                              > > >
>>              >                              > > > Cheers
>>              >                              > > >     Toerless
>>              >                              > > >
>>              >                              > > >
>>              >
>>         _______________________________________________
>>              >                              > > > BIER mailing list
>>              >                              > > > BIER@ietf.org
>>         <mailto:BIER@ietf.org>
>>              >
>>         <mailto:BIER@ietf.org><mailto:BIER@ietf.org
>>         <mailto:BIER@ietf.org%0b%C2%A0%20>>
>>         <mailto:BIER@ietf.org>>
>>              >                              > > >
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
>>              >                              > > >
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > --
>>              >                              > > > We???ve heard that a
>>         million monkeys
>>              >                             at a million keyboards could
>>              >                              > > produce the complete
>>         works of
>>              >                             Shakespeare; now, thanks to
>>         the Internet,
>>              >                              > > we know that is not 
>> true.
>>              >                              > > > ???Robert Wilensky
>>              >                              > >
>>              >                              > > --
>>              >                              > > ---
>>              >                              > > tte@cs.fau.de
>>         <mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de
>>         <mailto:tte@cs.fau.de>>____
>>              >
>>              >                         __ __
>>              >
>>              >
>>              >
>>              >
>>              >
>>         _______________________________________________
>>              >                 BIER mailing list
>>              > BIER@ietf.org
>>         <mailto:BIER@ietf.org> <mailto:BIER@ietf.org 
>> <mailto:BIER@ietf.org>>
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
>>              >
>>              >
>>              >
>>              >
>>              >
>>              >
>>              >
>>              > _______________________________________________
>>              > BIER mailing list
>>              > BIER@ietf.org <mailto:BIER@ietf.org>
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>>
>>              _______________________________________________
>>              BIER mailing list
>>         BIER@ietf.org <mailto:BIER@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>
>>
>>         _______________________________________________
>>         BIER mailing list
>>         BIER@ietf.org <mailto:BIER@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>         <image001.png>
>>
>>         _______________________________________________
>>         BIER mailing list
>>         BIER@ietf.org <mailto:BIER@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>         <image001.png>____
>>
>>     __ __
>>
>>     ____
>>
>>     __ __
>>
>>
>>     _______________________________________________
>>     BIER mailing list
>>     BIER@ietf.org <mailto:BIER@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e= 
>