review of draft-krishnan-6man-rs-mark-08

[Jari Arkko <[e-mail]>]

Suresh,

I have reviewed your draft. A few comments below. Overall, I think its 
not perfect but it is an acceptable solution to deal with the quirks of 
the broadband access networks. I think the draft is ready for WG 
adoption, and I support its adoption. However, there were a number of 
details that need to be more carefully specified before the document is 
ready to become an RFC.

Here are my comments:

> The applicability is limited to the N:1 VLAN allocation model.
>   

Since this is in the abstract, could you expand "N:1 VLAN" to something 
a bit more descriptive? I know what it is, you know what it is, but some 
other persons later reading this RFC may not be clear about it without 
sufficient DSL architecture background.

> DSL is a widely deployed access technology for Broadband Access for
> Next Generation Networks.  While traditionally DSL access networks
> were PPP based some networks are migrating from the traditional PPP
> access model into a pure IP-based Ethernet aggregated access
> environment. 

Expand DSL and PPP terms.

> One of the Ethernet and GPON aggregation models specified in this
> document bridges sessions from multiple user ports behind a DSL
> Access Node (AN), also referred to as a DSLAM, into a single VLAN in
> the aggregation network.  This is called the N:1 VLAN allocation
> model.
>   

Expand DSLAM and GPON...

> AN                      A DSL or GPON Access Node.  The Access Node
>                         terminates the phyiscal layer (e.g.  DSL
>                         termination function or GPON termination
>                         function)

physical

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

In Section 1.1 you noted that the AN does not implement an IPv6 stack 
but performs limited inspection and modification. You should add a note 
to this section to state the capabilities that are required by the AN in 
order to do what is suggested above, i.e., be capable of limited 
tracking of certain packets and be able to send a packet. One question 
that I have is if this implies that the AN needs to implement ND itself, 
to find the destination MAC address of the tunnel endpoint? I guess not, 
because you can use the L2 and L3 destinations from the original packet. 
Please confirm...

> When an end-device sends out a Router Solicitation, it is received by
> the access node. 

I would prefer to see a more exact description here. "The access node 
captures IPv6 packets that have protocol <P> and destination address <D> 
and ..."

> 5.1. On receiving a Router Solicitation from the end-device

I like this Section, but as noted above I'd like to know what part of ND 
is required or not. I think you can copy the destination address from 
the incoming packet, and for the L2 source address you use the AN's own 
MAC address?

> 5.2. On receiving a Router Advertisement from the Edge Router

Please be more specific about what packets the AN needs to listen on. 
Destination, source addresses, protocols, etc. (Similar to what we 
specify in RFC 4861 for ND packets.) Same for Section 6.1.

> The destination address of the
> outer IPv6 datagram MUST be set to [KNOWN_VALUE_X, say fe80::0] .
>   

You need to write this out, I presume you mean a new link-local scope 
multicast address AllBBFAccessNodes or something similar? You'll also 
need an IANA considerations section to allocate that. But I must say I 
did not fully understand why this address is required. Would it be 
possible to send it to the address from which you have previously 
received tunneled packets from? Or just all-nodes? Note that later in 
Section 6.2 you say that the L2 destination address is the last address 
from which you received a tunneled packet from. It would seem that the 
L3 could easily be set the same way.

Are there additional considerations regarding blocking similar packets 
from coming from the Internet or the subscriber side? Note that 6.2 says 
that the edge router should use a link local source address, but Section 
5.2 does not check for that... you should check for it.

>     LineIDLen
>
>        Length of the Line Identification field in number of octets.
>
>     Line Identification
>
>        Variable length data inserted by the Access Node describing the
>        subscriber agent circuit identifier corresponding to the logical
>        access loop port of the Access Node from which the RS was
>        initiated.
>   

Don't we need an "ID Type" field or similar, so that we can specify 
different encodings. You could start with ID Type = 0 which has only 
local significance.

Jari