Hi Ketan, Thank you for flagging this.
In the current *-24* draft, the clarification and references to existing LISP behavior (including multicast) are present earlier in the document, in *Section 7*. During the edits between -22 and -24 (notably the addition of new sections), the section numbering shifted, so what was previously “Multicast section 10" is no longer numbered the same way. That text explicitly relies on existing LISP specifications (including RFC 6831) and clarifies that this document does not redefine LISP multicast behavior is in section 7. So substantively, the point you raised is addressed, just not under the section number you originally cited. If you think it would improve clarity, we can certainly add an explicit cross-reference to RFC 6831 in a more visible way in section 8 as well. Thanks again for the careful review. Best regards, Padma On Thu, Jan 22, 2026 at 5:40 AM Ketan Talaulikar <[email protected]> wrote: > Hi Padma, > > Appreciate your help in working on this document and posting the updates. > > My ballot was non-blocking comments. I will let the other ADs drive their > DISCUSSions. > > There was just one comment that I did not find covered (or I possibly > missed the response): > > "Regarding Section 10 Multicast, I believe some references to LISP > multicast documents are necessary. Perhaps RFC6831 can be referenced again > here. I am not sure if any other is needed." > > Thanks, > Ketan > > > On Sat, Jan 10, 2026 at 7:12 AM Padma Pillay-Esnault <[email protected]> > wrote: > >> >> Hello Everyone >> >> Thank you again for your review and comments. >> The version -24 addresses all comments on the LC. >> >> Thanks >> Padma on behalf of all authors >> >> For your convenience i have the tracking table for these changes below >> >> *ID* >> >> *Reviewer* >> >> *Type* >> >> *Comment / Issue* >> >> *Where Addressed* >> >> *First Fixed In* >> >> MED-1 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Doc readiness / LC follow-ups >> >> Manageability & Ops >> >> *-24* >> >> MED-2 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Experimental status justification >> >> Introduction >> >> *-22* >> >> MED-3 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Deployment incentives missing >> >> Deployment Incentives >> >> *-24* >> >> MED-4 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Underlay control overstated >> >> Deployment Incentives >> >> *-24* >> >> MED-5 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Must not replace underlay protection >> >> Deployment Incentives >> >> *-24* >> >> MED-6 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Failure example viability >> >> Deployment Incentives >> >> *-24* >> >> MED-7 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Service chaining rationale >> >> Deployment Incentives / Service Chaining >> >> *-24* >> >> MED-8 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Existing service chaining not addressed >> >> Service Chaining >> >> *-24* >> >> MED-9 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Policy reasons insufficient >> >> Deployment Incentives >> >> *-24* >> >> MED-10 >> >> Mohamed Boucadair >> >> DISCUSS >> >> Interception risk acknowledgment >> >> Deployment Incentives / Security >> >> *-24* >> >> DHRUV-1 >> >> Dhruv Dhody >> >> OPSDIR >> >> No manageability section >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-2 >> >> Dhruv Dhody >> >> OPSDIR >> >> How ELPs are set >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-3 >> >> Dhruv Dhody >> >> OPSDIR >> >> How ELPs are monitored >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-4 >> >> Dhruv Dhody >> >> OPSDIR >> >> Packet drops (MUSTs) >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-5 >> >> Dhruv Dhody >> >> OPSDIR >> >> Logging expectations >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-6 >> >> Dhruv Dhody >> >> OPSDIR >> >> Failure signaling >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-7 >> >> Dhruv Dhody >> >> OPSDIR >> >> Troubleshooting guidance >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-8 >> >> Dhruv Dhody >> >> OPSDIR >> >> Verify ELP compliance >> >> Manageability / ELP Probing >> >> *-23* >> >> DHRUV-9 >> >> Dhruv Dhody >> >> OPSDIR >> >> YANG requirements >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-10 >> >> Dhruv Dhody >> >> OPSDIR >> >> Multiple mapping systems >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-11 >> >> Dhruv Dhody >> >> OPSDIR >> >> Bad ELP impact >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-12 >> >> Dhruv Dhody >> >> OPSDIR >> >> ELP validation responsibility >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-13 >> >> Dhruv Dhody >> >> OPSDIR >> >> Experimental vs Standards >> >> Introduction >> >> *-22* >> >> DHRUV-14 >> >> Dhruv Dhody >> >> OPSDIR >> >> “No protocol change” claim >> >> Abstract / Intro >> >> *-22* >> >> DHRUV-15 >> >> Dhruv Dhody >> >> OPSDIR >> >> “New RLOC encoding” wording >> >> Abstract >> >> *-22* >> >> DHRUV-16 >> >> Dhruv Dhody >> >> OPSDIR >> >> Terminology clarity >> >> Definitions >> >> *-22* >> >> DHRUV-17 >> >> Dhruv Dhody >> >> OPSDIR >> >> RTR scalability >> >> Manageability & Ops >> >> *-23* >> >> DHRUV-18 >> >> Dhruv Dhody >> >> OPSDIR >> >> Overall ops readiness >> >> Sections 1, 6, 10, 11 >> >> *-23* >> >> GORRY-1 >> >> Gorry Fairhurst >> >> DISCUSS >> >> ELP probing underspecified >> >> ELP Probing >> >> *-22* >> >> GORRY-2 >> >> Gorry Fairhurst >> >> DISCUSS >> >> ELP path validation >> >> ELP Probing >> >> *-22* >> >> GORRY-3 >> >> Gorry Fairhurst >> >> DISCUSS >> >> Monitoring expectations >> >> ELP Probing >> >> *-22* >> >> KETAN-1 >> >> Ketan Talaulikar >> >> COMMENT >> >> Probing integral >> >> ELP Probing >> >> *-22* >> >> KETAN-2 >> >> Ketan Talaulikar >> >> COMMENT >> >> Probing reference status >> >> ELP Probing >> >> *-22* >> >> KETAN-3 >> >> Ketan Talaulikar >> >> COMMENT >> >> Service chaining ambiguity >> >> Service Chaining / Deployment Incentives >> >> *-24* >> >> KETAN-4 >> >> Ketan Talaulikar >> >> COMMENT >> >> Which traffic to services >> >> Service Chaining >> >> *-24* >> >> KETAN-5 >> >> Ketan Talaulikar >> >> COMMENT >> >> Experimental track concern >> >> Introduction >> >> *-22* >> >> KETAN-6 >> >> Ketan Talaulikar >> >> COMMENT >> >> LCAF maturity >> >> Introduction >> >> *-22* >> >> KETAN-7 >> >> Ketan Talaulikar >> >> COMMENT >> >> Multicast refs missing >> >> Multicast Considerations >> >> *-22* >> >> KETAN-8 >> >> Ketan Talaulikar >> >> COMMENT >> >> Multicast behavior >> >> Multicast Considerations >> >> *-22* >> >> GENART-1 >> >> Peter Yee >> >> GEN-ART >> >> Abstract implies new encoding >> >> Abstract >> >> *-22* >> >> GENART-2 >> >> Peter Yee >> >> GEN-ART >> >> Intro ordering >> >> Introduction >> >> *-22* >> >> GENART-3 >> >> Peter Yee >> >> GEN-ART >> >> Acronyms expanded >> >> Intro / Definitions >> >> *-22* >> >> GENART-4 >> >> Peter Yee >> >> GEN-ART >> >> Path stretch defined >> >> Introduction >> >> *-22* >> >> GENART-5 >> >> Peter Yee >> >> GEN-ART >> >> ELP definition consistency >> >> Definitions / Sec 5 >> >> *-22* >> >> GENART-6 >> >> Peter Yee >> >> GEN-ART >> >> SHOULD/MAY usage >> >> Definitions >> >> *-22* >> >> GENART-7 >> >> Peter Yee >> >> GEN-ART >> >> ELP retrieval failure >> >> Section 5 >> >> *-22* >> >> GENART-8 >> >> Peter Yee >> >> GEN-ART >> >> CoS terminology >> >> Section 4.3 >> >> *-22* >> >> GENART-9 >> >> Peter Yee >> >> GEN-ART >> >> Loop wording >> >> Section 4.4 >> >> *-22* >> >> GENART-10 >> >> Peter Yee >> >> GEN-ART >> >> Expired reference >> >> References >> >> *-22* >> >> ERIC-1 >> >> Eric Vyncke >> >> COMMENT >> >> Security over-claim >> >> Security Considerations >> >> *-23* >> >> ERIC-2 >> >> Eric Vyncke >> >> COMMENT >> >> Interception risk clarity >> >> Security Considerations >> >> *-23* >> >> ADRIAN-1 >> >> Adrian Farrel >> >> COMMENT >> >> TE definition alignment >> >> Introduction >> >> *-22* >> >> ADRIAN-2 >> >> Adrian Farrel >> >> COMMENT >> >> RFC 9522 reference >> >> Introduction >> >> *-22* >> >> CHEN-1 >> >> Meiling Chen >> >> COMMENT >> >> Missing architecture figure >> >> Architecture / Figures >> >> *-22* >> >> CHEN-2 >> >> Meiling Chen >> >> COMMENT >> >> Protocol scope unclear >> >> Introduction / Architecture >> >> *-22* >> >> CHEN-3 >> >> Meiling Chen >> >> COMMENT >> >> Security risks analysis >> >> Security Considerations >> >> *-24* >> >> IANA-1 >> >> IANA (David Dong) >> >> IANA >> >> Registry actions >> >> IANA Considerations >> >> *-22* >> >> IANA-2 >> >> IANA (David Dong) >> >> IANA >> >> Retain IANA section >> >> IANA Considerations >> >> *-22* >> >> ---------- Forwarded message --------- >> From: <[email protected]> >> Date: Fri, Jan 9, 2026 at 4:52 PM >> Subject: [lisp] I-D Action: draft-ietf-lisp-te-24.txt >> To: <[email protected]> >> Cc: <[email protected]> >> >> >> Internet-Draft draft-ietf-lisp-te-24.txt is now available. It is a work >> item >> of the Locator/ID Separation Protocol (LISP) WG of the IETF. >> >> Title: LISP Traffic Engineering >> Authors: Dino Farinacci >> Michael Kowal >> Parantap Lahiri >> Padma Pillay-Esnault >> Name: draft-ietf-lisp-te-24.txt >> Pages: 25 >> Dates: 2026-01-09 >> >> Abstract: >> >> This document describes how Locator/Identifier Separation Protocol >> (LISP) re-encapsulating tunnels can be used for Traffic Engineering >> purposes. The mechanisms described in this document require no LISP >> protocol changes and specify how existing Routing Locator encodings >> are used to construct Explicit Locator Paths for traffic engineering >> purposes. The Traffic Engineering features provided by these LISP >> mechanisms can span intra-domain, inter-domain, or a combination of >> both. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-te/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-lisp-te-24.html >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-te-24 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> lisp mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
