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

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

Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D91B328F; Sun, 4 Oct 2015 06:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTppqwG1IQje; Sun, 4 Oct 2015 06:55:27 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B12E1B3290; Sun, 4 Oct 2015 06:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0DwAQDdLhFW/4sNJK1egydUbga+AwENgVohhXkCgRc4FAEBAQEBAQF/C4QlAQEDAWsOEAIBCEYyJQEBBA4FiCYIDcdtAQEBAQEBAQECAQEBAQEBAQEWBIZzAYN3gQaEIQgMJTMHhCwFkkmDMwGNFoFWhDiKcIIfhFeDbx8BAUKCER2BVHEBiz9CgQYBAQE
X-IronPort-AV: E=Sophos;i="5.17,633,1437436800"; d="scan'208";a="193851051"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 04 Oct 2015 13:55:26 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (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 xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 4 Oct 2015 08:55:25 -0500
Received: from xhc-aln-x14.cisco.com (173.36.12.88) by xch-rcd-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 4 Oct 2015 08:55:25 -0500
Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0248.002; Sun, 4 Oct 2015 08:55:25 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
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: <D2369A00.D559D%aretana@cisco.com>
References: <022901d0fdc9$0ea4ce80$2bee6b80$@olddog.co.uk>
In-Reply-To: <022901d0fdc9$0ea4ce80$2bee6b80$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.13]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C68C0F98F49BDB49B378629929456D62@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/0nZsFWXre8Q7Q940Sw-Q2w0sfyA>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-ls-distribution@ietf.org" <draft-ietf-idr-ls-distribution@ietf.org>
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2015 13:55:30 -0000

On 10/3/15, 6:48 AM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

Adrian:

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.

Thanks!

Alvaro.

. . .
>
>> Major:
>>
>> Section 5 (IANA Considerations)
>> I didn't see this comment as part of IANA's review, but the text about
>>the
>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
>specification)
>as described in RFC5226, and to verify the permanent and publically
>readily
>available of the document. The DE is also expected to check the clarity of

s/available/availability

>purpose and use of the requested code points. Lastly, the DE must verify
>that
>any specification produced in the IETF that requests one of these code
>points
>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
>is
>active or already published within the IETF.
>
. . .
>
>> I would like to have Designated Experts in place soon.  It seems to me
>>that
>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
>>second."
>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
>routing!).  
>> In fact, in 6.1.5 (Impact on Network Operation) you wrote:  "Frequency
>>of
>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
>>NLRIs."  
>> Why not use SHOULD?  If there may be significant operational impact I
>>think
>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
>reasonable
>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
>problem
>and given that IDR has done quite a bit of implementation and interop
>without
>anyone screaming, I assume this is OK.
>https://www.ietf.org/id/draft-ietf-idr-ls-distribution-impl-04.txt doesn't
>mention any problems. Are you aware of implementations where this is a
>problem?

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
>the
>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
>not
>caused by implementation choices, yet we are required (by the IESG) to
>supply
>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
>doesn't
>appear to be any indication that this is a problem in all networks with
>all BGP
>implementations. 
>
>> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
>>malformed
>attribute, then
>> it SHOULD use the 'Attribute Discard' action.."  Doesn't this mean that
>>the
>information may be
>> useless, completely missing, or in the best case incomplete?  Aren't we
>>better
>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
>whole
>session.

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.


. . .
>
>
>> 3.3.2.2 (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.
>
>Why?
>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 ³other..in 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
change.

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
>>simultaneously."
>Isn't this
>> an attack that any other node can try?  Why limit the discussion only to
>consumers?
>
>I think you have to be a recognised peer for this attack to have any
>significant
>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
>the
>> 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. :-(