[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    [mpls] AD review of draft-ietf-mpls-lsp-ping-ttl-tlv
From:       "Adrian Farrel" <adrian () olddog ! co ! uk>
Date:       2013-11-29 23:46:56
Message-ID: 0a1801ceed5d$4a03d670$de0b8350$ () olddog ! co ! uk
[Download RAW message or body]

Hi,

Thanks for this simple little I-D.

Just a few bits and pieces to resolve before we move forward.

Cheers,
Adrian

===

Obviously, the idnits issues need to be sorted out. 

---

Section 1
s/is being proposed/is defined/
s/this document this TLV/this document.  This TLV/

---

Surely this mechanism only works if the echo reply is sent down the 
co-routed return path LSP. All other mechanisms for returning the echo
reply make this mechanisms worse than silly! While you do say...
   The scope of this TTL TLV is currently limited to MS-PW or
   Bidirectional co-routed MPLS LSPs.
...I don't believe that actually applies the necessary constraint.
Shouldn't this somehow be tied to require the use of the return path
LSP, either by making the new TLV only valid when the return path is
specified to be that LSP, or by saying that the presence of the TLV
implies the use of the return path LSP. In either case, you have to 
describe what happens if the return path is specified using some other
mechanism and yet the TLV is present.

---

I think your security section should reference the security section of
4379. But there we find...

   To protect against unauthorized sources using MPLS echo request
   messages to obtain network information, it is RECOMMENDED that
   implementations provide a means of checking the source addresses of
   MPLS echo request messages against an access list before accepting
   the message.

You will need to explain how that recommendation is met since you have
opened the box from just the ingress to any node along the path.

Furthermore, you now have a field in the Echo Request that we can have
fun over-writing. What would happen if I modified the TTL TLV value 
field in transit?

---

The following paragraph in the IANA section needs work

   Time To Live TLV (See Section 3). The value should be assigned from
   the range (32768-49161) of optional TLV's which SHOULD be ignored if
   an implementation does not support or understand them as defined in
   section 3 of RFC 4379 [RFC4379].

1. I think you mean that it must be assigned from 32768-49161
2. You can truncate the text at "...optional TLV's."
3. s/TLV's/TLVs/

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]