Well, this RFC only changes the “unassigned” code points outlined in rfc7385 which in turn is already folded into IANA assignments. It does not changes any of the existing code points assignments for tunnel types, experimental, and reserved mentioned in rfc7385. So, as long as we update the IANA assignments with this new request, we are covered – with or without mentioning rfc7385 (IMHO). If you have strong objection, I can remove reference to rfc7385; otherwise, we can keep it as it should provide a better context for the reader (e.g., why we need to assign mirror code points).
Cheers, Ali From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>> Date: Tuesday, August 22, 2017 at 10:54 AM To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, "Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, "ops-...@ietf.org<mailto:ops-...@ietf.org>" <ops-...@ietf.org<mailto:ops-...@ietf.org>> Cc: "draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>" <draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12 I was referring to this document being marked as Updating rfc7385. In any case, that works for me. Thanks! Alvaro. On 8/22/17, 10:41 AM, "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>> wrote: Hi Alvaro, I am not modifying rfc7385 but rather trying to maintain backward/forward compatibility with it. The reason, I am defining additional “experimental" and “reserved” code points, is to maintain backward/forward compatibility with the rfc7385 code points. The new “experimental” and “reserved” code points (i.e., 0x7B – 0x7E, and 0x7F) are mirror images of the ones in rfc7385 (i.e., 0xFB – 0xFE, and 0xFF). If I don’t create these mirror images and leave them “unassigned”, then if somebody creates a tunnel type of 0x7B, then the corresponding composite tunnel type of that would be 0xFB which will conflict with existing code points in rfc7385 (i.e., 0xFB is defined as experimental). Cheers, Ali From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>> Date: Monday, August 21, 2017 at 6:26 PM To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, "Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, "ops-...@ietf.org<mailto:ops-...@ietf.org>" <ops-...@ietf.org<mailto:ops-...@ietf.org>> Cc: "draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>" <draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12 Ali: Hi! RFC7385 already defines an Experimental range, why do we need another one? Same question about reserving 0x7F (if rfc7385 already reserved 0xFF). One of the reasons I’m asking is because if you’re only changing the 0x0C – 0xFA range, which is currently unassigned, the you (1) only need to include those values in this document, and (2) you don’t need to Update rfc7385: Thanks! Alvaro. On 8/21/17, 5:47 PM, "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>> wrote: Trying for the 2nd time because of the format scramble in the previous email. Value Meaning Reference 0x0C-0x7A Unassigned 0x7B-0x7E Experimental this document 0x7F Reserved this document 0x80-0xFA Reserved for Composite tunnel this document 0xFB-0xFE Experimental [RFC7385] 0xFF Reserved [RFC7385] From: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>> Date: Monday, August 21, 2017 at 5:14 PM To: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, "Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, "ops-...@ietf.org<mailto:ops-...@ietf.org>" <ops-...@ietf.org<mailto:ops-...@ietf.org>> Cc: "draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>" <draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12 Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, <ssa...@cisco.com<mailto:ssa...@cisco.com>>, <jdr...@juniper.net<mailto:jdr...@juniper.net>>, <ju1...@att.com<mailto:ju1...@att.com>>, <sbout...@vmware.com<mailto:sbout...@vmware.com>>, <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>, <martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>, <aret...@cisco.com<mailto:aret...@cisco.com>>, <db3...@att.com<mailto:db3...@att.com>>, <akat...@gmail.com<mailto:akat...@gmail.com>>, Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> Resent-Date: Monday, August 21, 2017 at 5:15 PM Hi Alvaro, You’re right. I had some holes in my assignment. Following should fix it. ValueMeaningReference 0x0C-0x7AUnassigned 0x7B-0x7EExperimentalthis document 0x7FReservedthis document 0x80-0xFAReserved for Composite tunnelthis document 0xFB-0xFEExperimental RFC7385] 0xFFReserved[RFC7385] Thanks, Ali From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>> Date: Monday, August 21, 2017 at 1:05 PM To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, "Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, "ops-...@ietf.org<mailto:ops-...@ietf.org>" <ops-...@ietf.org<mailto:ops-...@ietf.org>> Cc: "draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>" <draft-ietf-bess-evpn-etree....@ietf.org<mailto:draft-ietf-bess-evpn-etree....@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12 Ali: Hi! So, you’re really only changing the 0x0C – 0xFA range, right? If my hex is not wrong, you’re missing some pieces below: 0x40-0x7F, and 0xC0-0xCF, which I’m assume remain Unassigned, right? Thanks! Alvaro. On 8/16/17, 5:54 PM, "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>> wrote: To maximize backward/forward compatibility, let's retain the value for "Experimental Use” and “Reserved” as before per [RFC7385] and reduce the range for Composite tunnel for this draft. So, the changes will be >From existing IANA assignments: 0x0C - 0xFA Unassigned 0xFB - 0xFE Experimental [RFC7385] 0xFF Reserved [RFC7385] To: 0x0C – 0x3F Unassigned 0x80 – 0xBF reserved for composite tunnel 0xD0 – 0xFA Unassigned 0xFB - 0xFE Experimental [RFC7385] 0xFF Reserved [RFC7385]
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
