Subject: [Bier] Comment on draft-hj-bier-mldp-signaling-00

From: Eric C Rosen <[email-masked]>
Date: Tue, 10 Jul 2018 17:12:19 -0400

I note that the problem described in draft-hj-bier-mldp-signaling is 
essentially the same problem that is solved by RFC 7060 ("Using mLDP on 
Targeted LDP Sessions").  Section 6 of that RFC discusses the use of  
multicast tunneling to transport packets from an ingress LDP edge node 
to a set of egress LDP edge nodes, and applying it to BIER is 
straightforward.

RFC 7060 does require targeted LDP sessions between edge nodes. 
Draft-hj-bier-mldp-signaling proposes to replace those LDP sessions 
either by using an SDN controller, or by encapsulating an mLDP packet in 
a BIER packet (analogous to what is done with PIM in 
draft-ietf-bier-pim-signaling).  There are a couple of issues with the 
"encapsulate mLDP packets in BIER" option:

- There is no such thing as an "mLDP packet".  You'd need to extract 
mLDP messages from the TCP stream, and you need to say exactly which 
messages need to be forwarded and which don't.

- If you are trying to connect two LDP sessions by sending mLDP messages 
in datagrams, you will have a big problem if one of those datagrams gets 
lost.  Or if one of the edge nodes reboots.

Eliminating the TCP-based LDP signaling protocol by inventing a new 
datagram-based LDP signaling protocol is probably not a simplification.

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sun, 15 Jul 2018 22:31:01 +0000

Hi Eric

Thanks for feedback, we did look at that RFC. 
Couple of thoughts:
1.	This RFC is non-segmented mLDP, we felt segmentation (terminating LDP signaling at BFIR/BFER) and stitching between BIER and MLDP will provide better scaling. i.e the draft is suggesting single label presenting the P2MP LSP in bier domain and stitching vs the rfc will mean  a unique label presenting each BFIR and it is non-segmented. 
2.	There is still the issue of pushing P2MP MPLS over BIER and finding the BFERs. i.e. BFIR still needs to track the BFERs as per this draft.
3.	We are not trying to connect the 2 LDP domains from signaling point of view, we are just trying to signal the FEC and stitch, just like draft-ietf-bier-pim-signaling we are open how to signal through BIER domain. 

The biggest thing we are trying to accomplish is to stitch 2 P2MP LSP in 2 disconnected LDP domains over BIER domain without any (software/HW) impact to the LDP domain and as always we are open to suggestion...

Regards

Hooman

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, July 10, 2018 5:12 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Comment on draft-hj-bier-mldp-signaling-00

I note that the problem described in draft-hj-bier-mldp-signaling is essentially the same problem that is solved by RFC 7060 ("Using mLDP on Targeted LDP Sessions").  Section 6 of that RFC discusses the use of multicast tunneling to transport packets from an ingress LDP edge node to a set of egress LDP edge nodes, and applying it to BIER is straightforward.

RFC 7060 does require targeted LDP sessions between edge nodes. 
Draft-hj-bier-mldp-signaling proposes to replace those LDP sessions either by using an SDN controller, or by encapsulating an mLDP packet in a BIER packet (analogous to what is done with PIM in draft-ietf-bier-pim-signaling).  There are a couple of issues with the "encapsulate mLDP packets in BIER" option:

- There is no such thing as an "mLDP packet".  You'd need to extract mLDP messages from the TCP stream, and you need to say exactly which messages need to be forwarded and which don't.

- If you are trying to connect two LDP sessions by sending mLDP messages in datagrams, you will have a big problem if one of those datagrams gets lost.  Or if one of the edge nodes reboots.

Eliminating the TCP-based LDP signaling protocol by inventing a new datagram-based LDP signaling protocol is probably not a simplification.

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 16 Jul 2018 02:36:13 +0000

Hooman,

> From: BIER <[email-masked]> On Behalf Of Bidgoli, Hooman (Nokia -
> CA/Ottawa)
> Sent: Sunday, July 15, 2018 6:31 PM
> To: Eric Rosen <[email-masked]>; BIER WG <[email-masked]>
> Subject: Re: [Bier] Comment on draft-hj-bier-mldp-signaling-00
> 
> Hi Eric
> 
> 1.	This RFC is non-segmented mLDP, we felt segmentation (terminating
> LDP signaling at BFIR/BFER) and stitching between BIER and MLDP will
> provide better scaling. i.e the draft is suggesting single label presenting the
> P2MP LSP in bier domain and stitching vs the rfc will mean  a unique label
> presenting each BFIR and it is non-segmented.

It's not clear why it provides better scaling. What do you mean by " the rfc will mean  a unique label presenting each BFIR and it is non-segmented"? I don't see the difference (your proposal uses per <EBBR, SD, tree> labels if I understand it correctly).

> 2.	There is still the issue of pushing P2MP MPLS over BIER and finding
> the BFERs. i.e. BFIR still needs to track the BFERs as per this draft.

Same as  RFC7060?

> 3.	We are not trying to connect the 2 LDP domains from signaling point
> of view, we are just trying to signal the FEC and stitch, just like draft-ietf-
> bier-pim-signaling we are open how to signal through BIER domain.

What's the problem with RFC7060 approach (with BIER being the underlying RSVP-TE P2MP tunnel)?

> 
> The biggest thing we are trying to accomplish is to stitch 2 P2MP LSP in 2
> disconnected LDP domains over BIER domain without any (software/HW)
> impact to the LDP domain and as always we are open to suggestion...
> 

RFC 7060 is also "stitching": the upstream LSR (of the targeted session) label switches an incoming label to an outgoing label, which is stacked over a  base tunnel (p2p or p2mp); the downstream LSR switches the incoming stacked label to one or more outgoing labels learned from its downstream.

A few comments about tree label allocation/distribution if we go with your proposal:

1. It does not have to be per <EBBR, SD, tree>. Per <EBBR, tree> alone is enough. This is for both method 1 and 2.
2. For method 2, tree label distribution could be done via BIER itself. Just send a BIER packet with a bitstring identifying all IBBRs.
3. Could consider method 3 as described in draft-zzhang-bess-mvpn-evpn-aggregation-label

Jeffrey

> multicast tunneling to transport packets from an ingress LDP edge node to a
> set of egress LDP edge nodes, and applying it to BIER is straightforward.
> 
> Draft-hj-bier-mldp-signaling proposes to replace those LDP sessions either
> by using an SDN controller, or by encapsulating an mLDP packet in a BIER
> packet (analogous to what is done with PIM in draft-ietf-bier-pim-
> signaling).  There are a couple of issues with the "encapsulate mLDP packets
> in BIER" option:
> 
> - There is no such thing as an "mLDP packet".  You'd need to extract mLDP
> messages from the TCP stream, and you need to say exactly which
> - If you are trying to connect two LDP sessions by sending mLDP messages in
> datagrams, you will have a big problem if one of those datagrams gets
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE
> &m=k275mmxBrbjLwskVNpK08-
> n5E8OsSD2aEta2jpd4G_w&s=44KkwwBfpo8sgiOBkbE21kUAWikkKPVvdKs_H
> FnM0xw&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE
> &m=k275mmxBrbjLwskVNpK08-
> n5E8OsSD2aEta2jpd4G_w&s=44KkwwBfpo8sgiOBkbE21kUAWikkKPVvdKs_H
> FnM0xw&e=

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 16 Jul 2018 10:25:02 -0400

On 7/15/2018 6:31 PM, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
> This RFC is non-segmented mLDP, we felt segmentation (terminating LDP signaling at BFIR/BFER) and stitching between BIER and MLDP will provide better scaling.

I don't really see what the control plane scaling advantage is.  We 
could discuss that once you provide a workable proposal for carrying the 
mLDP FEC Element (<root, opaque value>) across the BIER backbone.

> we are just trying to signal the FEC and stitch, just like draft-ietf-bier-pim-signaling

Since PIM is datagram-based signaling with periodic retransmissions, 
saying "send the PIM J/P messages across the backbone in 
BIER-encapsulated datagrams" is at least an understandable proposal.  
Since LDP is TCP-based, does not use datagrams, does not have periodic 
retransmissions, and cannot support arbitrary reordering of its messages,
saying "send the LDP messages across the backbone in BIER-encapsulated 
datagrams" is not a real proposal.  But that does seem to be what 
section 3.2.2.2 says.

I'd also point out that that the use of TCP-based signaling procedures 
is often regarded as a scaling advantage over the use of datagram-based 
signaling procedures, as it eliminates the need for periodic state 
refreshes when the state hasn't changed.

Section 3.4 seems to suggest getting BGP involved in some of the LDP 
signaling.  In that regard, please see RFC 7441.

> i.e the draft is suggesting single label presenting the P2MP LSP in bier domain and stitching vs the rfc will mean  a unique label presenting each BFIR and it is non-segmented.

I think the case you are considering here is where it is possible for 
more than one BFIR to be on the mLDP-signalled P2MP LSP.  For this 
scenario, I see two possibilities:

1.  For a given FEC element, all BFERs are somehow made to choose the 
same BFIR as the upstream hop.  In that case, since there is only one 
BFIR for the P2MP LSP, it assigns the label, and there is only one label 
for the FEC Element.

2. For a given FEC element, different BFERs may choose different BFIRs 
as the upstream hop.   In this case, each BFIR will assign its own label 
for the FEC Element, but each BFIR and BFER will have only one label per 
FEC Element.  (I think this is the preferable alternative, as it allows 
more optimal routing and doesn't appear to have any disadvantage when 
compared to 1.)

In both cases, the labels representing the FEC Elements are known only 
at the edges, and each edge node knows only one label for the FEC Element.

So I don't really see what the per-label scaling issue is.

> There is still the issue of pushing P2MP MPLS over BIER and finding the BFERs. i.e. BFIR still needs to track the BFERs as per this draft.

I don't think this draft says anything substantially different than RFC 
7060 on this matter.