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

From: Brian Haberman <[email-masked]>
Date: Wed, 02 May 2012 14:52:51 -0400

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?

- 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?

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

- 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?

- 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/

- 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?

Editorial
---------

* Introduction
- s/traditionally/traditional/
- s/[RFC1661] based some networks/[RFC1661] based, some networks/
- s/network in context/network in the context/
- None of the figures are referenced in the text
- Expand GPON acronym on its first use

* Terminology
- The definition of AN uses the terms northbound and southbound. It 
would be useful to briefly define those (or use different terms).
- I would define RG before Edge Router so that there is no dangling use 
of the term RG before it is defined. Or you can expand RG in the 
definition...
- It may be useful to state whether the use of an RG is optional or not.
- The definition of RG is missing a term: "...similar to one specified 
in or a Layer...".

* Section 2
- s/VLAN deployment models line/VLAN deployment models, line/
- DHCP should be expanded on first use and a reference given.
- I would suggest providing a reference for SLAAC.
- s/this results on some/this results in some/
- s/Router Solicitations by initiating RSs/Router Solicitations (RSes) 
by initiating RSes/
- s/RSs/RSes/g
- There is a dangling "e.g." in the middle of the third paragraph.

* Section 3
- s/the end-device on the circuit the end-device is connected on/the 
end-device on the circuit/
- It would be useful to include a reference for DHCP relay agents.

* Section 4
- The acronym ND needs to be expanded or changed to RS/RA.
- Specify that it is the Hop Limit of the *inner* packet that must not 
be decremented.

* Section 5.1
- The section uses the term "insert" when talking about the creation of 
the encapsulating (outer) packet.  This makes me think of modifying an 
existing packet.  It would be clearer to state that the encapsulating 
packet includes/contains a destination options header.

* Section 5.2
- s/router advertisement/Router Advertisement/
- Rather than saying the AN will "multicast" the inner packet, would be 
sufficient to say it will "transmit" the inner packet?

* Section 6.1
- Last sentence is missing a period.

* Section 6.2
- s/this router advertisement(es./this router advertisement./
- s/All BBF Access Nodes/All-BBF-Access-Nodes/g

* Section 6.3
- Provide an informative reference for ANCP.

* Section 7
- s/an alignment requirement of (none)/no alignment requirements/

* Section 7.1
- The last sentence of the first paragraph is missing a period.

Regards,
Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 17 May 2012 00:41:02 -0400

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

> shape, but I would like these issues addressed before moving on to IESG

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.

> 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?

> 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.

> the LIO?  Should there be some specification that the RA transmitted

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.

> s/The value 0 is considered invalid/The value MUST be greater than 0/

OK.

> 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

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 May 2012 09:09:23 -0400

Hi Suresh,

On 5/17/12 12:41 AM, Suresh Krishnan wrote:
> 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?

How about : "...is considered experimental and SHOULD only be used in 
deployments employing N:1 VLANs."?

I, personally, would not object to changing the above SHOULD to a MUST.

>
>>
>> - 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

Looks good to me.

>
>>
>> - 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.
>

Ok.

>
>>
>> - 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?
>

Ok.

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

Cool.  Once the new version is out, I will start an IETF Last Call.

Regards,
Brian