Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

[Alexandre Petrescu <[e-mail]>]

Le 21/11/2018 à 16:27, Templin (US), Fred L a écrit :
> HI Alex,
> 
>> -----Original Message-----
>> From: ipv6 [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
>> Sent: Wednesday, November 21, 2018 5:55 AM
>> To: [e-mail]
>> Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
>>
>>
>>
>> Le 18/11/2018 à 19:16, Ole Troan a écrit :
>>> Naveen,
>>>
>>> I don’t understand the problem description below, nor why it would
>>> require a different solution than any of those we already have.
>>
>> For my part, I think the problem is important in that we do not have a
>> solution at this time.
>>
>> We do not have a solution of simultaneous Prefix Delegation and Default
>> Route that is widely available on many platforms from small to large.
> 
> Our implementation of DHCPv6-ND is publicly available and runs on really
> any platforms small to large. It is linux-based, and so can run anywhere
> linux can run.

In theory yes, and I am wondering whether there is a package of 
DHCVPv6-ND for openwrt?  I am not able to build packages, and on small 
openwrt platforms it is almost impossible to compile natively.

And also, before I plan into using it, I wont commit any effort if it's 
not a standard.

>> What one may have running ok Prefix Delegation (DHCPv6 Server) and
>> Default Route (ICMPv6 Router Advertisement daemon) is a PC that is able
>> to run huge software on its powerful Intel processor over Ethernet at 1GBps.
> 
> Powerful processers aren't needed - we run our code on Android cellphones, e.g.,

Yes.

Alex
> 
> Thanks - Fred
> 
>> Alex
>>
>>>
>>> Does anyone else understand and can translate?
>>>
>>> Cheers
>>> Ole
>>>
>>> On 18 Nov 2018, at 18:51, Naveen Kottapalli <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> Hello Ole,
>>>>
>>>> Please find comments inline.
>>>>
>>>> Thanks & Regards,
>>>> Naveen
>>>>
>>>>
>>>> On Sat, 17 Nov 2018, 23:05 Ole Troan <[e-mail]
>>>> <mailto:[e-mail]> wrote:
>>>>
>>>>      Hi Naveen,
>>>>
>>>>      While the purpose of the proposal might be obvious to you, it
>>>>      might not be for the rest of us.
>>>>
>>>>      Can you please describe the problem you are trying to solve?
>>>>
>>>> Naveen] Below is the description of problems that are being tried to
>>>> solve:
>>>> 1. Solicit any prefix of pre configured length using RS / RA. We can
>>>> have it implemented in both of our CPE and router. But the solution
>>>> wouldn't be compliant or interoperable.
>>>> 2. Some of the prefixes that were assigned to hosts by our router are
>>>> lingering though the host interface is brought down and the prefix
>>>> isn't used anymore.
>>>> 3. Hosts during mobility are losing the existing ongoing traffic
>>>> sessions due to prefix change. This is because when the gateway
>>>> detects mobility to a different tunnel the existing session will be
>>>> cleared and a new session entry is created. During this process there
>>>> is no guarantee that the same prefix will be assigned back to the device.
>>>>
>>>>
>>>>      Can you please describe how existing solutions do not solve your
>>>>      problem?
>>>>
>>>> Naveen] All the prefixes were assigned using SLAAC and there is no
>>>> solution till date to solicit or release a specific prefix. It's not
>>>> just specific prefix, but the only existing solution to get a non /64
>>>> prefix is only through DHCPv6, which can't be done in the CPE.
>>>>
>>>>
>>>>      Note, “PD is not supported in SLAAC” is not the problem
>>>>      description I am hoping for.
>>>>
>>>> Naveen] Unfortunately yes for the use case where prefix length less
>>>> than 64. I see this as more like soliciting a prefix pool.  All the
>>>> host / CPE does is soliciting a prefix of desired length by including
>>>> existing options in RS.  But why a host or CPE soliciting a prefix
>>>> (which is already done by them) without introducing new message types
>>>> or options should be a problem?
>>>>
>>>>
>>>>      Cheers
>>>>      Ole
>>>>
>>>>      On 17 Nov 2018, at 18:16, Naveen Kottapalli
>>>>      <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>>      Hello Ole,
>>>>>
>>>>>      Following are the things that am trying to solve.
>>>>>
>>>>>      1. I can't sell oranges when apples are asked for.
>>>>>      2. Improving SLAAC as a protocol by providing options like
>>>>>      soliciting a prefix of certain length; releasing or declining a
>>>>>      prefix (this is equally more important for the protocol
>>>>>      perspective itself as a prefix is an important resource for the
>>>>>      router).
>>>>>
>>>>>      Please let me know which of the above points you think are not valid.
>>>>>
>>>>>      Thanks & Regards,
>>>>>      Naveen
>>>>>
>>>>>
>>>>>      On Fri, 16 Nov 2018, 00:21 Ole Troan <[e-mail]
>>>>>      <mailto:[e-mail]> wrote:
>>>>>
>>>>>          Naveen,
>>>>>
>>>>>          Let me quote from RFC1958:
>>>>>
>>>>>          3.2 If there are several ways of doing the same thing, choose
>>>>>          one.
>>>>>             If a previous design, in the Internet context or
>>>>>          elsewhere, has
>>>>>             successfully solved the same problem, choose the same
>>>>>          solution unless
>>>>>             there is a good technical reason not to.  Duplication of
>>>>>          the same
>>>>>             protocol functionality should be avoided as far as
>>>>>          possible, without
>>>>>             of course using this argument to reject improvements.
>>>>>
>>>>>
>>>>>          What problem are you trying to solve with your proposal which
>>>>>          isn’t covered by existing solutions?
>>>>>
>>>>>          Cheers,
>>>>>          Ole
>>>>>
>>>>>          > On 15 Nov 2018, at 18:17, Naveen Kottapalli
>>>>>          <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>          >
>>>>>          > Hello all,
>>>>>          >
>>>>>          > To be honest, there is no intention to compete with other
>>>>>          existing protocols.  I see that SLAAC has got some gaps w.r.t
>>>>>          the functionality and the same is covered in the draft.  And
>>>>>          I see the cases where this draft solves real time problems
>>>>>          where the existing bridge itself is not usable.
>>>>>          >
>>>>>          > @Ole / @Fred / others: If a device soliciting something
>>>>>          from the router using RS is considered as intruding into
>>>>>          other territory, IMHO it's very unfair way of evaluating.
>>>>>          For that matter whether a PIO is included in RS or not, a
>>>>>          device is soliciting the information from router.  When this
>>>>>          draft solves the problems it cannot be put down just by
>>>>>          saying it as a redundant to another standard, while actually
>>>>>          it is not.
>>>>>          >
>>>>>          > If a device soliciting required information using the
>>>>>          existing protocol standards without new message types or
>>>>>          option types or flags itself is treated as a wrapper or
>>>>>          redundant for other standards, aren't there overlapping
>>>>>          options in both SLAAC and DHCPv6 that can be sent to the
>>>>>          devices?  For that matter what about the complete SLAAC and
>>>>>          DHCPv6?  Am I wrong in quoting that both DHCPv6 and SLAAC are
>>>>>          redundant protocols to each other?
>>>>>          >
>>>>>          > I also agree that multiple attempts were made by many
>>>>>          respected members of the forum to bring in similar changes to
>>>>>          whatever my current draft suggested.  But not sure why they
>>>>>          couldn't become standards.  It shows the need of devices that
>>>>>          are looking for a solution and am sure people keep inventing
>>>>>          round-about solutions for the same.
>>>>>          >
>>>>>          > If someone sees a problem in mentioning DHCPv6 inside the
>>>>>          draft, please suggest another change for that.
>>>>>          >
>>>>>          > I understand that the forum has finite reservations on
>>>>>          providing extensions to existing protocols.  But I request
>>>>>          the forum and WG chairs to evaluate this draft fairly and
>>>>>          technically.
>>>>>          >
>>>>>          > Yours,
>>>>>          > Naveen.
>>>>>          >
>>>>>          >
>>>>>          > On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter
>>>>>          <[e-mail]
>>>>>          <mailto:[e-mail]>> wrote:
>>>>>          > in line..
>>>>>          > On 2018-11-14 09:34, Templin (US), Fred L wrote:
>>>>>          > > Hi Brian,
>>>>>          > >
>>>>>          > >> -----Original Message-----
>>>>>          > >> From: Brian E Carpenter
>>>>>          [mailto:[e-mail]
>>>>>          <mailto:[e-mail]>]
>>>>>          > >> Sent: Tuesday, November 13, 2018 11:37 AM
>>>>>          > >> To: Templin (US), Fred L <[e-mail]
>>>>>          <mailto:[e-mail]>>; Ole Troan
>>>>>          <[e-mail] <mailto:[e-mail]>>
>>>>>          > >> Cc: v6ops list <[e-mail] <mailto:[e-mail]>>;
>>>>>          6man WG <[e-mail] <mailto:[e-mail]>>
>>>>>          > >> Subject: Re: [v6ops] New Version Notification for
>>>>>          draft-naveen-slaac-prefix-management-00.txt
>>>>>          > >>
>>>>>          > >> On 2018-11-14 07:52, Templin (US), Fred L wrote:
>>>>>          > >>> HI Ole,
>>>>>          > >>>
>>>>>          > >>>> -----Original Message-----
>>>>>          > >>>> From: Ole Troan [mailto:[e-mail]
>>>>>          <mailto:[e-mail]>]
>>>>>          > >>>> Sent: Tuesday, November 13, 2018 10:36 AM
>>>>>          > >>>> To: Templin (US), Fred L <[e-mail]
>>>>>          <mailto:[e-mail]>>
>>>>>          > >>>> Cc: Naveen Kottapalli <[e-mail]
>>>>>          <mailto:[e-mail]>>; 6man WG <[e-mail]
>>>>>          <mailto:[e-mail]>>; v6ops list <[e-mail]
>>>>>          <mailto:[e-mail]>>
>>>>>          > >>>> Subject: Re: [v6ops] New Version Notification for
>>>>>          draft-naveen-slaac-prefix-management-00.txt
>>>>>          > >>>>
>>>>>          > >>>>
>>>>>          > >>>>
>>>>>          > >>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L
>>>>>          <[e-mail]
>>>>>          <mailto:[e-mail]>> wrote:
>>>>>          > >>>>>
>>>>>          > >>>>> Ole,
>>>>>          > >>>>>
>>>>>          > >>>>>> -----Original Message-----
>>>>>          > >>>>>> From: Ole Troan [mailto:[e-mail]
>>>>>          <mailto:[e-mail]>]
>>>>>          > >>>>>> Sent: Tuesday, November 13, 2018 9:38 AM
>>>>>          > >>>>>> To: Templin (US), Fred L <[e-mail]
>>>>>          <mailto:[e-mail]>>
>>>>>          > >>>>>> Cc: Naveen Kottapalli <[e-mail]
>>>>>          <mailto:[e-mail]>>; 6man WG <[e-mail]
>>>>>          <mailto:[e-mail]>>; v6ops list <[e-mail]
>>>>>          <mailto:[e-mail]>>
>>>>>          > >>>>>> Subject: Re: [v6ops] New Version Notification for
>>>>>          draft-naveen-slaac-prefix-management-00.txt
>>>>>          > >>>>>>
>>>>>          > >>>>>> Fred,
>>>>>          > >>>>>>
>>>>>          > >>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L
>>>>>          <[e-mail]
>>>>>          <mailto:[e-mail]>> wrote:
>>>>>          > >>>>>>>
>>>>>          > >>>>>>> Hi Ole,
>>>>>          > >>>>>>>
>>>>>          > >>>>>>>> -----Original Message-----
>>>>>          > >>>>>>>> From: Ole Troan [mailto:[e-mail]
>>>>>          <mailto:[e-mail]>]
>>>>>          > >>>>>>>> Sent: Monday, November 12, 2018 11:57 PM
>>>>>          > >>>>>>>> To: Templin (US), Fred L
>>>>>          <[e-mail] <mailto:[e-mail]>>
>>>>>          > >>>>>>>> Cc: Naveen Kottapalli <[e-mail]
>>>>>          <mailto:[e-mail]>>; 6man WG <[e-mail]
>>>>>          <mailto:[e-mail]>>; v6ops list <[e-mail]
>>>>>          <mailto:[e-mail]>>
>>>>>          > >>>>>>>> Subject: Re: [v6ops] New Version Notification for
>>>>>          draft-naveen-slaac-prefix-management-00.txt
>>>>>          > >>>>>>>>
>>>>>          > >>>>>>>> Fred,
>>>>>          > >>>>>>>>
>>>>>          > >>>>>>>>>>> I agree to some extent that DHCPv6 is a format
>>>>>          on wire.  But am sure it would consume more resources at
>>>>>          router to
>>>>>          > >> support
>>>>>          > >>>>>>>> DHCPv6
>>>>>          > >>>>>>>>>> as a whole along with SLAAC.
>>>>>          > >>>>>>>>>>
>>>>>          > >>>>>>>>>> Prefix delegation is quite different from SLAAC.
>>>>>          > >>>>>>>>>> Regardless this is water under the bridge. Since
>>>>>          2003.
>>>>>          > >>>>>>>>>
>>>>>          > >>>>>>>>> So I can understand this comment, the water under
>>>>>          the bridge refers to the
>>>>>          > >>>>>>>>> selection of DHCPv6 PD as the protocol for prefix
>>>>>          delegation. Is that what
>>>>>          > >>>>>>>>> you were meaning to say?
>>>>>          > >>>>>>>>
>>>>>          > >>>>>>>> Sure.
>>>>>          > >>>>>>>
>>>>>          > >>>>>>> OK, so you are saying that DHCPv6 is *the* chosen
>>>>>          protocol for Prefix Delegation
>>>>>          > >>>>>>> and there shall be no alternate IPv6 ND-based
>>>>>          protocol in addition to that. I don't
>>>>>          > >>>>>>> mind a statement like that, but would the community
>>>>>          agree with it?
>>>>>          > >>>>>>
>>>>>          > >>>>>> In general we as a community try to avoid providing
>>>>>          multiple equivalent solutions to the same problem. Sometimes
>>>>>          we fail.
>>>>>          > >>>>>
>>>>>          > >>>>> But, do you assert that DHCPv6 is the one and only
>>>>>          solution?
>>>>>          > >>>>
>>>>>          > >>>> I am saying that solving a problem that is already
>>>>>          solved is a waste of time and resources.
>>>>>          > >>>> Now if you install could solve a problem where we
>>>>>          don’t have a satisfactory solution...
>>>>>          > >>>
>>>>>          > >>> OK, then I will say it - DHCPv6 is the one and only
>>>>>          solution to Prefix Delegation
>>>>>          > >>> *in cases where a dynamic Prefix Delegation protocol is
>>>>>          needed*. (I add this
>>>>>          > >>> qualification because 'draft-templin-v6ops-pdhost'
>>>>>          lists other non-protocol
>>>>>          > >>> alternatives for a node receiving a prefix delegation.)
>>>>>          > >>
>>>>>          > >> I'm not disagreeing that DHCPv6-PD is the current IETF
>>>>>          solution, but there
>>>>>          > >> are some subtleties:
>>>>>          > >>
>>>>>          > >> 1) Since there are no protocol police, you can't
>>>>>          actually stop people
>>>>>          > >> using some other method of prefix delegation, which
>>>>>          would simply appear
>>>>>          > >> to be an out-of-band or "manual" mechanism as far as the
>>>>>          IETF protocols
>>>>>          > >> are concerned.
>>>>>          > >
>>>>>          > > Right, I wanted to be careful in how I worded my message
>>>>>          based on our
>>>>>          > > knowledge of other non-router methods (including anima)
>>>>>          which we
>>>>>          > > captured in 'draft-templin-v6ops-pdhost'. From that document:
>>>>>          > >
>>>>>          > > "10.  Prefix Delegation Services
>>>>>          > >
>>>>>          > >    Selection of prefix delegation services must be
>>>>>          considered according
>>>>>          > >    to specific use cases.  An example service is that
>>>>>          offered by DHCPv6
>>>>>          > >    [RFC3633].  An alternative service based on IPv6 ND
>>>>>          messaging has
>>>>>          > >    also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit].
>>>>>          > >
>>>>>          > >    Other, non-router, mechanisms may exist, such as
>>>>>          proprietary IPAMs,
>>>>>          > >    [I-D.ietf-anima-prefix-management] and
>>>>>          > >    [I-D.sun-casm-address-pool-management-yang]."
>>>>>          > >
>>>>>          > > Does this still ring true, or do we need to make some
>>>>>          adjustments based
>>>>>          > > on these recent discussions?
>>>>>          >
>>>>>          > I think it's still true, although as Ole and I said,
>>>>>          proposals such as
>>>>>          > anima-prefix-management, CASM amd HNCP do recognize
>>>>>          DHCPv6-PD as the
>>>>>          > boundary mechanism. On the other hand,
>>>>>          naveen-slaac-prefix-management
>>>>>          > intentionally competes with DHCPv6-PD, which is a different
>>>>>          discussiion..
>>>>>          >
>>>>>          >     Brian
>>>>>          >
>>>>>          > >
>>>>>          > > Thanks - Fred
>>>>>          > >
>>>>>          > >> 2) We did think about this question a bit while developing
>>>>>          > >>
>>>>>          https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07
>>>>>          > >> (which is approved and in the RFC Editor queue waiting
>>>>>          for missing
>>>>>          > >> references). The appendix A2 is supposed to show how a
>>>>>          prefix
>>>>>          > >> management system would interface to DHCPv6-PD at the
>>>>>          edges of an
>>>>>          > >> autonomic network. I think you'd find something similar
>>>>>          in any sort
>>>>>          > >> of coordinated prefix management scheme.
>>>>>          > >>
>>>>>          > >> 3) A similar situation arises in HNCP:
>>>>>          > >> https://tools.ietf..org/html/rfc7788#section-6.3.4
>>>>>          <https://tools.ietf.org/html/rfc7788#section-6.3.4>
>>>>>          > >>
>>>>>          > >>    Brian
>>>>>          > >>
>>>>>          > >>>
>>>>>          > >>>>>>>> The value proposition of something new, has to be
>>>>>          different than “just different wrapping”.
>>>>>          > >>>>>>>
>>>>>          > >>>>>>> By "different wrapping", are you are talking about
>>>>>          non-DHCPv6 protocol proposals?
>>>>>          > >>>>>>> If not, if you mean to say that the idea of
>>>>>          including a DHCPv6 option in RS/RA messages
>>>>>          > >>>>>>> is "just a different wrapping", then that is not
>>>>>          entirely true. By including both the IPv6
>>>>>          > >>>>>>> ND and DHCPv6 functions in a single message
>>>>>          exchange, there are fewer messages
>>>>>          > >>>>>>> and fewer round trips. That in itself is interesting.
>>>>>          > >>>>>>
>>>>>          > >>>>>> Don’t really see that as interesting. You will not
>>>>>          save a round trip, since the two protocols don’t depend on
>>>>>          each other.
>>>>>          > >>>>>
>>>>>          > >>>>> This gets us back to the M&O bits where there is a
>>>>>          cross-dependence between the two
>>>>>          > >>>>> protocols. Historically, you are supposed to wait
>>>>>          until the RS/RA exchange and check the
>>>>>          > >>>>> M&O bits before invoking DHCPv6 (two round trips).
>>>>>          Are you saying that that is no longer
>>>>>          > >>>>> the case? Have we declared that the M&O bits are
>>>>>          deprecated?
>>>>>          > >>>>
>>>>>          > >>>> DHCPv6 PD has never had any dependency on the M&O
>>>>>          bits. PD is a protocol between routers.
>>>>>          > >>>
>>>>>          > >>> OK, then let's ignore the M&O bits - I am fine with that.
>>>>>          > >>>
>>>>>          > >>>>> It is also important that there are fewer messages -
>>>>>          two instead of four. That matters
>>>>>          > >>>>> a great deal on low end links.
>>>>>          > >>>>
>>>>>          > >>>> I would like to see the maths behind that.
>>>>>          > >>>> Use header compression then.
>>>>>          > >>>
>>>>>          > >>> It isn't only a question of how many bytes - the
>>>>>          question is moreso how
>>>>>          > >>> many channel accesses are necessary. On some links,
>>>>>          sending everything in
>>>>>          > >>> a single channel access is less prone to collisions
>>>>>          than requiring multiple
>>>>>          > >>> channel accesses.
>>>>>          > >>>
>>>>>          > >>> Think about CB radio - after you say "breaker, breaker
>>>>>          one-nine" you get
>>>>>          > >>> to say as much as you want (within reason) without
>>>>>          having to undergo
>>>>>          > >>> channel contention multiple times. (That is not to say
>>>>>          that common data
>>>>>          > >>> links function the same as CB radio, but they do have
>>>>>          their CSMA protocols
>>>>>          > >>> for making sure they don't step on someone else's
>>>>>          transmission.)
>>>>>          > >>>
>>>>>          > >>>>>> Different wrapping. As in exactly same protocol
>>>>>          semantics, just options in ND instead of DHCP.
>>>>>          > >>>>>
>>>>>          > >>>>> No, the options in RS/RA are exactly DHCPv6 - they
>>>>>          are not different than DHCPv6.
>>>>>          > >>>>> That is the whole point.
>>>>>          > >>>>
>>>>>          > >>>> Right. I am sorry but I struggle getting why that is
>>>>>          valuable. ND is also a one to many protocol. That’s not
>>>>>          suitable for per-router
>>>>>          > >>>> delegation.
>>>>>          > >>>
>>>>>          > >>> IPv6 ND messages are permitted to be sent as unicast
>>>>>          (one-to-one). In this
>>>>>          > >>> case, the presence of a DHCPv6 option in the RS message
>>>>>          is indication that
>>>>>          > >>> the RA is to be returned via unicast.
>>>>>          > >>>
>>>>>          > >>> Thanks - Fred
>>>>>          > >>>
>>>>>          > >>>
>>>>>          > >>>>
>>>>>          > >>>> Cheers
>>>>>          > >>>> Ole
>>>>>          > >>>>
>>>>>          > >>>>
>>>>>          > >>>>>
>>>>>          > >>>>> Thanks - Fred
>>>>>          > >>>>>
>>>>>          > >>>>>> Cheers
>>>>>          > >>>>>> Ole
>>>>>          > >>>>>>
>>>>>          > >>>>>>
>>>>>          > >>>>>>>
>>>>>          > >>>>>>> Thanks - Fred
>>>>>          > >>>>>>>
>>>>>          > >>>>>>>> We are still struggling with “permissionless
>>>>>          extensions” of an IPv6 network. Something that solved that
>>>>>          problem, would be a
>>>>>          > >> lot
>>>>>          > >>>>>> more
>>>>>          > >>>>>>>> interesting to talk about.
>>>>>          > >>>>>>>>
>>>>>          > >>>>>>>> Cheers,
>>>>>          > >>>>>>>> Ole
>>>>>          > >>>>>
>>>>>          > >>>
>>>>>          > >>> _______________________________________________
>>>>>          > >>> v6ops mailing list
>>>>>          > >>> [e-mail] <mailto:[e-mail]>
>>>>>          > >>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>          > >>>
>>>>>          > >
>>>>>          >
>>>>>          > _______________________________________________
>>>>>          > v6ops mailing list
>>>>>          > [e-mail] <mailto:[e-mail]>
>>>>>          > https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------