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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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:[e-mail]]
Sent: Friday, January 25, 2019 3:16 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, January 25, 2019 2:20 PM
To: [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
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:


  1.  RFC7060 mLDP over Targeted sessions
  2.  BGP-MVPN/GTM with mLDP as the PE-CE protocol
  3.  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:[e-mail]] On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 1:15 PM
To: BIER WG <[e-mail]<mailto:[e-mail]>>
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://datatracker.ietf.org/doc/draft-hj-bier-mldp-signaling/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhj-2Dbier-2Dmldp-2Dsignaling_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=qCjzMO_5mJ31uNeQWAfFAtYuXU-SxLW6FZ3F9w1X7HM&s=BQN8YR0amWZvFTVJOYknPuhZFw-UKsOBzXeUYrznkZE&e=>

..as a BIER WG document.

This starts a two week counter.

Thanks,
Chairs
(Shep)