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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 21 Aug 2015 21:51:03 +0000

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

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 21 Aug 2015 22:35:27 +0000

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-masked]] 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,
> 
> 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.
> 
> There are a number of issues that needed to be resolved as part of the normal
> IETF process.
> 
> Issues for Resolution:
> 
>       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.
> 
>                filtering. I believe it should be pointed out that both the source
>   Section 4: Rather than expressing the constraints in terms of forwarding, they
>              should be expressed in terms of route installation and more onus
> Nits: I have some suggested editorial changes to the draft that I will unicast to
> David.
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 21 Aug 2015 23:22:08 +0000

>  (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
>
>>drafts as
>>unicast to

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 21 Aug 2015 23:26:13 +0000

> Right, with the obvious case being where the adjacent non-SD-capable router
> does does an Elvis imitation - “Return to Sender”.

 [Tony saiz:]  Which leads to "heartbreak hotel" ... 

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

[Tony saiz:] You want an oldie ?

Bacon, Francis (1605). "The Advancement of Learning" 6. London. pp. Chapter 1.

That's actually first mention in Western thought of what we call simply "binary system" ;-) 

Now back from shaping electrons into thought transmission (email) to shaping electrons into thought templates (code) ;-) 

-- tony