On 12 Mar 2009, at 09:01, Pekka Savola wrote:
Could you describe why L3VPNs or such are inadequate? The discussion in S 1.1 of draft doesn't really help much to understand what are the actual problems with these. It discusses unwillingness to implement L3VPNs on hosts but it's not clear why this is needed;
A critical purpose of the option is to enable the sender to inform the receiver of the correct Sensitivity Label for the data carried in that particular packet. This is described in the draft. A single UDP/IP session (one example is ONC RPC, but that is not the only example) between a pair of nodes might have different packets with different Sensitivity Labels. This is also described in the draft. So the labels are also used end-to-end, as the draft describes in detail, not just in the middle, as the draft also describes. In the special case where a node or link is not MLS, then the edge router facing that non-MLS link inserts/removes the labels on behalf of those (typically MS Windows) systems -- as described in the document.
and also not being able to carry sensitivity label in L3VPN but it's not clear why you couldn't just pick a localized approach to designate the labels or map them in some manner; etc.
L3 VPNs simply aren't, and never have been, an ACL mechanism for drop/no-drop decisions on a per-packet basis. If the label were a destination option, then routers would be incapable of applying ACL rules (drop or not drop) based on this option, and could not enable non-MLS end systems to participate in the MLS deployment. THe reasons a router wants to look at this option are: 1) to decide whether to drop the packet rather than forward it out some interface or accept it in from some interface. This is also described in the document. [Cisco even has some documentation on this if one grep's for RFC-1108 in their IOS manuals.] and 2) to decide whether to insert/remove a label from a packet, in the special case of packets from/to a non-labelled link, as described in the draft.
FWIW, I wouldn't have a problem with this draft if it didn't add a hop-by-hop option
The existing IP MLS label options all have hop-by-hop semantics, as another goal is to have routers that will examine the labels *only* (repeat *only*) for the purposes of ACLs. This is also described in the draft. Cisco shipped RFC-1108 support in the very early 1990s. I think it is still present in (router) IOS today. Those MLS options have ~20 years of operational experience that they do NOT cause any operational issues for operators or for routers. So there is LOTS of actual experience that says having this as a hop-by-hop option is NOT a problem for any party. This is not speculation or proof-by-assertion, but actual experimental result from ~20 years of MLS network deployment with RFC-1038, RFC-1108, and FIPS-188. I build routers. I built routers at Cisco in the middle 1990s. I think I understand the generalised anxiety about things in the middle of the network. However, in this special case, we have LOTS of experience that this kind of option is not problematic. We also have spent ~15 years trying to make other approaches work for MLS networks -- none of them could be made to work. L3VPNs just are not an ACL mechanism. No less than one of the Routing ADs have said L3 VPNs cannot solve the requirements of MLS networking, to the IESG, within the past month. Yours, Ran [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
