Re: [mpls] p2mp BFD over MPLS LSP

Greg Mirsky <gregimirsky@gmail.com> Wed, 17 October 2018 15:56 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 DB5EC130EB2; Wed, 17 Oct 2018 08:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 KZH9GUGgHx40; Wed, 17 Oct 2018 08:56:21 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 47D84130ED0; Wed, 17 Oct 2018 08:56:21 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id l1-v6so426253lfc.3; Wed, 17 Oct 2018 08:56:21 -0700 (PDT)
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=Q7xWwOLRwUyzDgFkaMzsoqD11kYade8HunPsroqFSqE=; b=mX30qVD87i9wbT5nFE325N23jlgOxS5KMeLhLX0yX5WT9/168G3qFUc0xt4koERGKm uwRzxKVtxWujb13Xzo5GjkqkFude7TZU2g+giC07qOQGHtuvaSB/oVaWFQNDUxhcb5JP MSw/cBfdrzg455F7Kbk7QUkPpCqG2+GmmLyO4kxh2cvuUaPAuMc0b9y9FaqHROwiqqwl 9MHYIfgZJqA2yZXWtHDqSbXz1EQeLdf2SrRtqYqhRI9X34p+FQWSvf6njqDDsEqjk/jc noYAroMZDZTxDztzvP0b6shmpKG64TkvLdFAfjpPYRlF0SM7I5N1MWs79xmn9azAi9Lv wEWg==
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=Q7xWwOLRwUyzDgFkaMzsoqD11kYade8HunPsroqFSqE=; b=rKWys3+ALcZExNv9YFXzzYYtXl0U3KS5hA45U0qSRURZTtg9Kb92jv59jP61WfIE9U T2T4kT0Z9khg3rbfrC4xbWQu0QnR8LEmuYxaiIK+IbmZRovPWa9XHLGrQDKwQMoS7ixN bLzVnD0dB+ZyfNBVcZikEbxhZxZY9RneH/qpOouCnBorTpnTsDeEbG6um8PS+UwcoX7g O7qOKQBVnBIP9UdlfNL9Rz7Ft9tD9NbRi3Ujb1DA6FeV66oZNvuRr2p3wuGIrQ+3s28l TYk34eVI/OorOCCepJYWKafqVVlmr2gBPdvC15+OG3Kk6ytd1XEQp8V/CEHKM98n/bZg YM2A==
X-Gm-Message-State: ABuFfoh0XmjH0WAe75mLPOEyRzWYP6CilDCa5+5ju22/73wO9wKxgs2A m5uwFFn9tM90GP4xecNG+800Y36/Szu4FhT4iwhQwHuF
X-Google-Smtp-Source: ACcGV625FfgpyrculaUVDkhl1FGmMIO07yQDh1jri4OsKmkYBda5dvg0H1S1HZzCdt49lY+5qoDZrNc2APpKqSUBBag=
X-Received: by 2002:a19:9f8c:: with SMTP id i134-v6mr15729964lfe.52.1539791779345; Wed, 17 Oct 2018 08:56:19 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVDvb6t3rh3sZUHrsApfJRb9A8GCLxPCe9b=tcvZz6J3w@mail.gmail.com> <CABNhwV2dkxWbJSShwWZ_Qqb0jOE_vAjG7YgVUj4Y8S2nqgF=mw@mail.gmail.com> <CA+RyBmX6KiE08vvRxS7KJFTGvaBuAeWP=+0n6M_hHv-Bz8THXQ@mail.gmail.com> <CABNhwV0zr5WeN+3jpxhw-8mR_gDOGdyCNf5sbesMMvPvmaZt+w@mail.gmail.com>
In-Reply-To: <CABNhwV0zr5WeN+3jpxhw-8mR_gDOGdyCNf5sbesMMvPvmaZt+w@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 17 Oct 2018 08:56:09 -0700
Message-ID: <CA+RyBmUud8K3=6Lpm=WrSxFmhVskakTa8P7DaQby55sQ8D242Q@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: mpls-chairs@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000093c6d05786eb659"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/tgveEIBE0rM3Cjf-uBxIV16tAN4>
Subject: Re: [mpls] p2mp BFD over MPLS LSP
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: Wed, 17 Oct 2018 15:56:33 -0000

Hi Gyan,
if the application requires protection switchover to be performed by the
head of the p2mp LSP, then you may take advantage of p2mp BFD with active
tails. I think that it is a more suitable mode of p2mp BFD for such
scenario. For the case of 1+1 protection p2mp BFD without active tails
seems an appropriate choice.

Regards,
Greg

On Wed, Oct 17, 2018 at 7:58 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Thanks Greg for the thorough explanation.
>
> P2MP BFD over mpls lsp so that could be mldp or TE p2mp lsp correct and
> for either if protection is done at the head of the lsp which would be the
> FEC root you would not need the P2MP bfd with active tail spec.
>
> Thank you
>
> Gyan
>
> Gyan
>
>
> On Mon, Oct 15, 2018, 10:44 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Hi Gyan,
>> thank you for your very pointed question. The base specification for BFD
>> in multipoint networks (often referred to as "p2mp BFD") explains that in
>> p2mp and mp2mp MPLS LSP cases p2mp BFD MAY use IP/UDP encapsulation in
>> Section 5.8:
>>
>>    For multipoint LSPs, when IP/UDP encapsulation of BFD control packets
>>    is used, MultipointTail MUST expect destination UDP port 3784.
>>    Destination IP address of BFD control packet MUST be in 127.0.0.0/8
>>    range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6.  The
>>    use of these destination addresses is consistent with the
>>    explanations and usage in [RFC8029].  Packets identified as BFD
>>    packets MUST be consumed by MultipointTail and demultiplexed as
>>    described in Section 5.13.2.  Use of other types of encapsulation of
>>    the BFD control message over multipoint LSP is outside the scope of
>>    this document.
>>
>> In some environments using IP/UDP encapsulation for BFD Control packet is
>> overburden, and this draft explains how p2mp BFD must be used with G-ACh
>> encapsulation. Both types, IP/UDP and G-ACh, may be used to monitor MVPN.
>> Additionally, note that the base p2mp BFD mode does not support tail
>> notification of the path failure to the head. If the protection action to
>> be performed not by the tail but the head, you'd need to use BFD for
>> Multipoint Networks with Active Tail specification. G-ACh encapsulation may
>> be used in any of these specs.
>>
>> Regards,
>> Greg
>>
>> On Sat, Oct 13, 2018 at 7:14 PM Gyan Mishra <hayabusagsm@gmail.com>
>> wrote:
>>
>>> Hi Greg
>>>
>>> So this Draft would support BFD with IPv6 encap along with the IPV4
>>> encap for P2MP MVPN LSP so would this support all MVPN profiles.
>>>
>>> Thank you
>>>
>>> Gyan
>>>
>>> On Sat, Oct 13, 2018, 4:25 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>>>
>>>> Dear WG Chairs, et al.,
>>>> as the author of the BFD for Multipoint Networks over
>>>> Point-to-Multi-Point MPLS LSP (draft-mirsky-mpls-p2mp-bfd) I would like to
>>>> ask you to consider WG adoption call of the draft. The document addresses
>>>> non-IP encapsulation of p2mp BFD over MPLS LSP that may be useful if the
>>>> overhead of IP, particularly IPv6, encapsulation is the concern. The base
>>>> specification of BFD for Multipoint Networks is at this time in IESG LC.
>>>>
>>>> Regards,
>>>> Greg
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>