Hi Authors,
Thank you for your work and publishing this new version.
I revisited our earlier discussions about pETR forwarding and Map-Cache
behavior and saw that Section 7 was updated. It now covers more-specific
EID-block entries, hole-prefix entries, and default Map-Cache entries,
which addresses my earlier concerns about forwarding unnecessary traffic
through pETRs.
Below are my comments and suggested updates to improve readability for your
consideration.
Thanks
Padma
1. Section 4 — PubSub subscription
Original text:
N-bit *MAY *be set as per [RFC9437].
PPE: PubSub is optional, but once an ITR requests a subscription, the
procedures in RFC 9437 are mandatory. The current MAY could be interpreted
as making the N-bit optional even for a subscription request. Please add
some clarifying text to remove ambiguity.
2. Section 5 — Map-Notify behavior
Original text:
When pETR registers or updates the pETR registration with the mapping
system, mapping system sends Map-Notify.
PPE: Could you clarify which Map-Notify is being referred to here? RFC 9301
uses Map-Notify for registration-related notifications, including
acknowledgments when requested, whereas RFC 9437 uses Map-Notify to notify
subscribers of mapping updates. Is this sentence referring to the
registration notification, the PubSub notification, or both?
Distinguishing these two procedures would remove the ambiguity.
3. Section 5 — PubSub N-bit
Original text:
With lisp-pubsub [RFC9437], N-bit* SHOULD *be set in the Map-Request from
ITR.
Proposed text:
When an ITR requests a subscription using LISP PubSub [RFC9437], it MUST
set the N-bit and follow the remaining subscription procedures in RFC 9437.
PPE: This suggestion is related to Comment 1 regarding the ambiguity
between optional use of PubSub and the requirements for establishing a
subscription.
4. Section 6 — Map-Reply versus Negative Map-Reply
Original text:
This Map-Reply has the following content (as defined per regular map-reply
and *negative-*map-reply in [RFC9301]):
An EID-Prefix calculated as non-LISP "hole" per the procedures in
[RFC9301] for *negative *map-reply.
RLOC count MUST be non-zero.
Proposed text:
This message is formatted as a regular Map-Reply [RFC9301] with the
following content:
An EID-Prefix calculated using the non-LISP-hole prefix-calculation
procedures in [RFC9301].
RLOC count MUST be non-zero.
PPE A Negative Map-Reply under RFC 9301 has an empty Locator-Set. Since the
draft requires a nonzero RLOC count, this is a regular Map-Reply carrying
pETR locators, while using the prefix-calculation procedure for a non-LISP
hole.
5. Section 7 — Non-LISP holes versus unregistered EIDs
Original text:
On receiving pETR Map-Notify/Map-Reply from the mapping system, ITR MAY
install/update map-cache and encapsulate the packets to pETR RLOCs as per
[RFC9300] for the destinations not known to the mapping system as EIDs or
known EIDs not registered to the mapping system.
PPE: Section 7 describes using more-specific EID-block entries, but what
happens when a known EID has no active registration?
Do non-LISP holes and temporarily unregistered EID-Prefixes require the
same forwarding treatment? Should the ITR fall back to a pETR mapping or
follow RFC 9301's negative-response behavior, given that the pETR may not
have a route to the unregistered EID?
Is this determined by local policy?
6. Section 7 — Distinguish Name mapping and IP Map-Cache entries
Original text:
On receiving pETR Map-Notify/Map-Reply, ITR MAY install/update following
map-cache entries with pETR RLOCs,
“hole” prefix [RFC9301] map-cache entry to encapsulate the packets to
pETR RLOCs
default map-cache entry to encapsulate the packets to pETR RLOCs.
PPE: RFC 9735 describes DN-based pETR discovery, but the association
between the DN mapping and the IP Map-Cache entries is unclear. Could you
clarify whether this association is locally configured and how changes to
the pETR RLOC set are reflected in the corresponding IP Map-Cache entries?
This would help remove ambiguity on Map-Cache installation and updates.
7. Section 9 — Security considerations
Original text:
There are no additional security considerations except what already
discussed in [RFC9301].
PPE: This section seems insufficient. A compromised or unauthorized pETR
mapping update could redirect traffic for broad prefixes, including a
default route. IMHO, the draft should address this risk and reference the
authentication, integrity, and replay-protection requirements of RFC 9437
when PubSub is used?
8. Section 11 — References
Please update the references to their latest published versions.
_______________________________________________
lisp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
