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

[Naveen Kottapalli <[e-mail]>]

Hello Ole,

Refined my problem statements below.  Please let me know if this is okay.

Yours,
Naveen.


On Sun, 18 Nov 2018 at 23:46, Ole Troan <[e-mail]> wrote:

> Naveen,
>
> I don’t understand the problem description below, nor why it would require
> a different solution than any of those we already have.
>
> Does anyone else understand and can translate?
>
> Cheers
> Ole
>
> On 18 Nov 2018, at 18:51, Naveen Kottapalli <[e-mail]>
> wrote:
>
> Hello Ole,
>
> Please find comments inline.
>
> Thanks & Regards,
> Naveen
>
>
> On Sat, 17 Nov 2018, 23:05 Ole Troan <[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. Soliciting any prefix of pre configured length using RS / RA is not
> currently supported.  Lack of this forces the devices to be at disposal of
> routers.  We can have it implemented in both of our CPE and router. But the
> solution wouldn't be compliant or inter-operable.  The reason why existing
> solutions can't be used is mentioned below.
> 2. Lingering SLAAC prefixes at router.  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. Devices lose ongoing data connectivity when mobility happens.  Hosts
> during mobility are losing the existing ongoing traffic sessions due to
> SLAAC 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]>
>> 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] 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]>
>>> 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]> 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]]
>>> > >> Sent: Tuesday, November 13, 2018 11:37 AM
>>> > >> To: Templin (US), Fred L <[e-mail]>; Ole Troan <
>>> [e-mail]>
>>> > >> Cc: v6ops list <[e-mail]>; 6man WG <[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]]
>>> > >>>> Sent: Tuesday, November 13, 2018 10:36 AM
>>> > >>>> To: Templin (US), Fred L <[e-mail]>
>>> > >>>> Cc: Naveen Kottapalli <[e-mail]>; 6man WG <
>>> [e-mail]>; v6ops list <[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]> wrote:
>>> > >>>>>
>>> > >>>>> Ole,
>>> > >>>>>
>>> > >>>>>> -----Original Message-----
>>> > >>>>>> From: Ole Troan [mailto:[e-mail]]
>>> > >>>>>> Sent: Tuesday, November 13, 2018 9:38 AM
>>> > >>>>>> To: Templin (US), Fred L <[e-mail]>
>>> > >>>>>> Cc: Naveen Kottapalli <[e-mail]>; 6man WG <
>>> [e-mail]>; v6ops list <[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]> wrote:
>>> > >>>>>>>
>>> > >>>>>>> Hi Ole,
>>> > >>>>>>>
>>> > >>>>>>>> -----Original Message-----
>>> > >>>>>>>> From: Ole Troan [mailto:[e-mail]]
>>> > >>>>>>>> Sent: Monday, November 12, 2018 11:57 PM
>>> > >>>>>>>> To: Templin (US), Fred L <[e-mail]>
>>> > >>>>>>>> Cc: Naveen Kottapalli <[e-mail]>; 6man WG <
>>> [e-mail]>; v6ops list <[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
>>> > >>
>>> > >>    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]
>>> > >>> https://www.ietf.org/mailman/listinfo/v6ops
>>> > >>>
>>> > >
>>> >
>>> > _______________________________________________
>>> > v6ops mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>