Hi Hemant I want this state this quite clearly that the AN is a network entity that is described in the Broad Band Forum (BBF) in many Technical Reports (TR) and is not required to be explained in an IETF draft or cut and paste. I never say this being done for other IETF RFC's that BBF requested IETF to work on or utilise it. A perfect example that is used widely in BBF document and by numerous Fixed Broadband Deployments is Option-82 as noted in RFC 3046. So we should follow that same agnostic approach.
The Aggregation Network is typically a Layer-2 network between the Access Node and Edge Node (BNG). The approach as is clearly covered in the draft is specifically in relation to an N:1 VLAN deployment model. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hemant Singh (shemant) Sent: August-17-10 6:16 PM To: Suresh Krishnan Cc: IPv6 WG Mailing List; Brian Haberman Subject: RE: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt Suresh, -----Original Message----- From: Suresh Krishnan [mailto:[email protected]] Sent: Monday, August 16, 2010 6:29 PM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List Subject: RE: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt >The AN functionality is defined in the BBF documents. I am not sure we >should cut and paste it from there. The document in question >(TR-101) is listed as a normative reference in this draft. Thanks much for the TR reference and your clarifications. Let me go through the TR document and then get back to you. However, I would still strive (if it's not too much trouble) to describe the AN in your document for IP properties like "is a LAN switch", can support an IPv6 address, will encapsulate ND RS message received from the home etc. Conversely, just highlight what IPv6 functionality the AN can't support. Sorry I don't fully comprehend your next question, so ill try to explain. When the Access Node receives the RS packet sent by IPv6 host, this packet is encapsulated in another IPv6 packet with the destination option in order to denote the Line-ID Option. This packet is then forarded to the Edge Node. The AN would do this for all received RS packets on configured ports upstream for the subscriber premises line. It has been decided in BBF that as we are "far from short of IPv6 Prefixes" that a unique prefix would be allocated to each home subscriber line. This can be done via DHCP_PD in the case of a Routed RG model or RA in the case you have a Bridged RG where by the RA is unicasted to ensure each IPv6 host is allocated a unique prefix. In some scenarios it may make sense to multicast the RA where by a single prefix is sent to the subscriber line, this would typically be the case for WiFi hot spot deployments as one typical example, others exist and vary from one SP to another etc etc etc.. For the DSL moden, or to be more precise the RG acting as a Layer-3 RG where by it sends out an NS_DAD when forming a LLA, from what I remember this is covered in one of the BBHome WG documents. I encourage you to write said contribution of your note to the BBF and present it to the BBHome WG. I understand your point on sending the NS_DAD before the RS, but unfortunately nothing prevents the latter and said solution must consider where we have IPv6 hosts directly connected where some will send an RS and do a DAD==0...unfortunate but true. Note that the main reason for having a "Line ID Option" is to identify the Subscriber Line, so im not sure BR Alan >No. The ethernet aggregation network will ensure (using MAC learning) >that only the specific AN that has the sender attached will get the RA >packet. What do you mean by "ethernet aggregation network"? Is that the Aggregation Node in Figure 1 of your document? I thought there is just a VLAN between the Edge Router and then Aggregation Node. Then it is clear from your document that there a VLANs between the Aggregation Node and each of the AN's. VLANs tell me the each of the Aggregation Node and the AN's are at least a network switch. So why wouldn't a RA destined to the home from the Edge Router with a destination of FF02::1 not reach other AN's? Isn't a switch supposed to flood packets to all ports for FF02::1? See this text from RFC 4541 in square bracket below. [In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is the address FF02::1 which is the all hosts link-scope address for which MLD messages are never sent. Packets with the all hosts link-scope address should be forwarded on all ports.] Also how does the above text map to the doctored RA with L3 multicast destination and L2 as unicast destination? >I am not sure I understand the problem. The original RS packet is sent >unchanged. IMHO, the LIO does not need any additional fields. The AN may receive any set of IPv6 packets, so first the AN somehow captures the multicast destined RS. Once such a multicast RS has been captured, the AN encaps the RS in an outer packet and adds the LIO to the outer packet. Well, isn't this a common type of RS in your document - meaning this multicast destined RS is commonly sent by the host in the home? My question was, how does the AN "sniff" or capture the unicast RS since the AN also needs to encapsulate such an RS in an outer packet right? By understanding how does the AN "sniffs" a unicast RS, I'd guess more of the L3 functionality of the AN as in how sophisticated is the AN's IPv6 deep packet introspection. Also, to reiterate, doesn't the AN need to process a unicast RS as well? >None of the devices do. The goal of the LIO is to make sure that two >different subscriber lines never get the same prefix for SLAAC. I understand the goal. Interesting. Can you give an example prefix sent in a PIO of a RA to a single home example, please? I want to see how much address space is being wasted by giving a different prefix to each home for the home to initiate SLAAC on. >If you are talking about duplicate link-locals, there is a different solution >proposed for it. Please see > >draft-costa-6man-dad-proxy-00 Thanks for this document reference. Another document for me to look at. However, I need to know if the home device can create a link-local address and then issue a NS(DAD)? Such details should be added to your document. Then as I said earlier, why not tighten DSL modem specific standards to say, the modem first creates a link-local address, performs DAD, and only then issues an RS. Then the RS is assured to include the Source Link Layer Address Option(SLLAO). On receiving such an RS, the Edge Router can now just unicast the RA back to the home. In a network architecture, I find it better to send a unicast control packet like the RA rather than sending an RA which is doctored for L2 as unicast with a L3 multicast destination. Also, since your document in section 2 draws a parallel to a DHCP relay agent, why not borrow one more idea from DHCPv6? Note DHCPv6 messages travel over a link-local address. So an IPv6 host does not issue a DHCPv6 SOLICIT unless the host has a link-local address. That is what I am suggesting - don't send the RS till the home device completes DAD for the link-local address. Anyone can keep me honest if it is prohibited by any of RFC 4862 or RFC 4861 for a host to wait for completing DAD for link-local address and then issuing an RS. Also, the home device in the DSL modem can certainly support a link-local address. At least the DSL modem has got to be a full IPv6 device, doesn't it? If not, why not? >As I said, the deployment models are covered in the BBF TR-101 document >update for IPv6. It is listed as a normative reference. As I said above, link-local address creation and performing DAD should be highlighted for what device such functionality is possible in Figure 1. Thanks much, Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
