Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

[heasley]

Wed, Dec 06, 2023 at 11:05:41AM -0500, Jeffrey Haas:
> On Dec 6, 2023, at 10:45 AM, Job Snijders  
> wrote:
> > The author of draft-fiebig-grow-bgpopsecupd asked whether the
> > GROW working group could consider adoption of their internet-draft.
> > 
> > This message is a request to the group for feedback on whether this
> > internet-draft should be adopted.
> > 
> > Title: Updated BGP Operations and Security
> 
> I support adoption of this work.

support.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[heasley]

I support adoption.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[heasley]

Sat, Jul 09, 2022 at 09:32:51PM +0200, Robert Raszuk:
> And here comes I think need for authors to clarify something. They said
> that such marking is going to be used along with NO-EXPORT.

no, you might have misread that; with no-export is possible but not necessary.

Eg: several (perhaps all now?) of the root servers lie within anycast
prefixes.  These should not be marked no-export, but *could* be marked
ANYCAST.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[heasley]

Fri, Jul 08, 2022 at 05:13:37PM +0200, Robert Raszuk:
> > I do not understand Robert's issues with this community.
> 
> Let me say that I like it from operational perspective.
> 
> However from routing perspective I have doubts on how this community is
> going to be originated and how it is going to be used.
> 

I do not preceive these concerns to be unique to this community.  rfc7999
(BLACKHOLE) is of little difference, for eg.  The draft and comments on
the WG ML have noted a few uses, besides it being informational.

> Example 1: Hyperscaler has global POP footprint and is offering anycast
> services for its VPCs. So lot's of prefixes are going to be marked as such.
> Is the expectations that ISPs will/shall use it ?

maybe; that is their decision, not ours nor the originating AS's.  They
might ignore BLACKHOLE, GRACEFUL SHUT, or no_export too.  They might
choose to ignore (or not) it only from Hyperscaler.  They might have a
specific agreement with Hyperscalar to observe the community.

> Example 2: Enterprise is injecting same prefix from different locations. It
> could be anycast or not. Or maybe as mentioned one host route within such
> /24 is true anycast. Is ISP suppose to alter their local pref according to
> such marking ? Even if there is no really ANYCAST service behind at all ?

They might; both are their decision.  They might not observe the community
for prefixes shorther than /24 (/64).  They might just not ignore (use) the
MEDs received.  They might not observe it for prefixes with an AS_PATH
greater than 1 AS.  They might advertise the more specific with no-export.

> Example 3: How do we detect misuse and accidental or purpose marking by
> malicious guys in the middle ?

you know that is not possible today.  You can choose to craft your policy
to limit from whom it is accepted or have other constraints, just as with
any other community.

Seems like we've been over this for other communities.  Besides Jeff's
requested changes (your Ex 2 & 3), perhaps you just want prefix lengths
addressed?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[heasley]

Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas:
> 
> 
> > On Jul 7, 2022, at 11:50 AM, Robert Raszuk  wrote:
> > But most if not all of those do not affect intradomain traffic engineering 
> > rules. 
> > 
> > So I think Jeff's point is how much trust is needed to overwrite your own 
> > policy in selecting exit points and overwriting your EPE policy, TE policy, 
> > Local Pref etc ... 
> 
> Exactly.
> 
> > And I think misuse of those can happen even over direct peerings if the 
> > overall objective is 
> > to avoid double checking the community against prefix lists. 
> 
> Exactly.

Meaning, please add a note to the security considerations saying don't trust
communities (this one included) from untrusted sources.  See rfc 7999 S6.

What a receiver's policy does with the community (or several other
well-knowns or another AS'es self-defined) is their decision.  The document
clearly dictates that a bgp implementation SHOULD NOT (imo MUST NOT) apply
[automatic] special handling of the community.  I do not understand Robert's
issues with this community.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[heasley]

Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> (as normal netizen)
> 
> On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> 
> > > Place LG info in peeringdb.com & peeringdb's api.
> >
> > +1
> >
> 
> huh,I had thought this was already actually included in peeringdb?
> 
>Looking Glass URL http://route-server.ip.att.net
> 

afict, its just a string, which does not provide a standard way to
represent location/geo.  i presume from earlier comments, that something
more structured is desired.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[heasley]

Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF):
> > Consistent API that serves RIB data
> 
> Initially I tried to avoid defining the exact API of the looking glass by
> pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it does
> not strictly define the response format instead leaving it up to the
> implementation what to return to queries, which IMO is not very useful for
> automation.
> 
> As y'all have pointed out there is a wealth of implementations out there
> that have tried to address this (and adding some others I've found):
> 
>- Paolo's pmacct looking glass document:
>https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT,
>- Birdseye https://github.com/inex/birdseye
>- CAIDA looking glass API
>https://www.caida.org/tools/utilities/looking-glass-api/
>- DE-CIX: https://www.de-cix.net/en/resources/looking-glass (which is
>using https://github.com/alice-lg/alice-lg)
>- RIPEStat's API, e.g.
>
> https://stat.ripe.net/data/looking-glass/data.json?preferred_version=2.1=2a0d:d740::/48
> 
> There's certainly value in going in and actually defining the data
> interchange format, but maybe that's worth doing in a different document to
> the propagation of the LG URL itself?

IMO, if you wish to formalize/define the "output" in rfc8522, do so.  let
the LG API (via http/whatever) retrieve information from the devices via
net/restconf.

I do not support adding such an interface to routers or dispersing LG
locations in BGP.  Place LG info in peeringdb.com & peeringdb's api.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[heasley]

Sun, Apr 25, 2021 at 03:07:29PM +0100, Nick Hilliard:
> what we need from routers is a consistent API endpoint which serves RIB 
> data, that can be consumed by client apps.

isnt that called net/restconf?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[john heasley]

Tue, Aug 04, 2020 at 03:36:18PM -0700, Greg Skinner:
> Out of curiosity, were people unhappy that 7908 called attention to the 
> organizations involved in the route leak incidents?  Also, arguably, the 
> mistakes called attention to in the AS_Path prepend draft have been 
> “memorialized” because they can be accessed through the Datatracker (provided 
> one knows how to use its history features).

I'm not; be specific.  Allow others to easily find the data for their
own research or verification of conclusions.  Is there value in hiding
our errors?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[john heasley]

Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker:
> > And what if I make it 675 ASes instead and watch sparks fly as a few
> > hops away routers hit the 4096-byte BGP message size?
> > 
> > Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit
> > AS path, so the first 32-bit router that tries to create a 700-hop
> > 32-bit AS path exceeds 4096 bytes?
> 
> You are applying a band-aid to a broken bone. There is many more ways you
> can push an UPDATE to over 4096 bytes. Using AS path alone is probably the
> least successful. There are many more transitive attributes that you can
> use to bloat an update. So whatever limit you come up with will not
> protect you from tripping over the message size limit.
> 
> It would be great if there is a standards document properly describing
> what to do in such a case because this is one of the underspecified corner
> cases in the current spec.

isnt this rfc7606

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[john heasley]

Mon, Sep 16, 2019 at 10:18:09AM -0500, David Farmer:
> Furthermore, excessively long paths will use more memory

Not significantly.  It is not length that represents large consumption
by AS-PATHs, its variance of paths in the RIB.  ie: no sane
implementation copies the path to every RIB entry, its a pointer/reference.

1 transit 1 ibgp: 185637 BGP AS-PATH entries using 8.8M
2 transits: 338034 BGP AS-PATH entries using 16.5M
1 transit 47 peers: 299673 BGP AS-PATH entries using 15M

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[heasley]

Wed, Mar 13, 2019 at 04:30:08PM +0100, Robert Raszuk:
> In general of course.
> 
> I was just describing the *local ISP customer's* inbound peering policy.
> Sorry if that wasn't clear.

by "local ISP", do you mean Comcast? :)  For a very small provider,
existing policy language could be sufficient; we're all making due with
what we have, but it really depends upon how pedantic they wish to be
about A route's attributes and the volume.  the more pedantic they wish to
be, the larger the policy; the config becomes large and their devices may
not have resources to handle it.  That assumes that they have the information
to be pedantic; see efforts of many to improve (speed, accuracy, etc) IRR
data or utilize sidr data in other ways.

More programability is needed, imo.  IOS XR has made improvements here with
parameterized RPL, for eg.

as for the draft itself, isnt the origin case handled by sidr?  and the
transit case by proposed path validation?

> Or do you see that even that has some limitations which may require extra
> solutions ? If so pls elaborate on what those limitations are.
> 
> Thx.
> R.
> 
> 
> 
> On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:
> 
> > Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > > Each decently managed AS today has strong EBGP ingress policy permitting
> > > only specific prefixes with specific AS-PATH which is applied in ingress
> > to
> > > ISP network. No more enhancement to this policy is required.
> >
> > I'm NOT speaking in support of this draft, I have not even read it.  But,
> > want to tell you that there are limitations to what filtering can be
> > imposed inbound and not just when the peer is very large.  effective
> > solutions should be welcomed.
> >

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[heasley]

Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> Each decently managed AS today has strong EBGP ingress policy permitting
> only specific prefixes with specific AS-PATH which is applied in ingress to
> ISP network. No more enhancement to this policy is required.

I'm NOT speaking in support of this draft, I have not even read it.  But,
want to tell you that there are limitations to what filtering can be
imposed inbound and not just when the peer is very large.  effective
solutions should be welcomed.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

[heasley]

Mon, Jan 21, 2019 at 01:51:50PM +0100, Job Snijders:
> > On the other side, the sentence "Vendors SHOULD share the behavior of
> > their implementations" perhaps can be made stronger by replacing the
> > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this
> > document".

s/share/clearly document/ is perhaps what is meant?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Comments on draft-sa-grow-maxprefix

[heasley]

Fri, Dec 28, 2018 at 03:52:39PM +0800, Tim:
> Soft limit:
> 
> 1) Alert only: Only alert triggered, neighbor is not impacted
> 
> 2) Alert + Stop receiving route: Alert triggered, no extra route accepted.

unless it repeats the alert for every bgp packet received with announcement
nlri (log coalescing/throttling permitted), that sounds like a terrible
action.  I expect that otherwise the event might (will) pass unnoticed.

> 2. Generally to protect network from impact of route leaking, based on 
> my experience only relying on prefix limit mechanism is not enough. 
> Reason include:
> 
> 1) Prefix limit is usually neighbor basis, while route leaking could 
> happen on multiple neighbors together.
> 
> 2) Consideration also need include devices on POP that receive all 
> internet routes from internet gateway via RR. Such devices could hold 
> multiple services not only just BGP.
> 
> In such case, either a BGP process based or global based memory 
> protection mechanism is needed.

seems to be common sense and out of scope.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

[heasley]

Mon, Jun 11, 2018 at 08:59:39PM +, Job Snijders:
> Dear working group,
> 
> The authors of draft-ymbk-grow-wkc-behavior [1] requested the chairs to
> consider issuing a call for working group adoption. Here is the
> abstract:
> 
> "Well-Known BGP Communities are manipulated inconsistently by
> current implementations. This results in difficulties for
> operators. It is recommended that removal policies be applied
> consistently to Well-Known Communities."
> 
> [1]: https://tools.ietf.org/html/draft-ymbk-grow-wkc-behavior-01
> 
> Please take a moment to read and evaluate the document and let the
> working group know whether you'd like to continue work on this document
> as working group or not.

i support adoption, preferring prescription of the process rather than
platform nuances.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7948 (5366)

[heasley]

Thu, May 24, 2018 at 01:49:17PM +0100, Nick Hilliard:
> Sandra Murphy wrote:
> > A university abandoning publication of its research and, at least
> > right now, not even sustaining the archive of its former
> > publications.  Ugh.
> 
> Long term document storage is hard.

caching copies (with attribution) shouldnt be that difficult.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

[heasley]

Thu, Jan 18, 2018 at 11:10:38AM -0500, Jay Borkenhagen:
> [resend - apologies for any dupes]
> 
> Distro cut *way* down.
> 
> Regarding the suggestion for "logging knobs":
> 
> - if it's just logging that a gshut action was taken, that's a local
>   implementation decision -- no need to mention it in the draft.
> 
> - if it's "Possibly raising alarms when something seems wrong", that
>   would be a bad idea.  There *will* be instances when traffic remains
>   on the link even after the graceful shutdown initiator has signaled
>   an approaching shutdown.

This a good point.  If the path is the only one, traffic will remain
until the path is withdrawn.  NOCs deal with enough errors & noise
already; this would be a difficult one for an NMS to adjudicate.

> To keep things simple and to allow the gshut draft to continue making
> progress, I'd prefer to leave it as-is.
> 
> Thanks.
> 
>   Jay B.
> 
> 
> bruno.decra...@orange.com writes:
> OK,
> Thanks Susan.
> 
> --Bruno
> 
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, January 18, 2018 12:25 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; 
> ops-...@ietf.org
> Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13
> 
> Bruno:
> 
> I'm sorry I'm this late for the review.   On the editorial nit, if you think 
> it helps - send it to the RFC
> editor.
> 
> On the logging knobs,  you understood my point.  Logs should cover what is 
> section 4.2.  However,
> since the document is in the RFC editor's queue - it is your choice.  If you 
> get a chance to edit it in -
> fine.  If not, those people who implement the gshut will probably put it in.
> 
> Thanks for asking,  Susan Hares
> 
> -Original Message-
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Thursday, January 18, 2018 6:19 AM
> To: Susan Hares
> Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; 
> ops-...@ietf.org
> Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13
> 
> Hi Susan,
> 
> Thanks for your time reviewing this document and you below comments.
> 
> Please see my replies inline [Bruno]
> 
> Note that however fast I'm answering to your review, that document is now in 
> RFC editor queue,
> and hence technical changes are much more difficult. (AFAIK, would require 
> specific approval
> from the responsible AD). Thanks for taking this into account.
> 
> 
> 
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com] Sent: Thursday, January 18, 2018 
> 9:46 AM  >
> To: ops-...@ietf.org Cc: grow@ietf.org; 
> draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org  >
> Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Reviewer: 
> Susan Hares  >
> Review result: Has Nits Status: Nits The operational procedures described in 
> this
> process for the gshut comment are accurately covered, and SHOULD work well.  
> The
> Appendices A-C add to an operations document and should be retained for 
> publication.
> 
> [Bruno] ok, thanks.
> 
> Technical nit:
> location of technical nit: (section 4.3) The document indicats that the "BGP 
> implementers
> SHOULD provide configuration knobs that utilize teh GRACEFUL_SHUTDOWN 
> community."
>  >
> What the problem is:
> The document does not say is that their should be error reporting knobs to 
> track the use of
> GRACEFUL_SHUTDOWN community.  This can go in section 4.3 in one or two 
> sentences.
> 
> [Bruno]
> Could you please elaborate on this? What do you have in mind by "error 
> reporting knobs"?
> Thinking about this, what I could think of would be logs detailing the steps 
> in section 4.2. Possibly
> raising alarms when something seems wrong. (e.g. after waiting for BGP 
> convergence, there is still
> some traffic sent/received over the interface(s) related to the EBGP session) 
> Is this what you were
> thinking about?
> 
> 
> Editorial nit:
> section 3. paragraph 2, p. 3
>  >
> /This is because alternate paths can be hidden by knodes of an AS./ commment: 
>  The implied
> "this" is too vague for a specification.
>  >
> Fix:/This lack of path occurs because alternate paths can be hidden by nodes 
> of an AS."/
> 
> 
> [Bruno]
> I agree that your proposed text makes it more explicit, which is always 
> better in a specification
> (when it's not redundant).
> However, I would note 2 points:
> - section 3 is part of the introduction to the problem space. It explains the 
> root cause of the
> problem. It's not part of the graceful shutdown specification.
> - The text you are referring to is a paragraph starting with:  "First, some 
> routers can have no path
> toward an affected prefix, and drop traffic destined to this prefix.  This is 
> because alternate paths
> can be hidden by nodes of an AS."
> Hence "This" refers to the short sentence which is immediately before. I 
> don't feel that 

Re: [GROW] Route Server ASN stripping hiding considered harmful?

[heasley]

Mon, Dec 18, 2017 at 04:36:56PM +0100, Job Snijders:
> pressure to set up bilateral sessions.

Is that negative?  Why not encourage ASes to have direct relationships
and stop maintaining route servers?  They should develop those relationships
and it might even be suggested that security and trouble shooting could
rely upon it.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[heasley]

Fri, Jun 30, 2017 at 03:26:08PM +, bruno.decra...@orange.com:
> > From: heasley [mailto:h...@shrubbery.net]  > Sent: Thursday, June 29, 2017 
> > 8:28 PM
> > 
>  > Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com:
>  > >
>  > >
>  > >  > From: heasley [mailto:h...@shrubbery.net]  > Sent: Monday, June 26, 
> 2017 7:07 PM
>  > >  > To: DECRAENE Bruno IMT/OLN
>  > >  > Cc: grow@ietf.org
>  > >  > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
>  > >  >
>  > >  > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com:
>  > >  > >  > Suggestions:
>  > >  > >  >
>  > >  > >  > OLD Abstract:
>  > >  > >  >This draft describes operational procedures aimed at reducing 
> the
>  > >  > >  >amount of traffic lost during planned maintenances of routers 
> or
>  > >  > >  >links, involving the shutdown of BGP peering sessions.
>  > >  > >  > NEW Abstract:
>  > >  > >  >This draft describes operational procedures aimed at reducing 
> the
>  > >  > >  >amount of traffic lost during planned maintenances of routers 
> or
>  > >  > >  >links, involving the shutdown of BGP peering sessions. 
> Additionally
>  > >  > >  >this document describes the use of a well-known Border Gateway
>  > >  > >  >Protocol (BGP) community to signal that a graceful shutdown 
> has been
>  > >  > >  >initiated for the tagged prefix.
>  > >  > >
>  > >  > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP 
> community, called
>  > gshut, to
>  > >  > signal the graceful shutdown of paths to other Autonomous Systems."
>  > >  >
>  > >  > s/paths to other Autonomous Systems./a path in the presence of other 
> paths./
>  > >  >
>  > >  > ie: it does nothing when there is no other path and it may not move to
>  > >  > anoter AS, just to another path.  it is per-session, not per-AS.
>  > >
>  > > My sentence was misleading. Changing to: "It defines a well-known BGP 
> community,
>  > called g-shut, to signal over the EBGP session to be shutdown, the 
> graceful shutdown of
>  > paths."
>  > 
>  > As Jakob mentioned, its not ebgp-only, as it also addresses shutting an
>  > ibgp or an entire speaker.
> 
> The procedure is not limited to ebgp. However the BGP community is defined in 
> order to perform the signaling specifically over EBGP.
> Over IBGP, we use LOCAL_PREF to lower the preference of the route. Even if 
> the community may be kept for information.

you would still want to add the community; if you have no other path, you
still want the community to be on routes to remote eBGP peers, if you have
any in-bound iBGP policy that might affect the LP, you still want/need to
communicate to the ibgp peers.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[heasley]

Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com:
> 
> 
>  > From: heasley [mailto:h...@shrubbery.net]  > Sent: Monday, June 26, 2017 
> 7:07 PM
>  > To: DECRAENE Bruno IMT/OLN
>  > Cc: grow@ietf.org
>  > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
>  > 
>  > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com:
>  > >  > Suggestions:
>  > >  >
>  > >  > OLD Abstract:
>  > >  >This draft describes operational procedures aimed at reducing the
>  > >  >amount of traffic lost during planned maintenances of routers or
>  > >  >links, involving the shutdown of BGP peering sessions.
>  > >  > NEW Abstract:
>  > >  >This draft describes operational procedures aimed at reducing the
>  > >  >amount of traffic lost during planned maintenances of routers or
>  > >  >links, involving the shutdown of BGP peering sessions. Additionally
>  > >  >this document describes the use of a well-known Border Gateway
>  > >  >Protocol (BGP) community to signal that a graceful shutdown has 
> been
>  > >  >initiated for the tagged prefix.
>  > >
>  > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, 
> called gshut, to
>  > signal the graceful shutdown of paths to other Autonomous Systems."
>  > 
>  > s/paths to other Autonomous Systems./a path in the presence of other 
> paths./
>  > 
>  > ie: it does nothing when there is no other path and it may not move to
>  > anoter AS, just to another path.  it is per-session, not per-AS.
> 
> My sentence was misleading. Changing to: "It defines a well-known BGP 
> community, called g-shut, to signal over the EBGP session to be shutdown, the 
> graceful shutdown of paths."

As Jakob mentioned, its not ebgp-only, as it also addresses shutting an
ibgp or an entire speaker.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[heasley]

Mon, Jun 26, 2017 at 05:39:12PM +0200, Job Snijders:
> > As for my requirements, I'm considering that our ASes have the
> > knowledge of the backup path. Hence I don't need for the extra
> > coverage. Regarding the extra cost, I agree that one can hardly
> > consider this unacceptable since this is the current behavior.
> > 
> > TL;DR: it's a tradeoff between 2 secondary objectives:
> > - reducing Internet churned (compared to today)
> > - improving the g-shut coverage when the AS does not know the backup path
> 
> + improve visibility into the operation

+1 for that; and allows it to (possibly) enter the records of routeviews.

& allows other ASes beyond the receiver to take action - even if the receiver
  does not have an alternate path ... which imiho ends this discussion about
  removing the community.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[heasley]

Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com:
>  > Suggestions:
>  > 
>  > OLD Abstract:
>  >This draft describes operational procedures aimed at reducing the
>  >amount of traffic lost during planned maintenances of routers or
>  >links, involving the shutdown of BGP peering sessions.
>  > NEW Abstract:
>  >This draft describes operational procedures aimed at reducing the
>  >amount of traffic lost during planned maintenances of routers or
>  >links, involving the shutdown of BGP peering sessions. Additionally
>  >this document describes the use of a well-known Border Gateway
>  >Protocol (BGP) community to signal that a graceful shutdown has been
>  >initiated for the tagged prefix.
>  
> [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, 
> called gshut, to signal the graceful shutdown of paths to other Autonomous 
> Systems."

s/paths to other Autonomous Systems./a path in the presence of other paths./

ie: it does nothing when there is no other path and it may not move to
anoter AS, just to another path.  it is per-session, not per-AS.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Benoit Claise's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

[heasley]

Thu, May 11, 2017 at 05:19:53AM -0700, Benoit Claise:
> Benoit Claise has entered the following ballot position for
> draft-ietf-grow-large-communities-usage-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Introduction
> 
>BGP Large Communities [RFC8092] provide a mechanism to signal opaque
>information between Autonomous Systems (ASs). 
> 
> Not only "between": BGP communities might also be used inside an AS, as
> you described in the "informational communities"

true; "and within" - would you pen that, job?

> As mentioned by Jouni in his OPS-DIR review:
> One minor nit I have relates to management & administration to the
> large communities functions and description of their semantics. Are
> those maintained somewhere? If there are existing repositories,
> documentation, etc it would be nice to point out those. The document
> now hints to NANOG and NLNOG..

They are not cataloged anywhere.  I think that you are interpretting
this draft to be more than an example of how one might use Large
Communities, that it is standardizing the Local Data fields, which is
not the case.  These values are defined by and have significance to
the ASN/Global Admin in the first field of the Large Comm.

Does this address the comment?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Suresh Krishnan's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

[heasley]

Tue, May 09, 2017 at 07:20:26PM -0700, Suresh Krishnan:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-grow-large-communities-usage-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Overall the document was well written and easy to read. I did have one
> question though. It is not clear how the values for the Local data part 1
> are matched up to the functions and communicated between the peer ASes?
> Is this going to stay purely a local matter between ASes or is there
> going to be a movement towards some sets of known functions (e.g. the BGP
> blackhole community RFC7999)?

LD1 and LD2 are expected to be unique to and defined by the GA (ASN).
No effort was made to address standardizing LD1 or LD2 values and this
was intentionally avoided in discussion of both this draft and RFC8092,
which itself creates no well-knowns like RFC7999.  well-knowns such as
RFC7999 are well served by RFC1997 communities and may co-exist with
RFC8092 communities, thus there is no need to duplicate them.

An effort could be made to standardize LD1 or LD2 or define well-knowns
requiring the utility of RFC8092, but that is considered out of scope
for this draft - and likely a rathole best explored separately.

Thanks for reviewing.

Prost

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-large-communities-usage-06

[heasley]

Tue, Apr 18, 2017 at 06:41:15AM -0700, Stewart Bryant:
> 5.  Security Considerations
> 
>Operators should note the recommendations in Section 11 of BGP
>Operations and Security [RFC7454].
> 
> SB> You do not address the question of whether there are new
> considerations, or considerations
> SB> that are of increased importance? Is there is text somewhere
> SB> that discusses the integrity and synchronization of the
> parameters
> SB> and any consequences that arise?

I agree that this draft lacks one detail of how RFC7454 applies to it, but
I also note that RFC7454 also does not explain the dangers of ignoring
the recommendations in S11.  I suggest that the subject of removing one's
own communities is subjective and a local issue for which we can only
hypothesize.  I'll try to address the latter, but I do not personally feel
this is necessary.

> ===
> 
> Minor issues:
> 
> 2.2.  Action Communities
> 
>Action Communities are added as a label to request that a route be
>treated in a particular way within an AS.  The operator of the AS
>defines a routing policy that adjusts path attributes based on the
>community.  For example, the route's propagation characteristics,
> the
>LOCAL_PREF (local preference), the next-hop, or the number of
> AS_PATH
>prepends to be added when it is received or propagated can be
>changed.
> 
> SB> Although these are well known to the target audience, I think you
> SB> need some references in the above para.

How so?  Do you mean actual community values similar to the example in 3.1.1?
Because these are int 4.x, as 3.x are examples related to 2.1.

> Nits/editorial comments: 
> 
> 6.  IANA Considerations
> 
>None.
> 
> SB> A little briefer than normal. 

Isn't it elegant. :)

thanks for the review.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[heasley]

Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta:
> What do you think in including also some suggestions when bringing up
> the BGP sessions?.  Sometimes it´s good idea to bring them up one by one
> or something like that, the idea is to make the device to fill out the
> forwarding table, create cache, perform ARP lookups, ND, and so on. To
> bring up all the session at once many times is not that good.

I'd expect this to prolong and exacerbate the 'path hunting', while the
min-advert-timer might help to squelch it if all sessions are enabled
at the same time - after the IGP settles, which is automatic in some
impl..

randy, link to path hunting paper?  i can't seem to find it.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Code nannies (Re: Do you want BGP to extend the message size for all BGP messages or just UPDATES.)

[heasley]

Thu, Mar 09, 2017 at 12:20:43PM +, Nick Hilliard:
> First, it's not guaranteed
> that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN
> message, and secondly, you're not guaranteed that just because the stack
> supports 4097 bytes on open due to e.g. unintentional coding reasons,
> that it actually supports 4097 bytes by design and that it actually
> works properly.

Ignoring support or opposition for the topic of the thread, why should
the ietf concern itself with programming (and testing) incompetency of
this magnitude?  The RFCs should document the procedure to negotiate
the capability, not endeavor to design for every possible programming
error.

> Nick
> 
> Susan Hares wrote:
> > Thomas: 
> > 
> > It is possible to create an option that requires implementation support
> > extended messages upon receiving a notification.  If the sequence is: 
> > Open-(4097 bytes) --> 
> >  <-notification (with indication message length is too long)
> > 
> > 
> > (sequence allowed RFC4271 current FSM) 
> > The extended messages would know to back down to 4096 and negotiate forward.
> > This would not let your BGP speaker get stuck.  It seems reasonable to make
> > the code take care of this problem rather than have a crisis in an
> > operator's day. 
> > 
> > Open (< 4096) bytes) ---> 
> > 
> > Just let us know what you want. 
> > 
> > Sue 
> > 
> > 
> > -Original Message-
> > From: Thomas Mangin [mailto:thomas.man...@exa.net.uk] 
> > Sent: Tuesday, March 7, 2017 4:39 PM
> > To: grow@ietf.org
> > Cc: Susan Hares
> > Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP
> > messages or just UPDATES.
> > 
> > Hello Nick,
> > 
> > I can see one reason why it would become undesirable in the future: 
> > 
> > If a then recent speaker, with support with this draft/RFC, and with a
> > yet-to be defined large number of capabilities, happened to generate an OPEN
> > message of 4097 bytes (to match its configuration), this OPEN would most
> > likely be seen as invalid by current implementations not supporting the
> > extension.
> > The excessive/invalid length when checking the OPEN message size will surely
> > caused the session to be terminated.
> > 
> > It would therefore prevent any session to come up (even if otherwise
> > everything is fine). Therefore should this size extension be applied, it
> > should be applied to all message types BUT the OPEN message. I think we are
> > currently not near needing 4096 bytes for OPEN (but the day will/may come).
> > 
> > ExaBGP would suffer from this issue as the check is currently performed on
> > ALL messages as currently specified including the OPEN.
> > 
> > So I would suggest to just change the wording to include all message type
> > but OPEN, and leave it as an exercise to the reader to write another draft
> > allowing to break capabilities over multiple messages.
> > 
> > Sincerely,
> > 
> > Thomas
> > 
> >> On 7 Mar 2017, at 21:08, Nick Hilliard  wrote:
> >>
> >> Susan Hares wrote:
> >>> This email is to make you aware of the discussion on the Extended
> >>> Messages draft (draft-ietf-idr-bgp-extended-messages-21).   Do you
> >>> want the message size extended for all BGP messages or just UPDATE
> >>> messages?   This probably is more important if you want to have a
> >>> larger size OPEN, ROUTE-REFESH, and UPDATES.The IDR co-chairs
> >>> value the operational input from GROW WG.
> >> I don't see any reason an extended message size should be limited to 
> >> just UPDATEs. Enke's suggestion for handling the single anomalous case
> >> (OPEN) looks reasonable.  I'd say, go for it!
> >>
> >> Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] ietf 97 agenda

[John Heasley]

Am 14.11.2016 um 23:52 schrieb Exa :
> 
> Hello Jeff,
> 
> Thank you very much for this document which present ever eloquently one of 
> the issues with the current development process.
> 
> It is however not how I would propose to move forward. As a individual 
> developer, I do not have an IANA code and I am not sure I could get one.

Have you tried?
 
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[heasley]

Wed, Aug 03, 2016 at 10:11:46PM -0400, Christopher Morrow:
> So, back to your discuss though:
>   "BGP speakers SHOULD only accept and honor BGP announcements carrying
>the BLACKHOLE community if the announced prefix is covered by a
>shorter prefix for which the neighboring network is authorized to
>advertise."
> 
> (note that 'shorter' is used here...again making the above bit more
> confiusing with smaller/larger)
> 
> MUST vs SHOULD for this, I do think the MUST would be easy to handle. Is
> this a problem in an RS situation? Probbaly not... on the RS, but on the
> distant peer, it likely is hard(er) to deal with. I don't imagine many folk
> prefix filter the RS session very tightly only because memberships come/go
> and you may not always get timely notice (I have no idea when people
> come/go at the IX's I connect to).
> 
> So, SHOULD makes some sense to me, at least in the RS peer/distant-peer
> world. Surely for direct BGP peerings MUST is a better idea, I think.

or strike the language altogether.  it is unnecessary.  if it is their
prefix and they want to blackhole it - whatever, their prerogative.

> I really question why this is a "SHOULD" and not a "MUST", even in an
> > informational RFC. Is the ability for a transit provider so loose that
> > appropriate route filters from a peer ASN can't be applied so that only a
> > "SHOULD" is practical? In which case I do question the sanity of making
> > such a recommendation and thus service available if some other ASN might
> > be able to inject the route and affect another service, even by mistake.
> > Potentially if RPKI is in use, then a peer AS might be able to validate
> > the announcement against a ROA. But it strikes me that this is not the
> > machinery you would want to tack on in this case.
> >
> >
> job and I chatted a bit about this (oddly, prior to your note here) and one
> thing to keep in mind with RPKI is that the ROA Owner (publisher?) would
> have to first know their special-prefix was going to be attacked, then set
> the ROA up (as a /32 or as a supernet -> /32). I'm skeptical of that being
> done, certainly today there are virtually no /32 ROA in the system.
> 
> RPKI probably isn't the tool to use here, for this.

I am not knowledgable of every facet of rpki, but I thought that it was
possible to express /length-or-longer?  But Randy has already pointed
that rpki doesnt cover communities; to middle men can alter it.

> > The same could be said for section 3.2. I would be rather wary of NOT
> > adding a NO_ADVERTISE (at the very least) and to be honest SHOULD still
> > seems far too loose for me. Almost all of the recipe's that I've gazed
> > upon
> >
> >
> ... you trailed off... I bet it was something like:"gazed upon require/use
> NO-advertise on the ISP side and no-export on the customer side
> 
> that's the recipe I setup when last i was an ISP...
> I think the hesitancy for 'MUST' there is that there are cases in use today
> where you would send a route-server the /32 + commnuity and WANT that to
> get to the remote peers.
> 
> If the RS did 'no-advertise' the route won't make it to the remote peer :(

and no-advertise is almost certainly wrong for most - it implies that you
carry the traffic from a remote location to the penultimate hop before the
customer only to /dev/null it there.

> > >From a comment point of view, this informational document is agnostic on
> > any operational differences between 2-byte and 4-byte ASNs. Is that
> > intentional? Are there any operational differences worth calling out in
> > regard to using extended communities etc?

Not that I know of; orthogonal.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[heasley]

Wed, Aug 03, 2016 at 12:02:36PM -0400, Christopher Morrow:
> > (2) IIUC, this proposal envisages BGP speakers commonly
> > telling others to blackhole specific /32's or /128's. And
> > of course as the draft says BGP doesn't provide us with a
> > way to "prevent the unauthorized modification of
> > information by the forwarding agent." Given those two
> >
> 
> err, there is MD5 auth for tcp... which SHOULD prevent modification
> in-flight.
> of course (ha!) there's notionally tcp-AO which should do the same thing,
> perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
> darn! no implementations of AO exist.

I do not believe that is the intended meaning; I think it is reference
to a device's route policy, intentional or accidental.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[heasley]

Wed, Jun 29, 2016 at 05:22:44PM -0400, Jared Mauch:
> > On Jun 29, 2016, at 5:10 PM, Nick Hilliard  wrote:
> > Job Snijders wrote:
> >> Do you have any more comments or concerns queued up?
> > 
> > I don't think the draft is well specified in terms of its intended
> > semantics.  This is a problem with a standards track document,
> > particularly one with big scary warnings in the security considerations
> > section.  It needs to be tightened up substantially before publication
> > could be considered.
> 
> Looking at section 5 of https://www.rfc-editor.org/rfc/rfc5635.txt

Why wouldn't you want to propogate BH routes?  If you want to BH the
traffic, then let it be dumped closer to the source.  You might
accidentally make things exciting for yourself, but it seems like
desirable behavior to me.

Since BH routes tend to be more specific, most are unlikely to be
propogated very far anyhow.

I think that the security concern lies far more in the lack of origin
validation [with rfc7908 usw.].

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[heasley]

Wed, Jun 29, 2016 at 10:54:30PM +0200, Job Snijders:
> On Wed, Jun 29, 2016 at 09:46:15PM +0100, Nick Hilliard wrote:
> > Job Snijders wrote:
> > > Should it be somehow clarified that router vendors are not supposed to
> > > implement mechanisms, which are by default enabled, that discard traffic
> > > for BLACKHOLE'ed prefixes?
> > 
> > I would have said the opposite, i.e. that any traffic tagged with this
> > prefix is dropped via e.g. null0 or martian mechanisms / etc.  But it
> > definitely needs to be defined because at the moment it's ambiguous.
> > Ambiguity is fine when it's your own network, but not fine when you're
> > defining something with global scope.
> 
> Why would you say the opposite? That goes counter to what the vendors
> are shipping today. The suggestion "do not do anything" is compatible
> with what ships today! :)
> 
> We can add a new section "3.4 - Vendor recommendations" and describe
> what it is we'd expect a network device vendor to implement or not to
> implement. 

It may be useful to be able to forward BH traffic off a router for analysis,
so discarding may not be desired.  I'd leave what is done with traffic by
default for configuration by operator.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-16: (with DISCUSS and COMMENT)

[heasley]

Sat, Dec 05, 2015 at 02:51:17AM +, John Scudder:
> On Dec 4, 2015, at 9:48 PM, Randy Bush  wrote:
> 
> >>   Where the security considerations outlined above are a concern, users
> >>   of this protocol should use IPsec [RFC4303] in tunnel mode with
> >>   preshared keys.
> > 
> > the classic wiggle from the 1990s.  and no one ever does it.  and at the
> > using layer, you can not even detect if it is in place and abort if it
> > is not.  #fail
> 
> I do not understand your point. Wasn't actually intended as a wiggle, but as 
> an option that you can actually do with existing shipping code. Maybe we can 
> discuss Monday. 

i too do not understand your point.  please explain in detail.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-petrie-grow-mrt-add-paths

[heasley]

Mon, Nov 02, 2015 at 05:27:15PM +0900, Jeffrey Haas:
> > Please consider this the start of a 3 week Adoption call for the noted
> > draft who's abstract is:
> >   "This document updates the Multi-threaded Routing Toolkit (MRT) export
> >   format for Border Gateway Protocol (BGP) routing information by
> >   extending it to support the Advertisement of Multiple Paths in BGP
> >   extensions."
> 
> IMO, this one is a no-brainer.  I encourage adoption, swift editing and then 
> ship as an RFC.

Agree with Jeff.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

[heasley]

Wed, Oct 14, 2015 at 05:09:14PM -0400, Jeffrey Haas:
> On Wed, Oct 14, 2015 at 08:47:17PM +0000, heasley wrote:
> > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext"
> > option - not for normal runtime, for debugging.  its darwinian, if someone
> > chooses to always run cleartext.
> 
> This is actually a big deal with regards to streaming routing protocols.
> 
> It's been my unfortunate experience over the years that most BGP developers
> have more than the usual familiarity with the implementation behaviors of
> TCP.  Even *normal* TCP has ugly properties that negatively impact BGP.
> Introduce another couple layers between the protocol PDUs and the final set
> of transports and it's a royal pain to do anything about.
> 
> To give a simplified and common issue, when BGP peering sessions on
> otherwise quiet links time out, you get to look at things like the TCP
> windows to see if your PDUs ever made it out and were advertised on the wire
> and acknowledged by the other side.  This often requires the sequencing data
> from both sides to try to pin down the problems.
> 
> Now introduce the peculiarities of other encapsulations and their
> interactions with the underlying timings of the protocol.  If I'm running
> TLS, how do I know that it hasn't chosen to hold up a PDU for an extra
> second or two in order to either have a full enough payload to make the
> crypto library happy?
> 
> I realize that these peculiarities can be addressed in the long-run, but I
> tend to see these issues as having negative consequences on the operational
> stability of the underlying protocol.

I may not follow you; I think that you are saying that by removing the
"non-cleartext" path for purposes of debugging, you may have changed the
behavior that is causing the thing that you are attempting to debug.  I
agree with that, but it does not discount the utility of being able to
capture whats on the wire for debugging.

> > I do not care if your suggested text is added or not; the existing security
> > section of the draft covers the subject for me.  Nor do I disagree that it
> > could support TLS, just do it in a separate draft and move this one along.
> > 
> 
> I suspect if you examined the idea of TLS as another one of the recommended
> transport security options in the context of the existing text, you'd be
> fine with that too.

By which you mean that, as implied in the security section of the draft,
one could run bmp over a vpn, ipsec tunnel, etc implemented external from
BMP - yes, I'm happy with the existing text.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

[heasley]

Wed, Oct 14, 2015 at 09:04:33PM +0100, Stephen Farrell:
> > I'd be happy to see the addition of TLS support in a future document.  I
> > also do not want TLS use to be required and I would like to see this
> > draft move forward without TLS.
> 
> My non-blocking comment asks about the why of that, which I
> really do not get, it's not like it's hard or new.

I feel that there is an overhead associated with TLS, etc for development,
debugging and runtime.  All concern me, as does lack of security.  For BMP,
a protocol most likely to be confined to a lab than the wild Internet, I am
more concerned about runtime cost and deployment (ie: initial development)
than with security of the session.

BMP could be run over an ipsec tunnel as an alternative to it being part of
the protocol.

For debugging purposes, I'd perfer to see ALL protocols have a "cleartext"
option - not for normal runtime, for debugging.  its darwinian, if someone
chooses to always run cleartext.

> But the DISCUSS from me is about truth in advertising - if
> the WG are presenting this as something that cannot in practice
> be secured (which is how I read the secdir thread) then that
> should be what the document says. (See my suggested text.)

I do not care if your suggested text is added or not; the existing security
section of the draft covers the subject for me.  Nor do I disagree that it
could support TLS, just do it in a separate draft and move this one along.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

[heasley]

Thu, Jan 03, 2013 at 02:31:16PM -0800, Tony Li:
 As I've said before, errors can be reasonably classified into two groups: 
 syntactic and semantic.  
 
 A syntactic error would be any inconsistency of length fields, 
 incompatibility between a type and a length, or any other error that would 
 introduce any doubt about the parsing of the message.  Once this type of 
 error has occurred, then the remainder of the data stream is wholly in doubt. 
  A session reset seems like the only (conservative) way of handling this, as 
 it's unclear that further data would be accurate.

Amen.  if you've come upon a syntactic error and therefore have zero
confidence that any bit in the message is correct, I dont understand how you
could have any confidence that treat-as-withdraw is treating the right
prefix(es) as withdrawn, or even logging the right prefix(es).  you cant
even have confidence about the length of the message.

The aforementioned sesson re-establishment suppression seems a far better
and consistent approach; it also doesnt seem to be the subject for an rfc.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] ixp jumbo frames doc

[john heasley]

Thu, Nov 17, 2011 at 04:23:03PM -0800, Martin J. Levy:
 Hence ... There is MSS negotiation; hence there is value; but I believe I 
 should only note this fact within the document and not make in any way a 
 requirement to tune or change the BGP or TCP knobs to take advantage of the 
 large MTU path.  The fact that some sessions enable this and some don't is 
 perfectly OK. It's being decided by the routers for whatever reason they 
 choose. 

enable what?  it's TCP that is concerned with the MTU ( MSS), not BGP.
a vendor might provide data about the underlying tcp connection in its
bgp session output, but that doesn't mean that BGP is concerned with its
value - its just handy debugging information for the operator.  I suppose
an implementation could use the MTU or MSS for something, but it shouldn't
need to do that if its TCP stack were implemented properly - implementation
specifc.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] ixp jumbo frames doc

[john heasley]

Thu, Nov 17, 2011 at 06:46:12PM -0500, Jakob Heitz:
 BGP uses TCP. Differing MTU has no impact on update generation in BGP. BGP 
 today has a maximum message size of 4096 bytes. TCP slices and dices that 
 into IP packets of its own choosing.

i was about to reply with the same, then it occured to me that an
implementation may have closer ties to the underlying mtu for rfc2385
or similar.  so the question becomes where implementation-specific
limitation belong in the draft.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt

[john heasley]

Thu, Dec 16, 2010 at 06:27:54PM -0800, John Scudder:
 On Dec 16, 2010, at 8:08 PM, Stephen Stuart wrote:
  I think it defeats a lot of use cases. Perhaps this subtle difference 
  should
  be discussed more before we proceed any further with this document.
  
  This was discussed before, if I recall correctly.
 
 That's correct.  In fact because of the divergence between -00 and -01, I 
 took pains to make this clear when presenting -01, including at NANOG and 
 GROW and probably other places.  Those interested in the history should be 
 able to find the slides easily enough.

why does this matter?  sure, adj-rib-in is MUST, but can that not be
configurable which is (are) exported?
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow