Shepherd writeup
rfc8043-12

ISE write-up for: draft-sarikaya-6man-sadr-overview-11

Abstract:
  "This document presents the source address dependent routing (SADR)
   problem space from the host perspective.  Both multihomed hosts and
   hosts with multiple interfaces are considered.  Several network
   architectures are presented to illustrate why source address
   selection and next hop resolution in view of source address dependent
   routing is needed.

   The document is scoped on identifying a set of scenarios for source
   address dependent routing from the host perspective and analyze a set
   of solutions to mitigate encountered issues.  The document does not
   make any solution recommendations.

This draft has no IANA Considerations.

This draft was discussed in the 6man WG. It was an early proposal, the
working group used it for discussion and finally came up with
ietf-6man-multi-homed-host, which was the WGs agreed way of solving
this problem.

Brian Carpenter and Fred Baker commented on this draft for me;
both pointed out that the WG were antagonistic towards it.
It was also reviewed by Pierre Pfister, his comments are appended
below.

I have also pointed out to the authors that for it to be published,
it needed some changes that 
 - it documents sadr discussions within 6man,
 - it does not recommend any particular solution and
 - it clearly states that it presents alternate approaches 
     to that agreed on by the WG. 

They have made the changes suggested by the reviewers and the ISE.

- - - - - - -

Pierre Pfister's comments

This draft is a problem statement document for IPv6 multi-prefix
environments.  It was a very useful document at the time of the
discussion, as it was used as basic material for solution documents
(chronologically):
  sarikaya-6man-next-hop-ra
  pfister-6man-sadr-ra
  sarikaya-6man-sadr-ra
  baker-6man-multi-homed-host -> ietf-6man-multi-homed-host

Proposed solutions implying on-wire protocol changes (all but the last
one) were rejected by the working group, while the final solution was
described by Brian Carpenter and drafted by Fred Baker, upon request
of the working group chairs.

IMHO, the first reason why this draft was rejected from 6man was its
association with sarikaya-6man-next-hop-ra, which was highly
controversial. Although the problem statement was reasonable, some WG
participants would rather just reject the problem statement by fear of
the single proposed solution. Which is why I decided to come-up with
another solution candidate (pfister-6man-sadr-ra). This draft was well
received by the working group, but later pushed-back due to its
proposed protocol changes. The WG chairs then asked Brian and Fred to
come-up with a solution which would not imply protocol changes.

Therefore, this whole series of drafts ended up being a fairly slow
way of making the working group look at the problem itself. Which
leads to the second reason why this draft is now rejected. It did its
job. It is not necessary anymore. It was certainly useful at the time
of the discussion. But the WG is now reaching consensus on a solution
and cannot spend the additional time to publish
sarikaya-6man-next-hop-ra as an RFC (That would still require a lot of
iterations and WG time).

I would humbly suggest to the authors that they focus on the already
adopted solution document (ietf-6man-multi-homed-host) and see if it
correctly solves the different issues they have identified, and if
not, that they participate in the discussions to improve it.

- - - - -
Back