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)" " Hop-by-hop routing with node-dependent topology information", V Fayet, Denis A Khotimsky, T. Przygienda, 1999/3/21, Conference INFOCOM'99. 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
