[ Top-post ]

Yup, I was thinking that, while substantive, that would be handled
while still keeping it in IESG eval -- but, I've just gone back and
re-read the threads, especially all of the mail (~102) after the IESG
/ telechat, and I've decided that I will have to return it to the WG.
Seeing as it has already had a WGLC, I expect that the next one can be
compressed.

The good news is that a: there have been a number of suggestions /
provided text to improve the document, and b: I'd expect the next IESG
eval to go easily.

Sorry all,
W


On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> Warren,
>
> I believe it's substantive that the text refers to sending unicast
> RAs without clarifying whether this means that they are sent
> with a unicast layer 2 address and a multicast layer 3 address
> (as per RFC6085) or that they are sent with both layer 2 and
> layer 3 addresses being unicast. At the moment, an implementer
> has to decide which of these is intended. If either is OK,
> that could be stated too.
>
> Specifically this clarification seems to be needed right after:
>
>> 4.  IPv6 Unique Prefix Assignment
>>
>>    When a UE connects to the shared provider managed network and is
>>    attached, it will initiate IP configuration phase.  During this phase
>>    the UE will, from an IPv6 perspective, attempt to learn the default
>>    IPv6 gateway, the IPv6 prefix information, the DNS information
>>    RFC8106 [RFC8106], and the remaining information required to
>>    establish globally routable IPv6 connectivity.  For that purpose, the
>>    the UE/subscriber sends a RS (Router Solicitation) message.
>>
>>    The First Hop Router receives this UE/subscriber RS message and
>>    starts the process to compose the response to the UE/subscriber
>>    originated RS message.  The First Hop Provider Router will answer
>>    using a unicast RA (Router Advertisement) to the UE/subscriber.
>
> Regards
>    Brian Carpenter
>
> On 05/09/2017 09:43, Warren Kumari wrote:
>> I'd like to note that that there is continuing discussion on this
>> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only
>> been able to somewhat monitor it, but have asked the v6ops chairs for
>> input. Much of the discussion has been interesting, but not
>> necessarily pertaining exactly to this document.
>> Fred kindly asked the list:
>> https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw
>> for anything substantive for the document (keeping in mind that it has
>> already gone through WGLC and IETF LC).
>>
>> So far it doesn't seem like there are any other major changes needed,
>> other than "asking that the applicability comment that communication
>> between such nodes on a LAN should go through a connecting router
>> (which seems to me a given due to the relationship with routing)
>> should be documented." and David Farmer's followup --
>> https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY
>>
>> Does anyone have anything else *substantive*? If so, I may have to
>> kick this back to the WG for another round.
>>
>> W
>>
>>
>>
>>
>> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan
>> <suresh.krishnan@gmail.com> wrote:
>>> Hi Gunter,
>>>   Thanks for the proposed text changes. They adequately address my DISCUSS
>>> points. I am hoping you will also converge in the discussion with Lorenzo on
>>> the actual value for the timer and/or specify an applicability statement. I
>>> will clear once the new revision posts.
>>>
>>> Regards
>>> Suresh
>>>
>>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp)
>>> <gunter.van_de_velde@nokia.com> wrote:
>>>
>>> Hi Suresh,
>>>
>>> Many thanks for the review and finding these issues. What do you think of
>>> the proposals below to fix those points of attention?
>>>
>>>    ----------------------------------------------------------------------
>>>    DISCUSS:
>>>    ----------------------------------------------------------------------
>>>
>>>    * Section 4
>>>
>>>    It is not clear what you intend here
>>>
>>>    "IPv6 Router Advertisement Interval = 300s"
>>>
>>>    The router advertisement interval is not configured as an absolute value
>>> but as
>>>    minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval)
>>> which are
>>>    used to calculate the actual advertisement interval. When the RA is sent
>>> from
>>>    an interface, the actual interval is an uniformly distributed random
>>> value
>>>    between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum
>>> you
>>>    need to clarify if you would like to have this as a lower bound or as an
>>> upper
>>>    bound.
>>>
>>> GV> I changed the line to make it more clear that the timer indicates the
>>> maximum Advertisement Interval
>>> GV>          <t>Maximum IPv6 Router Advertisement Interval = 300s</t>
>>>
>>>    ----------------------------------------------------------------------
>>>    COMMENT:
>>>    ----------------------------------------------------------------------
>>>
>>>    * Section 4
>>>
>>>    -> I think text is needed here to handle the case where the DNS server is
>>>    provided in the RA itself  (RFC8106)
>>>
>>>    "In addition it will use stateless DHCPv6 to get the IPv6 address of the
>>> DNS
>>>    server"
>>>
>>>    -> I am not sure what is the motivation for this text.
>>>
>>>    "however it SHOULD NOT use stateful DHCPv6 to receive a service provider
>>>    managed IPv6 address"
>>>
>>>    -> This text seems incorrect
>>>
>>>    "due to the L-bit set, it SHOULD send this traffic to the First Hop
>>> Provider
>>>    Router"
>>>
>>>    I think it should be the exact opposite. i.e. say *unset* instead of set
>>>
>>>    "due to the L-bit being unset, it SHOULD send this traffic to the First
>>> Hop
>>>    Provider Router"
>>>
>>> GV> What about the following modification in the text:
>>>
>>> OLD:
>>> The architected result of designing the RA as documented above is
>>>   that each UE/subscriber gets its own unique IPv6 prefix for which it
>>>   can use SLAAC or any other method to select its /128 unique address.
>>>   In addition it will use stateless DHCPv6 to get the IPv6 address of
>>>   the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive
>>>   a service provider managed IPv6 address.  If the UE/subscriber
>>>   desires to send anything external including other UE/subscriber
>>>   devices (assuming device to device communications is enabled and
>>>   supported), then, due to the L-bit set, it SHOULD send this traffic
>>>   to the First Hop Provider Router.
>>>
>>> New:
>>> The architected result of designing the RA as documented above is
>>> that each UE/subscriber gets its own unique IPv6 prefix for which it
>>> can use SLAAC or any other method to select its /128 unique address.
>>> Either stateless DHCPv6 <xref target="RFC3736">RFC3736</xref> or IPv6
>>> Router Advertisement Options for DNS Configuration
>>> <xref target="RFC8106">RFC8106</xref> can be used to get the
>>> IPv6 address of the DNS server. If the UE/subscriber desires to send
>>> anything external including other UE/subscriber devices (assuming device
>>> to device communications is enabled and supported), then, due to the
>>> L-bit being unset, it SHOULD send this traffic to the First Hop Provider
>>> Router.</t>
>>>
>>>
>>>
>>> Kind Regards,
>>> G/
>>>
>>>
>>
>>
>>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf