Subject: draft-ietf-v6ops-routing-guidelines-00.txt

From: Fred Baker <[email-masked]>
Date: Sat, 9 Sep 2006 05:17:04 +0800

So Marc posted the WG version of his document. Would folks please  
read it and comment to the list?

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Sep 2006 08:19:30 +0930

Hi,

On Sat, 9 Sep 2006 05:17:04 +0800

> read it and comment to the list?

2.4.  Site-scoped Unicast
~~~~~~~~~~~~~~~~~~~~~~~~~

"However, it may be advertised in an EGP between two
   networks sharing a private interconnect, but must not be advertised
   outside the scope of these networks.  When advertised in an EGP,
   these routes should be of length /48."

Worth adding a bit of text (maybe just one sentence) to include or
cover the SP, IGP for loopbacks, EGP for everything else internal
routing model as an acceptable case for ULA/EGP distribution ? I think
it is sort of covered, although I don't think people commonly would
consider an LB-IGP/EGP model to be internally multiple networks with
private interconnect.

2.5.  Global Unicast
~~~~~~~~~~~~~~~~~~~~
"The global unicast routes (2000::/3)[RFC4291] may be advertised in an
   IGP or EGP.  A minimal EGP routing policy should filter out routes
   that exceed a maximum length.  Determining the maximum length of a .."

I'd suggest starting a new paragraph at the second sentence, as that
sentence is the beginning text covering specifics of the EGP case.

2.6.  Default Route
~~~~~~~~~~~~~~~~~~~
"The default unicast route (::) may be advertised in an IGP.  In an
   EGP, it may be only advertised to the downstream but must not be
   advertised in the core."

I think the SP LB-IGP/EGP model would be a possible to exeception to
this, in the sense that "core" would probably be considered by most
people to be the core of the local network, rather than the Internet
"core". Maybe that could be clarified.

General Comment
~~~~~~~~~~~~~~~

There seem to be quite a number of uncapitalised "shoulds" and "musts"
in this document. I realise that this is probably appropriate for this
document, as it is not a specification document. However, where proper
"MUSTS" and "SHOULDS" do exist in the specification documents, I think
there could be some value in providing references to them, and maybe
quoting the specific text.

Regards,
Mark.

---

From: Kevin Loch <[email-masked]>
Date: Fri, 08 Sep 2006 21:05:28 -0400

> 2.6.  Default Route

Any network accepting :: would be by definition a "downstream" and such
mistakes tend to be rapidly self-correcting (at least in v4).

Here is an alternative paragraph:

"The default unicast route (::) may be advertised in an IGP or EGP.  It
MUST NOT be advertised in an EGP unless it has been requested by the
recipient.

Here are some ideas that might be useful in section 2:

"Routes that a network is unable or unwilling to forward packets towards 
MUST NOT be advertised in an EGP." (black holing)

"Global unicast routes MUST NOT be originated by and then advertised
in an EGP when not authorized by the registered delegate of the address
space." (hijacking)

- Kevin

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Sep 2006 12:28:03 +0930

Hi Kevin,

On Fri, 08 Sep 2006 21:05:28 -0400

> MUST NOT be advertised in an EGP unless it has been requested by the

While it's probably starting to get into pedantry, here's the scenario
I'm thinking of. I work for a smaller SP, where we have two upstream
transit providers, one primary, one backup. We're receiving full route
tables from both of them. However, internally, and we're moving mainly
to an IGP-LB/EGP everything else model, we distribute the full routes
from the primary transit into our internal transit routers, and then
generate a default towards the backup, so we have a default in our EGP,
that's very rarely if ever used, excepting if our primary transit
provider loses visibility to any parts of the Internet. Distributing
the backup link's routes into our network, even just to our primary
border router, gives the longest match rule a chance to override
LOCAL_PREF to our primary. A default injected into our EGP makes our
backup link an absolute last resort.

So, as per your suggested paragraph above, for our network, we're both
the originator and the recipient of the default, or we're downstream of
ourselves :-)

Regards,
Mark.