Subject: [Gen-art] Genart last call review of draft-ietf-grow-bgp-session-culling-04

From: Brian Carpenter <[email-masked]>
Date: Mon, 18 Sep 2017 21:44:58 -0700

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-grow-bgp-session-culling-04

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-grow-bgp-session-culling-04.txt
Reviewer: Brian Carpenter
Review Date: 2017-09-19
IETF LC End Date: 2017-09-25
IESG Telechat date: 

Summary: Ready with issues
--------

Minor Issues:
-------------

> 3.1.1.  Maintenance Considerations
>
>  Initiators of the administrative shutdown could consider using
>  Graceful Shutdown [I-D.ietf-grow-bgp-gshut] to facilitate smooth
>  drainage of traffic prior to session tear down, and the Shutdown
>  Communication [I-D.ietf-idr-shutdown]...

This strikes me as vague. "Could consider"? Surely if this is
a BCP, they MUST use some mechanisms and perhaps SHOULD use these
particular mechanisms. Otherwise the document doesn't specify
anything much at all for this case.

> 3.2.  Involuntary BGP Session Teardown Recommendations
...
>  In the absence notifications from the lower layer (e.g. ethernet link
>  down) consistent with the planned maintenance activities in a
>  switched layer-2 fabric, the Caretaker of the fabric could choose to
>  cull BGP sessions on behalf of the Operators connected to the fabric.

This seems incomplete. Firstly, I'm assuming that it should start
"In the absence of notifications...". Secondly, if there are no
fault indications, what causes the Caretaker to cull sessions?
What's the trigger? Is the Caretaker supposed to know by magic
that layer 2 maintenance is planned?
...
>  In this scenario, BGP Session Culling is accomplished through the
>  application of a combined layer-3 and layer-4 packet filter deployed
>  in the switched fabric itself.

Please add "as described in the next sub-section" because otherwise
the reader can easily be confused.

> 3.2.1.  Packet Filter Considerations
>
>  The following considerations apply to the packet filter design:
>
>  o  The packet filter MUST only affect BGP traffic specific to the
>     layer-2 fabric, i.e. forming part of the control plane of the
>     system described, rather than multihop BGP traffic which merely
>     transits

That's a goal, but it doesn't tell me how to achieve the goal.
What packet signature tells me which packets are specific to the
fabric? I suspect this might overlap with the last bullet - if so,
you might consider re-ordering the bullets.
...
>  o  The packet filter MUST affect all relevant Address Family
>     Identifiers

Define "relevant". And in Appendix A, explain precisely how
the example prefixes are used: what makes them relevant? Are they
normally announced by BGP to all the IXP's BGP peers?

--

---

From: Matt Griswold <[email-masked]>
Date: Thu, 21 Sep 2017 00:13:53 +0000

> Minor Issues:

Graceful Shutdown is just one of multiple ways an Operator can
accomplish that.

> >  In the absence notifications from the lower layer (e.g. ethernet
> >   link down) consistent with the planned maintenance activities in a
> >  switched layer-2 fabric, the Caretaker of the fabric could choose
> >   to cull BGP sessions on behalf of the Operators connected to the
> >   fabric.  
> 
> "In the absence of notifications...".

Fixed!

> Secondly, if there are no fault indications, what causes the
> Caretaker to cull sessions? What's the trigger? Is the Caretaker
> supposed to know by magic that layer 2 maintenance is planned?

The Caretaker controls the layer 2 network, so yes, would do this as
part of the maintenance process.

> >  application of a combined layer-3 and layer-4 packet filter
> >   deployed in the switched fabric itself.  
> 

Added.

> Define "relevant".

Removed "relevant".

> And in Appendix A, explain precisely how the example prefixes are
> used: what makes them relevant? Are they normally announced by BGP to
> all the IXP's BGP peers?

They are the IXP LAN addresses, as explained above the examples.

Thanks for your review!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Sep 2017 14:19:29 +1200

> Graceful Shutdown is just one of multiple ways an Operator can

Understood, so perhaps it's a MAY not a SHOULD, but the text still
really only seems to say "do the right thing" without saying what
that is. To be honest the whole document is a bit like that - written
for members of the club who know how to run BGP, rather than for a
newcomer who wants to know how to run BGP.

> part of the maintenance process.

Again: not clear to a newcomer. 

> They are the IXP LAN addresses, as explained above the examples.

Yes, I realise that, but again you're assuming that the reader has
a complete picture in her mind. Maybe there's actually a need for
a scenario description in the Introduction, or at least a reminder
that in normal operation, paths through the fabric in question may be
known throughout the BGP realm, and the objective is to delete
those paths before starting maintenance.

> Thanks for your review!

You're welcome,
    Brian

---

From: Matt Griswold <[email-masked]>
Date: Thu, 21 Sep 2017 19:08:55 +0000

* Brian E Carpenter <[email-masked]> [170921 14:19 +1200]:
> Understood, so perhaps it's a MAY not a SHOULD

You're right, I will update it to MAY.

> but the text still really only seems to say "do the right thing"
> without saying what that is. To be honest the whole document is a bit
> like that - written for members of the club who know how to run BGP,
> rather than for a newcomer who wants to know how to run BGP.

That's really by design, the document is for people who know and run
BGP, I think putting too much basic BGP knowledge would make it
monotonous. Any ideas on how to meet in the middle?

> Again: not clear to a newcomer.

The updated language is:

  Throughout this document the "Caretaker" is defined to be in control
  of the lower layer network, while "Operators" directly administrate
  the BGP speakers.

I think that clears it up?

> >> used: what makes them relevant? Are they normally announced by BGP
> >>   to all the IXP's BGP peers?  
> > 

Again, that section is for IXP Caretakers so I don't think we need to
go into IXP operational details too much. Adding a brief scenario
paragraph should work, I'll write something up.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Sep 2017 08:23:48 +1200

Hi Matt,
> monotonous. Any ideas on how to meet in the middle?

Your suggestion below "Adding a brief scenario paragraph should work,
I'll write something up." would do it, I think. (I should add that my
perspective is that of someone who understands in theory how BGP is supposed
to work but has never personally practiced it - I'm not suggesting you
need to cover everything, just supply a few clues.)

> I think that clears it up?

Yes.

> paragraph should work, I'll write something up.

Great.

    Brian

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Sep 2017 17:12:41 -0400

> monotonous. Any ideas on how to meet in the middle?

Section 3.1.1 seems to be uniquely short.  I would favor adding a list
of the "multiple ways an Operator can accomplish that."  Even just
listing the *names* of the methods that might be used is a useful guide
-- a novice operator can use search engines to find tutorial information
regarding the various methods.

Dale

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 25 Sep 2017 11:13:45 +0100

> regarding the various methods.

Hi Dale,

At an IXP, it's fine for a client network operator to voluntarily shut
down their bgp sessions, as noted in section 3.1, and let traffic drain
off an interface.  This is the standard operational practice.

Graceful shutdown and Shutdown Communication could be used, but they're
new and are arguably overkill in many situations because for the most
part, network flaps are a part of life and people aren't interested in
what's going on in other peoples' networks unless it affects their own.

The point of the ID is that it's about session culling / involuntary
session drops initiated by the IXP Caretaker, and I think we need to
stay on topic in the draft, rather than get bogged down in tangential stuff.

Nick