Early Review of draft-ietf-idr-segment-routing-te-policy-18
review-ietf-idr-segment-routing-te-policy-18-intdir-early-haberman-2022-07-08-00
Request | Review of | draft-ietf-idr-segment-routing-te-policy |
---|---|---|
Requested revision | No specific revision (document currently at 26) | |
Type | Early Review | |
Team | Internet Area Directorate (intdir) | |
Deadline | 2022-07-31 | |
Requested | 2022-06-21 | |
Requested by | Susan Hares | |
Authors | Stefano Previdi , Clarence Filsfils , Ketan Talaulikar , Paul Mattes , Dhanendra Jain | |
I-D last updated | 2022-07-08 | |
Completed reviews |
Secdir Early review of -18
by Vincent Roca
(diff)
Intdir Early review of -18 by Brian Haberman (diff) Rtgdir Early review of -18 by Mohamed Boucadair (diff) |
|
Assignment | Reviewer | Brian Haberman |
State | Completed | |
Request | Early review on draft-ietf-idr-segment-routing-te-policy by Internet Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/int-dir/riasU416d8MDLRH_nEa4tKpgFNk | |
Reviewed revision | 18 (document currently at 26) | |
Result | Ready w/issues | |
Completed | 2022-07-08 |
review-ietf-idr-segment-routing-te-policy-18-intdir-early-haberman-2022-07-08-00
1. Section 2.1 - The definition of the NLRI lacks sufficient detail on what constitutes a malformed NLRI (e.g., a multicast address in the Endpoint field) and how those errors should be handled. Are all the error conditions described in Section 5? If so, a forward reference to Section 5 would be useful. 2. Section 2.1 - The paragraph describing the next-hop network address field seems incomplete. Specifically, how does a node handle the length = 32 case? That does not appear to be described in Section 3 of RFC 4760. What purpose does this encoding serve? Do the addresses need to be validated in some form? Does "global IPv6 address" include ULAs in this context? Does this encoding support the Type G & J segment types? 3. In several places, the document mentions this information potentially transiting multiple ASes. What BGP policies are needed to ensure that this info doesn't propagate globally? Waiting until the Security Considerations section for such discussion was unsatisfying as a reader. Perhaps a short example topology up front to set the stage?