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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
