Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt

[Ole Troan <ot@cisco.com>]

Fred et al,

this is an interesting topic, but I believe this is new innovative work and out of scope for this draft. could we move this to a separate thread from the draft last call?

cheers,
Ole


On Jan 11, 2010, at 19:11 , Templin, Fred L wrote:

> Mark,
> 
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mark Smith
>> Sent: Sunday, January 10, 2010 3:19 AM
>> To: Mikael Abrahamsson
>> Cc: IPv6 Operations
>> Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
>> 
>> On Sun, 10 Jan 2010 11:48:06 +0100 (CET)
>> Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>> 
>>> On Sun, 10 Jan 2010, Mark Smith wrote:
>>> 
>>>> My argument is that if an SP chooses to have the layer 2 edge
>>>> device perform those security functions, then there is an opportunity
>>>> for more optimal traffic forwarding via a mechanism like a
>>>> prefix-redirect. You may not like that design, but you might not have
>>>> to be making decisions about the tradeoffs between backhaul cost, capex
>>>> and opex of aggregated-vs-per-POP layer 3 and the influence over
>>>> customer density and geography that other SPs around the world have to
>>>> make.
>>> 
>>> Since some ISPs seem fine with backhauling their PPPoE traffic to a single
>>> place in a whole nation, let's (as said in another mail) postpone these
>>> hypothetical optimizations to a later update of the document. Right now we
>>> need to get IPv6 out the door at all, and still do it securely. I'd rather
>>> have the vendors implement the things we have in the document right now,
>>> than adding more things in there and postponing deployment further.
>>> 
>> 
>> I agree, the draft shouldn't be held up. I wasn't ever saying that this
>> prefix-redirect idea should be in this draft, only that CPE RAs towards
>> the SP might be a place that such a supported capability could be
>> announced, which of course wouldn't be possible if this draft stopped
>> CPE from issuing RAs.
>> 
>> Thinking about it a bit further, I think a Neighbor Announcement option
>> might be an alternative and possibly better place for this capability
>> announcement option, should the idea itself have merit.
> 
> Use of the NA instead of RA would prevent the CE router
> from advertising information that would conflict with
> the information advertised by SP routers. I am thinking
> here about link-related information such as Reachable
> Time, Retrans Timer, and those confounded M&O bits that
> occur in RA messages but not NA.
> 
> One matter of concern is whether we can use NA messages
> for the purpose of SEND Authorization Delegation Discovery
> per RFC3971, Section 6. By my read of that section, it says
> that the authorization model is used to protect Router
> Discovery but it does *not* say that only RA messages (and 
> not NA) must be used. Hence, I presume that we can piggyback
> RFC3971 section 6 authorization delegation discovery on top
> of NA messages?
> 
> James Woodyatt's disclaimer notwithstanding, does anyone
> see an issue with using unsolicited, unicast NAs?
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
>> Regards,
>> Mark.
>> 
> 
>