IETF Logo Mail Archive

Re: [mpls] Question regarding RFC8595

Greg Mirsky <gregimirsky@gmail.com> Tue, 19 April 2022 20:49 UTC

Return-Path: <gregimirsky@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 880393A15BA for <mpls@ietfa.amsl.com>; Tue, 19 Apr 2022 13:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlRSt66A-l9J for <mpls@ietfa.amsl.com>; Tue, 19 Apr 2022 13:48:59 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251143A15BE for <mpls@ietf.org>; Tue, 19 Apr 2022 13:48:59 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id bn33so22005411ljb.6; Tue, 19 Apr 2022 13:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wFxZg+higM8wmleetOL60KWSMvNTwGDeW9HmDZ1l/oE=; b=UDnBGStFQak/iSgwfcldyXIAjGs61O0TCDLrdaiTlKVoscbcNluybj68OpOILjx0cd 8VHr8A7oJiLqAMUgJOf8Z883VvLTjJHJFCpBALH3x1eWJFMoNi47XAyNIasxWvsaVP1o x9r8ELSLrl9M0GHbusKipbWFm5/TCvrJfgMy9YVRVfUdQjYOD1BnwzRy6zzLFtIaPiXc vnKhuVoFnDd9gp3GJ0RXe7o6v+YvdHnVwKL6zMO2OYsuTF7YtBC12b7qydiv6y0g4oYf zWH+TFN/2GRPSX2h4xMK1605YIBIFuIeICIvkia888oed14Gea3yvGqlqixbjMhSbFOa 0Qhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wFxZg+higM8wmleetOL60KWSMvNTwGDeW9HmDZ1l/oE=; b=OJRCXlVJYQilj20DCmWs9N8NIcAkT4834OvRaTeMKD34hF9Ma5SAOuwisRSRn8rWI8 ZuhZWJCNyK3WVT2vazTRIMhCAXNk5QNHeFR0je5G1h/hc0VKL26EFPdGP2PS7hs+zgrO kLVUlV3SDaDivEWaYcEP4Mg8uSfYAj9LNOEpgLLNDhns6UwPUEEpShmTXvZFATTsmGcY WnijrgKnVkJ+12tMuC7Thn2ikaH9vioiwlY4XIfnA6Sg3iaMcB6cgxemJrCN5hNdXMPL f6wcboT3YTaZjTZ+ggEH2n8SgouBRSxQIhO6LxcAFKqxqBZknG2MMzmd/HEz0GgjjdNY w2gQ==
X-Gm-Message-State: AOAM530fxXKnf0Q98QTc0gqbVtWV4RnyLQ1bJuc8ABe015dDN1+txhzj WiF6oh6+5O+cyWsAr2MV+atvth7oH6/qhhorkLI=
X-Google-Smtp-Source: ABdhPJwqf/1oVwqlNhtgvUMnx4gq1vvmzYRWgVdcrqvo28v79Ykbly1v0k6tVRYC0FDyjs2ZOyM6SuJFZU/SxpVzhvc=
X-Received: by 2002:a2e:1f11:0:b0:24b:6b35:42e3 with SMTP id f17-20020a2e1f11000000b0024b6b3542e3mr10870146ljf.195.1650401336367; Tue, 19 Apr 2022 13:48:56 -0700 (PDT)
MIME-Version: 1.0
References: <BY3PR13MB4787F13F0F3C25BE67F2980C9AF29@BY3PR13MB4787.namprd13.prod.outlook.com> <BY3PR05MB8081E5BDE972DF291BB65ADAC7F29@BY3PR05MB8081.namprd05.prod.outlook.com>
In-Reply-To: <BY3PR05MB8081E5BDE972DF291BB65ADAC7F29@BY3PR05MB8081.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 19 Apr 2022 13:48:44 -0700
Message-ID: <CA+RyBmV1wNr00yLvurddf+v3saHJuLx87TCY-6QkU57cOPuz8A@mail.gmail.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Cc: Haoyu Song <haoyu.song@futurewei.com>, "draft-ietf-mpls-sfc@ietf.org" <draft-ietf-mpls-sfc@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000641e7905dd08011c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/w-moLC8Cw2H51UsbxaMsMf_Xf_U>
Subject: Re: [mpls] Question regarding RFC8595
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 19 Apr 2022 20:49:04 -0000

Hi John,
in the course of working on the draft-saad-mpls-miad-usecases, the authors
agreed that the mechanism defined in RFC 8595 might need a further
extension to support NSH Context Header, fixed-sized and variable-length.
The next version of the draft reflects that. I agree that PSD seems a
logical mechanism to support the NSH Context Header in the context of RFC
8595. Using PSD to carry the entire NSH, i.e., the combination of Base
Header, Service Path Header, and Context Header(s), in the paradigm of RFC
8595 seems to be sub-optimal.

Regards,
Greg

On Tue, Apr 19, 2022 at 12:40 PM John E Drake <jdrake=
40juniper.net@dmarc.ietf.org> wrote:

> Haoyu,
>
>
>
> I think RFC 8595 could be supplemented by carrying the NSH as post-stack
> data.  I think the existing mechanisms defined in RFC 8595 for carrying SFC
> traversal information should be retained, so we may have a case for
> post-stack data without an NAI.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of * Haoyu Song
> *Sent:* Tuesday, April 19, 2022 2:23 PM
> *To:* draft-ietf-mpls-sfc@ietf.org
> *Cc:* mpls@ietf.org
> *Subject:* [mpls] Question regarding RFC8595
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear RFC8595 authors,
>
>
>
> I have a question. RFC8595 provides a method to emulate NSH in MPLS data
> plane.
>
> Now we are working on defining a new framework to support network actions
> in MPLS data plane.
>
> Once we have that, do you think it’s possible and useful to support NSH
> natively in MPLS data plane? That is, to put NSH directly in post-stack
> data (PSD) container.
>
> What I see an advantage is NSH can carry metadata while the emulating
> approach can’t.
>
> I’m not an expert of NSH so I need your thoughts on this. Thank you very
> much!
>
>
>
> Best regards,
>
> Haoyu
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

v2.23.0 | Report a Bug | By Email