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

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

Hi Jeffrey

Thanks, I suggest to have a talk between your self, me and ICE in Prague before any thing new is submitted so we are in complete sync. 

Assuming if we are going after multiple ways of signaling it might be beneficial to have a common dataplane procedure.

I think no Mather what signaling we use (PCE, BGP etc...)  the datapath portion is similar to what is suggested in the datapath forwarding section of the current draft.

Regards

Hooman

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[e-mail]> 
Sent: Sunday, January 27, 2019 7:05 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; IJsbrand Wijnands (iwijnand) <[e-mail]>
Cc: Mankamana Mishra (mankamis) <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Hi Hooman,

> -----Original Message-----
> From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> [mailto:[e-mail]]
> Sent: Saturday, January 26, 2019 4:08 PM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; IJsbrand Wijnands
> (iwijnand) <[e-mail]>
> Cc: Mankamana Mishra (mankamis) <[e-mail]>; 
> [e-mail]; BIER WG <[e-mail]>
> 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 <[e-mail]>
> Sent: Saturday, January 26, 2019 1:33 PM
> To: IJsbrand Wijnands (iwijnand) <[e-mail]>
> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; 
> Mankamana Mishra (mankamis) <[e-mail]>; [e-mail]; 
> BIER WG <[e-mail]>
> 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)
> <[e-mail]> 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 <[e-mail]>
> >> Sent: Friday, January 25, 2019 8:24 PM
> >> To: Mankamana Mishra (mankamis)
> >> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa); [e-mail]; 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)
> <[e-mail]> 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 
> >> <[e-mail]>
> 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:[e-mail]]
> >> Sent: Friday, January 25, 2019 3:41 PM
> >> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail];
> BIER WG <[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]>
> >> Sent: Friday, January 25, 2019 3:23 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
> >>
> >>
> >>
> >> 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]> On Behalf Of Jeffrey (Zhaohui) 
> >> Zhang
> >> Sent: Friday, January 25, 2019 2:20 PM
> >> To: [e-mail]; BIER WG <[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:
> >>
> >>
> >>
> >>    • 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:[e-mail]] On Behalf Of Greg 
> >> Shepherd
> >> Sent: Friday, January 25, 2019 1:15 PM
> >> To: BIER WG <[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://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
> >> [e-mail]
> >> 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
> >> [e-mail]
> >> 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=
> >