Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 28 January 2019 00:05 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 AD4B0130EF2 for <bier@ietfa.amsl.com>; Sun, 27 Jan 2019 16:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.254
X-Spam-Level:
X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Ce_HkqfhRUW7 for <bier@ietfa.amsl.com>; Sun, 27 Jan 2019 16:05:24 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 0358312D4F3 for <bier@ietf.org>; Sun, 27 Jan 2019 16:05:23 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0RNulsa025529; Sun, 27 Jan 2019 16:05:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=IVizky2xvhPZM9phsjI1+7ARvVgyD57Clrc1tojZlq4=; b=PCKtyltaHOUM/J9ajbFBP4SL2Gp1m7tz1p+Iq6FWXGBjVvInPZZwhIpn3iOMrscgAYOK kmBO5cZkokVvuUVMgCp8mEGHl6Ejmii4tc2OgEEZS9kfQXSpEWx1Xf1CjfTQS2JvXgZr NoGbr+yo37nXakHQ/H1wN2j6UA+Ky4QfFswJ98SUucZ18974mp8nNyWgBuzm9ZJejWxW r3IoRrIrXNFEG3E7GZReOIs1ZxLFWrjPnPQ7e++QF4r3NIl23Ei+6dYTQg9H6rEB1Csp 3RUbPMDf1GZK6957jCadH3T6KEVOYeRE9xPK/ToGNZ58jjCHSBhc5u8qxz2yIzC520sz 4A==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp2050.outbound.protection.outlook.com [104.47.42.50]) by mx0b-00273201.pphosted.com with ESMTP id 2q8pbn1qpk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Jan 2019 16:05:21 -0800
Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2695.namprd05.prod.outlook.com (10.166.200.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.13; Mon, 28 Jan 2019 00:05:17 +0000
Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::b852:f457:24e:fb7e]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::b852:f457:24e:fb7e%10]) with mapi id 15.20.1558.023; Mon, 28 Jan 2019 00:05:17 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, "IJsbrand Wijnands (iwijnand)" <iwijnand@cisco.com>
CC: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>, "gjshep@gmail.com" <gjshep@gmail.com>, BIER WG <bier@ietf.org>
Thread-Topic: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
Thread-Index: AQHUtNn5vseFKk0exki3P9CcP/G0KaXAV7DggAAURACAAABfoIAABqiAgAABEcCAAEG0gIAADGEZgAAZbICAAIG3gIAAhCCDgAArUgCAAb6eEA==
Date: Mon, 28 Jan 2019 00:05:17 +0000
Message-ID: <CO2PR05MB245516497353F10214AD2E36D4960@CO2PR05MB2455.namprd05.prod.outlook.com>
References: <CABFReBrQj+hMYd7JxuxQ-VbxAgB1SakGgaNcX+rQWNOFJ4hPtg@mail.gmail.com> <CO2PR05MB245537F2CA6097F54B7CC1BED49B0@CO2PR05MB2455.namprd05.prod.outlook.com> <DB7PR07MB4745FDBAB74969AC700545F0919B0@DB7PR07MB4745.eurprd07.prod.outlook.com> <CO2PR05MB2455F6545FC0596842C0324FD49B0@CO2PR05MB2455.namprd05.prod.outlook.com> <DB7PR07MB47454BF80720E3CC9316FA3E919B0@DB7PR07MB4745.eurprd07.prod.outlook.com> <CO2PR05MB2455F35A0FFCB5AFD09CD022D49B0@CO2PR05MB2455.namprd05.prod.outlook.com> <AC7D14B2-68DB-4D7C-8511-BD0AABEA6BA3@cisco.com> <40FC316A-D5BC-4E78-8144-CB09BDFC3D65@juniper.net> <DB7PR07MB4745801BA6C365C91E0985DE91940@DB7PR07MB4745.eurprd07.prod.outlook.com>, <4EAAACBA-9ED2-43EA-8469-3C421E9BA335@cisco.com> <11717C54-A75F-4322-B95B-9E8D76262A75@juniper.net> <DB7PR07MB474574F710F5800359CD82F391940@DB7PR07MB4745.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB474574F710F5800359CD82F391940@DB7PR07MB4745.eurprd07.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.0.600.7
dlp-reaction: no-action
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2695; 6:BBaGIapYVG7cWFVW0icQdZ+mRUi+0u9aVcz9jYJFOJPa7DtLAfuy1zSVDB7BxnBUG1ZVrdXxJDvNXGcHDs5F1s9NUudm/h3GgqL4Xle2qutDmuGPEpL6dYLHabMZJvK2IqMbltgLChfdi4QR8yoWooNSRKACticS3LdjPKxyRRF3SsfedGR8qdA/VPizGwHNhhDLDn/Qc2dpx/V2LbXzfvruFaNsNkBxcdce0mAb5j4ayy4h4kMIaxaqUdt+TIPVV1Ctprf1VXeobDWjgY5Y9NKhE3p0mWPAMsLt16FSYzKPE2bxlFm8LJJTlxPQXIlYAJlgPxdnY/rPgqaI0pnt8TaKsS2NQLaCqMxVJ+N1rqjIoLxmIvMQjFu+lVpXkzwF9XlvhjUMDHdS2EpPCpMpIqe9cHxg6dLqegs/ChlzJ5g0OTzWYZa1rItlSf6lH9UXADsz1RfAz91pMpep3+gsQw==; 5:GMatuP9NB7OR6y2OmsAX7W13aqBwcioMEOnBJOu5q195YZ/rEgwzyiGU8RoC6miWi1tSoWO/3hR6TUOEbCM4zTV27pvuraivrSqfKr/woUXZbjXdn5mD2EZrU/XGgJcKkqJGkX3ZprkWf6RvgxHfSnLVMC0jhYLHbn1mEZewur4n1Odit6/hMvstjYbSiPYulLsHzx54sCpbOPzNHlSeFQ==; 7:RE7uGz5wd3kSciXnO0J+QzksyV2nj/VXs6R1J+vwMkE+lNW8nJrd4dV3sGOn3zRvcwkKf2f17BnhJ5OmGgWK60kso2Rj1h65bF3OXcnyd63q6sYmCaVui5HEjKxPxbklYXiYzcgGVwc3iSf6UUiISA==
x-ms-office365-filtering-correlation-id: 1e606ce6-be46-44b2-1564-08d684b44951
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO2PR05MB2695;
x-ms-traffictypediagnostic: CO2PR05MB2695:
x-microsoft-antispam-prvs: <CO2PR05MB26956A4CBD36D6387A8C6140D4960@CO2PR05MB2695.namprd05.prod.outlook.com>
x-forefront-prvs: 0931CB1479
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(346002)(396003)(366004)(189003)(52314003)(199004)(13464003)(966005)(14454004)(71200400001)(6306002)(486006)(71190400001)(14444005)(102836004)(256004)(9686003)(6436002)(99286004)(55016002)(97736004)(53546011)(6506007)(478600001)(33656002)(186003)(26005)(53936002)(66066001)(76176011)(30864003)(66574012)(54906003)(2906002)(7736002)(8676002)(110136005)(316002)(39060400002)(305945005)(105586002)(93886005)(106356001)(68736007)(3846002)(6246003)(7696005)(476003)(6116002)(25786009)(74316002)(19627235002)(11346002)(8936002)(81156014)(296002)(81166006)(86362001)(446003)(229853002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2695; H:CO2PR05MB2455.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-message-info: gTzHWVdGmKvZIU2Xj+6kQ2+APyXb+n++Ct74QpGuG6LcynDmjn/CPKjmo44ZMfcpwt2B8OIrOM8tHB81gHMRgpz0fz7AdIRK3DLiUK4+QR5izL3x+zjrQfLVa1KmKATlhjXfvJe1dCsdwUoCVFyKWQEM2JAC+k0JCwlBnw01e33Q+as/oYV8FptjGxz9aVEELZBeDjA3MIEMUEItU+aZ3ewM0yCWsR/nm9Zat4cHrQw28ulYw7Zm8ls6dtecIfh+XNcwlDHCkLO9vYAvAdhi6e9LlVazY+T/lH/fY9pkUgx+Ko9mp//5GUEbucJP1OxXrkmUseaVUUk3IISdidPte4sLw69L8JLkAGaoNRkmbBCnVhouQIjJ0HrBNLBRxAjIzTT59qtmyz9kH55rDZEraMVsdBXdOLWcwXb4fju9NNc=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e606ce6-be46-44b2-1564-08d684b44951
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 00:05:17.7752 (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-Transport-CrossTenantHeadersStamped: CO2PR05MB2695
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-27_15:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901270193
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/CGXU3aWXWLpIDfs_exnfqV1W304>
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
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: Mon, 28 Jan 2019 00:05:27 -0000

Hi Hooman,

> -----Original Message-----
> From: Bidgoli, Hooman (Nokia - CA/Ottawa)
> [mailto:hooman.bidgoli@nokia.com]
> Sent: Saturday, January 26, 2019 4:08 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; IJsbrand Wijnands
> (iwijnand) <iwijnand@cisco.com>
> Cc: Mankamana Mishra (mankamis) <mankamis@cisco.com>;
> gjshep@gmail.com; BIER WG <bier@ietf.org>
> Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> 
> Just to be clear so the suggestion here is
> 
> 1.	we will go forward with a SDN general solution

An SDN solution makes sense if targeted mLDP or BGP-MVPN does not work for some customer. If you develop the SDN approach, would be good to generalize it.

> 2.	RFC 7060 for non SDN mLDP only solution (by the way Jeffrey I thought
> you said we don't need a draft for 7060 and BIER stitching, i.e. pim-signaling
> will cover this also? )

Not sure why you mention pim-signaling above. It's not related.

Jeffrey

> 
> Correct?
> 
> Regards
> 
> Hooman
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> Sent: Saturday, January 26, 2019 1:33 PM
> To: IJsbrand Wijnands (iwijnand) <iwijnand@cisco.com>
> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>;
> Mankamana Mishra (mankamis) <mankamis@cisco.com>; gjshep@gmail.com;
> BIER WG <bier@ietf.org>
> Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> 
> And that mLDP control plane is not hop by hop through the core. It hops over
> the entire core.
> 
> Sent from my iPhone
> 
> > On Jan 26, 2019, at 5:40 AM, IJsbrand Wijnands (iwijnand)
> <iwijnand@cisco.com> wrote:
> >
> > Hi Hooman,
> >
> >> We are gone have fully mesh TLDP between EBBRs and IBBRs, the
> dataplane on most if not all BIER routers will support MPLS anyway.
> >>
> >> If the network already supports and implemented mLDP then what is the
> incentive to go to TLDP, one would keep mLDP P2MP tunnels in parallel with
> BIER and be done with.
> >
> > There is a big difference between running mLDP as the data-plane vs. tLDP
> as the control-plane. tLDP is just a TCP session to carry the Label Mappings
> across. And the EBBR and IBBR’s have already a LDP process running in order
> to border between BIER and mLDP. So a provider is not adding any new
> control—plane, just re-using what is already there. To me that makes a lot of
> sense.
> >
> > Thx,
> >
> > Ice.
> >
> >>
> >>
> >> I am open with BGP signaling that said I am not sure if I understand the
> MVPN comment? As in segmented tunnels?
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> Hooman
> >>
> >>
> >>
> >> Send from mobile
> >>
> >>
> >>
> >> From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> >> Sent: Friday, January 25, 2019 8:24 PM
> >> To: Mankamana Mishra (mankamis)
> >> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa); gjshep@gmail.com; BIER WG
> >> Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> I would say that this draft could be for controller based option.
> >>
> >>
> >>
> >> One can still use RFC7060/MVPN/GTM+BIER, with just a little bit
> clarification on BIER specifics:
> >>
> >>
> >>
> >> - For RFC7060 method, specify BIER parameters for base tunnel as an
> “interface”.
> >>
> >> - For MVPN/GTM method, point out that the procedure in draft-ietf-bier-
> mvpn applies to mLDP case as well, with GTM or MVPN. Need to exam if GTM
> needs a bit more work.
> >>
> >>
> >>
> >> I can start a short draft to include the above two options. I think the
> controller option should be in its own draft because a lot of new details need
> to spelled out, and in theory that could be generalized.
> >>
> >>
> >>
> >> Jeffrey
> >>
> >> Sent from my iPhone
> >>
> >>
> >> On Jan 25, 2019, at 7:40 PM, Mankamana Mishra (mankamis)
> <mankamis@cisco.com> wrote:
> >>
> >> Does it mean we making / concluding solution which MUST have controller ?
> >>
> >> Sent from my iPad
> >>
> >>
> >> On Jan 25, 2019, at 1:04 PM, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> wrote:
> >>
> >> That looks better …
> >>
> >>
> >>
> >> What are the “label, label-action, BGP PTA opaque” in #2 for?
> >>
> >> In #5, PCE only needs to tell EBBR the label and list of IBBRs, and tell IBBRs
> the label and the EBBR.
> >>
> >> Oh, who determines what subdomain to use? Should it be the PCE?
> Perhaps add subdomain to the above line.
> >>
> >>
> >>
> >> BTW in concept this is no different from BGP-MVPN method (except the
> label assignment and EBBR determination) 😊
> >>
> >>    • You have a session between the controller and every border router
> (PCEP vs. BGP)
> >>    • You have to encode the FEC/label and signal to every EBBR/IBBR (PCEP
> vs. BGP)
> >>
> >>
> >> It does have the SDN halo ... I’m good with that 😊
> >>
> >>
> >>
> >> Now will you be tempted to consider the following?
> >>
> >>
> >>
> >>    • Can I use this for (s,g)/(*,g) traffic, whether in a VPN or in the global
> table?
> >>    • Can I use this for other tunnel types?
> >>
> >>
> >> After all, the infrastructure you build for mLDP over BIER equally applies to
> the above two additional scenarios.
> >>
> >> Then, do we make it generic? If yes, where do we do it 😊
> >>
> >>
> >>
> >> Jeffrey
> >>
> >>
> >>
> >> From: Bidgoli, Hooman (Nokia - CA/Ottawa)
> [mailto:hooman.bidgoli@nokia.com]
> >> Sent: Friday, January 25, 2019 3:41 PM
> >> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; gjshep@gmail.com;
> BIER WG <bier@ietf.org>
> >> Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> Ok lets converge to the controller solution then…
> >>
> >>
> >>
> >> As of now the controller solution was written that all the PCUpd is done via
> the EBBR (BFIR) I will change the solution so that the PCUpd is done on IBBR
> (BFER)
> >>
> >>
> >>
> >> 1. the IBBR will determined that the source of the FEC is over BIER domain.
> >>
> >> 2. IBBR will send PCUpd to the PCE with source-ip, label, label-action, BGP
> PTA opaque etc…
> >>
> >> 3. PCE will assign a BIER domain label for stitching to this P2MP LSP (mLDP)
> >>
> >> 4. PCE will determine the EBBR base on the information provided by IBBR
> >>
> >> 5. PCE will update the EBBR with NHLFE (stitch LDP to BIER domain label)
> information  and IBBR with NHLFE (stitch BIER domain label to LDP)
> information
> >>
> >> 6. as IBBRs come online for that specific P2MP LSP (i.e. that specific source
> and opaque) the PCE will update the EBBR with list of IBBRs so the EBBR can
> build its beir header accordingly
> >>
> >> 7 traffic will arrive from ldp domain to BFIR swap labels from LDP to BIER
> domain label. In addition push bier header forward to BFERs
> >>
> >> Etc…
> >>
> >>
> >>
> >> Maybe SDN will satisfy every body concerns…
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> Hooman
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> >> Sent: Friday, January 25, 2019 3:23 PM
> >> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>;
> gjshep@gmail.com; BIER WG <bier@ietf.org>
> >> Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> Hi Hooman,
> >>
> >>
> >>
> >> For 3) below, you still have LDP on the border routers and access interfaces,
> and the TLDP is not tied to interfaces, so I still don’t see a issue with TLDP.
> >>
> >>
> >>
> >> Controller based solution may be ok (I need to read that more closely), but
> I can’t support the refreshed inline messages.
> >>
> >>
> >>
> >> Thanks.
> >> Jeffrey
> >>
> >>
> >>
> >> From: Bidgoli, Hooman (Nokia - CA/Ottawa)
> [mailto:hooman.bidgoli@nokia.com]
> >> Sent: Friday, January 25, 2019 3:16 PM
> >> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; gjshep@gmail.com;
> BIER WG <bier@ietf.org>
> >> Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> Thanks Jeffrey
> >>
> >>
> >>
> >> Yes we had long discussions on this very useful thankyou!
> >>
> >>
> >>
> >> My 2 cents
> >>
> >>
> >>
> >> 1. We need a solution that is generic for all if not most MPLS protocols.
> >>
> >> 2. Not all cores will have fully mesh BGP, even that I am not against this but
> it will be restrictive, mLDP PE-CE need BGP fully mesh core also.
> >>
> >> 3. I still don’t see a issue why a thin layer of generic signaling with refresh
> timer is not appropriate. The only argument I hear against it is that why not
> use TLDP ( the protocol we are trying to eliminate)
> >>
> >> 4. The draft also proposes a SDN solution to mitigate the challenge ( maybe
> this is the cleanest way to go forward and the most generic) when a BFIR
> detect that the label mapping message is for a node across BIER domain it will
> send a PCRept with the info and the SDN controller assigns a BIER domain
> label and configure the stitching via a PCInit message. Same type of idea for
> release message…
> >>
> >>
> >>
> >> In short this is a very realistic issue for BIER brown field deployment where
> portion of the network, like a converge core, needs to be upgraded first.
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> Hooman
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: BIER <bier-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
> >> Sent: Friday, January 25, 2019 2:20 PM
> >> To: gjshep@gmail.com; BIER WG <bier@ietf.org>
> >> Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> There were quite some offline discussions on this, and I don’t think we’re
> ready to adopt this draft yet.
> >>
> >>
> >>
> >> There are basically three options to signal mLDP over a BIER core:
> >>
> >>
> >>
> >>    • RFC7060 mLDP over Targeted sessions
> >>    • BGP-MVPN/GTM with mLDP as the PE-CE protocol
> >>    • This draft-hj
> >>
> >>
> >> #1 is already a RFC and can be easily applied to a BIER core.
> >>
> >> For #2, RFC6514 already covers mLDP as PE-CE protocol. Now with a BIER
> core, the only difference is that the provider tunnel is BIER. Although draft-
> ietf-bier-mvpn talks about (C-S/*,C-G), other than that all the procedures
> apply to mLDP as PE-CE protocol. All we need to do is to extend GTM RFC7716
> (global table multicast with BGP-MVPN) to cover mLDP as the access protocol.
> >>
> >>
> >>
> >> #3 converts hard state LDP label mapping/withdraw into soft state
> messages carried in BIER. To me that just does not make sense.
> >>
> >> One reason given for doing #3 is that operators would not want to run LDP
> session over the core. I am not yet convinced on that – on the border routers
> you need to run LDP on the access interfaces anyway, I really don’t see the
> concern with running targeted session over the core.
> >>
> >>
> >>
> >> Thanks.
> >>
> >> Jeffrey
> >>
> >>
> >>
> >> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
> >> Sent: Friday, January 25, 2019 1:15 PM
> >> To: BIER WG <bier@ietf.org>
> >> Subject: [Bier] Call for adoption: draft-hj-bier-ldp-signaling
> >>
> >>
> >>
> >> Please read and reply to this thread with your vote for/against adoption of:
> >>
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dhj-2Dbier-2Dmldp-
> 2Dsignaling_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=Vpx0Ms4_sh-AGey7q6TwIobZ1fXErpA8hmzgCH-
> zBEQ&s=ey6RLaJG8XZW0q7ua9BYDpy2ZPZ1SzYlDytynfJEyGw&e=
> >>
> >>
> >>
> >> ..as a BIER WG document.
> >>
> >>
> >>
> >> This starts a two week counter.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Chairs
> >>
> >> (Shep)
> >>
> >> _______________________________________________
> >> BIER mailing list
> >> BIER@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scb
> fh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=Vpx0Ms4_sh-AGey7q6TwIobZ1fXErpA8hmzgCH-
> zBEQ&s=2EQnrOIGydT1kpVNchErJua1WTL5-ajVxKhl4STlYDw&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=HAkYuh63rsuhr6Scb
> fh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=Vpx0Ms4_sh-AGey7q6TwIobZ1fXErpA8hmzgCH-
> zBEQ&s=2EQnrOIGydT1kpVNchErJua1WTL5-ajVxKhl4STlYDw&e=
> >