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

["Andrew G. Malis" <[e-mail]>]

Greg,

It's looking much better, thanks.

In your new text, I noticed some missing words at the end of section 3. In
the following, I've bolded and italicized the missing words.

   If *the* BFD control packet *is* encapsulated in
   IP/UDP, *then* the source IP address MUST be used to demultiplex the
   received BFD control packet as described in Section 3.1.  *The* non-IP
   encapsulation case *is* described in Section 3.2.

Just make those changes, and then upload it for the adoption poll.

Thanks again,
Andy



On Sun, Nov 18, 2018 at 5:13 PM Greg Mirsky <[e-mail]> wrote:

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