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

[Suresh Krishnan <[e-mail]>]

Hi Jari,
   Thanks for your review. Please find responses inline.

On 10-10-27 04:36 PM, Jari Arkko wrote:
> 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.

Does replacing "N:1 VLAN allocation model" with

"broadband network deployment scenarios where multiple user ports are 
mapped to the same virtual interface on the Edge Router."

work?

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

OK.

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

OK.

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

OK.

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

Yes. Your understanding is correct.

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

OK.

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

Yes. This is the intent. I will change the text in Section 5.1 to 
clarify that both L2 and L3 destination addresses are copied from the 
original RS.

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

OK.

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

I think all nodes multicast should work just fine as the destination. I 
will make the change in the next revision.
.
> 
> 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.

OK.

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

The way I say it, the line ID was an opaque field. Do we need to define 
what is inside?

Thanks
Suresh