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

Tony Li <tony.li@tony.li> Fri, 11 August 2023 00:09 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E2BC151980; Thu, 10 Aug 2023 17:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level:
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTv6u6AULBpb; Thu, 10 Aug 2023 17:09:52 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1C3C151539; Thu, 10 Aug 2023 17:09:52 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-5655f47ae3fso737269a12.1; Thu, 10 Aug 2023 17:09:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691712591; x=1692317391; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=fWz0eaIaWjHtIGzLKz6yScJG1NVhI+84fFcuaRARxn4=; b=fosxCvfctOFX4k/XTejTVk5mIMMwTcKcfhRNcToXdoxNaB3PUoKG8+/g0O4umEnoZw ECunEQgmqWLkaVLgHpbVyBMY+jzRGhEn7LYEo7A/i2YABRkAAV85KKU8GDXYmssNQYEV lyi0CZzCMoDXD4L3XaNKAe4BM8Evy6KQ9/hNgwaX6JslsvUfw8c7qu1zAbclAK8oTIq4 9eLznWZyiByNQvzNMbNnXh8bsWPXr29Sa4UFFuEIG9dyoMUoicj9TlZ0flRvJwnhbPuN HBjVj1HdK4QXQ8/tVqDJ5/fCDPpXuUUF7dgq6tC+VD7kvIjT951UxXycGDrunWZIuJeu /jxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691712591; x=1692317391; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fWz0eaIaWjHtIGzLKz6yScJG1NVhI+84fFcuaRARxn4=; b=a3gjLi742vvalWuxnDvpijrt0ju0noeIIrqmla4kkBnxQbt4RjGa6zXbyz/UPRrBmX 2trzTUM876Hv4YFEGTG6j6BdgDT0a9GM+7MIZsI2DAgvMrs5WHHFgmcPAQMDt2JosUtZ TkL1P2rOxhWPApNuliAMv1h+DnceYkPsCBxcczcYi5tfhbf+D/bM+sny2kGo0auN8sR5 5hU1kAJZ4Xhkeub0CqLP+fE2LXBpfhpU6B9H06OFDP1ET7LxYWtRigGu9RKFsdtr2qh9 bp+an4oCuhjb0EOfmstSCRnp0wH8LMhAuRUxLYnfg+yIospRM2jnpt8QbaPOgL5bQsNJ 2uHQ==
X-Gm-Message-State: AOJu0YyVVSddOrvY736zHVq8OfJbYtJlGPDJsBkGb94YWmzSD5IrVbXe xdV2ZXGIIynt1El+NRZ+cvY=
X-Google-Smtp-Source: AGHT+IGFQmN9E72IMaVwXkq0iwqlNE2A4ppuKquZqrzNkpGAyFnInDP7KWJml2V4ZZVZ4dntWInUGQ==
X-Received: by 2002:a17:903:2d0:b0:1b8:a697:3719 with SMTP id s16-20020a17090302d000b001b8a6973719mr409093plk.25.1691712591056; Thu, 10 Aug 2023 17:09:51 -0700 (PDT)
Received: from smtpclient.apple (c-73-231-0-74.hsd1.ca.comcast.net. [73.231.0.74]) by smtp.gmail.com with ESMTPSA id v22-20020a17090331d600b001b895a18472sm2369375ple.117.2023.08.10.17.09.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2023 17:09:50 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <809C0713-597B-4B3D-BCE4-691E7858CE54@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5BCAAEA-1DB0-4309-8505-4D1D29098108"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Thu, 10 Aug 2023 17:09:39 -0700
In-Reply-To: <CA+RyBmVS2ZWyAtkfUX32msTLYsyk5-KFdKNvz6JuZyWhPP3vHQ@mail.gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "mpls@ietf.org" <mpls@ietf.org>, BIER WG <bier@ietf.org>
To: Greg Mirsky <gregimirsky@gmail.com>
References: <71c69c9d-6069-83d3-f37a-bcbbfc9797d4@pi.nu> <CA+RyBmWMNZof04EyQ55LzsKvbh+JpRr_p7n30ToLhVS94Br8hA@mail.gmail.com> <8f44de4b-0234-32c5-3fbe-74b16f75ac7f@pi.nu> <CA+RyBmWQOmWg8dvLxieTfTopbX45sVS8um+jVrW6XGXm4D=b2g@mail.gmail.com> <BL0PR05MB5652C6A0B99E2464240AFD60D413A@BL0PR05MB5652.namprd05.prod.outlook.com> <CA+RyBmVLPFOH6p5JRXEFTEQbE8oX--mtcdTh+YXOwEmOAz3=Sw@mail.gmail.com> <9d4a01f1-8459-33ab-9281-e64602c2f4f7@joelhalpern.com> <CA+RyBmVS2ZWyAtkfUX32msTLYsyk5-KFdKNvz6JuZyWhPP3vHQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/GLNu1D1HCct6FJ_PFfXeI2GWVHk>
Subject: Re: [mpls] First IMPLS MNA Interim meeting after IETF 117
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2023 00:09:56 -0000

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 <mailto: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):
>>> 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.
>>> 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 <mailto: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 <mailto:mpls-bounces@ietf.org>> On Behalf Of Greg Mirsky
>>>> Sent: Monday, August 7, 2023 9:00 PM
>>>> To: Loa Andersson <loa@pi.nu <mailto:loa@pi.nu>>
>>>> Cc: gjshep@gmail.com <mailto:gjshep@gmail.com>; Tony Przygienda <tonysietf@gmail.com <mailto:tonysietf@gmail.com>>; mpls@ietf.org <mailto: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 <mailto: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> 
>>>> > <mailto: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> <mailto:loa@pi.nu <mailto:loa@pi.nu>>
>>>> >     Senior MPLS Expert loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com> <mailto: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> <mailto: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 <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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls