Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

[JORDI PALET MARTINEZ <[e-mail]>]

    > On Apr 12, 2017, at 5:52 AM, STARK, BARBARA H <[e-mail]> wrote:
    > 
    >> I tend to agree with you but with a slightly different proposal:  pick ONE
    >> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P
    >> mechanism (MAP-E).
    > 
    > Because RFC 7084 is also used as a mandatory reference in BBF TR-124 (used by telco ISPs to help with CE router RFPs), and most ISPs have no interest in requiring capabilities that are not useful to or relevant in their deployment, there MUST NOT be any mandatory transition mechanisms included in a 7084-bis.
    
    No hats
    
    I'm not sure I would go so far as your respective statements, but I agree that we don't want a laundry list of mechanisms that mostly make equipment more expensive, harder to use, and harder to sell. It's kind of pointless. It seems to me that if a network wants to use a given transition technology, it 

[Jordi] I disagree here. Adding the actual transition mechanism (all them) in the v-01 of the document (submitted today) means 0,15% of extra flash memory (slide 4 in my Chicago presentation) in the average “very low cost” CE today available in the market (8 Mbytes flash, leaving still about 2.5-3 Mbytes for future upgrades). I’ve done this analysis based on OpenWRT and several products in the market that use this or similar Linux-based implementations, which I think is probably 80% of the market today, and going up. More and more product now start using 16 Mbytes flash. There is no need for more CPU power or more RAM. In fact, there were 3 “major well-know” vendors in the meeting room and didn’t said that I’m wrong on this. May be if they are reading, they could confirm.

should specify that to its vendor(s) in the RFP/RFQ.

[Jordi] The point here is what I’ve indicated several times. Vendors are telling ISPs that they don’t support a given transition mechanism such as lw4o6, 464XLAT or MAP, because they’re aren’t in the RFC7084. Smaller ISPs have even a worst situation because they can’t do RFQs as their quantity is too small, so they just go to retail. This has been confirmed in the list by several folks.

    
    A data point of interest: https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-transition-mechanism-based-information.html is being flagged in the media as a reason to not deploy IPv6 - transition technologies that use tunnels apparently bypass intrusion detection technologies. I would argue that the point is flawed; put the tunnel intrusion detection technology between the tunnel endpoints and the user, problem solved. One issue there might be with the IDS itself - if it only looks at IPv4, it's not going to detect much in IPv6.
    
    But in general, I tend to think that a better recommendation would be to walk through our list of technologies and obsolete them - like we did with 6to4.
    
    > Barbara
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.