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

[Eric C Rosen <[e-mail]>]

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.