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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 04 October 2015 18:09 UTC

Return-Path: <adrian@olddog.co.uk>
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 D9FA51B343B; Sun, 4 Oct 2015 11:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 ij9_w82K8OM5; Sun, 4 Oct 2015 11:09:01 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCE11B3416; Sun, 4 Oct 2015 11:09:00 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t94I8uj4024107; Sun, 4 Oct 2015 19:08:56 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t94I8seI024086 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2015 19:08:55 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Alvaro Retana \(aretana\)'" <aretana@cisco.com>
References: <022901d0fdc9$0ea4ce80$2bee6b80$@olddog.co.uk> <D2369A00.D559D%aretana@cisco.com>
In-Reply-To: <D2369A00.D559D%aretana@cisco.com>
Date: Sun, 4 Oct 2015 19:08:54 +0100
Message-ID: <02b201d0fecf$bc422040$34c660c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKMJJdt6aER1MTZdE6+ValWAmuL1wLZgAiRnM6IzLA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-21858.001
X-TM-AS-Result: No--33.940-10.0-31-10
X-imss-scan-details: No--33.940-10.0-31-10
X-TMASE-MatchedRID: pS5owHKhBO2nykMun0J1wgRH1Nr7oERdo4jW7zSDg9mLaDxfPEIN+zME cqwMcuifgewoUL5rrDTxTwx4UJIMcgHu7QwNULrh+8AO9OcJ/m9tai4vnmEaPbV5fSMRD1zq4dJ viaysceyaF3c5uYrk370eS9od1h8i0A69txyFJ82aVoAi2I40/cd5cqtswikA/k12Sb2MaHlZu1 5Q7zMZnUMfeadxmJnPiSQL5szRvdFiWV0DQ85LUvSG/+sPtZVkhEIiqNvBrmMCsxyhR8y7CQZJD o6pCM7jJG1hIJqzSYhbrnBpy/UJ9af+cR4Xt9khsyNb+yeIRAosmbwU4T1YtWS9XHvX/HEtns6Y HyuEzV0eJQzperFpy4i8xxxX57I3RrYNcarBmZ+iI3xhOar5y5E+3DCX3uibnSPw4pGdVDwyGVj 0xBH3hsQjeQq0xROI3m5AEUZFDkRoAILruplAqpyBsp6+TmyGGNMTWh+TA9tBDVeC8J7uwVi7de uxKA/M2gVhOa7tXP/ysycfpXevWbfKPdPtGlNyxZQoGMRGhhP6e9LB8NtoJcnB8kQWoALBjGNBd Wf39CJLhC3+rtVVC30sIJ6TTREWSbc8Wi8YbVu3UCG/IQp2Przn940luuzsYespCp11tTjbNQh8 5GhqIoUd6eG8B4adoyTOXOsos+VS/isIEXGDv3uzDvI75j0sgdJqo7qRbOWFz4nDgsy1wM8L/tE hBpSg6TVUhtWEBm89RNTzYBet3vL41OcGi0pOliwpJdZauwcpWss5kPUFdFBJj9noZE9aBuaWJM DEarYdcxr3vPTRr2v2dnV8xLDip7OUOPQ+9P2eAiCmPx4NwLHlqZYrZqdI+gtHj7OwNO0CpgETe T0ynA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/Bujpg48L2ELNro1b8CWDOAlHk2I>
Cc: idr@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
Reply-To: adrian@olddog.co.uk
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 18:09:04 -0000

Thanks for this Alvaro,

I made some further changes and just posted a revised I-D.

I'll spell out the changes for the WG and answer your email shortly.

Adrian

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]
> Sent: 04 October 2015 14:55
> To: adrian@olddog.co.uk
> Cc: draft-ietf-idr-ls-distribution@ietf.org; idr@ietf.org
> Subject: Re: Alvaro's AD Comments on draft-ietf-idr-ls-distribution
> 
> 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. :-(