INPUT draft-ietf-ngtrans-harden-00.txt

[Jim Bound]

Hi Bob,

>If we agree in prinicpal on the draft, and each pTLA implements it in
>general, with the goal of a production quality network, we will start to
>identify (and force changes on) the unreliable pTLAs.

I have spent the evening with the draft on hardening and have given this
a lot of thought and just read Steve's mail to the IPng list.  I think
we need to move forward with the draft, whatever that means, are we
talking BCP or Informational?

>I believe that a quality production backbone environment is what we are
>after now, with most of the testing occurring at sites. 

I agree and I can't believe anyone can live without sending non-Provider
upstream advertisements for now as stated in the harden draft.  I think
this is fine for now.

>We have had little or no comment on Rob's Hardening draft to date, so I
>would encourage everyone to read it, make comments and improvements to it
>(to the list please).

>	<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt>

I think its an excellent piece of work and document to read.  Very well
structured and very clear on what the rules are so all the pTLAs and the
pNLAs should be pretty clear on what filtering means.  If one does not
know what lead and filltering means then they should not be implementing
the draft most likely.  So it might be good up front to say the
background a reader should have to read this draft, if customer X picks
it up because they are reading all the IPv6 specs (and some do) they
might want a hint that they should get their network operator folks to
parse this spec if they are not of that discipline.

Its intuitive to me being around IPv6 and the GSE meetings and
discussions and I have a bias to favor |absolute| aggregation as I did
in those discussions.  But it might be nice to add a paragraph on what
that means as some of the intense discussion was willing to give up
aggregation to solve a need rather quickly IMO.  

My head jerked on not advertising link-local addresses in an IGP at first 
because we need to survive renumbering in an IGP as we test that function.  
But we do permit adv's of sitelocal addresses  and that will work too.  
For the case where all the prefixes are really dead at a site and new
ones were not provided during the renumbering phase fast enough through
some SNAFU or something via administration at the border routers.  In
that case sitelocal addresses will be very useful.

I have not looked at the OSPFv6 stuff for awhile but it used to provide
linklocal addresses to adjacent nodes.  So I am not sure this applies or
still the case as OSPFv6 was not in the hardening draft.  But I will
check eventually.

I also think the authors did a good job of focusing on where this
applies.

My input is its fine and we should move on here.

Good Job to you and the authors,
/jim