Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

Ole Troan <otroan@employees.org> Wed, 11 September 2013 12:04 UTC

Return-Path: <otroan@employees.org>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004CE11E8230 for <dhcwg@ietfa.amsl.com>; Wed, 11 Sep 2013 05:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGD54gvvABdp for <dhcwg@ietfa.amsl.com>; Wed, 11 Sep 2013 05:04:25 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C611E810B for <dhcwg@ietf.org>; Wed, 11 Sep 2013 05:04:25 -0700 (PDT)
Received: from dhcp-10-61-101-234.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id D52065EEE; Wed, 11 Sep 2013 05:04:23 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_B0F005EA-2790-48D0-BCFC-41BA51FB916D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <52305986.2010503@gmail.com>
Date: Wed, 11 Sep 2013 14:04:20 +0200
Message-Id: <FB56FE0A-9088-4040-BCE7-C69399D64171@employees.org>
References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> <5212694A.6000807@gmail.com> <CAOv0Pi87akb24PaYJKPzK3+cfCr1DHDu-h2sF3HwTxBvzZC9+w@mail.gmail.com> <C2A9B74C-A52C-4605-824E-40E3E9C190E0@gmail.com> <52305986.2010503@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 12:04:30 -0000

Alexandru,

>>> In RFC 3315 DHCPv6-PD there is a questionable use of the term
>>> 'provider edge router.' in a section describing the behaviour of
>>> the Relay agent:
>>> 
>>> 14.  Relay agent behavior
>>> 
>>> A relay agent forwards messages containing Prefix Delegation
>>> options in the same way as described in section 20, "Relay Agent
>>> Behavior" of RFC 3315.
>>> 
>>> If a delegating router communicates with a requesting router
>>> through a relay agent, the delegating router may need a protocol or
>>> other out-of-band communication to add routing information for
>>> delegated prefixes into the provider edge router.
>>> 
>>> I wonder whether the Authors actually meant 'Relay Agent' by that
>>> 'provider edge router'. Because otherwise the term doesn't appear
>>> elsewhere in the document.
>> 
>> (Assuming you meant RFC3633) Yes, s/provider edge router/relay
>> agent/
> 
> Yes, I meant RFC3633, and yes s/provider edge router/relay agent.
> 
> That would make for an errata that one could suggest in the errata site?

I'm not sure I see what difference it would make?

>>> Also, did the authors of RFC3315 meant that a new protocol is
>>> needed between Server and Relay Agent?  Or did they mean that
>>> inserting a routing table should happen by that 'out-of-band' means
>>> (and not 'out-of-band communication')?
>> 
>> Not speaking for Ole, I meant that some other means, which might be a
>> protocol, manual configuration, etc., is needed to add routing
>> information into the relay agent.
> 
> In that sense I agree with it.  It is thus a problem that is already explicit in this RFC.

everyone does this with snooping today, but that's not covered by any RFC.
the closest we got to exploring the options was in http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00

cheers,
Ole