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

[Greg Mirsky <[e-mail]>]

Hi Andy,
thank you for your help and patience. Will do as you've suggested.

Kind regards,
Greg

On Mon, Nov 19, 2018 at 8:23 AM Andrew G. Malis <[e-mail]> wrote:

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