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

May be this will make it:

Actual text:
The CE router MAY support 6in4 functionality.  If 6rd is implemented,
6in4 MUST be supported as well.

New text:
The CE router MAY support 6in4 functionality.  If 6rd is implemented,
6in4 is already supported as well, as the underlying protocol/technology 
is the same, being the only difference, having the mention of “6in4” 
in the GUI/CLI (just an example) if it is being configured manually,
or even stating that in the relevant documentation. In other words, 
no additional code is required for the support of 6in4 when 6rd is already supported

Saludos,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Responder a: <jordi.palet@consulintel.es>
Fecha: miércoles, 12 de abril de 2017, 19:52
Para: "v6ops@ietf.org" <v6ops@ietf.org>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Hi Barbara,

    Thanks a lot for the explanation. I see your point clearer now.

    I’ve never intended (once I made the first question on this in the list and got some inputs, before the first individual ID version), to use MUST.

    I used MUST for the 6in4 if 6rd is available, because when you have 6rd support in any router, you can just select 6rd and configure a 6in4 and it works, but many ISPs don’t even realize it because they can’t see “a menu” (if using the GUI, just an example), 6in4. So, my intent was to make it more “obvious”.

    If you feel that using the work MUST “breaks” it, I will find an alternative way to explain it and keep using MAY in this case.

    Ii think we will be in-sync with that change, unless you spot anything else in the current version … of course happy to heard about that!

    Regards,
    Jordi

    -----Mensaje original-----
    De: "STARK, BARBARA H" <bs7652@att.com>
    Responder a: <bs7652@att.com>
    Fecha: miércoles, 12 de abril de 2017, 19:44
    Para: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
    Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

        > What I’m saying is that it makes sense to have a single transition mechanism
        > (if it is possible, and actually IT IS with 464XLAT) in both kind of networks.

        464XLAT is not useful to me. It is not used in any of the networks of my employer. Therefore, it will not be requested in any RFP that I help author, nor will it be required (MUST) by any document referenced by an RFP that I help author. If it magically appears in CE routers without getting in my way, then I won't mind it being there.

        -------- snip -----------

        > Despite that, I think and it has been said by real operators in this list a few
        > months ago, they actually use RFC7048 for their RFQs to vendors, and they
        > need support of not just 6rd and DS-lite as we have today. Some of them
        > mention specifically lw4o6, 464XLAT and MAP.

        RFC 7084 is a mandatory requirement of BBF TR-124, which my company uses for its RFPs. Since my RFPs will not ever require (MUST) 464XLAT, if 7084-bis were to make it a MUST requirement, then 7084-bis would be useless to me as a reference and I would have to ensure 7084-bis was not a requirement in TR-124. And as someone who's written a lot of CE router RFPs, I know for a fact that it is not at all difficult to say "Req1: Do all mandatory requirements of RFC 7084-bis." "Req2: Do 464XLAT as described in RFC 7084-bis."

        To be clear: I do not object to the current language of "SHOULD" for 464XLAT. I object to the proposal that it become "MUST".
        While I'm at it, I also object to the current language that "If 6rd is implemented, 6in4 MUST be supported as well."  This statement will make the document useless for me as a RFP reference (directly or indirectly), because I will not be requiring 6in4 in my CE routers.

        If you want IETF to produce a CE router profile that is just intended to be useful for some operators, please don't call it 7084-bis or have it obsolete 7084. Make it something else (not 7084-bis). A 7084-bis that mandates (MUST) any particular transition technology other than the one deployed in my network is unacceptable to me. And that includes mandating a technology not deployed in my network, just because it implements one that is deployed.

        For this document to be a true replacement of RFC 7084, it MUST NOT introduce any "MUST" requirements that an operator currently using RFC 7084 (directly or indirectly) does not want in their CE router.
        7084-bis MUST NOT interfere with, place undue burden on, or add cost to existing deployments and the CE routers used in those existing deployments.
        Barbara

    **********************************************
    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.

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    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.

**********************************************
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.