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

[Bob Fink]

Jim,

Thanks for your comments.

The draft is intended to replace the current RFC 2546 on 6bone routing
practice which is informational.

Bob

===
At 01:04 AM 7/22/99 -0400, Jim Bound wrote:
>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
>