Yoshi -
Thanx for the review.
Replies inline.
> -----Original Message-----
> From: Yoshifumi Nishida <nishida@xxxxxxxxxx>
> Sent: Thursday, December 13, 2018 1:05 AM
> To: tsv-art@xxxxxxxx
> Cc: idr@xxxxxxxx;
ietf@xxxxxxxx;
draft-ietf-idr-te-pm-bgp.all@xxxxxxxx
> Subject: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15
>
> Reviewer: Yoshifumi Nishida
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review
> team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@xxxxxxxx if you reply to or forward this review.
>
> Summary: Ready with Nits
>
> 1: The TLV formats in the draft look identical with RFC7471 except the value in
> Type field.
> it would be better to clarify this points so that the readers who are
> familiar with RFC7471 can interpret them easily. I am also wondering if
> the format figures of TLV are necessary when the same figures are already
> presented in RFC7471.
>
[Les:] The draft says:
Section 2
" TLV formats follow the rules defined in [RFC7752]."
Then in each subsequent sub-section 2.x both RFC 7471 and draft-ietf-lsr-isis-rfc7810bis are explicitly referenced.
The TLV formats need to be presented here since these are the BGP-LS encodings, which are similar to but NOT identical to the IGP specific encodings (for example IS-IS encoding uses an 8-bit type/length).
Right. But, but in case of OSPF, I think the format will be identical except the type field value.
I just thought if you add one sentence to clarify the formats happen to be the same as 7471, it could be a small benefit for OSPF users.
But, this is not a strong opinion.
[Les:] The format follows RFC7752. It just happens in this case the format for these TLVs matches OSPF – that isn’t always the case. As a practical matter
I don’t think it helps implementers to point out when BGP-LS TLVs are identical to protocol X or protocol Y.
> 2: There is no guidance for default values such as measurement interval in
> the
> draft. If these values should also be inherited from other draft, it should be
> stated.
>
[Les:] This is not within the purview of this draft. All this draft is doing is defining the encodings for the BGP-LS advertisements which are essentially copies of what the IGPs are advertising.
Does it mean when an IGP advertises these metrics at 10 sec interval, the BGP-LS will be advertised at the same interval?
[Les:] The IGP RFCs provide significant detail on the importance of controlling the rate of change of advertisements.
Given that, yes – I would expect that updates are provided to BGP whenever the IGP advertisements change.
BGP implementations typically have their own knobs to control the frequency of BGP updates – but given the filtering done at the source I would hope implementations
have no need for additional dampening in BGP itself – but that is an implementation choice.
Les
