Dear authors,
Thank you for this easy-to-follow document. Please see my comments for
https://datatracker.ietf.org/doc/draft-ietf-lisp-te/. I have included line
numbers from nits to help identify where in the document my comments apply.
General comments taken from nits:
-- The document has examples using IPv4 documentation addresses according
to RFC6890 but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Jim> I would suggest that the authors consider IPv6 examples also within the
document and if so, RF3849 has a documentation prefix for this purpose.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
Jim> Authors, please fix this.
-- The document date (4 November 2024) is 141 days in the past. Is this
intentional?
Jim> A new version should be uploaded given that this document is unlikely to
make it through IESG review before it expires.
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: A later version (-20) exists of
draft-ermagan-lisp-nat-traversal-19
--------------------------------------------------------------------------------
6 P. Lahiri
7 4 November 2024
Jim> Parantap provides no affiliation or author address - is this intentional?
9 LISP Traffic Engineering
10 draft-ietf-lisp-te-20
19 combination of both.
Jim> s/combination/a combination
136 Explicit Locator Path (ELP): The ELP is an explicit list of RLOCs
137 for each RTR a packet SHOULD travel along its path toward a final
138 destination ETR (or PETR). The list MAY be a strict ordering
139 where each RLOC in the list is visited. However, the path from
140 one RTR to another is determined by the underlying routing
141 protocol and how the infrastructure assigns metrics and policies
142 for the path.
Jim> This appears to be already defined in section 3 of RFC 8060. It is fine to
keep the definition here but please put a pointer to the original RFC for
completeness.
211 encapsulates to Y, and then finally Y re-encapsualtes to ETR.
Jim> s/re-encapsualtes/re-encapsulates
239 1. The ITR will retrieve the ELP from the mapping database. If no
240 ELP is returned from the mapping system, follow typical
241 procedures from [RFC9301]. When a ELP is returned, a ELP
242 validity check MUST be performed detailed in Section 5.4.
Jim> This validity check is to avoid encoding loops as per section 5.4. Suggest
to reword “When an ELP is returned, an ELP validity check for encoding errors
MUST be performed as detailed in Section 5.4 of this document”.
442 Since an ELP-node knows the reachabiliy of the next ELP-node in a ELP
Jim> s/reachabiliy/reachability
454 An ELP can be used to deploy services at each reencapsulation point
Jim> s/reencapsulation/re-encapsulation
463 which case, the scurbber delivers packets back to the RTR which
Jim> s/scurbber/scrubber
551 Figure 3: An entry for host 'S-EID' sending to application group 'G'
Jim> Is Figure 3 really a figure or just text? If not then remove Figure 3.
580 Figure 4: Using ELPs for multicast flows
Jim> Is Figure 4 really a figure or just text?
609 11. Security Considerations
611 When an RTR receives a LISP encapsulated packet, it can look at the
612 outer source address to verify that RLOC is the one listed as the
613 previous hop in the ELP list. If the outer source RLOC address
614 appears before the RLOC which matches the outer destination RLOC
615 address, the decapsulating RTR (or ETR if last hop), SHOULD choose to
616 drop the packet.
Jim> SHOULD or MUST? What happens if it does not drop the packet?
Thanks!
Jim
_______________________________________________
lisp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
