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

[Greg Shepherd <[e-mail]>]

Great discussion, thanks. Clearly more work, but that's why it's here.
However none of the discussion included votes to/for adoption. :)

Please reply for/against adoption as a WG item.

Thanks,
Chairs
(Shep)

On Sun, Jan 27, 2019 at 4:43 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[e-mail]> wrote:

> 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=
> > >
>