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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hooman,

> -----Original Message-----
> From: BIER <[e-mail]> On Behalf Of Bidgoli, Hooman (Nokia -
> CA/Ottawa)
> Sent: Sunday, July 15, 2018 6:31 PM
> To: Eric Rosen <[e-mail]>; BIER WG <[e-mail]>
> Subject: Re: [Bier] Comment on draft-hj-bier-mldp-signaling-00
> 
> 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.

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

> Regards
> 
> Hooman
> 
> 
> -----Original Message-----
> From: BIER [mailto:[e-mail]] On Behalf Of Eric C Rosen
> Sent: Tuesday, July 10, 2018 5:12 PM
> To: BIER WG <[e-mail]>
> 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
> [e-mail]
> 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=
> _______________________________________________
> BIER mailing list
> [e-mail]
> 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=