Re: [sfc] Fw:New Version Notification for draft-ao-sfc-oam-path-consistency-04.txt

Greg Mirsky <gregimirsky@gmail.com> Thu, 14 February 2019 00:35 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48838130EB9 for <sfc@ietfa.amsl.com>; Wed, 13 Feb 2019 16:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlxzif4-fDdC for <sfc@ietfa.amsl.com>; Wed, 13 Feb 2019 16:35:16 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 7E847130EB4 for <sfc@ietf.org>; Wed, 13 Feb 2019 16:35:15 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id j19so2880506ljg.5 for <sfc@ietf.org>; Wed, 13 Feb 2019 16:35:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kz/q/E/CsSV2BHOZTphKd3lSrl12h+ya33OH3rjlMew=; b=APc2c/hmnw0tjXxqIEhZ/5IH2+fldt2vO5uwD6DknVwCSFvr+bW6w7l9C2QjKRqAqp w9QGblJ//UogHqhatS3YU7vuvZNTJrjOh7p6DrO66nkSvJ8OBbPnS9uIO5QFGYrz51Ey 2odBxjedaG8xCBYkN0Tcoa+6KDyoBRuyIEjDHYSRy0jtA3P1ArUtD8cwl6bTnudBdOI5 8Ik1kmaSaHaaCFYMTzszHW7eBdUdJfkP9J+8488oaHZSMmP47QtfUyuwkEtjmc+J7HTe Y3ymudRK/M67gGw5AUNBAR29yculFbdlPGmeHOuVby5MBRM+G4XZu138oCnFDdnym6n9 DFGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kz/q/E/CsSV2BHOZTphKd3lSrl12h+ya33OH3rjlMew=; b=PT4jz9VEQ7Rb98gIXoWoRRzL70QTAzuJI2DlPrA/i3f1FvDW9x4Nos9MZMlahkzSRM rTH5jDFVRJvEzLhE1EuFGcY2Eal+tYCru0dTvECRuQgZyVo/6njFsD2QgwNY7vHL9eMc dLj95IAdc8/SNdiQVS53waqWQx5KM2nu8iUQw2FyT5OW54LVkiByG+/2oBli81C47PGU Er14nJ7R28B3SPixuSsEAcFroM7xD73Ob6jMg/3CzXLLtqT7U/WBTlL7NttQ4Sw2oiRj QZi/BcqkFXWHdcRSaeyPymOYdGdrSPFd9yNFkc5wc99kxtuj55kJzgKQkU8dVPZUJjV9 my1g==
X-Gm-Message-State: AHQUAuYQ03Reo0KOVEiNdVFOg0iw4G+3lDrx7ga1U9br96LxxBoJH7GX I5zLok7CzS/ZG+2uCNfocst8YJEIiJKJmGAWGGk=
X-Google-Smtp-Source: AHgI3Ib3NBlN6zQH/QQUizRzNQ4dg5NeV/tvTy0fMRs40l61fN47ebMQQnLL+imNH6PRRe1z+rtTe0EqY5SGLD7pNiI=
X-Received: by 2002:a2e:86ca:: with SMTP id n10-v6mr451574ljj.49.1550104513430; Wed, 13 Feb 2019 16:35:13 -0800 (PST)
MIME-Version: 1.0
References: <201901030041.x030fHSA068733@mse01.zte.com.cn> <FRXPR01MB013498F3DC3E93804109F978D16E0@FRXPR01MB0134.DEUPRD01.PROD.OUTLOOK.DE> <CA+RyBmWw55PFRqs3=FY4aAA=4QcxmPAwa8Y_tnp5JzQMgY7PvQ@mail.gmail.com>
In-Reply-To: <CA+RyBmWw55PFRqs3=FY4aAA=4QcxmPAwa8Y_tnp5JzQMgY7PvQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 13 Feb 2019 16:35:01 -0800
Message-ID: <CA+RyBmXb5hOSvY2ueSfxmowxoV+rUZyjVha4HWQoWRwiAM8JJw@mail.gmail.com>
To: Dirk.von-Hugo@telekom.de
Cc: ao.ting@zte.com.cn, Service Function Chaining IETF list <sfc@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000e3839e0581cfd4cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/q3-eQAAcMES-s4hYRyfT1kgIpTA>
Subject: Re: [sfc] Fw:New Version Notification for draft-ao-sfc-oam-path-consistency-04.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 00:35:22 -0000

Hi Dirk, et al.,
I've updated the Active SFC OAM draft to address comments from Dirk. Much
appreciate your feedback whether changes captured and resolved them all.
Will post the new version after your response.

Regards,
Greg

On Tue, Feb 5, 2019 at 4:41 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Dirk,
> thank you for your kind words about the drafts, thoughtful comments, and
> the most helpful suggestions. Will work on updating drafts and will share
> the proposed changes with you shortly.
>
> Best regards,
> Greg
>
> On Tue, Feb 5, 2019 at 8:06 AM <Dirk.von-Hugo@telekom.de> wrote:
>
>> Dear all,
>>
>> I have read both drafts on extending SFC OAM by adding a reply path TLV
>> for testing SFPs and for checking consistency of SFPs.
>>
>> I believe that for operators such measures are very useful when SFC is
>> deployed in future networks and logical network slices.
>>
>>
>>
>> As both drafts rely on adopted WG draft
>> https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01 I also had
>> a look at that one.
>>
>> Comments and nits:
>>
>> P.4:
>>
>> the service SFP1 may be realized through two RSPs, RSP1(SF1--SF3--SF5)
>> and RSP2(SF2--SF4--SF5). =>
>>
>> the service SFP1 may be realized through two independent RSPs,
>> RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6).
>>
>> Since IMO there are further possible RSPs as SF1—SF4--SF5, SF1—SF3—SF6,
>> etc.
>>
>> P.7:
>>
>> BFD => BFD (Bidirectional Forwarding Detection)
>>
>> P.8:
>>
>>    o  Reply via Specified Path (TBA7) =>    o  Reply via Specified Path
>> (TBA8)
>>
>> P.9/p.10:
>>
>> *5.2*
>> <https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01#section-5.2>*.
>> SFC Echo Request Reception*
>>
>> *5.4*
>> <https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01#section-5.4>*.
>> Overlay Echo Reply Reception*
>>
>> There is still text missing in both sections
>>
>>
>>
>> Regarding the main drafts in focus here I only have very minor comments
>> (nits) on draft-ao-sfc-oam-returned-path-specified-02:
>>
>> P.2:
>>
>> [RFC7665], For example, => [RFC7665]. For example,
>>
>> P.3:
>>
>> the SFC Reply Path TLV Section 4. => the SFC Reply Path TLV as described
>> in Section 4.
>>
>> P.5:
>>
>> return path is a SFP => return path is an SFP
>>
>> SFP,it is assumed that the last SFF doesn't know the reply path of a SFC
>>
>> => SFP, it is assumed that the last SFF doesn't know the reply path of an
>> SFC
>>
>>
>>
>> And on draft-ao-sfc-oam-path-consistency-04.txt:
>>
>> P.2:
>>
>> Sometimes, a SF needs to => Sometimes, an SF needs to
>>
>> P.4:
>>
>> following values Section 5.1 => following values further detailed in
>> Section 5.1
>>
>> as as described in Section=> as is described in Section
>>
>> P.6:
>>
>> list of the SFs are in load balance group
>>
>> => list of the SFs which are in included in a load balance group.
>>
>> P.8/9:
>>
>> TBA1-TBA4, TBA6-TBA8 are requested but no TBA5?!
>>
>>
>>
>> As already said I think the extensions are useful and I see no open gaps.
>>
>> Thanks!
>>
>> Kind regards
>>
>> Dirk
>>
>>
>>
>> *From:* sfc <sfc-bounces@ietf.org> *On Behalf Of *ao.ting@zte.com.cn
>> *Sent:* Mittwoch, 2. Januar 2019 15:42
>> *To:* sfc@ietf.org
>> *Subject:* [sfc] Fw:New Version Notification for
>> draft-ao-sfc-oam-path-consistency-04.txt
>>
>>
>>
>> Hi all,
>>
>>
>>
>> We have updated a new version for draft draft-ao-sfc-oam-path-consistency-04
>> based on the discussion in the mailist. The main change is the COAM Reply
>> message for load balance scenario in section 3.4.2.  Any comments are
>> always welcome.
>>
>>
>>
>> We think both draft-ao-sfc-oam-path-consistency-04(
>> https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-04) and
>> draft-ao-sfc-oam-returned-path-specified-02(
>> https://tools.ietf.org/html/draft-ao-sfc-oam-return-path-specified-02)
>> are ready. We request for the consideration of the WG adoption.
>>
>>
>>
>> Best Regards.
>>
>> Ting Ao
>>
>>
>>
>> 原始邮件
>>
>> *发件人:*internet-drafts@ietf.org <internet-drafts@ietf.org>
>>
>> *收件人:*Gregory Mirsky <gregimirsky@gmail.com>;敖婷00071246;Kent Leung <
>> kleung@cisco.com>;Zhonghua Chen <18918588897@189.cn>;Greg Mirsky <
>> gregimirsky@gmail.com>;
>>
>> *日 **期 **:*2018年12月27日 16:26
>>
>> *主 **题 **:New Version Notification for
>> draft-ao-sfc-oam-path-consistency-04.txt*
>>
>>
>> A new version of I-D, draft-ao-sfc-oam-path-consistency-04.txt
>> has been successfully submitted by Ting Ao and posted to the
>> IETF repository.
>>
>> Name:        draft-ao-sfc-oam-path-consistency
>> Revision:    04
>> Title:        SFC OAM for path consistency
>> Document date:    2018-12-27
>> Group:        Individual Submission
>> Pages:        11
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ao-sfc-oam-path-consistency-04.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ao-sfc-oam-path-consistency/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-04
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ao-sfc-oam-path-consistency
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ao-sfc-oam-path-consistency-04
>>
>> Abstract:
>>    Service Function Chain (SFC) defines an ordered set of service
>>    functions (SFs) to be applied to packets and/or frames and/or flows
>>    selected as a result of classification.  SFC Operation,
>>    Administration and Maintenance can monitor the continuity of the SFC,
>>    i.e., that all elements of the SFC are reachable to each other in the
>>    downstream direction.  But SFC OAM must support verification that the
>>    order of traversing these SFs corresponds to the state defined by the
>>    SFC control plane or orchestrator, the metric referred in this
>>    document as the path consistency of the SFC.  This document defines a
>>    new SFC OAM method to support SFC consistency check, i.e.
>>    verification that all elements of the given SFC are being traversed
>>    in the expected order.
>>
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>