Re: [Bier] [mpls] First IMPLS MNA Interim meeting after IETF 117

Hi all,

As a reminder, the network slice use case for DetNet is described in the draft below:

https://datatracker.ietf.org/doc/draft-sw-detnet-network-slice-mapping-yang/ 

Best regards,

Xueyan

Original

From: Jeffrey(Zhaohui)Zhang <zzhang=40juniper.net@dmarc.ietf.org>
To: Tony Przygienda <tonysietf@gmail.com>;Joel Halpern <jmh@joelhalpern.com>;
Cc: BIER WG <bier@ietf.org>;mpls@ietf.org <mpls@ietf.org>;
Date: 2023年08月11日 23:42
Subject: Re: [mpls] [Bier] First IMPLS MNA Interim meeting after IETF 117

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

For the slice use case, I’d like to refer to a almost two-year-old draft: https://datatracker.ietf.org/doc/html/draft-zzhang-bier-slicing-and-differentiation-00.

Juniper Business Use Only

From: BIER <bier-bounces@ietf.org> On Behalf Of Tony Przygienda
 Sent: Friday, August 11, 2023 4:19 PM
 To: Joel Halpern <jmh@joelhalpern.com>
 Cc: Tony Li <tony.li@tony.li>; mpls@ietf.org; BIER WG <bier@ietf.org>
 Subject: Re: [Bier] [mpls] First IMPLS MNA Interim meeting after IETF 117

[External Email. Be cautious of content]

I watch the discussion develop quite agnostically. I see the slice use case as valid (though practically speaking I doubt we need more than DSCP bits unless someone convinces me that it's worth holding state for 100s of slices in core routers and get paid for it but on the other hand we hold state for 10Ks of LSPs and it pays ;-) . My question is now what is the _precise_ use case for slice

1) do we need slice control _per_ branching point/destination, i.e. on replication one branch can  end up on different slice than another branch? In such case it looks to me that the info must be before BIER, ie. we carry MPLS stack fronting BIER holding the branche's slice, otherwise we have to craft a BIER payload for every replication branch and this is performance wise prohibitive since it may force in silicon replication of whole BIER packets just to muck up the slice (and operationally the whole thing is not even possible since branching cannot be controlled on network changes so all of a sudden a branch will send to different destinations than before the topology change and hence the "slice per destination" is a concept that cannot be controlled).

2) the whole BIER subdomain (i.e. "tree" instance) is on a single slice. Here we could put the slice into BIER in some MPLS independent manner. Most logical seems to me to carry inside BIER an MPLS frame (if MPLS already carries the slice via ISD or whatever) via proto=1 and the silicon on forwarding sees proto=1 and looks into the MPLS stack to find the slice. no need to come up with complications to have BIER label support PSD or further label stacks as single stack etc for this use case). Now, every encaps (ether, whatever) would need to look into the BIER payload with the e.g. ethernet frame with slice info on it (no idea how taht would look but it's kind of similar for BIER carrying through 802.1q in ethernet frame proto type) would need to do that but slice is here the concept that an underlay wants to impose and it seems the price of having to parse the encaps on every forwarding hop to find the slice.  Dragging slice into BIER AFAIS would lead to MPLS having one slice and then BIER another slice and then the questions arise "is theat the same namespace or is ther MPLS slicing and BIER slicing".

Ultimately, if slicing is the only use case and we can live with 256 of those, BIER offers subdomains which support flex algo, own computation types, whatever one imagines and it's feasible to think of a subdomain as homomorphic to a slice if one chooses such a mappng AFAIS

And to drag it even further, BIER supports MT as well so it's really combination of 12 bit MT + 8 bit SD that could define a slice. That's _tons_ stuff

But yes, SD and MT are control plane concepts and if people are bent on carrying slice on the packet then consideration 1 and 2 applies

-- tony

On Fri, Aug 11, 2023 at 2:56 AM Joel Halpern <jmh@joelhalpern.com> wrote:

I think the solution has to be per encaps.  For example, it does not 
 good for BIER if MPLS solves it, and then one tries to use SRv6 to carry 
 BIER carrying IPv6 with an IPv6 NRP indication. Whereas, if BIER as 
 decided how to address or identify NRPs, then things flow through just 
 fine, with no need for forcing anything past anything else.  Let's not 
 complicate our lives.

 Yours,

 Joel

 On 8/10/2023 8:49 PM, Tony Li wrote:
 > I concur that it is not up to MPLS to unilaterally decide that.  However, it does seem to me that folks that DO want a NRP architecture with MPLS and multicast are going to want some solution.
 >
 > I’m less comfortable with ignoring this issue as it could block MNA deployment.
 >
 > T
 >
 >> On Aug 10, 2023, at 5:45 PM, Joel Halpern <jmh.direct@joelhalpern.com> wrote:
 >>
 >> If Detnet or BIER want to support an NRP selector, it is up to them to define how to support it.  It is not up to MPLS to try to reach through layers of encapsulation.  (Given their nature, it is not clear to me that either one needs an NRP selector.  But that is for those working groups to decide.)
 >>
 >> Yours,
 >>
 >> Joel
 >>
 >> On 8/10/2023 8:43 PM, Tony Li wrote:
 >>> Hi Greg,
 >>>
 >>>
 >>>> indeed, section 2.1 and 3.4 describe optional scopes of the particular MNA and optional AD. What I'm looking for perhaps needs a different term. I think that we agree that the scope is the scope of the MPLS stack, whether ISD MNA or PSD MNA. Is my understanding correct? If that is the case, then we cannot expect MNA work across the BIER distribution tree but only between adjacent BFRs because the MPLS stack, including the BIER-MPLS label, is disposed of before BFD processes the BitString based on the BIFT-id information. Now, looking back at our discussion of DetNet and MNA, I have come to the realization that MNA is applicable only at DetNet forwarding sub-layer between DetNet Service sub-layer nodes. In other words, on the LSP that connects two DetNet nodes with any of PREOF functions. And to make NA action work across the DetNet Service sub-layer, in my opinion, requires changes to d-CW and d-ACH, making it into a DetNet Network Action. The alternative, as I can see it, is to use the management plane to install MNA on each of the segments of the underlay across the given overlay service.
 >>> I confess that I have no understanding of DetNet, but as long as BIER and DetNet treat MPLS as a pure underlay, there are going to be architectural limitations. How do we propagate an NRP selector across a BIER/MPLS or MPLS/DetNet network?
 >>>
 >>> Changing all layers to make this work strongly suggests that we’ve got something screwy in the forwarding plane architecture.
 >>>
 >>> Tony
 >>>
 >>>
 > _______________________________________________
 > mpls mailing list
 > mpls@ietf.org
 > https://www.ietf.org/mailman/listinfo/mpls
 _______________________________________________
 BIER mailing list
 BIER@ietf.org
 https://www.ietf.org/mailman/listinfo/bier