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

["Templin (US), Fred L" <[e-mail]>]

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.

> 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.,

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
> --------------------------------------------------------------------