Hi Joel,
Many thanks for your review and please find responses inline below. I will update the draft with the same based on your feedback.
Thanks,
Ketan
-----Original Message-----
From: Joel Jaeggli <joelja@xxxxxxxxx>
Sent: 09 May 2018 12:16
To: ops-dir@xxxxxxxx
Cc: idr@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-idr-bgp-ls-segment-routing-ext.all@xxxxxxxx
Subject: Opsdir early review of draft-ietf-idr-bgp-ls-segment-routing-ext-06
Reviewer: Joel Jaeggli
Review result: Has Nits
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.
[KT] I agree this is generally true in case of BGP. However, in this specific case of BGP-LS, the Node, Link and Prefix NLRIs actually contain the identifiers/descriptors which include the source of the information - as in the specific IGP node originating it. So would you agree that in this specific BGP-LS case the statement is valid?
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.
[KT] Sure. I would remove the "northbound" term.
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.
[KT] Agree. I would say "The semantic of the Source Router-ID TLV for ISIS is defined in [RFC7794]. For OSPF, the TLV carries the OSPF Router-ID of the originator of the prefix."
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.
[KT] Agree and I would specifically put the normative reference to RFC7752.
