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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 12 Mar 2019 09:00:19 -0700

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!

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Mar 2019 09:15:08 +0000

Hi Mirja,

Thanks for your comments!

> -----Original Message-----
> From: Mirja Kühlewind via Datatracker [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2019 12:00 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-
> multipath-06: (with COMMENT)
> 
> 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.)
> 
> 
> 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?

Best regards,
Mach

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Mar 2019 10:51:22 +0100

Hi Mach,

Please see below

> On 13. Mar 2019, at 10:15, Mach Chen <[email-masked]> wrote:
> 
> Hi Mirja,
> 

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

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Mar 2019 10:40:09 +0000

Hi Mirja,

Thanks, that's help a lot :-)

Best regards,
Mach 

> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2019 5:51 PM
> To: Mach Chen <[email-masked]>
> Cc: Mirja Kühlewind via Datatracker <[email-masked]>; The IESG
> <[email-masked]>; [email-masked]; draft-ietf-mpls-lsp-ping-lag-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-
> >> Cc: [email-masked];
> >> [email-masked]; [email-masked]; [email-masked]
> >> 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
> >> 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!
> >
> "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.”
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Mar 2019 10:52:22 +0000

Hi Mirja,

> So adding pointer to these two documents/sections would be good as well

How about adding the below sentence?

"The similar rate limiting paradigm is already adopted in [RFC8029] and RFC[6425]."

Best regards,
Mach

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Mar 2019 13:03:35 +0100

Hi Mach,

See below.

> On 13. Mar 2019, at 11:52, Mach Chen <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> "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

---

From: Mach Chen <[email-masked]>
Date: Thu, 14 Mar 2019 01:43:59 +0000

Hi Mirja,

Thanks for your suggestion, will add to the next revision.

Best regards,
Mach  

> Sent: Wednesday, March 13, 2019 8:04 PM
> Cc: [email-masked]; Mirja Kühlewind via Datatracker <[email-masked]>;
> [email-masked]; [email-masked]; The
> IESG <[email-masked]>; [email-masked]
> >>>> 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://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multi
> >>>> pa
> >>>> th/
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>> COMMENT:
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>> for the review)! I support adding another sentence with a pointer
> >>>> to rate-limit requirements in other docs. Thanks for proposing this
> >> "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.”
> >>
> “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
> >>>>
> >>>
> >