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

From: Greg Shepherd <[email-masked]>
Date: Fri, 25 Jan 2019 10:15:14 -0800

Please read and reply to this thread with your vote for/against adoption of:

https://datatracker.ietf.org/doc/draft-hj-bier-mldp-signaling/

..as a BIER WG document.

This starts a two week counter.

Thanks,
Chairs
(Shep)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Jan 2019 19:19:46 +0000

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:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 1:15 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

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.

Thanks,
Chairs
(Shep)

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Jan 2019 20:16:18 +0000

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 <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, January 25, 2019 2:20 PM
To: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Thanks.
Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 1:15 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Fri, 25 Jan 2019 20:21:40 +0000

The problem that this draft attempts to solve is something that is worth to be addressed. However, based on the discussions I’ve had with various people last IETF, I don’t see us converging on the solution as documented in this draft. As Jeffrey explain, there are other ways to solve the problem with are fundamentally different as to what is documented in this draft and need to be discussed in the WG. I’m against adoption of this draft because of that reason.

Thx,

Ice.

> On 25 Jan 2019, at 20:19, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> 	• RFC7060 mLDP over Targeted sessions
> 	• BGP-MVPN/GTM with mLDP as the PE-CE protocol
> 	• This draft-hj
>  
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Jan 2019 20:22:41 +0000

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:[email-masked]]
Sent: Friday, January 25, 2019 3:16 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Thanks Jeffrey

My 2 cents

Regards

Hooman

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, January 25, 2019 2:20 PM
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Jan 2019 20:41:27 +0000

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 <[email-masked]>
Sent: Friday, January 25, 2019 3:23 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Hi Hooman,

Thanks.
Jeffrey

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

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Jan 2019 21:03:51 +0000

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:[email-masked]]
Sent: Friday, January 25, 2019 3:41 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Regards

Hooman

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

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Sat, 26 Jan 2019 00:40:25 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

That looks better …

Jeffrey

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 26 Jan 2019 01:24:44 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPad

That looks better …

Jeffrey

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=Gvexxpex5S5OOrt55CjvP7zN0L7R57t39CkPGe5VH60&s=xYqymT7jm6lV9wfcueE9jiTcHXYLC_hxVWd0UYN_eS0&e=>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sat, 26 Jan 2019 02:36:23 +0000

Inline

Regards

Hooman

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Friday, January 25, 2019 4:04 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
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.

  *   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

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sat, 26 Jan 2019 02:55:43 +0000

Jeffrey

I am really trying to keep an open mind about 7060, but even a glass wine didn’t help 😉
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.

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 <[email-masked]>
Sent: Friday, January 25, 2019 8:24 PM
To: Mankamana Mishra (mankamis)
Cc: Bidgoli, Hooman (Nokia - CA/Ottawa); [email-masked]; BIER WG
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Jeffrey
Sent from my iPhone

Jeffrey

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 26 Jan 2019 03:22:55 +0000

Hi Hooman,

I don’t think you need to let the controller know the mLDP label? As long as the controller comes back with an assigned BTL, then IBBR/EBBR can all do the tunnel stitching.
Instead of label-action, it is really join/leave (especially if you are going to generalize it).
Still don’t follow the PTA thing. In BGP-MVPN, PTA is used to encode the provider tunnel; here you seem to be using it to encode the “overlay state”. Is that right?

If you do make it generic (both on the tunnel side and on the overlay state side), then BIER is not the right place. Not sure about Spring either.

Jeffrey

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

Inline

Regards

Hooman

That looks better …

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 26 Jan 2019 03:34:46 +0000

Hi Hooman,

You’re talking moving to mLDP over a BIER core – so you’re doing mLDP already, and will continue to do it on the border routers but removing mLDP from inside the core. Isn’t that the use case?
With that just do the targeted session among the border routers and you’re all set.

The only drawback is the full mesh of LDP sessions – but the BGP-MVPN option does not have that drawback as it uses RR.

MVPN does not mean segmented tunnels. Since you’re open to BGP signaling and generalization – then BGP-MVPN already has everything you need to handle everything: whether it is (s,g), (*,g) or mldp, whether the “core tunnel” is BIER or anything else.

Jeffrey

From: Bidgoli, Hooman (Nokia - CA/Ottawa) [mailto:[email-masked]]
Sent: Friday, January 25, 2019 9:56 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Mankamana Mishra (mankamis) <[email-masked]>
Cc: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Jeffrey

Regards

Hooman

Send from mobile

Cc: Bidgoli, Hooman (Nokia - CA/Ottawa); [email-masked]<mailto:[email-masked]>; BIER WG

Jeffrey
Sent from my iPhone

Jeffrey

Regards

Hooman

Hi Hooman,

Thanks.
Jeffrey

Thanks Jeffrey

My 2 cents

Regards

Hooman

Thanks.
Jeffrey

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Sat, 26 Jan 2019 10:39:59 +0000

Hi Hooman,

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

> On Jan 25, 2019, at 7:40 PM, Mankamana Mishra (mankamis) <[email-masked]> wrote:
> 
> On Jan 25, 2019, at 1:04 PM, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> That looks better …
> 
>  
> 
> 	• 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)
>  
> 
> 	• 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?
>  
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 26 Jan 2019 18:32:53 +0000

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) <[email-masked]> wrote:
> 
> Hi Hooman,
> 
>> 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.
>> 
>> 
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=Vpx0Ms4_sh-AGey7q6TwIobZ1fXErpA8hmzgCH-zBEQ&s=2EQnrOIGydT1kpVNchErJua1WTL5-ajVxKhl4STlYDw&e=
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=Vpx0Ms4_sh-AGey7q6TwIobZ1fXErpA8hmzgCH-zBEQ&s=2EQnrOIGydT1kpVNchErJua1WTL5-ajVxKhl4STlYDw&e=
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sat, 26 Jan 2019 21:07:56 +0000

Just to be clear so the suggestion here is

1.	we will go forward with a SDN general solution
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? ) 

Correct? 

Regards

Hooman

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[email-masked]> 
Sent: Saturday, January 26, 2019 1:33 PM
To: IJsbrand Wijnands (iwijnand) <[email-masked]>
Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Mankamana Mishra (mankamis) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Sent from my iPhone

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Jan 2019 00:05:17 +0000

Hi Hooman,

> Sent: Saturday, January 26, 2019 4:08 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; IJsbrand Wijnands
> (iwijnand) <[email-masked]>
> Cc: Mankamana Mishra (mankamis) <[email-masked]>;
> [email-masked]; BIER WG <[email-masked]>

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

> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>;
> Mankamana Mishra (mankamis) <[email-masked]>; [email-masked];
> BIER WG <[email-masked]>
> >> 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.
> >
> >>
> >>
> >> - 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
> >>
> >>
> >> BTW in concept this is no different from BGP-MVPN method (except the
> label assignment and EBBR determination) 😊
> >>
> >> 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)
> >>
> >>
> >>
> >> 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…
> >>
> >>
> >>
> >> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]; BIER WG <[email-masked]>
> >> 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
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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=
> >>
> >> 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=
> >

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 28 Jan 2019 00:43:30 +0000

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 <[email-masked]> 
Sent: Sunday, January 27, 2019 7:05 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; IJsbrand Wijnands (iwijnand) <[email-masked]>
Cc: Mankamana Mishra (mankamis) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call for adoption: draft-hj-bier-ldp-signaling

Hi Hooman,

> you said we don't need a draft for 7060 and BIER stitching, i.e. 
> pim-signaling will cover this also? )

Jeffrey

> incentive to go to TLDP, one would keep mLDP P2MP tunnels in parallel 
> with BIER and be done with.
> >
> 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
> >>
> >>
> >>
> mvpn applies to mLDP case as well, with GTM or MVPN. Need to exam if 
> GTM needs a bit more work.
> >>
> >>
> >>
> 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 1:04 PM, Jeffrey (Zhaohui) Zhang 
> >> <[email-masked]>
> wrote:
> >>
> >> That looks better …
> >>
> >>
> >>
> >> In #5, PCE only needs to tell EBBR the label and list of IBBRs, and 
> >> tell IBBRs
> the label and the EBBR.
> >>
> >>    • 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)
> >>
> >>
> >>    • Can I use this for (s,g)/(*,g) traffic, whether in a VPN or in 
> >> the global
> table?
> >> After all, the infrastructure you build for mLDP over BIER equally 
> >> applies to
> the above two additional scenarios.
> >>
> >> 2. IBBR will send PCUpd to the PCE with source-ip, label, 
> >> label-action, BGP
> PTA opaque etc…
> >>
> and opaque) the PCE will update the EBBR with list of IBBRs so the 
> EBBR can build its beir header accordingly
> >>
> timer is not appropriate. The only argument I hear against it is that 
> why not use TLDP ( the protocol we are trying to eliminate)
> >>
> 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…
> >>
> >>
> >>
> >> There were quite some offline discussions on this, and I don’t 
> >> think we’re
> ready to adopt this draft yet.
> >>
> >>
> >>
> 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.
> >>
> >>
> >>
> 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
> >>
> >>
> >>