Subject: RE: [16NG] Comments ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

From: "Narvaez, Paolo \(Paolo\)" <[email-masked]>
Date: Wed, 10 Jan 2007 14:16:16 -0600

Hongseok, 

Thanks for the reply. Please find below some additional comments to your
response.

Thanks,
Paolo

> -----Original Message-----
> From: Hongseok Jeon [mailto:[email-masked]] 
> Sent: Friday, December 22, 2006 5:31 AM
> To: Narvaez, Paolo (Paolo)
> Cc: [email-masked]
> Subject: RE: [16NG] Comments 
> ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt 
> > 
> > Section 5.3 - 
> > 
> > 
> > "When performing bridging, any packets destined for one of the
> >    addresses in the Filtering Database SHALL be forwarded 
> directly to
> >    that port, if appropriate for the particular scenario, and all
> >    packets received from a port, for which the packet's 
> > destination MAC
> >    address is also an entry for that port in the Filtering Database,
> >    SHALL be silently discarded."
> > 
> > 
> > 2) It does not mention what happens to packets with a MAC DA 
> > equal to the MAC address of a SS. These should not be forwarded.
> 
> It depends on the scenario. In case of public access 
> scenario, the packets 
> should be transmitted to AR and then relayed to the intended 
> SS by relaying 
> function on AR. In VLAN scenario, the packets are directly 
> forwarded to the 
> intended SS by bridge. 

For the public access case, I understand why the AR would want to
forward a packet back to another SS based on a destination IP address.
But why would the AR forward based on a MAC DA?  That MAC address should
not even have been known to the originating SS. In fact, the AR should
drop any Ethernet frame with a unicast MAC DA that does not match the
MAC address of one of its interfaces. 

If the public access case is supposed to prevent direct Ethernet
connectivity between SSs, packets with a MAC DA = SS MAC address should
be dropped. Forwarding them to the AR is a waste of bandwidth, since
they will be dropped by the AR anyway.

> > Section 6.1 -
> > 
> > "Figure 3 depicts an IEEE 802.16 network deployment scenario without
> >    direct host-to-host communication.  In the general public access
> >    case, direct communication between nodes is restricted because of
> >    security and accounting issues.  In this scenario, the 
> bridge SHALL
> >    forward all packets received from any radio side port to 
> a network
> >    side port.  Peer-to-peer communication is not supported by 
> > the bridge
> >    and all packets originated from a SS should be delivered 
> to an AR."
> > 
> > 4) What is the behavior of the bridge in the public access 
> > scenario when the Ethernet frame arriving over the air (or 
> > from the AR) has one or more VLAN tags? Is the VLAN tag 
> > stripped off? Is it ignored? Are SSs and ARs forbidden from 
> > sending VLAN-tagged frames to the bridge?
> 
> Public access scenario does not consider Ethernet frames 
> embedded with VLAN
> tag.
> Ethernet frames with VLAN tag are handled in VLAN scenario and we will
> provide 
> the detail procedures in next version document. 

In the public access scenario how do you guarantee that the terminal
does not send Ethernet frames with VLAN tags? How does the bridge react
if this happens? The text should explain how this is prevented or should
explain how the bridge deals with these packets.

> > Section 7.2 -
> > 
> > "The bridge SHALL support filtering of all packets received from a
> >    network side port to a destination MAC address or Multicast IP
> >    address not existing in the ICT or expired address."
> > 
> > 
> > 7) What happens if there are multiple network side ports? In 
> > that case, I think you would want to filter broadcasting to 
> > the air interfaces, but you will still want to broadcast on 
> > the remaining network ports.
> 
> Filtering in this document focuses on multicast data, and 
> broadcasting 
> data destined for sleep mode SSs.  Broadcast data for wake-up 
> SSs does 
> not be filtered. Hosts in network side always wake up and 
> thus broadcast 
> data for the host does not need to be filtered. 

I agree. The document should make a distinction between the different
types of ports and clarify that filtering only applies to the air ports.

> > Section 7.6 -
> > 
> > "The AR SHALL have packet-relay functionality.  The AR 
> relays packets
> >    destined for IP broadcast address and link-local scoped multicast
> >    addresses to incoming interface again.  When relaying, 
> AR does not
> >    decrease the value of TTL or Hop Limit."
> > 
> > 8) Can this on-link packet-relay functionality be performed 
> > at the bridge instead of the AR? Since the bridge already has 
> > several IP-snooping capabilities (ARP-proxy, ND-relay) and 
> > has knowledge of IP addresses, it seems that it could also 
> > perform this function. In this case, the AR would not require 
> > any modifications and would behave like a standard AR. The 
> > bridge requires modifications anyways.
> 
> The position of packet-relay functionality on AR is based on 
> the assumption
> which 
> all traffics from SS should be transmitted to AR in the public access
> scenario. 

I understand that the current draft is placing the relay functionality
in the AR. My question is about the rationale behind it. It seems that
this functionality could also be performed by the bridge. Two benefits
of placing this functionality at the bridge is that 1) it eliminates the
round-trip multicast traffic to and from the AR and 2) no modifications
are required at the AR (the AR is a standard router). Therefore, what is
the design rationale for placing the relay functionality in the AR?

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: "Hongseok Jeon" <[email-masked]>
Date: Tue, 16 Jan 2007 17:54:28 +0900

Paolo, 

Thank you for your comments. 

Now we are going to update our draft. It will have lots of change.

The updated draft does not use any tunnels between bridges.      
In the updated draft, MAC-Forced Forwarding [RFC4562] can be used 
to send all the packets from SSs toward AR in case of public access scenario

and IGMP/MLD snooping [RFC4541] provides an efficient transmission of IP
multicast data. 
Also some additional functionalities is to be presented for broadcast
filtering.  

Best Regards,
Hongseok

> From: Narvaez, Paolo (Paolo) [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 5:16 AM
> To: Hongseok Jeon
> Cc: [email-masked]
> Thanks for the reply. Please find below some additional 
> comments to your response.
> 
> Thanks,
> Paolo
> 
> destination 
> > > MAC
> > > 2) It does not mention what happens to packets with a MAC 
> DA equal 
> > > to the MAC address of a SS. These should not be forwarded.
> > 
> > It depends on the scenario. In case of public access scenario, the 
> > packets should be transmitted to AR and then relayed to the 
> intended 
> > SS by relaying function on AR. In VLAN scenario, the packets are 
> > directly forwarded to the intended SS by bridge.
> 
> 
> For the public access case, I understand why the AR would 
> want to forward a packet back to another SS based on a 
> destination IP address.
> But why would the AR forward based on a MAC DA?  That MAC 
> address should not even have been known to the originating 
> SS. In fact, the AR should drop any Ethernet frame with a 
> unicast MAC DA that does not match the MAC address of one of 
> its interfaces. 
> 
> If the public access case is supposed to prevent direct 
> Ethernet connectivity between SSs, packets with a MAC DA = SS 
> MAC address should be dropped. Forwarding them to the AR is a 
> waste of bandwidth, since they will be dropped by the AR anyway.
> 
> 
> 
> 
> > > Section 6.1 -
> > > 
> > >    side port.  Peer-to-peer communication is not supported by the 
> > > bridge
> > > 4) What is the behavior of the bridge in the public 
> access scenario 
> > > when the Ethernet frame arriving over the air (or from 
> the AR) has 
> > > one or more VLAN tags? Is the VLAN tag stripped off? Is 
> it ignored? 
> > > Are SSs and ARs forbidden from sending VLAN-tagged frames to the 
> > > bridge?
> > 
> embedded with 
> > VLAN tag.
> > provide the detail procedures in next version document.
> 
> In the public access scenario how do you guarantee that the 
> terminal does not send Ethernet frames with VLAN tags? How 
> does the bridge react if this happens? The text should 
> explain how this is prevented or should explain how the 
> bridge deals with these packets.
> 
> 
> 
> > > Section 7.2 -
> > > 
> > > 7) What happens if there are multiple network side ports? In that 
> > > case, I think you would want to filter broadcasting to the air 
> > > interfaces, but you will still want to broadcast on the remaining 
> > > network ports.
> > 
> > data destined for sleep mode SSs.  Broadcast data for 
> wake-up SSs does 
> > not be filtered. Hosts in network side always wake up and thus 
> > broadcast data for the host does not need to be filtered.
> 
> I agree. The document should make a distinction between the 
> different types of ports and clarify that filtering only 
> applies to the air ports.
> 
> 
> 
> > > Section 7.6 -
> > > 
> > > 8) Can this on-link packet-relay functionality be 
> performed at the 
> > > bridge instead of the AR? Since the bridge already has several 
> > > IP-snooping capabilities (ARP-proxy, ND-relay) and has 
> knowledge of 
> > > IP addresses, it seems that it could also perform this 
> function. In 
> > > this case, the AR would not require any modifications and would 
> > > behave like a standard AR. The bridge requires modifications 
> > > anyways.
> > 
> > The position of packet-relay functionality on AR is based on the 
> > assumption which all traffics from SS should be transmitted 
> to AR in 
> > the public access scenario.
> 
> 
> I understand that the current draft is placing the relay 
> functionality in the AR. My question is about the rationale 
> behind it. It seems that this functionality could also be 
> performed by the bridge. Two benefits of placing this 
> functionality at the bridge is that 1) it eliminates the 
> round-trip multicast traffic to and from the AR and 2) no 
> modifications are required at the AR (the AR is a standard 
> router). Therefore, what is the design rationale for placing 
> the relay functionality in the AR?