RE: AD review: draft-ietf-6man-lineid

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 17 May 2012 04:41 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8721F867F for <ipv6@ietfa.amsl.com>; Wed, 16 May 2012 21:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Level:
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 W4xroB0rj2Vr for <ipv6@ietfa.amsl.com>; Wed, 16 May 2012 21:41:49 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5B21F8665 for <ipv6@ietf.org>; Wed, 16 May 2012 21:41:49 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4H4flSG028601; Wed, 16 May 2012 23:41:48 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 17 May 2012 00:41:42 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Brian Haberman <brian@innovationslab.net>, "draft-ietf-6man-lineid@tools.ietf.org" <draft-ietf-6man-lineid@tools.ietf.org>, 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>
Date: Thu, 17 May 2012 00:41:02 -0400
Subject: RE: AD review: draft-ietf-6man-lineid
Thread-Topic: AD review: draft-ietf-6man-lineid
Thread-Index: Ac0olNxg87/aTYNTS1KnLeFiAxw5CALUmcmY
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC1514E4C2398@EUSAACMS0703.eamcs.ericsson.se>
References: <4FA18283.40507@innovationslab.net>
In-Reply-To: <4FA18283.40507@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2012 04:41:50 -0000

Hi Brian,
  Thanks for the comments. Please find responses inline.

Brian Haberman wrote:
> All,
>        Here are my comments on the LineID draft.  It is in pretty good
> shape, but I would like these issues addressed before moving on to IESG
> Review/IETF Last Call...
> 
> Substantive
> -----------
> 
> - Section 2 (paragraph 3) : This text talks about "the network" getting
> some information from the subscriber-originated RS messages.  Is it
> really the AN that gets this information or is it really the Edge
> Router?  What information is being lost when the subscriber-initiated RS
> messages stop?

It is mainly the MAC address of the host that initiated the RS. The proxy RS from the AN cannot convey this to the edge router.

> 
> - Section 2 (paragraph 5) : This paragraph states that this approach is
> "NOT RECOMMENDED for general deployments".  Do you really mean general
> deployments or is is better to say deployments not using the N:1 VLAN model?

It is intended to convey that this mechanism applies to n:1 vlan models and is not generally applicable. If we use "NOT RECOMMENDED for deployments not using N:1" we end up with a double negative. Will that work for you?

> 
> - Section 5.1 : If the AN has an IPv6 address, why is its use in the
> encapsulating header only a SHOULD?

I am rewording this section to include an additional case that came up. I will change this to a MUST, The New text will read 


OLD:
If the AN has an IPv6 address, it SHOULD use this
address in the Source Address field of the outer IPv6 datagram.
Otherwise it MUST use the unspecified address as the Source Address
of the outer IPv6 datagram.

NEW:

If the AN has an IPv6 address, it MUST use this address in the Source Address field of the outer IPv6 datagram. Otherwise, when the end-device sends out a Router Solicitation and uses a link-local address in the Source Address field, the AN MUST copy this address in the Source Address field of the outer IPv6 datagram.
In all other cases, the AN MUST use the unspecified address as the Source Address of the outer IPv6 datagram.

> 
> - Section 6.3 : How does the edge router know what prefixes to map to
> the LIO?  Should there be some specification that the RA transmitted
> must/should carry a PIO?

The LIO gets mapped to the prefix either by configuration or some form of dynamic provisioning using a protocol like RADIUS. I will add an explicit statement that this RA MUST carry this prefix in the PIO.

 
> 
> - Section 7 : I would suggest for the definition of the Option Length
> s/The value 0 is considered invalid/The value MUST be greater than 0/

OK.

> 
> - Section 7.1 : I have questions on the use of SHOULD NOT in the last
> two paragraphs. In what situation would two line IDs be considered equal
> if they do not match byte-by-byte?  To me, this can be changed to MUST
> NOT. I am not sure there is really any reason to say an intermediate
> system SHOULD NOT examine the Line ID.  There is no way to enforce that
> rule.  In what situation (or type of situation) would an intermediate
> system be allowed to modify the Line ID?

I cannot see any reasonable cases where there can be exceptions to this. I will change these to MUST NOTs.

> 
> Editorial
> ---------

I will make all these editorial changes,

Thanks
Suresh