Thank you Peter, this addresses my comments.
Yaron
On 05/11/2018 10:12, Peter Psenak wrote:
Hi Yaron,
thanks for your comments, please see inline:
On 04/11/18 16:38 , Yaron Sheffer wrote:
Reviewer: Yaron Sheffer
Review result: Has Nits
Summary: document has non-security related nits.
Details
* The definition of "segment" is different here from the one used in the
architecture RFC. The RFC is more abstract, quoting: A node steers a
packet
through an ordered list of instructions, called "segments". Whereas
here a
segment is simply a sub-path. This is confusing to a non-expert, and
perhaps
indicates a change in the group's thinking.
the definition in this draft relates to segment as used by IGPs, in
which case a segment represents the sub-path. There are other segments
outside of IGPs which can represent other things, but they are not
covered by this draft.
* SID/Label Sub-TLV: is it Mandatory? If so, please point it out.
SID/Label Sub-TLV is not advertised on its own. It is advertised as a
sub-TLV of the:
3.2. SID/Label Range TLV
3.3. SR Local Block TLV
Both of these section specify that SID/Label Sub-TLV MUST be included.
* "The SR-Algorithm TLV is optional" - I find this sentence confusing.
Maybe
replace by "The SR-Algorithm TLV is mandatory for routers that implement
segment routing"?
the text says:
"If the SR-Algorithm TLV
is not advertised by the node, such node is considered as not being
segment routing capable."
Isn't that sufficient?
* The reference under "IGP Algorithm Type" registry should be to the IANA
registry itself, not to the I-D that defines it. (In particular since
the IANA
registry has already been established,
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types).
I got another comment from Opsdir last call review to include the I-D
that defined it. I Added them both, hopefully that satisfy everybody.
* OSPFv3 Extended Prefix Range TLV Flags octet: add the usual
incantation about
reserved bits.
Done.
* In general I agree with the reasoning in the Security
Considerations. I would
like to raise the question if, in addition to mis-routing, this adds a
threat
of massive denial-of-service on MPLS endpoints, e.g. by allowing an
attacker
who has OSPF access to introduce routing loops. (This may be
completely bogus,
I am far from expert with either of these protocols).
above is addressed by usage of the usage of the OSPF authentication as
described in the security section.
thanks,
Peter
.
