Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-04

[Greg Mirsky <[e-mail]>]

Hi Andy,
please find my notes and answers in-line tagged GIM2>>. All updates can be
reviewed in the attached diff and the working version of the draft.

Regards,
Greg

On Wed, Oct 31, 2018 at 6:41 AM Andrew G. Malis <[e-mail]> wrote:

> Greg,
>
> Thanks for checking.
>
> You didn't really address my comment: "I would have expected to see at
> least a reference to RFC 4687, "Operations and Management (OAM)
> Requirements for Point-to-Multipoint MPLS Networks", and some text on how
> this draft addresses the requirements in that draft.".
>
GIM>> This is not the specification for p2mp BFD. Issues of scaling and
performance of p2mp BFD discussed in detail in BFD for Multipoint Neworks
for use case of tail-only monitoring the unidirectional path, and BFD for
Multipoint Networks with Active Tail, for scenarios when the head uses
multipoint Poll sequence optionally in combination with unicasted Poll to
the particular tail to be aware of the state of the unidirectional path of
the multicast tree to tha tail. For example, the Security Considerations in
draft-ietf-bfd-multipoint suggest that:
      If redundant streams are expected for a given multicast stream,
      then the implementations should not create more MultipointTail
      sessions than the number of streams.  Additionally, when the
      number of MultipointTail sessions exceeds the number of expected
      streams, then the implementation should generate an alarm to users
      to indicate the anomaly.

      The implementation should have a reasonable upper bound on the
      number of MultipointTail sessions that can be created, with the
      upper bound potentially being computed based on the number of
      multicast streams that the system is expecting.

draft-ietf-bfd-multipoint-active-tail additionally notes that:
implementations that create MultpointClient sessions
   dynamically upon receipt of BFD Control packet from a tail MUST
   implement protective measures to prevent an infinite number of
   MultipointClient sessions being created.  Below are listed some
   points to be considered in such implementations.

      When the number of MultipointClient sessions exceeds the number of
      expected tails, then the implementation should generate an alarm
      to users to indicate the anomaly.

      The implementation should have a reasonable upper bound on the
      number of MultipointClient sessions that can be created, with the
      upper bound potentially being computed based on the number of
      multicast streams that the system is expecting.

In addition to these considerations listed in the base specifications for
p2mp BFD, I've added the following text:
    Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in
   section 4.1 [RFC4687] to avoid congestion in the control plane or the
   data plane caused by the rate of generating BFD control packets.  An
   operator SHOULD consider the amount of extra traffic generated by
   p2mp BFD when selecting the interval at which the MultipointHead will
   transmit BFD control packets.  Also, the operator MAY consider the
   size of the packet the MultipointHead transmits periodically as using
   IP/UDP encapsulation adds up to 28 octets, which is more than 50% of
   BFD control packet length, comparing to G-ACh encapsulation.


> You added a reference in the security section, but nothing about how your
> draft addresses the 4687 requirements.
>
> Also, you didn't really address my next comment: "I also expected more
> text on the relationship between this draft and RFC 6425, "Detecting
> Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"',
> and more of an explanation of why the keyword MAY is used in sections 4.1
> and 4.2 - what are the implications of following or not following the MAY
> in each case?"
>
> Regarding RFC 6425, I was looking for text along the lines of why one
> would choose to implement this draft rather than 6425 (or both), to give
> product implementers and network operators guidance on whether to use 6425,
> this draft, or both for MPLS p2mp data plane failure detection. Otherwise,
> why would they bother with this draft when they already have 6425 working?
>
> Also, in sections 4.1 and 4.2, you just added another MAY to section 4.1,
> but again, what happens if you don't do the MAYs in both sections? Why
> would I want to do the MAYs? Why would I not want to? The text doesn't say.
>
GIM2>> I've expanded the text and section 4.1 of the draft now is as
follows:
    LSP Ping is the part of on-demand OAM toolset to detect and localize
   defects in the data plane, and verify the control plane against the
   data plane by ensuring that the LSP is mapped to the same FEC, at the
   egress, as the ingress.

   LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
   MultipointTail.  If the LSP Ping used, it MUST include the Target FEC
   TLV and the BFD Discriminator TLV defined in [RFC5884].  The Target
   FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425].  It is
   RECOMMENDED setting the value of Reply Mode field to "Do not reply"
   [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp
   BFD session.  A MaultipointTail that receives the LSP Ping that
   includes the BFD Discriminator TLV:

   o  MUST validate the LSP Ping;

   o  MUST associate the received BFD Discriminator value with the p2mp
      LSP;

   o  MUST create p2mp BFD session and set bfd.SessionType =
      MultipointTail as described in [I-D.ietf-bfd-multipoint];

   o  MUST use the source IP address of LSP Ping, the value of BFD
      Discriminator from the BFD Discriminator TLV, and the identity of
      the p2mp LSP to properly demultiplex BFD sessions.

   Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD
   be used to verify the control plane against the data plane
   periodically by checking that the p2mp LSP is mapped to the same FEC
   at the MultipointHead and all active MultipointTails.  The rate of
   generation of these LSP Ping Echo request messages SHOULD be
   significantly less than the rate of generation of the BFD Control
   packets because LSP Ping requires more processing to validate the
   consistency between the data plane and the control plane.  An
   implementation MAY provide configuration options to control the rate
   of generation of the periodic LSP Ping Echo request messages.


> Finally, in section 3, the following sentence doesn't scan:
>
>    The source IP
>    address MAY be drawn from the IP header if BFD control packet
>    transmitted by the head using IP/UDP encapsulation as described in
>    Section 3.1.
>
> Did you mean "uses" instead of "using"?
>
GIM2>> Yes, it does need re-wording. Would this be better:
 If BFD control packet encapsulated in
   IP/UDP, the source IP address MUST be used to demultiplex the
   received BFD control packet as described in Section 3.1.

>
> Thanks,
> Andy
>
>
>
>
>
> On Tue, Oct 30, 2018 at 11:05 AM Greg Mirsky <[e-mail]>
> wrote:
>
>> Dear Andy,
>> thank you for the review and the detailed suggestions. Attached please
>> find the updated version of the draft and the diff to highlight the
>> proposed changes. Please let me know if these address your comments.
>>
>> Kind regards,
>> Greg
>>
>> On Wed, Oct 24, 2018 at 11:11 AM Greg Mirsky <[e-mail]>
>> wrote:
>>
>>> Dear Andy,
>>> thank you for your thorough review and the most helpful comments. I'll
>>> work on the update to address them.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Wed, Oct 24, 2018 at 9:17 AM Andrew G. Malis <[e-mail]>
>>> wrote:
>>>
>>>> I’ve been selected as an MPLS-RT reviewer for
>>>> draft-mirsky-mpls-p2mp-bfd-04, which is currently a candidate for MPLS WG
>>>> adoption. This draft documents procedures for using BFD for multipoint
>>>> networks to detect data plane failures in MPLS p2mp LSPs.
>>>>
>>>> The BFD WG has been working on draft-ietf-bfd-multipoint, which
>>>> describes BFD procedures for multipoint and multicast networks.
>>>> draft-mirsky-mpls-p2mp-bfd uses that draft as a basis to detect MPLS data
>>>> plane failures for p2mp LSPs. This is a straightforward and useful
>>>> application of the BFD draft for MPLS data plane failure detection.
>>>>
>>>> However, I would have expected to see at least a reference to RFC 4687,
>>>> "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS
>>>> Networks", and some text on how this draft addresses the requirements in
>>>> that draft.
>>>>
>>>> I also expected more text on the relationship between this draft and
>>>> RFC 6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS -
>>>> Extensions to LSP Ping"', and more of an explanation of why the keyword MAY
>>>> is used in sections 4.1 and 4.2 - what are the implications of following or
>>>> not following the MAY in each case?
>>>>
>>>> The draft also needs an editing pass, for example "MaultipointHead"
>>>> for "MultipointHead" and some incorrect English grammar in several
>>>> places.
>>>>
>>>> Once these items have been addressed, I think that the draft should be
>>>> ready for an adoption call.
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>>
>>>>