Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

"Alvaro Retana (aretana)" <> Sun, 04 October 2015 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F0D91B328F; Sun, 4 Oct 2015 06:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aTppqwG1IQje; Sun, 4 Oct 2015 06:55:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B12E1B3290; Sun, 4 Oct 2015 06:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9057; q=dns/txt; s=iport; t=1443966927; x=1445176527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=63KgYbhyh3mQqutj7XoXGCgQxSsxgAoRpkRqGIBM4GM=; b=ERpTQTTmA6e25rX15eK+R1WgVVW6iCSiwkiM9zsjr523m2dXjw8Gu5Jy AeP+/EfM3uSt5XeKTs20jre8bLBJoGSuAAUbd0KZB6HBC8uv3ZA2XuEX0 vpVGbR211SMqtHdG1OzoiTUQ/MemnRwMvJM5RtfZuRsTDGdv9oheeBGSH Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,633,1437436800"; d="scan'208";a="193851051"
Received: from ([]) by with ESMTP; 04 Oct 2015 13:55:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t94DtPKU029253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Oct 2015 13:55:26 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 4 Oct 2015 08:55:25 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 4 Oct 2015 08:55:25 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Sun, 4 Oct 2015 08:55:25 -0500
From: "Alvaro Retana (aretana)" <>
To: "" <>
Thread-Topic: Alvaro's AD Comments on draft-ietf-idr-ls-distribution
Thread-Index: AdD9yQO60fpcSwLyRE2qgwPvotAKewA66wGA
Date: Sun, 4 Oct 2015 13:55:24 +0000
Message-ID: <>
References: <022901d0fdc9$0ea4ce80$2bee6b80$>
In-Reply-To: <022901d0fdc9$0ea4ce80$2bee6b80$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Oct 2015 13:55:30 -0000

On 10/3/15, 6:48 AM, "Adrian Farrel" <> wrote:


Hi!  Thanks for helping move this document forward.

I¹m replying only to the points I don¹t agree with, or just have some
additional comments about.  Please take a look below.



. . .
>> Major:
>> Section 5 (IANA Considerations)
>> I didn't see this comment as part of IANA's review, but the text about
>Designated Experts
>>  should be clarified.  There is some guidance in RFC5226.
>You're right.
>I think we should add a new subsection 5.1...
>5.1  Guidance for Designated Experts
>In all cases of review by Designated Expert (DE) described here, the DE is
>expected to ascertain the existence of suitable documentation (a
>as described in RFC5226, and to verify the permanent and publically
>available of the document. The DE is also expected to check the clarity of


>purpose and use of the requested code points. Lastly, the DE must verify
>any specification produced in the IETF that requests one of these code
>has been made available for review by the IDR working group, and that any
>specification produced outside the IETF does not conflict with work that
>active or already published within the IETF.
. . .
>> I would like to have Designated Experts in place soon.  It seems to me
>having 2 of the
>> authors volunteer (primary and backup) would be ideal.  Please let me
>>know if
>you want to do it.
>I think the absence of an answer speaks for itself.


Given the potential for extensions, I¹ll be back knocking soon..

>> 6.1.2 (Installation and Initial Setup): [default] "maximum rate at which
>Link-State NLRIs will
>> be advertised/withdrawn from neighbors is set to 200 updates per
>Where did the
>> number come from?  It does look very big.  Are you assuming just
>>changes or
>startup as well?
>> One of my concerns is the interaction with other BGP stuff (like regular
>> In fact, in 6.1.5 (Impact on Network Operation) you wrote:  "Frequency
>Link-State NLRI
>> updates could interfere with regular BGP prefix distribution.  A network
>operator MAY use
>> a dedicated Route-Reflector infrastructure to distribute Link-State
>> Why not use SHOULD?  If there may be significant operational impact I
>you should be
>> more direct with the guidance.
>There are several questions folded in here.
>Firstly, understand that the maximum rate described here is the default
>rate if
>not overridden by an operator or by an implementation that knows better.
>So we
>shouldn't get too hung up on it. Although, obviously, there is a
>expectation that if an implementation uses this default value the function
>should work.
>Why 200? Not sure where that came from. I have no evidence that 200 is a
>and given that IDR has done quite a bit of implementation and interop
>anyone screaming, I assume this is OK.
> doesn't
>mention any problems. Are you aware of implementations where this is a

No, but implementation and interop (most likely in a controlled
environment) is very different than operation in the wild.  But I am sure
that you (and everyone else listed as an author) obviously knows that.

>Could BGP-LS advertisements impact on "other BGP stuff"? Well, that
>really is an
>implementation and deployment issues? Will the BGP-LS speaker doing the
>advertisements also advertise "other BGP stuff" on the same session? Is
>advertisement higher cost than the consolidation of IGP-TE information
>and the
>application of policy to determine what LS information to advertise.
>Could the
>advertisements be prioritised? This has been something of a recent thread
>on the
>IDR list and, although you are raising interesting questions, I don't
>believe we
>have any way to draw a line unless someone reports real problems that are
>caused by implementation choices, yet we are required (by the IESG) to
>defaults for configurable parameters.

Section 6 is the ³Operational Considerations² section, where I expect you
to provide operational considerations.  It sounds like you¹re saying we
need deployment (not just testing) experience so that clear guidance can
be given and that you¹re otherwise putting numbers in there just because
you have to, am I interpreting this correctly?

>Why "MAY" use a dedicated RR rather than "SHOULD"? Because there really
>appear to be any indication that this is a problem in all networks with
>all BGP
>> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
>attribute, then
>> it SHOULD use the 'Attribute Discard' action.."  Doesn't this mean that
>information may be
>> useless, completely missing, or in the best case incomplete?  Aren't we
>off just resetting
>> the session or at least requesting a route refresh?
>I don't think we are assuming corruption. So the malformed attribute
>comes as
>the result of an implementation difference or a bug at the sender.

That would still result in the receiver not having the information.  The
cause doesn¹t seem to matter in this case, the end result does.

>Requesting a
>refresh runs a significant risk of simply thrashing the advertisement
>since each
>time it is sent it will contain the same malformed attribute. This
>problem is
>considerably worsened if the session is reset because then we thrash the

Of course.

I was trying (and didn¹t do a good job) to suggest that if we had
isolation (as in carrying the BGP-LS in a separate session/RR
infrastructure), then a better job could be done at not only isolating
from failure but also at recovering information so that both application
could work better.

. . .
>> (MPLS Protocol Mask TLV)
>> OLD>  
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-
>>   IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2.
>> NEW>
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with other protocol-Ids.
>Certainly your proposal appears right: there are only four protocols
>listed in
>Table 2, but there is the question of future IDs. So we could write...
>   Generation of the MPLS Protocol Mask TLV is only valid for
>   originators which have local link insight, like for example Protocol-
>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>   TLV MUST NOT be included in NLRIs with the other Protocol-IDs
>   listed in Table 2.
>I don't object to this change, but struggle to see the value.

Why?  Potential future IDs..

I think that just listing IDs that are now in Table 2 (as in the original
text, which is the same as saying ³ Table 2²), doesn¹t cover
future IDs that don¹t have ³local link insight².  Table 2 already contains
IDs for protocols that have that insight and others that don¹t..and we (at
least I) don¹t know what other things will be put in there.  In short, I
think we should just leave it open and not list specifics as those could

Now that I revisit this point, I think that the new text should be
something like this:

   The ŒMPLS Protocol Mask¹ TLV SHOULD only be used with
   originators that have local link insight, like for example
   Protocol-IDs 'Static' or 'Direct' as per Table 2.

That way, if others come up in the future we¹re covered and not dependent
on a Table.

. . .
>> Section 8 (Security Considerations) "The principal attack a consumer
>>may apply
>is to 
>> attempt to start multiple sessions either sequentially or
>Isn't this
>> an attack that any other node can try?  Why limit the discussion only to
>I think you have to be a recognised peer for this attack to have any
>value that is specific to *this* document.

I meant that a BGP Speaker could also start multiple sessions with a
consumer, for example.

. . .
>> Curious question:  When encoding a "normal" size node using BGP-LS,
>>what is
>> resulting size of the UPDATE?
>I'll leave this as an exercise for the reader.

Thanks! :-(

I was mostly wondering if the information is anywhere close to 4k or not.
The implementation report doesn¹t say anything either. :-(