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

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
>