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,

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-multipath/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> 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.

Thanks!
Mirja


> 
> Best regards,
> Mach 
>> 
>