Subject: [nvo3] is it resonsable that draft-dunbar-nvo3-nva-mapping-distribution-01 suggests NVE using bit-map to represent its supported VNs?

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 Jan 2015 21:53:45 +0000

When a NVE is initialized or re-started, it uses Virtual Network scoped instances of the IS-IS to announce all the Virtual Networks in which it is participating.

The  current draft-dunbar-nvo3-nva-mapping-distribution-01 suggests using the bit map to represent the supported VNs.
   +-+-+-+-+-+-+-+-+
   |     Type      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |  Start VN ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VNID bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Enabled-VN TLV

For 24-bits VN ID, there could be 16million VNs. Even with the "Start VN ID" listed, the number of bytes for the bitmap can be very large.

Therefore, I think it is better to have a flag indicating if the VNs are listed individually, Upper/Lower ranges, or bit mapped.

Any other suggestions?

Linda

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Jan 2015 14:26:49 -0800

On Thu, Jan 29, 2015 at 1:53 PM, Linda Dunbar <[email-masked]> wrote:
> When a NVE is initialized or re-started, it uses Virtual Network scoped
> instances of the IS-IS to announce all the Virtual Networks in which it is
> participating.
>
>
>
> The  current draft-dunbar-nvo3-nva-mapping-distribution-01 suggests using
> the bit map to represent the supported VNs.
>
>    +-+-+-+-+-+-+-+-+
>
>    |     Type      |                  (1 byte)
>
>    +-+-+-+-+-+-+-+-+
>
>    |   Length      |                  (1 byte)
>
Hi Linda,

First a couple of meta comments on the draft:

- Sizes of type and lengths in TLVs are inconsistent (some 16 bits,
some 32 bits). It might be just as well to make all of them 16 bits.
- For the above, I think the Start VNID field is 4 bytes not 2 bytes.
- Please avoid implicitly setting constraints on the data plane in the
definition of control plane. For instance, I've already made arguments
that VN ID might be thirty-two bits, and there's little cost to
defining thirty-two bit VN IDs in the control plane.

>
>
>
>
> For 24-bits VN ID, there could be 16million VNs. Even with the “Start VN ID”
> listed, the number of bytes for the bitmap can be very large.
>
>
>
> Therefore, I think it is better to have a flag indicating if the VNs are
> listed individually, Upper/Lower ranges, or bit mapped.
>
I wouldn't use a flag for that, it's probably cleaner to define
another TLV type that gives a list of VNIDs. Either the list or
bit-map can be used interchangeably.

Tom

>
>
> Any other suggestions?
>
>
>
> Linda
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 Jan 2015 22:57:01 +0000

Tom, 

Comments inserted below:

-----Original Message-----

- Sizes of type and lengths in TLVs are inconsistent (some 16 bits, some 32 bits). It might be just as well to make all of them 16 bits.

[Linda] will correct it. 

- For the above, I think the Start VNID field is 4 bytes not 2 bytes.
- Please avoid implicitly setting constraints on the data plane in the definition of control plane. For instance, I've already made arguments that VN ID might be thirty-two bits, and there's little cost to defining thirty-two bit VN IDs in the control plane.

[Linda] Sorry it should be 4 bytes (with 1 byte reserved and 24 bits for the VNid). 

Linda
> Therefore, I think it is better to have a flag indicating if the VNs 
> are listed individually, Upper/Lower ranges, or bit mapped.
>
I wouldn't use a flag for that, it's probably cleaner to define another TLV type that gives a list of VNIDs. Either the list or bit-map can be used interchangeably.

Tom

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Jan 2015 09:30:07 +0000

> I wouldn't use a flag for that, it's probably cleaner to define another TLV type
> that gives a list of VNIDs. Either the list or bit-map can be used interchangeably.

There has been a draft (https://tools.ietf.org/html/draft-xu-nvo3-isis-cp-00) talking about that approach. By the way, we have implemented a demo on Quagga (installed on Ubuntu) which is capable of interworking with OVS. 

Best regards,
Xiaohu

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 30 Jan 2015 22:52:31 +0000

Xiao Hu, 

Do you mean this TLV in your draft?

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+
         | Type=VN Info  |
         +-+-+-+-+-+-+-+-+
         |    Length     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         |                 Originating NVE's IP Address                  |
         |                         (128 bits)                            |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Resv (8 bits) |                VN ID (24 bits)                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Resv (12 bits)     |       Local MPLS Label (20 bits)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         :                                                               :
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Resv (8 bits) |                 VN ID (24 bits)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Resv (12 bits)     |       Local MPLS Label (20 bits)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So you are assuming to use the list of VNs. If a NVE participate in 20 VNs (or more for TOR based NVE), there will be 20* (4 bytes). 

Correct?

Why need to list the Local MPLS Label? What if there is no MPLS used?

Linda

-----Original Message-----
From: Xuxiaohu 
Sent: Friday, January 30, 2015 3:30 AM
To: Tom Herbert; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: RE: [nvo3] is it resonsable that draft-dunbar-nvo3-nva-mapping-distribution-01 suggests NVE using bit-map to represent its supported VNs?

> another TLV type that gives a list of VNIDs. Either the list or bit-map can be used interchangeably.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 31 Jan 2015 01:30:56 +0000

Hi Linda,

> From: Linda Dunbar
> Sent: Saturday, January 31, 2015 6:53 AM
> To: Xuxiaohu; Tom Herbert
> Subject: RE: [nvo3] is it resonsable that
> draft-dunbar-nvo3-nva-mapping-distribution-01 suggests NVE using bit-map to
> represent its supported VNs?
> 
> Xiao Hu,
> 

Yes.

>           0                   1                   2
> 3
>          |
> |
>          |                         (128 bits)
> |
>          |
> |
>          :
>      :
> So you are assuming to use the list of VNs. If a NVE participate in 20 VNs (or
> more for TOR based NVE), there will be 20* (4 bytes).

Yes, if there are too many VN instances, they could be listed in more than one TLV.

> Why need to list the Local MPLS Label? What if there is no MPLS used?

The MPLS label would be useful only in the case where the VNs are identified by MPLS labels on the data plane. the MPLS label could be set to zero if there is no MPLS used.

Best regards,
Xiaohu

> Subject: RE: [nvo3] is it resonsable that
> draft-dunbar-nvo3-nva-mapping-distribution-01 suggests NVE using bit-map to
> represent its supported VNs?
> 
> There has been a draft (https://tools.ietf.org/html/draft-xu-nvo3-isis-cp-00)
> talking about that approach. By the way, we have implemented a demo on
> Quagga (installed on Ubuntu) which is capable of interworking with OVS.
> 
> Best regards,
> Xiaohu
> 
> > Tom
> >
> > >
> > >
> > > Any other suggestions?
> > >
> > >
> > >
> > > Linda
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >