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

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Oct 2010 23:36:38 +0300

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 Oct 2010 23:08:41 -0400

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

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

> Expand DSL and PPP terms.

OK.

>> the aggregation network.  This is called the N:1 VLAN allocation

OK.

>>                         termination function or GPON termination

OK.

> because you can use the L2 and L3 destinations from the original packet. 

Yes. Your understanding is correct.

> captures IPv6 packets that have protocol <P> and destination address <D> 

OK.

> the incoming packet, and for the L2 source address you use the AN's own 

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.

> specify in RFC 4861 for ND packets.) Same for Section 6.1.

OK.

> 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.
.
> 5.2 does not check for that... you should check for it.

OK.

> different encodings. You could start with ID Type = 0 which has only 

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

Thanks
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2010 09:08:23 +0300

Suresh,

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

Yes.

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

That's one approach, but -08 does not even say that. If that's the 
approach we're taking with regards to this field, then you should say 
something like "The contents of this field are not standardized and have 
only local significance."

However, I would personally probably insert a type octet in front so 
that it would be possible to add different types of identification 
later. But I don't feel strongly about it.

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Oct 2010 18:42:02 -0400

Hi Jari,

>> mapped to the same virtual interface on the Edge Router."

OK. Will update this.

> later. But I don't feel strongly about it.

Sounds good. Will do. Ole also suggested using something like the relay 
agent Remote-ID (RFC4649).

Thanks
Suresh