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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux