Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

["Ali Sajassi (sajassi)" <[e-mail]>]

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)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 22, 2017 at 10:54 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>> 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)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 21, 2017 at 6:26 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 21, 2017 at 5:14 PM
To: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>, "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Thomas Morin <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 21, 2017 at 1:05 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>> 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]