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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Inline

Regards

Hooman

From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Friday, January 25, 2019 4:04 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

That looks better …

What are the “label, label-action, BGP PTA opaque” in #2 for?
HB> label is the mLDP label, label-action for the PCE to figure out if it is assigning a label or removing a label, PTA color aka opaque and source is the key I would imagine.

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.
HB> yes SD needs to be send up from IBBR also I agree missed that.

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?
HB> yes I would imagine the key here is different but I don’t see why not, obviously in this case there is no stitching label. The controller just builds a list of all interested IBBRs on the EBBR. I am not against this we can add a new PCEP objects and TLVs here to have a true generic solution. That said I would imagine pim-signaling is more powerful.

  *   Can I use this for other tunnel types?
HB> yes that is the beauty of PCE solution I am trying to see how RSVP-TE S2Ls will work with this also.
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 😊
HB> not sure BIER WG? I think it is the best place or SPRING?
Jeffrey

From: Bidgoli, Hooman (Nokia - CA/Ottawa) [mailto:[e-mail]]
Sent: Friday, January 25, 2019 3:41 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 25, 2019 3:23 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Friday, January 25, 2019 3:16 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[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)