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

[Joel Halpern <[e-mail]>]

Not getting MNS support is not a problem if the tassk is for MPLS to 
connect BIER nodes.

Separately, if there is an outer MPLS thing being carried by a BIER 
packet, then it is payload that is being multicast.   I guess that works 
as well as if one was using MPLS multicast.  And since it is payload, it 
pops up for processing exactly when the BIER is exhausted.

Now, if we want BIER to have additional MNA-like functionality, we would 
need to add that to BIER.  In the BIER working group. And if we / they 
did that, it would be trivial to inlclude appropriate MNA NAS in the 
MPLS label stack built by the BIER node that understood the new BIER 
functionality.

But this is not a problem MNA need to solve.  Lets get MNA ISD done, and 
see if it actually works and people actually deploy it.

Yours,

Joel

On 8/10/2023 8:09 PM, 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 <[e-mail]> 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 <[e-mail]> 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
>>>     <[e-mail]> 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 <[e-mail]> *On Behalf Of * Greg Mirsky
>>>         *Sent:* Monday, August 7, 2023 9:00 PM
>>>         *To:* Loa Andersson <[e-mail]>
>>>         *Cc:* [e-mail]; Tony Przygienda
>>>         <[e-mail]>; [e-mail]
>>>         *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 <[e-mail]> 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 <[e-mail]
>>>             > <mailto:[e-mail]>> wrote:
>>>             >
>>>             >     Working Group,
>>>             >
>>>             >     The first MPLS MNA Interim meeting is planned for
>>>             2023-08-10, give we
>>>             >     have an agenda.
>>>             >
>>>             >     /Loa
>>>             >     --
>>>             >     Loa Andersson               email: [e-mail]
>>>             <mailto:[e-mail]>
>>>             >     Senior MPLS Expert [e-mail]
>>>             <mailto:[e-mail]>
>>>             >     Bronze Dragon Consulting             phone: +46
>>>             739 81 21 64
>>>             >
>>>             >  _______________________________________________
>>>             >     mpls mailing list
>>>             > [e-mail] <mailto:[e-mail]>
>>>             > 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: [e-mail]
>>>             Senior MPLS Expert [e-mail]
>>>             Bronze Dragon Consulting      phone: [phone]
>>>
>>>
>>>     _______________________________________________
>>>     mpls mailing list
>>>     [e-mail]
>>>     https://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>