Early Review of draft-ietf-idr-bgp-ls-segment-routing-ext-06
review-ietf-idr-bgp-ls-segment-routing-ext-06-opsdir-early-jaeggli-2018-05-08-00
Request | Review of | draft-ietf-idr-bgp-ls-segment-routing-ext |
---|---|---|
Requested revision | No specific revision (document currently at 18) | |
Type | Early Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2018-05-18 | |
Requested | 2018-05-04 | |
Requested by | Susan Hares | |
Authors | Stefano Previdi , Ketan Talaulikar , Clarence Filsfils , Hannes Gredler , Mach Chen | |
I-D last updated | 2018-05-08 | |
Completed reviews |
Opsdir Early review of -06
by Joel Jaeggli
(diff)
Rtgdir Early review of -06 by Victoria Pritchard (diff) Genart Last Call review of -14 by Roni Even (diff) Secdir Last Call review of -14 by Paul Wouters (diff) |
|
Assignment | Reviewer | Joel Jaeggli |
State | Completed | |
Request | Early review on draft-ietf-idr-bgp-ls-segment-routing-ext by Ops Directorate Assigned | |
Reviewed revision | 06 (document currently at 18) | |
Result | Has nits | |
Completed | 2018-05-08 |
review-ietf-idr-bgp-ls-segment-routing-ext-06-opsdir-early-jaeggli-2018-05-08-00
I have performed a requested early review on the behalf of the operations directorate of the current draft-ietf-idr-bgp-ls-segment-routing-ext-06. Generally I think this document is good, I won't say ready, as this review is intended as an early review not a final one. Some nits 1- introduction This way, all BGP speakers (specifically the route-reflectors) obtain Link-State information from all IGP areas (and from other ASes from EBGP peers). * BGP speakers are agnostic about the source of the information beyond that it was exported with certain properties from the rib of it’s neighbor. 2 - An external component (e.g., a controller) then can collect SR information in the "northbound" direction across IGP areas or ASes and construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end-to-end forwarding. * Unqualified use of the term northbound I find generally problematic, particularly in the case of a route reflector. Previously RFC 7752 manged to use the term in the title and then never again within the text. 3- 2.3.3. Source Router Identifier (Source Router-ID) TLV The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the originator of the Prefix. For IS-IS protocol this is as defined in [RFC7794]. The Source Router-ID TLV may be used to carry the OSPF Router-ID of the prefix originator. The Source Router-ID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // IPv4/IPv6 Address (Router-ID) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, see Section 4. Length: 4 or 16. IPv4/IPv6 Address: 4 octet IPv4 address or 16 octet IPv6 address. The semantic of the Source Router-ID TLV is defined in [RFC7794]. * While RFC7794 Router-IDs are in fact IP addresses. OSPF Router-IDs are not even if they happen to look like them, this is particularly germain with ospfv3 but it’s worth making the distinction. 4 - 5.1.1. Operations Existing BGP and BGP-LS operational procedures apply. No additional operation procedures are defined in this document. * An informative or normative reference (probably to 7752 especially fault mangement) is probably required.