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

["Acee Lindem (acee)" <[e-mail]>]

On 8/21/15, 6:35 PM, "Antoni Przygienda" <[e-mail]>
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:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtgwg