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

[Mach Chen <[e-mail]>]

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]."

Best regards,
Mach 

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