Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Mach,

See below.

> On 13. Mar 2019, at 11:52, Mach Chen <[e-mail]> wrote:
> 
> Hi Mirja,
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind [mailto:[e-mail]]
>> Sent: Wednesday, March 13, 2019 5:51 PM
>> To: Mach Chen <[e-mail]>
>> Cc: Mirja Kühlewind via Datatracker <[e-mail]>; The IESG
>> <[e-mail]>; [e-mail]; draft-ietf-mpls-lsp-ping-lag-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-
>> multipath-06: (with COMMENT)
>> 
>> Hi Mach,
>> 
>> Please see below
>> 
>>> On 13. Mar 2019, at 10:15, Mach Chen <[e-mail]> wrote:
>>> 
>>> Hi Mirja,
>>> 
>>> Thanks for your comments!
>>> 
>>>> -----Original Message-----
>>>> From: Mirja Kühlewind via Datatracker [mailto:[e-mail]]
>>>> Sent: Wednesday, March 13, 2019 12:00 AM
>>>> To: The IESG <[e-mail]>
>>>> Cc: [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Mirja Kühlewind's No Objection on
>>>> draft-ietf-mpls-lsp-ping-lag-
>>>> multipath-06: (with COMMENT)
>>>> 
>>>> Mirja Kühlewind has entered the following ballot position for
>>>> draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>> this introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipa
>>>> th/
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> -
>>>> COMMENT:
>>>> ---------------------------------------------------------------------
>>>> -
>>>> 
>>>> I wanted to comment on the same sentence/normative requirement as
>>>> Alvaro did in his point (2). Given Alvaro's additional information
>>>> that there is actually even a technical conflict with this
>>>> requirement, I think this should be address before publication and
>>>> might even be discuss-worthy. However, I'm really not an expert on
>>>> MPLS and therefore leave the decision to state a discuss ballot position to
>> potentially other, more knowledgable ADs.
>>>> 
>>>> Thanks for addressing the TSV-ART review comments (and thanks Jörg
>>>> for the review)! I support adding another sentence with a pointer to
>>>> rate-limit requirements in other docs. Thanks for proposing this
>>>> change. Looking forward this see this in the doc!
>>> 
>>> Are you suggesting to add a reference, do you have any specific docs
>> suggestion?
>> 
>> In your reply to Joerg’s tsv-art review (on Dec 14 already), you proposed to
>> add the following statement:
>> 
>> "For an LSP path, it may be over several LAGs. For each LAG, there will be
>> many member links. To exercise all the links, many Echo Request/Reply
>> messages will be sent in a short period. It's possible that those messages may
>> traverse a common path as a burst. Under some circumstances this might
>> cause congestion at the common path. To avoid potential congestion, it is
>> RECOMMENDED that implementations to randomly delay the Echo Request
>> and Reply messages at the Initiating LSRs and Responder LSRs.”
>> 
>> You also said:
>> "RFC8029 (Security Consideration) does recommend the implementation to
>> regulate the ping traffic to the control plane, it  applies to this document as
>> well.
>> 
>> At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces some
>> ways to limit the message rate. The way of random delay messages would
>> apply to this document as well.”
>> 
>> So adding pointer to these two documents/sections would be good as well
>> maybe.
> 
> How about adding the below sentence?
> 
> "The similar rate limiting paradigm is already adopted in [RFC8029] and RFC[6425].”

That works, or, even better, you could say something more similar than what you said earlier, e.g.

“Rate limiting of ping traffic is further specified in RFC8092 (secti?n 1) and RFC6425 (section 2.2) which apply to this document as well.”

Thanks, 
Mirja


> 
> Best regards,
> Mach 
> 
>> 
>> Thanks!
>> Mirja
>> 
>> 
>>> 
>>> Best regards,
>>> Mach
>>>> 
>>> 
>