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

Hi Tony,
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.

On Thu, Aug 10, 2023 at 5:09 PM Tony Li <tony.li@tony.li> wrote:

>
> Hi Greg,
>
> Scopes are covered in sections 2.1 and 3.4.
>
> Perhaps I’m misunderstanding your intent.
>
> The problem that I’m trying to understand is how we get actions to
> propagate in a joint BIER/MPLS network.  It would seem to me that we would
> want the BFR to propagate any MNA headers that it receives, either ISD or
> PSD.  Without this we don’t get end-to-end MNA support, which would seem to
> be problematic.
>
> Tony
>
>
> On Aug 10, 2023, at 4:47 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Joel,
> I've looked through the MNA Framework
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-fwk/> and couldn't
> find the issue of the MNA scope settled or explained. The document lists
> different scopes of a particular MNA with or without associated AD, but not
> the scope of the MNA in the MPLS domain. I think that it would be helpful
> to have this issue clarified and explicitly recognized. The MNA Framework
> document seems like the most appropriate document for that.
>
> Regards,
> Greg
>
> On Thu, Aug 10, 2023 at 4:05 PM Joel Halpern <jmh@joelhalpern.com> wrote:
>
>> This sounds to me like a use case that doesn't exist.   If the MPLS label
>> stack is fully removed, then it is fully removed.  Including any PSD (and,
>> by definition, any ISD.)  This is not a difference between ISD and PSD.
>>
>> If we want to create such a case, one can imagine various awkward ways to
>> make it work.  But since we donb't have a use case for it, why would we do
>> so?
>>
>> Yours,
>>
>> Joel
>> On 8/10/2023 7:01 PM, Greg Mirsky wrote:
>>
>> Hi Jeffrey,
>> thank you for joining in the interim meeting and helping out with your
>> expertise.
>>
>> Dear All,
>> I have been thinking about the question raised by Jie today, the scope of
>> MNA in connection to BIER. As we've discussed, the scope of ISD MNA is
>> between BFRs that act as LERs in the MPLS underlay network. But what would
>> be the scope of PSD MNA? There, in my opinion, could be several scenarios
>> depending on where NASI, BIER-MPLS LSE, and a PSD MNA block are located. I
>> can see these options (just technically possible, not in the order of my
>> preference or viability of the case):
>>
>>    1. NASI precedes BIER-MPLS LSE, BIER-MPLS LSE is BoS, and PSD MNA
>>    immediately follows BoS with BIER Header following PSD block. In this case,
>>    I imagine that LER will dispose of NASI and PSD MNA block. Then BFR steps
>>    in and using BIFT-id contained in BIER-MPLS LSE processes the BIER header.
>>    It seems like PSD MNA is gone and, if not for an additional effort, the
>>    scope of PSD MNA is a single MPLS LSP between BFRs acting as LERs.
>>    2. Next is the case when the BIER-MPLS LSE precedes NASI, NASI
>>    includes an LSE that is BoS. PSD MNA follows the BoS LSE and then we find
>>    the BIER header. I don't see much difference with the previous scenario
>>    with perhaps a bit easier to retain PSD and push it onto replicated
>>    packets. But that, in my opinion, is still an extra effort on the part of
>>    the implementation.
>>
>> Am I missing something? Personally, I don't see this as a specific BIER
>> issue but as a case of an MNA over a multi-segment LSP. What are your
>> thoughts?
>>
>> Regards,
>> Greg
>>
>> On Thu, Aug 10, 2023 at 6:36 AM Jeffrey (Zhaohui) Zhang <
>> zzhang@juniper.net> wrote:
>>
>>> Hi,
>>>
>>>
>>> I tend to use email to organize my thoughts and share in preparation for
>>> discussions. The following are my thoughts on this topic.
>>>
>>>
>>>    - For BIER-MPLS, BIER is considered as MPLS payload. It should
>>>    continue to be considered as MPLS payload in the presence of PSD MNA. With
>>>    that, we should not put the PSD after the BIER header.
>>>    - While RFC8296 (BIER Encapsulation) has the BIER header starting
>>>    with an MPLS LSE (referred to as BIER label, with S=1) that is followed by
>>>    the rest of BIER header, a more logical view is that the BIER label is the
>>>    MPLS layer while the “rest of BIER header” is the BIER level. When PSD MNA
>>>    is needed, it should be put between the BIER label and the “rest of BIER
>>>    header”.
>>>    - Now the question is backward compatibility – how to prevent a
>>>    legacy BFR from receiving a BIER packet with a PSD MNA between the BIER
>>>    label and the rest of the BIER header.
>>>
>>>
>>>
>>> When an upstream BFR1 sends to a directly connected downstream BFR2,
>>> only one label is needed in the label stack – the BIER label itself. We can
>>> have the BFRs signal if it can handle PSD MNA so that the upstream BFR
>>> won’t put PSD MNA if the downstream BFR does not support it.
>>>
>>>
>>> There are cases when BFR1 needs to tunnel to BFR2 through some transit
>>> LSRs – then the label stack includes the tunnel label and BIER label. Now
>>> the problem is how to prevent those transit LSRs from inserting a PSD MNA
>>> if BFR2 is legacy. That is actually a BIER-agnostic issue – there may be
>>> other non-BIER situations where we don’t want transit LSRs to insert PSD
>>> MNA, unless the LSP egress can remove the PSD MNA and present the bottom
>>> label together with the payload to the “upper layer”.
>>>
>>>
>>> In case of LDP/RSVP LSPs, the signaling can indicate if the egress LER
>>> can do that. In case of SR-MPLS, IGP can indicate if an LSR/LER can do that.
>>>
>>>
>>> The options in slide 6 do not seem to work because the transit LSRs may
>>> not understand BIER at all.
>>>
>>>
>>> Jeffrey
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of * Greg Mirsky
>>> *Sent:* Monday, August 7, 2023 9:00 PM
>>> *To:* Loa Andersson <loa@pi.nu>
>>> *Cc:* gjshep@gmail.com; Tony Przygienda <tonysietf@gmail.com>;
>>> mpls@ietf.org
>>> *Subject:* Re: [mpls] First IMPLS MNA Interim meeting after IETF 117
>>>
>>>
>>> *[External Email. Be cautious of content]*
>>>
>>>
>>> Hi Loa,
>>>
>>> I received great suggestions on the slides from Tony. Attached, please
>>> find the copy ready for the interim next Thursday. Please let me know if
>>> there are any further questions.
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>> On Tue, Aug 1, 2023 at 1:38 PM Loa Andersson <loa@pi.nu> wrote:
>>>
>>> Greg, (copying bier chairs)
>>>
>>> Very good!
>>>
>>>
>>> Bier chairs,
>>>
>>> We like a discussion on the interworking between BIER over MPLS and MNA
>>> PSD. We did something similar for DetNet a few weeks back. Greg Mirsky
>>> has offered to do a presentation from a bier perspective. He has
>>> suggested that we have the presentation Thursday 2023-08-10, but if you
>>> have a date that suits you better we can do that.
>>>
>>> Greg should check the slides with you before the presentation.
>>>
>>> Plz send us a mail to let us know if this is OK, or if you have comments.
>>>
>>> /Loa
>>>
>>>
>>>
>>> On 2023-08-01 21:08, Greg Mirsky wrote:
>>> > Hi Loa,
>>> > I can have the presentation on the interworking between BIER over MPLS
>>> > and MNA PSD ready for the interim meeting next week.
>>> >
>>> > Regards,
>>> > Greg
>>> >
>>> > On Tue, Aug 1, 2023 at 2:07 AM Loa Andersson <loa@pi.nu
>>> > <mailto:loa@pi.nu>> wrote:
>>> >
>>> >     Working Group,
>>> >
>>> >     The first MPLS MNA Interim meeting is planned for 2023-08-10, give
>>> we
>>> >     have an agenda.
>>> >
>>> >     /Loa
>>> >     --
>>> >     Loa Andersson                        email: loa@pi.nu <mailto:
>>> loa@pi.nu>
>>> >     Senior MPLS Expert loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com
>>> >
>>> >     Bronze Dragon Consulting             phone: +46 739 81 21 64
>>> >
>>> >     _______________________________________________
>>> >     mpls mailing list
>>> >     mpls@ietf.org <mailto:mpls@ietf.org>
>>> >     https://www.ietf.org/mailman/listinfo/mpls
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!ARvx9v2rELDCdO2fVWtMCR6OxIAEkXVSp-GAbIo7qXblBIAbcx5etRCBbLTFLK1kiSbIktRcTczAVpsUH3Ak8g$>
>>> >     <https://www.ietf.org/mailman/listinfo/mpls
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!ARvx9v2rELDCdO2fVWtMCR6OxIAEkXVSp-GAbIo7qXblBIAbcx5etRCBbLTFLK1kiSbIktRcTczAVpsUH3Ak8g$>
>>> >
>>> >
>>>
>>> --
>>> Loa Andersson                        email: loa@pi.nu
>>> Senior MPLS Expert                          loa.pi.nu@gmail.com
>>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>>
>>>
>> _______________________________________________
>> mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>