Subject: [mpls] (no subject)

From: Greg Mirsky <[email-masked]>
Date: Sat, 13 Oct 2018 13:24:35 -0700

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 13 Oct 2018 22:13:48 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Oct 2018 07:44:10 -0700

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 <[email-masked]> wrote:

>> 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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Oct 2018 10:58:22 -0400

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 <[email-masked]> 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:
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Oct 2018 08:56:09 -0700

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 <[email-masked]> wrote:

> 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
>
>
>>> 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
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Oct 2018 03:47:46 +0000

Hi,

Cc BFD WG

It would be useful to understand the use case motivation or applicability of this draft, other than it can be done.

I’m also increasingly concerned by confusing scope and definition of specifications.

For example:

https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2

3.2.  Non-IP Encapsulation of Multipoint BFD

   Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP MUST use
   Generic Associated Channel (G-ACh) Label (GAL) [RFC5586] at the
   bottom of the label stack followed by Associated Channel Header
   (ACH).  Channel Type field in ACH MUST be set to BFD CV [RFC6428].

First, there’s no definition for non-IP BFD in RFC 5586 — only in RFC 5885.
Second, the specification in RFC 6428 applies to MPLS Transport Profile only. NOT for MPLS, and explicitly NOT for P2MP!

https://tools.ietf.org/html/rfc6428#section-1

   This document specifies the BFD extension and behavior to satisfy the
   CC, proactive CV monitoring, and the RDI functional requirements for
   both co-routed and associated bidirectional LSPs.  Supported
   encapsulations include Generic Associated Channel Label (GAL) /
   Generic Associated Channel (G-ACh), Virtual Circuit Connectivity
   Verification (VCCV), and UDP/IP.  Procedures for unidirectional
   point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for
   further study.

So, no, this does not work.

RFC 6428 does not have scope for P2MP.
And RFC 5586 does not specify anything for BFD. Instead, what needs to be cited (appropriately and expanded) is RFC 5885

https://tools.ietf.org/html/rfc6428#section-4
      RFC 5884 - BFD CC in UDP/IP/LSP
      RFC 5885 - BFD CC in G-ACh
      RFC 5085 - UDP/IP in G-ACh
       MPLS-TP - CC/CV in GAL/G-ACh or G-ACh

Thanks,

— Carlos Pignataro

On Oct 13, 2018, at 4:24 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls