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

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
>
>