The Line-Identification Option
draft-ietf-6man-lineid-08

IANA has reviewed draft-ietf-6man-lineid-08 and has the following comments:

IANA has a question about the IANA actions requested in the IANA
Considerations section of this document.

IANA understands that upon approval of this document, there are two
IANA actions which must be completed.

First, in the Destination Options and Hop-by-Hop Options subregistry of
the Internet Protocol Version 6 (IPv6) Parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml

a new IPv6 destination option will be registered as follows:

Hex value: [ TBD ]
act: 10
chg: 0
rest: [ TBD ]
Description: Line Identification Option
Reference: [ RFC-to-be ]

Second, in the Link-Local Scope Multicast Addresses subregistry of
the IPv6 Multicast Address Space Registry located at:

www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml

Address: [ TBD at time of allocation ]
Description: All BBF Access Nodes
Reference: [ RFC-to-be ]

Currently the Link-Local Scope Multicast Addresses registry is maintained
through expert review as defined in RFC 5226.

IANA Question -> has the document been reviewed by the Link-Local Scope
Multicast Addresses registry expert?

IANA understands these two actions to be the only ones needed to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Line Identification Destination Option) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'The Line Identification Destination Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-09-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In Ethernet based aggregation networks, several subscriber premises
  may be logically connected to the same interface of an edge router.
  This document proposes a method for the edge router to identify the
  subscriber premises using the contents of the received Router
  Solicitation messages.  The applicability is limited to broadband
  network deployment scenarios where multiple user ports are mapped to
  the same virtual interface on the edge router.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
1. (cleared)

2. (cleared)

3. (cleared)

4. Two questions about this text from section 6.2:

  If the Source Address field of the received IPv6 datagram
  was not the unspecified address, the Edge router MUST copy this
  address into the Destination Address field of the outer IPv6 datagram
  sent back towards the Access Node.  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.  Otherwise, the destination address of the
  outer IPv6 datagram MUST be set to the well-known link-local scope
  All-BBF-Access-Nodes multicast address [to be allocated].

Is the "tunneled RA" the "outer IPv6 datagram"?

Does the "Otherwise" apply to the first "If" in the quoted text?

(update) I see that section 6.2 has been revised to clarify the
various cases.  In e-mail, you explained that "tunneled RA" is
equivalent to "outer IPv6 datagram".  While this is a non-blocking
comment, it would be good to be consistent in using one term or the
other throughout the document (I would suggest "outer IPv6 datagram"
as more precise and clear), or add a sentence explaining the two
phrases are equivalent.

5.(cleared)

6. (new, from previous Discuss point 2) The use of the word "uses"
clarifies that this option will only be carried in an RS in a tunnel.
It wouldn't hurt to add a sentence that explicitly expresses that
restriction, and specifies the behavior if an "untunneled" RS carrying
this option is received.

7. (new, from previous Discuss point 8)  I've cleared my Discuss
based on the text regarding MTU in rev -07.  I
suggest some minor word-smithing for that next text:

OLD:

  The edge router MUST ensure that it does not transmit tunneled RAs
  whose size is larger than the MTU of the link between the edge router
  and the AN. i.e.  The outer IPv6 datagram would require
  fragmentation.  This is required because the AN may not be capable of
  handling the reassembly of such fragmented datagrams.

NEW:

  The edge router MUST ensure that it does not transmit tunneled RAs
  whose size is larger than the MTU of the link between the edge
  router and the AN, which would require that the outer IPv6 datagram
  undergo fragmentation.  This limitation is imposed because the AN
  may not be capable of handling the reassembly of such fragmented
  datagrams.

[Ballot discuss]
Updated for rev -06; waiting for -07 to be available to clear point 8.

1. (cleared)

2. (cleared, but see new comment)

3. (cleared)

4. (cleared)

5. (cleared)

6. (cleared, but see updated comment)

7. (cleared)

8. The document needs to address the interaction between the
mandated encapsulation mechanism and the link MTU
between the AN and the Edge Router.

[Ballot comment]
1. (cleared)

2. (cleared)

3. (cleared)

4. Two questions about this text from section 6.2:

  If the Source Address field of the received IPv6 datagram
  was not the unspecified address, the Edge router MUST copy this
  address into the Destination Address field of the outer IPv6 datagram
  sent back towards the Access Node.  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.  Otherwise, the destination address of the
  outer IPv6 datagram MUST be set to the well-known link-local scope
  All-BBF-Access-Nodes multicast address [to be allocated].

Is the "tunneled RA" the "outer IPv6 datagram"?

Does the "Otherwise" apply to the first "If" in the quoted text?

(update) I see that section 6.2 has been revised to clarify the
various cases.  In e-mail, you explained that "tunneled RA" is
equivalent to "outer IPv6 datagram".  While this is a non-blocking
comment, it would be good to be consistent in using one term or the
other throughout the document (I would suggest "outer IPv6 datagram"
as more precise and clear), or add a sentence explaining the two
phrases are equivalent.

5.(cleared)

6. (new, from previous Discuss point 2) The use of the word "uses"
clarifies that this option will only be carried in an RS in a tunnel.
It wouldn't hurt to add a sentence that explicitly expresses that
restriction, and specifies the behavior if an "untunneled" RS carrying
this option is received.

[Ballot discuss]
Updated by adding point 8.

1. In section 4:

  This document recommends tunneling Neighbor discovery packets inside
  another IPv6 packet that uses a destination option to convey line
  identification information.

Is this an RFC 2119 recommendation?  Under what circumstances would a
device not encapsulate the original RS as recommended, and what are
the consequences of not using encapsulation?

2. Following up on point 1, throughout the rest of the document there
is text that is conditional on, e.g., "receives a tunneled Router
Solicitation".  What is the behavior in the case of a non-tunneled RS
that includes an LIO?

3. Is the link between an AN and the Edge Router a point-to-point
link?  If not, it seems to me that the Line ID MUST be unique across
all ANs that share a link to the Edge Router.

In the case where an AN
sends an encapsulated RS to the Edge Router with the source address
set to the unspecified address, the Edge Router will multicast the
corresponding RA, and the RA will be received by all the ANs on that
link.  If two different ANs happen to use the same Line ID, they will
both then forward that RA on the identified subscriber line (and one
of the ANs will be wrong).

4. For completeness, the document should have text requiring the AN to
join the All-BBF-Access-Nodes multicast group.

5. In section 6.2, is the "circuit identifier corresponding to the
logical access loop port of the Access Node to which the RA MUST be
sent" the same as the Line ID field from the received RS?  If not,
where does that circuit identifier come from?

6. Also in section 6.2, there are two potentially contradictory
requirements on the "link-layer destination address of the tunneled
RA" (I assume the "tunneled RA" is the outer IPv6 datagram):

  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.

  The link-layer destination address of the tunneled RA MUST
  be set to the unicast link-layer address of the Access Node that sent
  the tunneled Router Solicitation which is being responded to.

7. I don't see any text in section 6.2 about how a prefix is
associated with the Line ID in an LIO.  Section 8 describes
reclamation of allocated prefixes, which implies there is a mechanism
for allocating prefixes, but section 6.2 seems to simply assume that
there is a prefix that corresponds to the received LIO.

8. The document needs to address the interaction between the
mandated encapsulation mechanism and the link MTU
between the AN and the Edge Router.

[Ballot comment]
1. I'm curious about the use of "Ethernet" as an adjective
throughout the document.  For example, in the abstract, what does
"Ethernet" mean in the phrase "Ethernet based aggregation networks",
and does "Ethernet" add anything to the understanding of the sentence?

2. From section 2:

  While this protocol improves
  the the robustness of relying on Router Solicitations in lieu of
  DHCP, this results on some limitations specified below.

In addition to the typo "the the" in the second line, I found the
sentence a little confusing.  Perhaps:

  While this option improves the reliability of operation in
  deployments that use Router Solicitations rather than DHCP, there
  are some limitations as specified below.

3. In section 5.1:

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

This text is a little confusing to me, because of the "link-local"
qualifier in the second line.  Is it just the case that the AN copies
the Source Address from the received RS, regardless of whether or not
it is the unspecified address?

4. Two questions about this text from section 6.2:

  If the Source Address field of the received IPv6 datagram
  was not the unspecified address, the Edge router MUST copy this
  address into the Destination Address field of the outer IPv6 datagram
  sent back towards the Access Node.  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.  Otherwise, the destination address of the
  outer IPv6 datagram MUST be set to the well-known link-local scope
  All-BBF-Access-Nodes multicast address [to be allocated].

Is the "tunneled RA" the "outer IPv6 datagram"?

Does the "Otherwise" apply to the first "If" in the quoted text?

5. Also in section 6.2, it would be clearer to move the text about the
destination address of the inner RA up to the first paragraph, where
the RA is specified as constructed according to RFC 4861.

[Ballot discuss]
This is strictly for the shepherd and the IESG; authors don't need to do anything about this. Further, my intention is to clear this DISCUSS during the telechat today; this is simply a placeholder to make sure that it gets DISCUSSed on the IESG call:

Could we get some further explanation about this document being "Experimental"? As far as I can tell, the only reason for Experimental instead of Proposed Standard is that it has limited applicability. However, that is taken care of in the Applicability Statement at the top of the document. I see no indication in the document about how the experiment might take place, what the results of such an experiment might be, or anything at all to indicate that there is an experiment of any sort going on here. I *hate* using document status as some sort of punishment, or worse as an indication that the WG did not *really* have consensus on this document. Please explain.

[Ballot comment]
I am balloting "yes" but there are some minor comments from Dave
Sinicrope's Routing Directorate review. Please consider them
before advancing the document for publication.

1.  Section 1.1 Terminology & all related sections:  Throughout
    several sections of the document the term "subscriber" is used.
    It is not defined in the Terminology.  It seems this is often
    used synonimously with End-device which is defined.  This is
    particularly true of section 2. Applicability Statement. 
    Please define "subscriber" or substitute a defined term (e.g.,
    "end device") for "subscriber" throughout the document.

2.  Section 1.1 Terminology & all related sections:  Throughout
    several sections of the document the term "host" is used. While
    "host" is defined in the Terminology, it seems this is often
    used synonimously with End-device where it would be better to
    use the latter term.  This is particularly true of section 2.
    Applicability Statement paras 3 and 5.  Please substitute "end
    device" for "host" throughout the document where this is
    applicable.

3.  Section 2. Applicability Statement: This section focuses on the
    limitations of the draft, but it should elaborate more on the
    applicability and usefulness of the draft to support stateless
    auto configuration.

4.  Section 2. Applicability Statement, para 3, last 2 sentences:
    These statements make it appear that all broadband networks rely
    on the [end device] MAC address and that it is not recommended
    that this draft be used for networks that require the [end
    device] MAC address, leading the reader to the possible conclusion
    that this draft has little use.  In practice some broadband
    networks use the [end device] MAC address, but not all making the
    draft far more applicable than indicated.  Please qualify the
    penultimate sentence of paragraph 3 "currently used in <"some"
    or "many"> Broadband networks"

5.  Section 2 Applicability Statement: The document would benefit
    from a brief flow diagram showing the Router Solicitation &
    Router Advertisement flows between the nodes shown in Figure 1.

6.  Section 4 Basic Operation, last sentence:  The last sentence is
    not clear as to why a packet with a hop limit not set to 255 is
    discarded.  Please briefly elaborate (e.g., "because they appear
    to be more than a single hop away.")

7.  Section 5.1 On receiving a Router Solicitation: Add a figure
    showing the construction of a tunneled Router Solicitation.  Add
    "See Figure X" within the paragraph to reference the figure.

8.  Section 5.2.1 Identifying tunneled Router Advertisements: It is
    unclear, at least initially, what is meant by "All BBF Access
    Nodes".  Please clarify its use as done in section 6.2, noting
    that it is a well known, link-local scoped multicast address.

9.  Section 5.3 On detecting a subscriber circuit coming up, para 1,
    "When the access node": I believe what is meant by "When the
    access node detects that a subscriber circuit has come up" is
    really "Each time the access node detects that a subscriber
    circuit has come up".  "When the" could be misinterpreted as
    meaning "the first time".  Please change "When the" to "Each
    time" in this sentence.

10. Section 6.1 On receiving a Tunneled Router Solicitation: It is
    not clear how the edge router recognizes a tunneled RS. Please
    briefly elaborate on how this datagram is identified by the
    edge router.

11. Section 6.1 On receiving a Tunneled Router Solicitation, "The
    link-layer destination address of the tunneled RA MUST".  There
    are two statements in this paragraph that start with this clause
    that seem to be contradictory.  Please reconcile and clarify.

12. Section 6.3 Sending periodic unsolicited Router Advertisements:
    This section would benefit from a forward reference to section 8
    Garbage collection of unused prefixes to help the reader
    understand when and how the prefixes are eventually removed or
    cleared.

13. Section 7 Line Identification Destination Option (LIO): Change
    "no alignment requirement." to "… no byte alignment
    requirement."

14. Section 7.1 Encoding of Line ID, para 3: It is not clear why
    compatibility with DHCP is needed as these are two independent
    protocols.  The section notes the derivation of the option from
    DHCP.  It seems to be implied that compatibility is kept to allow
    the same processing to be used.  If this is the case it should be
    stated.  If it is not the case, the rationale would help the
    reader understand better why compatibility must be kept and the
    relation to the install base which would seem to need a software
    upgrade to support this draft.

Nits:

1.  Section 2 Applicability Statement, para 3: This paragraph should
    be broken into two paragraphs as the latter sentences explain
    limitations and recommendations of the draft itself while the
    earlier sentences explain operation of Router Solicitation and
    Advertisement.

2.  Section 5.1 On receiving a Router Solicitation:  Clarify the use
    of "the unspecified address", with a reference or context. (e.g.,
    "the unspecified address defined in RFC"

3.  General: inconsistent use of capitalization on "Edge Router"/"edge
    router"/"Edge router"

[Ballot discuss]
1. In section 4:

  This document recommends tunneling Neighbor discovery packets inside
  another IPv6 packet that uses a destination option to convey line
  identification information.

Is this an RFC 2119 recommendation?  Under what circumstances would a
device not encapsulate the original RS as recommended, and what are
the consequences of not using encapsulation?

2. Following up on point 1, throughout the rest of the document there
is text that is conditional on, e.g., "receives a tunneled Router
Solicitation".  What is the behavior in the case of a non-tunneled RS
that includes an LIO?

3. Is the link between an AN and the Edge Router a point-to-point
link?  If not, it seems to me that the Line ID MUST be unique across
all ANs that share a link to the Edge Router.

In the case where an AN
sends an encapsulated RS to the Edge Router with the source address
set to the unspecified address, the Edge Router will multicast the
corresponding RA, and the RA will be received by all the ANs on that
link.  If two different ANs happen to use the same Line ID, they will
both then forward that RA on the identified subscriber line (and one
of the ANs will be wrong).

4. For completeness, the document should have text requiring the AN to
join the All-BBF-Access-Nodes multicast group.

5. In section 6.2, is the "circuit identifier corresponding to the
logical access loop port of the Access Node to which the RA MUST be
sent" the same as the Line ID field from the received RS?  If not,
where does that circuit identifier come from?

6. Also in section 6.2, there are two potentially contradictory
requirements on the "link-layer destination address of the tunneled
RA" (I assume the "tunneled RA" is the outer IPv6 datagram):

  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.

  The link-layer destination address of the tunneled RA MUST
  be set to the unicast link-layer address of the Access Node that sent
  the tunneled Router Solicitation which is being responded to.

7. I don't see any text in section 6.2 about how a prefix is
associated with the Line ID in an LIO.  Section 8 describes
reclamation of allocated prefixes, which implies there is a mechanism
for allocating prefixes, but section 6.2 seems to simply assume that
there is a prefix that corresponds to the received LIO.

[Ballot comment]

1. I'm curious about the use of "Ethernet" as an adjective
throughout the document.  For example, in the abstract, what does
"Ethernet" mean in the phrase "Ethernet based aggregation networks",
and does "Ethernet" add anything to the understanding of the sentence?

2. From section 2:

  While this protocol improves
  the the robustness of relying on Router Solicitations in lieu of
  DHCP, this results on some limitations specified below.

In addition to the typo "the the" in the second line, I found the
sentence a little confusing.  Perhaps:

  While this option improves the reliability of operation in
  deployments that use Router Solicitations rather than DHCP, there
  are some limitations as specified below.

3. In section 5.1:

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

This text is a little confusing to me, because of the "link-local"
qualifier in the second line.  Is it just the case that the AN copies
the Source Address from the received RS, regardless of whether or not
it is the unspecified address?

4. Two questions about this text from section 6.2:

  If the Source Address field of the received IPv6 datagram
  was not the unspecified address, the Edge router MUST copy this
  address into the Destination Address field of the outer IPv6 datagram
  sent back towards the Access Node.  The link-layer destination
  address of the tunneled RA MUST be resolved using regular Neighbour
  Discovery procedures.  Otherwise, the destination address of the
  outer IPv6 datagram MUST be set to the well-known link-local scope
  All-BBF-Access-Nodes multicast address [to be allocated].

Is the "tunneled RA" the "outer IPv6 datagram"?

Does the "Otherwise" apply to the first "If" in the quoted text?

5. Also in section 6.2, it would be clearer to move the text about the
destination address of the inner RA up to the first paragraph, where
the RA is specified as constructed according to RFC 4861.

[Ballot comment]
Former DISCUSS points, now resolved [3 July]:

1. Suresh has confirmed that the NOT RECOMMENDED text in Section 2 is correctly meant in the 2119 sense, and shouldn't be MUST NOT.

2. Suresh has confirmed that the AN is not physically accessible to the subscriber, so securing the network beginning at that point and continuing out is sufficient.

========
Non-blocking comments;  no need to respond to these:

Authors:
Thank you for being very clear in the IANA Considerations.

*** A note to the document shepherd about the writeup:
You say, in responses to writeup questions (1) and (2), that there was a great deal of discussion and disagreement about this document in the WG:

> (1) Experimental as indicated in the header. This designation
> was reached after a long discussion in the working group.

> (2) Working Group Summary
> It was difficult reaching a consensus on this document, hence the two w.g. last
> calls. This approach was requested by the Broad Band Forum. The issues were
> resolved by some changes in the document and an agreement to have it be an
> experimental RFC.

It would have been helpful to have had more explanation (perhaps in the response to question (9)) of what the issues were, why they were considered difficult problems, and how that led to Experimental status rather than... what status was it intended for before?  A lot of discussion happened about why this is problematic or questionable, and how that got resolved, and ADs from other areas have to review it without any of that background.  These writeups aren't just meant to say "yes" and "no", and "yeh, there were issues."  This one is pretty perfunctory.

[Ballot comment]
Picking up on Stephen's point about referring the LIO referring to "subscriber premise."  The last sentence of s3 does use this term so maybe just sprinkling premise in s2/s3 title?

[Ballot discuss]
These should be a really easy DISCUSS points to sort out, with one round of... well, discussion.

*** Point 1:
-- Section 2, Applicability Statement --

  For this reason, the solution described in this
  document is NOT RECOMMENDED for networks that require the MAC address
  of the endpoint for identification.

  Thus this protocol is NOT RECOMMENDED for networks that
  require automatic notification when a subscriber is no longer active.

This is just to make sure you're using NOT RECOMMENDED in the correct 2119 way, rather than as capitalized plain English.  In English, when you tell me that this protocol is not recommended for my environment, I'm going to move on and not use it.  In other words, I think you're telling me not to use it, full stop.

In 2119 language that would be "this protocol MUST NOT be used [in the described environment]."  But NOT RECOMMENDED is a "SHOULD NOT" -- it says not to use it unless you fully understand the consequences... but it does allow for using it.  The (excellent) explanatory text makes me think you really want MUST NOT.

So I want to make sure that you really mean "NOT RECOMMENDED" here, and that you don't really want a "MUST NOT" formulation instead.

*** Point 2:
Your diagrams in the introduction are very helpful; thanks.  One thing I don't get from them is which pieces are under control (administrative or physical) of the subscriber.  You say that the network between the AN and the ER needs to be trusted.  Where is the AN, physically?  Is it at the subscriber's premises (part of the DSL equipment)?  Or is it locked away in the CO, down the street?  That is, is there a way the subscriber could corrupt the AN, or is it protected from tampering by the subscriber?

[Ballot comment]
Non-blocking comments;  no need to respond to these:

Authors:
Thank you for being very clear in the IANA Considerations.

*** A note to the document shepherd about the writeup:
You say, in responses to writeup questions (1) and (2), that there was a great deal of discussion and disagreement about this document in the WG:

> (1) Experimental as indicated in the header. This designation
> was reached after a long discussion in the working group.

> (2) Working Group Summary
> It was difficult reaching a consensus on this document, hence the two w.g. last
> calls. This approach was requested by the Broad Band Forum. The issues were
> resolved by some changes in the document and an agreement to have it be an
> experimental RFC.

It would have been helpful to have had more explanation (perhaps in the response to question (9)) of what the issues were, why they were considered difficult problems, and how that led to Experimental status rather than... what status was it intended for before?  A lot of discussion happened about why this is problematic or questionable, and how that got resolved, and ADs from other areas have to review it without any of that background.  These writeups aren't just meant to say "yes" and "no", and "yeh, there were issues."  This one is pretty perfunctory.

[Ballot comment]

- Just want to check, I'm fairly sure no change is needed but
just in case... Is there any way in which the LIO for one
subscriber can leak out so as to be visible to another
subscriber?

- Wouldn't it be better to say that the LIO identifies the
subscriber premises or account rather than the subscriber?
That is, its not a person, being identified, e.g. the title of
section 3 reads like there might be something privacy
sensitive here, but I don't think there is really.

- Some fixes due to Dan Harkins' secdir review [1] comments
seem to be agreed by the authors.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03361.html

IANA has reviewed draft-ietf-6man-lineid-05 and has the following comments:

IANA understands that upon approval of this document, there are two IANA actions
which must be completed.

First, in the Destination Options and Hop-by-Hop Options subregistry of the
Internet Protocol Version 6 (IPv6) Parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml

a new IPv6 destination option will be registered as follows:

Hex value: [ TBD ]
act: 10
chg: 0
rest: [ TBD ]
Description: Line Identification Option
Reference: [ RFC-to-be ]

Second, in the Link-Local Scope Multicast Addresses subregistry of the IPv6
Multicast Address Space Registry located at:

www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml

Address: [ TBD at time of allocation ]
Description: All BBF Access Nodes
Reference: [ RFC-to-be ]

IANA understands these two actions to be the only ones needed to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Line Identification Destination Option) to Experimental RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'The Line Identification Destination Option'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In Ethernet based aggregation networks, several subscriber premises
  may be logically connected to the same interface of an edge router.
  This document proposes a method for the edge router to identify the
  subscriber premises using the contents of the received Router
  Solicitation messages.  The applicability is limited to broadband
  network deployment scenarios where multiple user ports are mapped to
  the same virtual interface on the Edge Router.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ballot/


No IPR declarations have been submitted directly on this I-D.

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

Document Write up for  UPDATED V2

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Experimental as indicated in the header. This designation was reached after a long discussion in the working group.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document defines a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router.

Working Group Summary

It was difficult reaching a consensus on this document, hence the two w.g. last calls. This approach was requested by the Broad Band Forum. The issues were resolved by some changes in the document and an agreement to have it be an experimental RFC.

Document Quality

This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Significant reviews have been done by Wojciech Dec and Ran Atkinson.

Personnel

Bob Hinden is the Document Shepherd.
Brian Haberman is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Read the document and check for NITs.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I am not aware of any IPR disclosures.

The document authors:

Suresh Krishnan
Alan Kavanagh
Balazs Varga
Sven Ooghe
Erik Nordmark

have said they complied with the IPR rules as defined in BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

I am not aware of any IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Pretty solid. The people who had raised objections earlier, now support this going forward as an Experimental RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No serious problems.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The draft request a new IPv6 destination option and a new IPv6 link-scoped multicast address. No new registries are required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

UPDATED Writeup:

Title : The Line Identification Destination Option
Author(s) : Suresh Krishnan
Alan Kavanagh
Balazs Varga
Sven Ooghe
Erik Nordmark
Filename : draft-ietf-6man-lineid-04.txt
Pages : 15
Date : 2012-03-09


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Experimental as indicated in the header. This designation was reached after a long discussion in the working group.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document defines a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router.

Working Group Summary

It was difficult reaching a consensus on this document, hence the two w.g. last calls. This approach was requested by the Broad Band Forum. The issues were resolved by some changes in the document and an agreement to have it be an experimental RFC.

Document Quality

This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Significant reviews have been done by Wojciech Dec and Ran Atkinson.

Personnel

Bob Hinden is the Document Shepherd.
Brian Haberman is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Read the document and check for NITs.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I am not aware of any IPR disclosures.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

I am not aware of any IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Pretty solid. The people who had raised objections earlier, now support this going forward as an Experimental RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No serious problems.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The draft request a new IPv6 destination option and a new IPv6 link-scoped multicast address. No new registries are required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Experimental as indicated in the header. This designation was reached after a long discussion in the working group.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document defines a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router.

Working Group Summary

It was difficult reaching a consensus on this document, hense the two w.g. last calls. This approach was requested by the Broad Band Forum. The issues were resolved by some changes in the document and an agreement to have it be an experimental RFC.

Document Quality

This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Significant reviews have been done by
Fernando Gont and Ran Atkinson.

Personnel

Bob Hinden is the Document Shepherd.
Brian Haberman is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Read the document and check for NITs.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I am not aware of any IPR disclosures.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

I am not aware of any IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Pretty solid. The people who had raised objections earlier, now support this going forward as an Experimental RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No serious problems.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The draft request a new IPv6 destination option and a new IPv6 link-scoped multicast address. No new registries are required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A