RE: Quality Assurance Review of "Destination/Source Routing" - draft-lamparter-rtgwg-dst-src-routing-01

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:rtgwg-bounces@ietf.org] 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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg