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

[Alexandre Petrescu <[e-mail]>]

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.

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.

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