Fred, > Have my responses wrt your comments cleared up the concerns > to the point that this document can be considered as a 6man > working group item to update RFC4861?
No, we would have to see more support from the working group before it could be considered a working group document. You could ask for a slot at the next IETF meeting if you wish. Bob > Thanks - Fred > [email protected] > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Templin, Fred L >> Sent: Wednesday, November 25, 2009 8:47 AM >> To: Bob Hinden; Thomas Narten >> Cc: [email protected] >> Subject: RE: New draft on "Stub Router Advertisements in IPv6 >> NeighborDiscovery" >> >> Hi Bob, >> >>> -----Original Message----- >>> From: Bob Hinden [mailto:[email protected]] >>> Sent: Tuesday, November 24, 2009 2:52 PM >>> To: Thomas Narten >>> Cc: Bob Hinden; Templin, Fred L; [email protected] >>> Subject: Re: New draft on "Stub Router Advertisements in IPv6 Neighbor >>> Discovery" >>> >>> >>> On Nov 24, 2009, at 11:37 AM, Thomas Narten wrote: >>> >>>> Fred, >>>> >>>> Can you summarize what problem this draft is aimed at solving? What >>>> is the motivation for this draft? (I've read it, but I don't >>>> understand what the benefit of this approach is or what problem it >>>> solves.) >>>> >>> >>> In the Introduction says: >>> >>> A stub router is any router that attaches stub networks to the link, >>> but does not itself attach the link to a provider network. Here, a >>> "stub network" could be as simple as a small collection of IPv6 >>> links, or as large as a complex corporate enterprise network. Stub >>> routers are said to be "non-authoritative" for the link, since they >>> cannot themselves provide forwarding services for packets emanating >>> from their stub networks without using another router on the link as >>> a transit. >>> >>> I disagree with this and don't think that a router that is connected to an >>> ISP is inherrently >> higher >>> priority than other routers. >> >> I don't understand this comment. The entity I am calling >> "stub router" is simply trying to find a way to forward >> packets on to their final destination using the best >> possible exit router. There is nothing said or implied >> about "priority". >> >>> This is definitely not true in enterprise networks. >> >> This is actually all about enterprise networks; in some ways, >> an ISP network can be seen as just a special case of an >> Enterprise network. >> >>> We have other ways of doing this in a more general fashion such as RFC4191 >>> "Default Router >>> Preferences and More-Specific Routes". >> >> Exactly; this document very much expects that stub routers >> will advertise RFC4191 more-specific routers. >> >>> I don't see any need to define "stub routers" and see a lot >>> of harm doing so. For example, in an enterprise, routing may be setup to >>> keep the traffic inside >> of >>> the enterprise for a long as possible and not use the local ISP connection. >>> The inter-enterprise >>> links might be much faster. >> >> The way it works is that the stub router may have a default >> route but may not have a more-specific route to the destination >> inside the enterprise. It then sends the packet to a default >> router which hairpins it back to a router within the enterprise >> that aggregates the more-specific route, but also sends a >> redirect back to the stub router that originated the packet. >> The stub router then sends an RA to the enterprise router >> that aggregates the more-specific route, then subsequent >> packets flow through the more-specific route and eliminate >> the dogleg. >> >> So yes; packets stay inside the enterprise and do not go out >> the local ISP connection only to come back in again. >> >> Fred >> [email protected] >> >>> Bob >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
