Subject: Re: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt

From: "t.petch" <[email-masked]>
Date: Fri, 4 Nov 2011 14:38:27 +0100

Some possible tweaks.

s3.2
 "A bit MUST NOT be set .. "
suggest
 "The A bit MUST NOT be set ..."
to make it clear that this is a reference to A bit and not to a bit.

s3.3.1 last paragraph
would be good to recommend (SHOULD) a error reply and return code here (2?)

s3.3.2 last paragraph
Flag field is defined in 3.2 not 3.3

s5 I would like more detail.  I understand the attack but do not know how to
prevent it.  Active attackers forging source addresses are a major problem with
SMTP; how damaging, and how hard to prevent, will be forged reply addresses,
along with whatever sub-TLV the attacker sees devilment in?  If active attackers
are excluded by other means, then that would be worth a mention.

I never know when you need a reference to
Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations
Section in RFCs", IETF RFC 5226, May 2008

RP; I know what RP means; Rendezvous Point (multicast), or Route
Processor(routing) or Relying Party(sidr/bgpsec).  I would prefer to see it
spelt out most of the time, and only abbreviated when it is part of something
else, but that may be my unusual context.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 31, 2011 3:40 AM
Subject: [mpls] I-D Action:
draft-ietf-mpls-return-path-specified-lsp-ping-04.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Multiprotocol Label Switching
Working Group of the IETF.
>
> Title : Return Path Specified LSP Ping
> Author(s) : Mach(Guoyi) Chen
> Wei Cao
> So Ning
> Frederic Jounay
> Simon Delord
> Filename: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt
> Pages : 18
> Date: 2011-10-30
>
>  This document defines extensions to the failure-detection protocol
>  for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
>  known as &quot;LSP Ping&quot; that allow selection of the LSP to use for the
>  echo reply return path.Enforcing a specific return path can be used
>  to verify bidirectional connectivity and also increase LSP ping
>  robustness.It may also be used by Bidirectional Forwarding
>  Detection (BFD) for MPLS bootstrap signaling thereby making BFD for
>  MPLS more robust.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pi
ng-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
>
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pin
g-04.txt
> TF.

---

From: Mach Chen <[email-masked]>
Date: Mon, 07 Nov 2011 03:27:59 +0000

Hi Tom,

Many thanks for your valuable comments!

Please see my reply inline...

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Friday, November 04, 2011 9:38 PM
> To: Mach Chen
> Cc: [email-masked]
> Subject: Re: [mpls] I-D Action:

Yes, will fix it.

> Flag field is defined in 3.2 not 3.3

Good catch, will fix it.

> are excluded by other means, then that would be worth a mention.

OK, we will carefully consider this and add more text in the next version.

> Section in RFCs", IETF RFC 5226, May 2008

OK, will add the reference in the next revision.

> else, but that may be my unusual context.

Reasonable request, I will re-examine the document and try to make it clearer.

Many thanks,
Mach