Re: [Bier] BIERv6 and BIERin6 OAM support discussion

Gyan Mishra <hayabusagsm@gmail.com> Thu, 26 November 2020 05:49 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEB33A0B2D for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 21:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s3BZIBIht60 for <bier@ietfa.amsl.com>; Wed, 25 Nov 2020 21:49:30 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 02EB43A0B2B for <bier@ietf.org>; Wed, 25 Nov 2020 21:49:30 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id w4so752037pgg.13 for <bier@ietf.org>; Wed, 25 Nov 2020 21:49:29 -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; bh=m5YxyXsnIPzkgHUgBCwCQ9FQZH6h3n805tQNpWzIXhc=; b=KnZ5nX9AVL3+e752PZuY4MektRgkPw6/5ndYNaD0i67artUBtvN3uLg9RsmnP8hoIi 24lG+resNcjiam/O3q68m/pHGx3o4kYcDoPW68pEJUXpaKM6h3Q3rQkj2V5RxHsO8Drc Xfp1xSW7PpIql686Gfm0RJfjERAMNXt6F7lbVhKTYoMHcd/LYep1kfi7Oj+Ul2tVvUYK pXWry1llg5ZuQsIyQnRysUukdourhedyT8Hocfk1ZIO47onX+KYM1rSuGtMLWOxmAL5x cpW5WoLql85lgeqJBSqGGa+Nt6yugFO1n2uQGSBogtr0yaP6tQNyAVf4ttWa21RSNj/F Y09Q==
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; bh=m5YxyXsnIPzkgHUgBCwCQ9FQZH6h3n805tQNpWzIXhc=; b=j+K7RG/I5Qj8IIyoAFAkyfKx0mEiM+LZM2K9URxpiOxvk1nXzXTfccJ9VN9ibSdchQ FbTgcjYc/MIVqaSKROFLlBZQOYx4Y+IxwWjoO7/m2sF+0CFELJ1JXFIsMdPtduas047n od5eWY/g+mYgyb9CJibXt7XfLqpif8LW33BY//+xhsGemwiGB2SWRmT3CjhSMjZ7zm3y QMAd6f3INNXvsUN1aCCabQETMQIBOBsMB2CsU1yUrY4SyfjC2SM3M74z+Y6FsEtWoMs3 TQX8H/I+tOshC6O8beRo2rZ4EY0x9N3XWVjJTDxMEPlkFOmxPKBXBlpsYq1ZTMi7Hy3h F90Q==
X-Gm-Message-State: AOAM533788GvTFpe6QxQxGz87lw2CMDCtcA2xWeIkvFWyX1hh3rO9g2z Ch/+1aQxAKfc9xXeDnnnRrTIng9ZVJb2gZTvSGHfFOKwx4s=
X-Google-Smtp-Source: ABdhPJzdcfbtXjtmZJ2X+hoGcibsjnwSv1OFsALXTCA8oAXNz3KBS8zD5WjCCqCMPjmzsEo4OiDeUm3QPdEmmev9EJQ=
X-Received: by 2002:aa7:8812:0:b029:199:25e7:4ab7 with SMTP id c18-20020aa788120000b029019925e74ab7mr1437496pfo.30.1606369769315; Wed, 25 Nov 2020 21:49:29 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV17gK0-OVthEa=JMmYmHS5+oXi9_W5=H-PqR5qiRDp38g@mail.gmail.com> <CABNhwV3-BSjdqdqxoqTJ8+xf+gM9OC21ZuPTZBJyJWzbSS+Apg@mail.gmail.com>
In-Reply-To: <CABNhwV3-BSjdqdqxoqTJ8+xf+gM9OC21ZuPTZBJyJWzbSS+Apg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 26 Nov 2020 00:49:10 -0500
Message-ID: <CABNhwV2go38QPCKU0uZi7vPkyvoxoAoOBiZxMn0PO3s-cmHLog@mail.gmail.com>
To: BIER WG <bier@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>, Greg Shepherd <gjshep@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>, Michael McBride <michael.mcbride@futurewei.com>, Tianran Zhou <zhoutianran@huawei.com>, Tony Przygienda <tonysietf@gmail.com>, Xiejingrong <xiejingrong@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000007a61a905b4fc1b52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/qQ1FrF2YlUs-kTMZiNmk2orwVag>
Subject: Re: [Bier] BIERv6 and BIERin6 OAM support discussion
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2020 05:49:32 -0000

Greg

With BIERv6 the Bier header encoded in DOH, as it is encoded as long as we
include the 2 bit OAM field for PNPM in the DOH encoding, is it possible
that OAM could work with BIERv6?

Kind Regards

Gyan
On Thu, Nov 26, 2020 at 12:37 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Greg
>
> With RFC 8296 Non MPLS BIER Ethernet next header 0xAB37  and optIonal
> BIERin6 encapsulation single hop or multi hop tunnel the BIER header is
> present either after Ethernet header in the latter or after the IPv6 header
> in BIERin6 and is present to encode OAM value for proto fied.
>
> With BIERv6 there is not any “BIER” encapsulation layer as the BIER header
> is encoded in IPV6 extension header DOH header.  As it is not encoded in
> the IPV6 packet header and is part of IPv6 header as is an extension
> header, OAM will not work natively with BIERv6.
>
>
> Jingrong and Xuesong
>
> Please shed some light on how OAM would work with BIERv6?
>
> Thanks
>
> Gyan
>
> On Wed, Nov 25, 2020 at 11:47 PM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>> RE: BIER in IPV6 environment OAM support
>>
>> ***Tonys email related to OAM requirement***
>>
>> Quick correction here as to OAM. OAM is worked on and multiple quite
>> extensive & well-written drafts dealing with OAM aspects are adopted/in
>> flight since quite a while (I count 4 adopted & 1 individual). BIER has
>> been specifically architected with multicast OAM in mind which is
>> non-trivial such as MTU discovery (we have 2 drafts for a good reason &
>> discussion is pending) and dealing with OAM when we're dealing with mp2mp
>> trees (which BIER basically is or can be used at). One of the reasons BIER
>> found interest in the set of people that need/like it is that they were
>> looking for very tight OAM guarantees in orders of microseconds and that
>> without highly specific hardware designed for it is very difficult (and
>> packet format, that's why OAM is first order citizen in BIER in terms of
>> bits provided e.g. for marking purposes and can be found in a very specific
>> offset. to support the OAM desired HW has to process and generate
>> sub-microseconds trains.
>>
>> As far as I saw there was not much on the radar in terms of anything
>> comparable in SRv6 OAM work beside "SID-ping" if the intention is to rely
>> on SRv6 to deal with that problem. But of course I may have missed some
>> draft. Even if they work on unicast OAM I may express my profound doubts
>> there will be interest or focus to solve OAM for SRv6 becoming a L3
>> multicast transport with the type of OAM BIER needs on top.
>>
>> As to desired OAM, I think we have an OAM requirements draft adopted with
>> quite a list of industry authors since quite a bit. this draft has WG
>> consensus and has to be satisfied.
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/?include_text=1
>>
>> -- tony
>>
>> Greg Mirsky update request to BIER IPv6 Requirements draft:
>>
>> Dear All,
>> I apologize for jumping into this discussion but have someone said "OAM"?
>> :)
>> I much appreciate what our co-chair (and contributor to BIER OAM) had to
>> say about the state of BIER OAM work. I agree with Tony's summary that our
>> joint efforts already created the toolset of the distinctive solutions for
>> BIER OAM. We've followed draft-ietf-bier-oam-requirements
>> <https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/> to
>> define the comprehensive set of OAM mechanisms that support proactive and
>> on-demand failure detection and localization using both BFD and echo
>> request/reply. Also, as Tony mentioned, we have drafts on path MTU
>> discovery in the BIER environment and application of the Alternate Marking
>> method for the packet delay and packet loss measurement in a BIER domain.
>> In my opinion, the section on OAM in draft-ietf-bier-ipv6-requirements is
>> helpful. I have a question on the intention of the following wording:
>>
>> .... by specifying a new method for the same functionality.
>>
>> If there's, for example, WG draft on proactive failure detection in the
>> BIER network using p2mp BFD with unsolicited notifications, why would we
>> entertain the idea of defining a new protocol or method for the same
>> purpose? I think that the ability to use BIER OAM solutions as defined in
>> their respective drafts already accepted by the WG (and some even passed
>> WGLC) is the litmus test for any proposed method of realizing BIER in IPv6
>> network. Thus I propose the following change of Section 3.1.4
>> <https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09#section-3.1.4>
>> :
>> OLD TEXT:
>>    BIER OAM tools like [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam]
>>    should be supported, either directly using existing methods, or by
>>    specifying a new method for the same functionality.  They are likely
>>    to be needed in normal BIER deployment for diagnostics.
>> NEW TEXT:
>>    BIER OAM tools defined in WG document, for example,
>>    [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam],
>>    must be supported as defined in the respective specifications.
>> Consistency
>>    of OAM BIER tools is essential for the productive operation of BIER
>> networks.
>>
>>
>> Regards,
>> Greg
>>
>>
>> RE:  Greg Mirsky start of BIER IPv6 OAM discussion related to the two
>> IPV6 environment solutions
>>
>> Hi Tianran,
>> I just recently read both proposals - BIERin6 and BIERv6. Understandably,
>> I was interested in how each solution handles BIER OAM.
>> draft-zhang-bier-bierin6 explains that:
>>    BIER has its own OAM function, so generally the IPv6 OAM function is
>>    not needed.
>> And I agree with that conclusion. BIER OAM will work because BIER header
>> is used as defined in RFC 8296, including using OAM value in the Proto
>> field.
>> draft-xie-bier-ipv6-encapsulation states that:
>>         How BIER-PING is supported in BIERv6
>>         encapsulation without using this Proto field is outside the
>>         scope of this document.
>> That left me with many questions. Thus, from my point of view, BIERv6
>> needs to demonstrate how BIER OAM, as defined in numerous WG drafts, works
>> in BIERv6 domain. Without that, I cannot compare the two proposals fairly.
>>
>> Regards,
>> Greg
>>
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD