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

[Behcet Sarikaya <[e-mail]>]

Replace DSL
with Broadband in the text below as
DSL Forum is now called
Broadband Forum.

Regards,

Behcet



----- Original Message ----
> From: Jari Arkko <[e-mail]>
> To: Suresh Krishnan (QB/EMC) <[e-mail]>; IETF IPv6 Mailing 
>List <[e-mail]>
> Sent: Wed, October 27, 2010 3:36:38 PM
> Subject: review of draft-krishnan-6man-rs-mark-08
> 
> 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
> 
> --------------------------------------------------------------------
> IETF  IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>