From nobody Mon Apr 24 11:00:15 2023
Return-Path: <gregimirsky@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id DBECEC14CE45;
 Mon, 24 Apr 2023 11:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 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_NONE=-0.0001,
 RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001,
 URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 eJXspMVOhI8M; Mon, 24 Apr 2023 11:00:11 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [IPv6:2a00:1450:4864:20::436])
 (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 2A629C14CEFD;
 Mon, 24 Apr 2023 11:00:11 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-2f6401ce8f8so2890489f8f.3; 
 Mon, 24 Apr 2023 11:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1682359209; x=1684951209;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=340IVMwVmRLNSS7ulhqhDHryP2X6wRdmr2voCyasTX0=;
 b=HQMSjEjc2JF1ZM88CcyTYO/Gisrd11uAEI8QwVgOxlRKE7x711FjSC7E93QcEhGHb9
 8fCUPPRGEcC+t/lDjdXLHI9427JuPBjcrSs+5XoaX/fPrabJQ5VRHZCavK4rTiwfWrmi
 XYNr5hI323qbUQqMXSlSht2mlrIoGCUkBIVtSYBQLwEMKZYAtH8F6TRrH6if6RvaL9k6
 PXx9pr0IjLftDKUL+Q7w08F8MRNO3m05Us++Ki4zChboj6UiCtu285CvPg0M2AITX5Zi
 JWpDyw6qt7cqe23VbvdXZV7rQHVnpnRfcu36qVAFv4WZQLFrd4xHZ8EOUfJOTzPtxebU
 w1Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1682359209; x=1684951209;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=340IVMwVmRLNSS7ulhqhDHryP2X6wRdmr2voCyasTX0=;
 b=J3SmTCimbG/XVbOM4TrblUm1lKopFj8q5PuI/RolUv1oin0Ljj5CZ5qM35fWcSvXfV
 6S4y5TGZVAFcd7g3UkRWM2WZuCLCex/nEegN3rurkLl8X9ADuVAAo3GFOYUfXL7d3CcK
 O0glJ8zQcAYrqEG4sx5W+yk+jwAJdRtCozudOauW87u4zGpaV4a0aszVo100k1LB2Go+
 ckVnNkhsq+PXx/7dlncspVSejGA5kqaJQtrY5b9R40XaR2Hi4UKNgKBgUdWHRFVYXFa+
 XSDSQWW4eFtqZ/zYANd4BgK1oT1TTkOgR5t/UpAp6xgbbKwuU3qyhWY928PfXXNLqxtw
 fHIA==
X-Gm-Message-State: AAQBX9dvNX586SQ6GSFcmmbCtN9SlEw2D9zJfKt/jsAD42ZxRbVCzkdv
 1cObZGIKBX7Mvhi8JufgCthTgYT2+j33K30kDMs=
X-Google-Smtp-Source: AKy350a9PyHg7LRUUIO7aLewE8wwZ94H4O2wSbu+aFskETH4r2MJS5MvRrQzpZK6Bpm08YPLXEPMlpZquQboQmHwrK8=
X-Received: by 2002:a5d:6591:0:b0:2fb:1a68:1d96 with SMTP id
 q17-20020a5d6591000000b002fb1a681d96mr9630079wru.15.1682359209128; Mon, 24
 Apr 2023 11:00:09 -0700 (PDT)
MIME-Version: 1.0
References: <167990761218.28475.14370047592920159610@ietfa.amsl.com>
 <CA+RyBmWGW6vg+-Gq-7tZp=oxDA3TP8EnRGk0h2hLSjwOyr-5Hg@mail.gmail.com>
 <CAH6gdPw8gdnB3TXNwBpqUGVdrEUF8iq35==buBwRUjGwikF6cg@mail.gmail.com>
 <CA+RyBmWWpC4a6ktUEo1_mx=u17rNSuyfDMLm36OV8_9Rpin5xQ@mail.gmail.com>
 <DU0PR07MB92181C32BF60B84D54790A0CEB8F9@DU0PR07MB9218.eurprd07.prod.outlook.com>
In-Reply-To: <DU0PR07MB92181C32BF60B84D54790A0CEB8F9@DU0PR07MB9218.eurprd07.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 24 Apr 2023 10:59:55 -0700
Message-ID: <CA+RyBmUOB0Y7eQDTn5HJ875V=chR2Pu4TZO0ZdBQhi6ni-sWAw@mail.gmail.com>
To: "Matthew Bocci (Nokia)" <matthew.bocci@nokia.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, spring <spring@ietf.org>, 
 "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000b76de05fa18c735"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/7TNf1RLQgMp-gt-wJZjW_rCWkW4>
Subject: Re: [spring] Pending work items on draft-ietf-spring-bfd
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>,
 <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>,
 <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2023 18:00:14 -0000

--0000000000000b76de05fa18c735
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ketan and Matthew,
thank you for your insights into the applicability of the S-BFD application
in Segment Routing. I would greatly appreciate it if you could help me
understand the relationship between the general statement "S-BFD is used to
monitor SR Policy" and its application if SR-based SFC as described in
draft-ietf-spring-nsh-sr
<https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/>. I interpret
the statement "S-BFD is used to monitor an SR Policy" as applicable to all
scenarios with all behaviors. If that is the case, how would the SR part of
the encapsulation of the S-BFD Control message look in SR-based SFC? Would
it be identical to the encapsulation of a data packet that includes NSH?
Thank you for your help.

Regards,
Greg

On Fri, Mar 31, 2023 at 10:23=E2=80=AFAM Matthew Bocci (Nokia) <
matthew.bocci@nokia.com> wrote:

> Hi Greg
>
> I see S-BFD as the most prevalent flavour of BFD for monitoring SR
> Policies,  avoiding the need for LSP Ping bootstrapping. Nokia has an
> implementation for both MPLS and SRv6 SR Policies, and I am aware of othe=
rs
> out there.
>
> Given the widespread implementation of S-BFD for SR Policy, it would make
> sense to incorporate S-BFD as a mechanism in the SPRING BFD draft.
>
> Regards
>
>
> Matthew
>
> ------------------------------
> *From:* spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Sent:* Wednesday, March 29, 2023 3:19:47 AM
> *To:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Cc:* spring <spring@ietf.org>; spring-chairs@ietf.org <
> spring-chairs@ietf.org>
> *Subject:* Re: [spring] Pending work items on draft-ietf-spring-bfd
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See http://nok.it/ext for additional
> information.
>
>
> Hi Ketan,
> thank you for sharing your comments about the state of
> draft-ietf-spring-bfd. Please find my notes in-line below under the GIM>>
> tag.
>
> Regards,
> Greg
>
> On Wed, Mar 29, 2023 at 11:11=E2=80=AFAM Ketan Talaulikar <ketant.ietf@gm=
ail.com>
> wrote:
>
> Hi Greg/Authors,
>
> I believe this draft still needs work before it is ready for WGLC.
>
> Specifically, it does not cover the use of S-BFD for the monitoring of SR
> Policies and AFAIK this is the more widely used than the mechanism
> specified in the draft currently (i.e. than the bootstrap via LSP Ping to
> setup a "normal" BFD session).
>
> GIM>> Can you clarify how BFD or S-BFD can monitor an SR Policy? As
> defined in RFC 5880, the scope of BFD is:
>
>    a protocol intended to detect faults in the
>    bidirectional path between two forwarding engines, including
>    interfaces, data link(s), and to the extent possible the forwarding
>    engines themselves, with potentially very low latency.
>
> At the same time, I believe that an SR policy can be monitored using LSP
> Ping with the corresponding Target FEC.
>
>
> I am not saying that the mechanism in the draft cannot be used, but
> progressing this document toward publication without reflecting the other
> alternate mechanism that IMO is far more widely implemented and
> deployed will provide a somewhat misleading picture.
>
> My request to the authors is to consider inclusion of text from
> https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/ in this
> WG document. We can discuss f2f during this week if you agree.
>
> GIM>> Thank you for your suggestion. Let us discuss the applicability of =
a
> BFD-based mechanism in monitoring an SR policy.
>
>
> I would like us to seek inputs from implementers and operators on which o=
f
> these two mechanisms they prefer/use. Including this in the document woul=
d
> also be helpful.
>
> GIM>> I wholeheartedly agree and welcome anyone to share their experience=
s
> of monitoring SR policies with MPLS OAM tools.
>
>
> Thanks,
> Ketan
>
> On Mon, Mar 27, 2023 at 6:04=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.co=
m> wrote:
>
> Refresh and to update author's contact information.
>
> Dear All,
> the draft is stable and the authors believe it is ready for the WG LC. We
> appreciate the WG Chairs' consideration for starting the WG LC.
>
> Regards,
> Greg (on behalf of the authors)
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Mar 27, 2023 at 6:00=E2=80=AFPM
> Subject: New Version Notification for draft-ietf-spring-bfd-06.txt
> To: Mach Chen (Guoyi) <mach.chen@huawei.com>, Greg Mirsky <
> gregimirsky@gmail.com>, Ilya Varlashkin <imv@google.com>, Jeff Tantsura <
> jefftant.ietf@gmail.com>, Jiang Wenying <jiangwenying@chinamobile.com>
>
>
>
> A new version of I-D, draft-ietf-spring-bfd-06.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-ietf-spring-bfd
> Revision:       06
> Title:          Bidirectional Forwarding Detection (BFD) in Segment
> Routing Networks Using MPLS Dataplane
> Document date:  2023-03-27
> Group:          spring
> Pages:          14
> URL:
> https://www.ietf.org/archive/id/draft-ietf-spring-bfd-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/
> Html:
> https://www.ietf.org/archive/id/draft-ietf-spring-bfd-06.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-bfd
> Diff:
> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-spring-bfd-06
>
> Abstract:
>    Segment Routing (SR) architecture leverages the paradigm of source
>    routing.  It can be realized in the Multiprotocol Label Switching
>    (MPLS) network without any change to the data plane.  A segment is
>    encoded as an MPLS label, and an ordered list of segments is encoded
>    as a stack of labels.  Bidirectional Forwarding Detection (BFD) is
>    expected to monitor any existing path between systems.  This document
>    defines how to use Label Switched Path Ping to bootstrap a BFD
>    session, control an SR Policy in the reverse direction of the SR-MPLS
>    tunnel, and applicability of BFD Demand mode in the SR-MPLS domain.
>    Also, the document describes the use of BFD Echo with BFD Control
>    packet payload.
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>

--0000000000000b76de05fa18c735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ketan and Matthew,<div>thank you for y=
our insights into the applicability of the S-BFD application in Segment Rou=
ting. I would greatly appreciate it if you could help me understand the rel=
ationship between the general statement &quot;S-BFD is used to monitor=C2=
=A0SR Policy&quot; and its application if SR-based SFC as described in=C2=
=A0<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/">d=
raft-ietf-spring-nsh-sr</a>. I interpret the statement &quot;S-BFD is used =
to monitor an SR Policy&quot; as applicable to all scenarios with all behav=
iors. If that is the case, how would the SR part of the encapsulation of th=
e S-BFD Control message look in SR-based SFC? Would it be identical to the =
encapsulation of a data packet that includes NSH?</div><div>Thank you for y=
our help.</div><div><br></div><div>Regards,</div><div>Greg</div></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fr=
i, Mar 31, 2023 at 10:23=E2=80=AFAM Matthew Bocci (Nokia) &lt;<a href=3D"ma=
ilto:matthew.bocci@nokia.com">matthew.bocci@nokia.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div>
<div>
<div dir=3D"ltr">
<div>Hi Greg</div>
<div dir=3D"ltr"><br>
</div>
<div dir=3D"ltr">I see S-BFD as the most prevalent flavour of BFD for monit=
oring SR Policies, =C2=A0avoiding the need for LSP Ping bootstrapping. Noki=
a has an implementation for both MPLS and SRv6 SR Policies, and I am aware =
of others out there.</div>
<div dir=3D"ltr"><br>
</div>
<div dir=3D"ltr">Given the widespread implementation of S-BFD for SR Policy=
, it would make sense to incorporate S-BFD as a mechanism in the SPRING BFD=
 draft.</div>
<div dir=3D"ltr"><br>
</div>
<div dir=3D"ltr">Regards</div>
<div dir=3D"ltr"><br>
</div>
</div>
</div>
<div id=3D"m_-2736489803760440699ms-outlook-mobile-signature">
<div><br>
</div>
<div style=3D"direction:ltr">Matthew</div>
<div><br>
</div>
</div>
</div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_-2736489803760440699divRplyFwdMsg" dir=3D"ltr"><font face=3D"C=
alibri, sans-serif" style=3D"font-size:11pt" color=3D"#000000"><b>From:</b>=
 spring &lt;<a href=3D"mailto:spring-bounces@ietf.org" target=3D"_blank">sp=
ring-bounces@ietf.org</a>&gt; on behalf of Greg Mirsky &lt;<a href=3D"mailt=
o:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail.com</a>&gt;<br=
>
<b>Sent:</b> Wednesday, March 29, 2023 3:19:47 AM<br>
<b>To:</b> Ketan Talaulikar &lt;<a href=3D"mailto:ketant.ietf@gmail.com" ta=
rget=3D"_blank">ketant.ietf@gmail.com</a>&gt;<br>
<b>Cc:</b> spring &lt;<a href=3D"mailto:spring@ietf.org" target=3D"_blank">=
spring@ietf.org</a>&gt;; <a href=3D"mailto:spring-chairs@ietf.org" target=
=3D"_blank">spring-chairs@ietf.org</a> &lt;<a href=3D"mailto:spring-chairs@=
ietf.org" target=3D"_blank">spring-chairs@ietf.org</a>&gt;<br>
<b>Subject:</b> Re: [spring] Pending work items on draft-ietf-spring-bfd</f=
ont>
<div>=C2=A0</div>
</div>
<div>
<table border=3D"0" width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"left">
<tbody>
<tr>
<td style=3D"background:rgb(255,185,0);padding:5pt 2pt">=C2=A0</td>
<td width=3D"100%" style=3D"background:rgb(255,248,229);padding:5pt 4pt 5pt=
 12pt">
<div style=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34);font-=
weight:bold"><font size=3D"3">CAUTION:</font></span> This is an external em=
ail. Please be very careful when clicking links or opening attachments. See=
 <a href=3D"http://nok.it/ext" target=3D"_blank">http://nok.it/ext</a> for =
additional information.</div>
</td>
</tr>
</tbody>
</table>
<p>=C2=A0</p>
<div>
<div dir=3D"ltr">
<div dir=3D"ltr">
<div dir=3D"ltr">Hi Ketan,
<div>thank you for sharing your comments about the state of draft-ietf-spri=
ng-bfd. Please find my notes in-line below under the GIM&gt;&gt; tag.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Greg</div>
</div>
<br>
<div>
<div dir=3D"ltr">On Wed, Mar 29, 2023 at 11:11=E2=80=AFAM Ketan Talaulikar =
&lt;<a href=3D"mailto:ketant.ietf@gmail.com" target=3D"_blank">ketant.ietf@=
gmail.com</a>&gt; wrote:<br>
</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div>Hi Greg/Authors,</div>
<div><br>
</div>
<div>I believe this draft still needs work before it is ready for WGLC.</di=
v>
<div><br>
</div>
<div>Specifically, it does not cover the use of S-BFD for the monitoring of=
 SR Policies and AFAIK this is the more widely used than the mechanism spec=
ified in the draft currently (i.e. than the bootstrap via LSP Ping to setup=
 a &quot;normal&quot; BFD session).</div>
</div>
</blockquote>
<div>GIM&gt;&gt; Can you clarify how BFD or S-BFD can monitor an SR Policy?=
 As defined in RFC 5880, the scope of BFD is:</div>
</div>
</div>
<blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
<div>
<div>
<div>=C2=A0 =C2=A0a protocol intended to detect faults in the</div>
</div>
</div>
<div>
<div>
<div>=C2=A0 =C2=A0bidirectional path between two forwarding engines, includ=
ing</div>
</div>
</div>
<div>
<div>
<div>=C2=A0 =C2=A0interfaces, data link(s), and to the extent possible the =
forwarding</div>
</div>
</div>
<div>
<div>
<div>=C2=A0 =C2=A0engines themselves, with potentially very low latency.=C2=
=A0</div>
</div>
</div>
</blockquote>
At the same time, I believe that an SR policy can be monitored using LSP Pi=
ng with the corresponding Target FEC.<br>
<div dir=3D"ltr">
<div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div><br>
</div>
<div>I am not saying that the mechanism in the draft cannot be used, but pr=
ogressing this document toward publication without reflecting the other alt=
ernate mechanism that IMO is far more widely implemented and deployed=C2=A0=
will provide a somewhat misleading picture.</div>
<div><br>
</div>
<div>My request to the authors is to consider inclusion of text from <a hre=
f=3D"https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/" targ=
et=3D"_blank">
https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/</a> in thi=
s WG document. We can discuss f2f during this week if you agree.<br>
</div>
</div>
</blockquote>
<div>GIM&gt;&gt; Thank you for your suggestion. Let us discuss the applicab=
ility of a BFD-based mechanism in monitoring an SR policy.=C2=A0</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div></div>
<div><br>
</div>
<div>
<div>I would like us to seek inputs from implementers and operators on whic=
h of these two mechanisms they prefer/use. Including this in the document w=
ould also be helpful.</div>
</div>
</div>
</blockquote>
<div>GIM&gt;&gt; I wholeheartedly agree and welcome anyone to share their e=
xperiences of monitoring SR policies with MPLS OAM tools.=C2=A0</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Ketan</div>
<br>
<div>
<div dir=3D"ltr">On Mon, Mar 27, 2023 at 6:04=E2=80=AFPM Greg Mirsky &lt;<a=
 href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail.=
com</a>&gt; wrote:<br>
</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">Refresh and to update author&#39;s contact information.
<div><br>
</div>
<div>Dear All,</div>
<div>the draft is stable and the authors believe it is ready for the WG LC.=
 We appreciate the WG Chairs&#39; consideration for starting the WG LC.</di=
v>
<div><br>
</div>
<div>Regards,</div>
<div>Greg (on behalf of the authors)<br>
<br>
<div>
<div dir=3D"ltr">---------- Forwarded message ---------<br>
From: <span dir=3D"auto">&lt;<a href=3D"mailto:internet-drafts@ietf.org" ta=
rget=3D"_blank">internet-drafts@ietf.org</a>&gt;</span><br>
Date: Mon, Mar 27, 2023 at 6:00=E2=80=AFPM<br>
Subject: New Version Notification for draft-ietf-spring-bfd-06.txt<br>
To: Mach Chen (Guoyi) &lt;<a href=3D"mailto:mach.chen@huawei.com" target=3D=
"_blank">mach.chen@huawei.com</a>&gt;, Greg Mirsky &lt;<a href=3D"mailto:gr=
egimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail.com</a>&gt;, Ilya =
Varlashkin &lt;<a href=3D"mailto:imv@google.com" target=3D"_blank">imv@goog=
le.com</a>&gt;,
 Jeff Tantsura &lt;<a href=3D"mailto:jefftant.ietf@gmail.com" target=3D"_bl=
ank">jefftant.ietf@gmail.com</a>&gt;, Jiang Wenying &lt;<a href=3D"mailto:j=
iangwenying@chinamobile.com" target=3D"_blank">jiangwenying@chinamobile.com=
</a>&gt;<br>
</div>
<br>
<br>
<br>
A new version of I-D, draft-ietf-spring-bfd-06.txt<br>
has been successfully submitted by Greg Mirsky and posted to the<br>
IETF repository.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-spring-bfd<br>
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A006<br>
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection=
 (BFD) in Segment Routing Networks Using MPLS Dataplane<br>
Document date:=C2=A0 2023-03-27<br>
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spring<br>
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14<br>
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.o=
rg/archive/id/draft-ietf-spring-bfd-06.txt" rel=3D"noreferrer" target=3D"_b=
lank">
https://www.ietf.org/archive/id/draft-ietf-spring-bfd-06.txt</a><br>
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://datatracker.iet=
f.org/doc/draft-ietf-spring-bfd/" rel=3D"noreferrer" target=3D"_blank">http=
s://datatracker.ietf.org/doc/draft-ietf-spring-bfd/</a><br>
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.o=
rg/archive/id/draft-ietf-spring-bfd-06.html" rel=3D"noreferrer" target=3D"_=
blank">https://www.ietf.org/archive/id/draft-ietf-spring-bfd-06.html</a><br=
>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org=
/doc/html/draft-ietf-spring-bfd" rel=3D"noreferrer" target=3D"_blank">https=
://datatracker.ietf.org/doc/html/draft-ietf-spring-bfd</a><br>
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://author-too=
ls.ietf.org/iddiff?url2=3Ddraft-ietf-spring-bfd-06" rel=3D"noreferrer" targ=
et=3D"_blank">https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-spring=
-bfd-06</a><br>
<br>
Abstract:<br>
=C2=A0 =C2=A0Segment Routing (SR) architecture leverages the paradigm of so=
urce<br>
=C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S=
witching<br>
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s=
egment is<br>
=C2=A0 =C2=A0encoded as an MPLS label, and an ordered list of segments is e=
ncoded<br>
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection=
 (BFD) is<br>
=C2=A0 =C2=A0expected to monitor any existing path between systems.=C2=A0 T=
his document<br>
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap a BFD=
<br>
=C2=A0 =C2=A0session, control an SR Policy in the reverse direction of the =
SR-MPLS<br>
=C2=A0 =C2=A0tunnel, and applicability of BFD Demand mode in the SR-MPLS do=
main.<br>
=C2=A0 =C2=A0Also, the document describes the use of BFD Echo with BFD Cont=
rol<br>
=C2=A0 =C2=A0packet payload.<br>
<br>
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
<br>
</div>
</div>
</div>
_______________________________________________<br>
spring mailing list<br>
<a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org</a><br=
>
<a href=3D"https://www.ietf.org/mailman/listinfo/spring" rel=3D"noreferrer"=
 target=3D"_blank">https://www.ietf.org/mailman/listinfo/spring</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div>

--0000000000000b76de05fa18c735--

