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

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 17 Aug 2017 00:54:03 +0000

Hi Carlos,

Thanks for your review and comments. Please see inline for my responses.

On 8/7/17, 2:46 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:

Reviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review result: Has Nits (and one potential Issue)

I am the OPS-DIR reviewer and in general I do not have operational concerns
with this document.

The main issue I have is in regards to the redefinition of the MSB of the
Tunnel Type, and associated backwards/forward compatibility considerations.

I note that RFC 7385 is Normatively referenced by a number of I-Ds:
https://datatracker.ietf.org/doc/rfc7385/referencedby/
BUT draft-ietf-bess-evpn-etree is not:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/referencedby/

So would those former be pointing to old info? And what other Backwards Compat
considerations are there?

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]

Further, some nits and editorials for your consideration:

   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree). A solution
   framework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
   Multiprotocol Label Switching (MPLS) Network").

Proposed? Or Described / Defined?
OK, changed to "described"

Same comment for the first sentence of the second paragraph of the Intro.
Changed to "describes"

   This document makes use of the
   most significant bit of the scope governed by the IANA registry
   created by RFC7385, and hence updates RFC7385 accordingly.

RFC 7385 does not mention a "scope". This really talks about the Tunnel Type.
Please reword for unambiguous clarity.

Changed it to "This document makes use of the most significant bit of the PMSI tunnel type governed by the IANA ..."

3.1 Known Unicast Traffic

   To support the above ingress filtering functionality, a new E-TREE
   Extended Community with a Leaf indication flag is introduced [section
   5.2]. This new Extended Community MUST be advertised with MAC/IP

Section 5.2 is not a referenced citation.

Changed it to "[5.1]". Nice catch! Thanks.

Similar issue with [5.1] at:

   In PBB-EVPN, the PE advertises a Root/Leaf indication along with each
   B-MAC Advertisement route, to indicate whether the associated B-MAC
   address corresponds to a Root or a Leaf site. Just like the EVPN
   case, the new E-TREE Extended Community defined in section [5.1] is
   advertised with each MAC Advertisement route.

This paragraph refers to the correct section!

3.2 BUM Traffic

Please expand to Broadcast, Unkonwn, Multicast.

Done.

   When receiver ingress-replication label is needed, the high-order bit
   of the tunnel type field (Composite Tunnel bit) is set while the
   remaining low-order seven bits indicate the tunnel type as before.

I believe it would be useful to depict the Composite Tunnel bit in Figure 5 as
well... It's not only a 1-octet Type.

I believe the description is clear in the text and adding additional diagram and text to describe the diagram would make it too verbose.

Also, please note:

  ** Obsolete normative reference: RFC 5226

Changed it to RFC 8126.

  ** Downref: Normative reference to an Informational RFC: RFC 7387

That's OK.

Thanks again for your review,
Ali

Thank you!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 17 Aug 2017 01:57:46 +0000

Thanks Ali. General Ack to all your responses, make sense.

A follow-up question, though:

I notice “Reserved” in a few places. For example in Figure 4, which seems to make sense as the Reserved is a Must Be Zero (MBZ)

However, on the Flags, it says:

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |  reserved   |L|
         +-+-+-+-+-+-+-+-+

…

 Initial registrations are as follows:

         bit               Name                         Reference

         0-6               Reserved                     This document
         7                 Leaf-Indication              This document

Do you mean “Reserved” for the unassigned bit flags, or “Unassigned” (see the different in RFC 8126).

Finally, in the sentence:

   The reserved bits should be set to zero by the transmitter and should
   be ignored by the receiver.

Do those two “should” mean “should”, “SHOULD”, or “MUST”?

Thanks!

Carlos.

On Aug 16, 2017, at 8:54 PM, Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

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]

Proposed? Or Described / Defined?
OK, changed to “described"

Changed to “describes"

Changed it to “This document makes use of the most significant bit of the PMSI tunnel type governed by the IANA …"

Changed it to “[5.1]”. Nice catch! Thanks.

3.2 BUM Traffic

Done.

Also, please note:

Changed it to RFC 8126.

That’s OK.

Thank you!

Carlos.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 18 Aug 2017 04:48:22 +0000

Hi Carlos,

Thanks for additional comments. Please refer to my replies inline.

From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 16, 2017 at 6:57 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |  reserved   |L|
         +-+-+-+-+-+-+-+-+

…

         bit               Name                         Reference

WRT to IANA, I meant “Unassigned”.  I will update both the flag digram and the IANA section to indicate “unassigned".

I will change it to "The reserved and unassigned bits SHOULD be set to zero by the transmitter and SHOULD be ignored by the receiver."

Thanks again,
Ali

Thanks!

Carlos.

Hi Carlos,

0x0C - 0xFA Unassigned

3.2 BUM Traffic

Done.

Also, please note:

Changed it to RFC 8126.

That’s OK.

Thank you!

Carlos.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 21 Aug 2017 20:05:46 +0000

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)" <[email-masked]<mailto:[email-masked]>> wrote:

  0xFF
 Reserved [RFC7385]

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 22 Aug 2017 00:14:58 +0000

Hi Alvaro,

You're right. I had some holes in my assignment. Following should fix it.

   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]

Thanks,
Ali

From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 21, 2017 at 1:05 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

0x0C - 0xFA Unassigned

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 22 Aug 2017 00:47:03 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 21, 2017 at 5:14 PM
To: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>
Resent-Date: Monday, August 21, 2017 at 5:15 PM

Hi Alvaro,

   Value MeaningReference
   0x0C-0x7A Unassigned
   0x7B-0x7E Experimentalthis document
   0x7F Reservedthis document
   0x80-0xFA Reserved for Composite tunnelthis document
   0xFB-0xFE Experimental RFC7385]
   0xFF Reserved[RFC7385]

Thanks,
Ali

Ali:

Hi!

Thanks!

Alvaro.

0x0C - 0xFA Unassigned

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 22 Aug 2017 01:26:50 +0000

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)" <[email-masked]<mailto:[email-masked]>> wrote:

Value               Meaning                            Reference
0x0C-0x7A      Unassigned

Hi Alvaro,

You’re right. I had some holes in my assignment. Following should fix it.

   Value MeaningReference
   0x0C-0x7A Unassigned

Thanks,
Ali

Ali:

Hi!

Thanks!

Alvaro.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 22 Aug 2017 17:41:55 +0000

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

Date: Monday, August 21, 2017 at 6:26 PM

Ali:

Hi!

Thanks!

Alvaro.

Value               Meaning                            Reference
0x0C-0x7A      Unassigned

Hi Alvaro,

   ValueMeaningReference
   0x0C-0x7AUnassigned
   0x7B-0x7EExperimentalthis document
   0x7FReservedthis document
   0x80-0xFAReserved for Composite tunnelthis document
   0xFB-0xFEExperimental RFC7385]
   0xFFReserved[RFC7385]

Thanks,
Ali

Ali:

Hi!

Thanks!

Alvaro.

0x0C - 0xFA Unassigned

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 22 Aug 2017 17:54:20 +0000

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)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alvaro,

Cheers,
Ali

Ali:

Hi!

Thanks!

Alvaro.

Value               Meaning                            Reference
0x0C-0x7A      Unassigned

Hi Alvaro,

   ValueMeaningReference
   0x0C-0x7AUnassigned

Thanks,
Ali

Ali:

Hi!

Thanks!

Alvaro.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 22 Aug 2017 18:11:53 +0000

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

Date: Tuesday, August 22, 2017 at 10:54 AM

Thanks!

Alvaro.

Hi Alvaro,

Cheers,
Ali

Ali:

Hi!

Thanks!

Alvaro.

Value               Meaning                            Reference
0x0C-0x7A      Unassigned

Hi Alvaro,

   ValueMeaningReference
   0x0C-0x7AUnassigned

Thanks,
Ali

Ali:

Hi!

Thanks!

Alvaro.

0x0C - 0xFA Unassigned