On 8/21/15, 6:35 PM, "Antoni Przygienda" <[email protected]> wrote:
>Actually the section: > >" This means in particular that a router using the source address as > extra qualifier MUST NOT route packets based on a source/destination > route to a system that doesn't support source/destination routes (and > hence doesn't understand the route)." > >is sufficient but more than necessary and I would correct this. The full >condition is > >" a router using the source address as > extra qualifier (SD-capable) CAN route packets based on a >source/destination > route to a system B that doesn't support source/destination routes > IIF it can ensure that B's shortest path to destination does not >include an SD-router again > (i.e. the packet MUST NOT re-enter the domain of SD-capable routers)" Right, with the obvious case being where the adjacent non-SD-capable router does does an Elvis imitation - “Return to Sender”. > >" Hop-by-hop routing with node-dependent topology information", V Fayet, >Denis A Khotimsky, T. Przygienda, 1999/3/21, Conference INFOCOM'99. An oldie but a goodie ;^) Thanks, Acee > > >thanks > >--- tony > >An idealist believes that the short run doesn’t count. A cynic believes >the long run doesn’t matter. A realist believes that what is done or left >undone in the short run determines the long run. ~~~ Sidney J. Harris > >> -----Original Message----- >> From: rtgwg [mailto:[email protected]] On Behalf Of Acee Lindem >>(acee) >> Sent: Friday, August 21, 2015 2:51 PM >> To: Routing Directorate; Routing WG; David Lamparter >> Subject: Quality Assurance Review of "Destination/Source Routing" - >>draft- >> lamparter-rtgwg-dst-src-routing-01 >> >> Hello David, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >>drafts as >> they pass through WG adoption, IETF last call, and IESG review, and >>sometimes >> on special request. The purpose of the review is to provide assistance >>to the >> Routing ADs. For more information about the Routing Directorate, please >>see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, >>it would >> be helpful if you could consider them along with any other IETF Last >>Call >> comments that you receive, and strive to resolve them through >>discussion or by >> updating the draft. >> >> >> Since this is an initial QA review, I intend to focus on the main area >>that require >> discussion in the WG. >> >> Document: draft-lamparter-rtgwg-dst-src-routing-01 >> Reviewer: Acee Lindem >> Review Date: 21 Aug 2015 >> Intended Status: Standards Track >> >> Summary: >> >> I believe the document is ready for Working Group adoption and further >> discussion. >> There are a number of issues that needed to be resolved as part of the >>normal >> IETF process. >> >> Issues for Resolution: >> >> Section 3.1: Ultimately we need to choose a variant for recursive >>route >> resolution. I believe we should choose one that simpler than >>variant 4. >> The reason being that BCP 38 is normally not a factor for use >>cases where >> complex recursive resolution is required. However, this is a >>topic for >> WG discussion. >> >> Section 3.2: Again, I believe one option needs to be selected for uRPF >> filtering. I believe it should be pointed out that both >>the source >> and destination are reversed in the uRPF lookup. >> >> Section 3.3: I don’t see why multicast is not applicable since there >>are >> (S,G) >> multicast routes (where the source is always /128). >> >> Section 4: Rather than expressing the constraints in terms of >>forwarding, they >> should be expressed in terms of route installation and >>more onus >> should be placed on the routing protocol. >> >> Nits: I have some suggested editorial changes to the draft that I will >>unicast to >> David. >> >> Thanks, >> Acee >> >> >> >> >> >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
