Re: [Tsv-art] Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

["Les Ginsberg (ginsberg)" <[e-mail]>]

Yoshi –

Inline.

From: Yoshifumi Nishida <[e-mail]>
Sent: Thursday, December 13, 2018 11:16 AM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

Hi Les,
On Thu, Dec 13, 2018 at 10:13 AM Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:
Yoshi -

Thanx for the review.
Replies inline.

> -----Original Message-----
> From: Yoshifumi Nishida <[e-mail]<mailto:[e-mail]>>
> Sent: Thursday, December 13, 2018 1:05 AM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]> 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

Thanks,
--
Yoshi