RE: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

["Susan Hares" <shares@xxxxxxxx>]

Les and Yoshi:

 

You both raised two sides of the issue regarding the BGP-LS TLVs when these TLVs align with IGP TLVs.

 

Side 1: It is helpful to note that the TLVs are the same

Side 2: It is confusing to have this information in individual drafts.    

 

This is not a single draft issue but a concern regarding several drafts in the BGP-LS series from IDR.

 

Yoshi -  Would it help the clarity of the BGP-LS series to have an explanatory draft that indicates the places to find the alignment?  Or should we suggest a note to IANA registration to provide clarity.  

 

Thank you for raising both sides of this issue.   Your IDR chairs and AD have been discussing how to make this easier to understand for implementers and those who deploy the BGP-LS code.  

 

Susan Hares

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@xxxxxxxxx]
Sent: Thursday, December 13, 2018 4:57 PM
To: Yoshifumi Nishida
Cc: nishida@xxxxxxxxxx; tsv-art@xxxxxxxx; idr@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-idr-te-pm-bgp.all@xxxxxxxx
Subject: RE: Tsvart last call review of draft-ietf-idr-te-pm-bgp-15

 

Yoshi –

 

Inline.

 

From: Yoshifumi Nishida <nishida@xxxxxxxxxxxxxx>
Sent: Thursday, December 13, 2018 11:16 AM
To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
Cc: nishida@xxxxxxxxxx; tsv-art@xxxxxxxx; idr@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-idr-te-pm-bgp.all@xxxxxxxx
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) <ginsberg@xxxxxxxxx> wrote:

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

 

Thanks,

--

Yoshi