_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.iet=
f.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E =
Carpenter
<brian.e.carpenter@gmail.c=
om> wrote:
[resend with corrected address, =
sorry]

Hi,

 The first three bits (bits 5-7) are precedence =
bits. They are
 assigned according to [RFC0791]. Precedence =
values '110' and '111'
 are selected for routing =
traffic.

 The last three bits (bits 8-10) are class =
selector bits. Thet are
 assigned as =
follows:

001 - BK or background =
traffic
...
As can be seen the markings are the same as in =
IEEE 802.1p...
This is not in any way compatible with RFC 2474, =
which also made the
relevant part of RFC 791 =
obsolete.

If you want to be compatible with RFC 2474 you =
should not specify the
bits at all - just say that they are exactly as =
defined in RFC 2474
and the various PHB definitions that have been =
published.

I think that diffserv is less relevant in the =
context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a =
different matter,

Yes this is more relevant for =
VXLAN.

but you cannot mix the two up in this =
way.

I now understand that we confused the two very =
different things.

Regards,

Behcet
    =
Brian

<=
span style=3D'color:#888888'> 
_______________________________________________
nvo3 mailing =
list
nvo3@ietf.org
On Mon, Nov 10, 2014 at 9:41 PM, Brian E=
 Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are pre=
cedence bits. They are
 assigned according to [RFC0791]. Preced=
ence values '110' and '111'
 are selected for routing traffic.<=
/o:p>

 The last three bits (bits 8-10) are cla=
ss selector bits. Thet are
 assigned as follows:<=
/pre>

001 - BK or background traffic

...

As can be seen the markings are the same=
 as in IEEE 802.1p...

This is not in any way compatible with R=
FC 2474, which also made the
relevant part of RFC 791 obsolete.<=
/o:p>

If you want to be compatible with RFC 24=
74 you should not specify the
bits at all - just say that they are exa=
ctly as defined in RFC 2474
and the various PHB definitions that hav=
e been published.

I think that diffserv is less relevant i=
n the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p t=
hat is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this wa=
y.

I now understand that we confused the tw=
o very different things.

Regards,

Behcet

    Brian

________________________________________=
_______
nvo3 mailing list
nvo3@ie=
tf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E=
 Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are pre=
cedence bits. They are
 assigned according to [RFC0791]. Preced=
ence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are cla=
ss selector bits. Thet are
 assigned as follows:<=
/pre>

001 - BK or background traffic

...

As can be seen the markings are the same=
 as in IEEE 802.1p...

This is not in any way compatible with R=
FC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 24=
74 you should not specify the
bits at all - just say that they are exa=
ctly as defined in RFC 2474
and the various PHB definitions that hav=
e been published.

I think that diffserv is less relevant i=
n the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p t=
hat is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this wa=
y.

I now understand that we confused the tw=
o very different things.

Regards,

Behcet

    Brian

________________________________________=
_______
nvo3 mailing list
nvo3@ie=
tf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM=
, Brian E Carpenter
<brian.e.carpenter@gmail.com> w=
rote:
[resend with corrected address,=
 sorry]
=C2=A0
Hi,
=C2=A0

 The first three bits (bits 5-7=
) are precedence bits. They are
 assigned according to [RFC0791=
]. Precedence values '110' and '111'
 are selected for routing traff=
ic.
=C2=A0
 The last three bits (bits 8-10=
) are class selector bits. Thet are
 assigned as follows:=

=C2=A0
001 - BK or background traffic<=
/span>

...

As can be seen the markings are=
 the same as in IEEE 802.1p...

This is not in any way compatib=
le with RFC 2474, which also made the
relevant part of RFC 791 obsole=
te.
=C2=A0
If you want to be compatible wi=
th RFC 2474 you should not specify the
bits at all - just say that the=
y are exactly as defined in RFC 2474
and the various PHB definitions=
 that have been published.

=C2=A0
I think that diffserv is less r=
elevant in the context of VXLAN.
=C2=A0

 If you
want to be compatible with IEEE=
 802.1p that is a different matter,

=C2=A0
Yes this is more relevant for V=
XLAN.
=C2=A0

but you cannot mix the two up i=
n this way.

=C2=A0
I now understand that we confus=
ed the two very different things.
=C2=A0
Regards,
=C2=A0
Behcet

=C2=A0=C2=A0=C2=A0 Brian=

=C2=A0
=C2=A0
=C2=A0

=C2=A0
_______________________________=
________________
nvo3 mailing list=

nvo3@ietf.org
https://www.ietf.org/mailman/list=
info/nvo3

On Mon, Nov 10, 2014 at 9:41 PM=
, Brian E Carpenter
<brian.e.carpenter@gmail.com> w=
rote:
[resend with corrected address,=
 sorry]
=C2=A0
Hi,
=C2=A0

 The first three bits (bits 5-7=
) are precedence bits. They are
 assigned according to [RFC0791=
]. Precedence values '110' and '111'
 are selected for routing traff=
ic.
=C2=A0
 The last three bits (bits 8-10=
) are class selector bits. Thet are
 assigned as follows:=

=C2=A0
001 - BK or background traffic<=
/span>

...

As can be seen the markings are=
 the same as in IEEE 802.1p...

This is not in any way compatib=
le with RFC 2474, which also made the
relevant part of RFC 791 obsole=
te.
=C2=A0
If you want to be compatible wi=
th RFC 2474 you should not specify the
bits at all - just say that the=
y are exactly as defined in RFC 2474
and the various PHB definitions=
 that have been published.

=C2=A0
I think that diffserv is less r=
elevant in the context of VXLAN.
=C2=A0

 If you
want to be compatible with IEEE=
 802.1p that is a different matter,

=C2=A0
Yes this is more relevant for V=
XLAN.
=C2=A0

but you cannot mix the two up i=
n this way.

=C2=A0
I now understand that we confus=
ed the two very different things.
=C2=A0
Regards,
=C2=A0
Behcet

=C2=A0=C2=A0=C2=A0 Brian=

=C2=A0
=C2=A0
=C2=A0

=C2=A0
_______________________________=
________________
nvo3 mailing list=

nvo3@ietf.org
https://www.ietf.org/mailman/list=
info/nvo3

On M=
on, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
[resend with correcte=
d address, sorry]
=C2=A0
Hi,
=C2=A0
 The=
 first three bits (bits 5-7) are precedence bits. They are
 assigned according t=
o [RFC0791]. Precedence values '110' and '111'
 are selected for=
 routing traffic.
=C2=A0
 The last three bits (bits 8-10) are class selector bits. Th=
et are
 assigned as follows:
=C2=A0
001 - BK or background traffic
...
=
As can be seen the markings are the =
same as in IEEE 802.1p...
This is not in any way compatible with RF=
C 2474, which also made the
relevant part of RFC 791 obsolete.
=C2=A0
If you want to be co=
mpatible with RFC 2474 you should not specify thebits at all - just say that th=
ey are exactly as defined in RFC 2474
and the various PHB definitions that have =
been published.
=C2=A0
I think that diffserv is less relevant in the c=
ontext of VXLAN.
=C2=A0
 If yo=
u
wan=
t to be compatible with IEEE 802.1p that is a different matter,
=
=C2=A0
Y=
es this is more relevant for VXLAN.
=C2=A0
but you cannot mix the two up in this way.
=C2=
=A0
I now un=
derstand that we confused the two very different things.
=C2=A0
Regards,
=C2=A0<=
/u>
Behcet
=C2=A0=

=C2=
=A0
=
=C2=A0
=C2=A0
_______________________________________________
nvo3 mailing list
nvo3@ietf.org=

https://www.ietf.org=
/mailman/listinfo/nvo3
On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.=
e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are p=
recedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '=
111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the sa=
me as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, wh=
ich also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the conte=
xt of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this =
way.

I now understand that we confused the two very diff=
erent things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/nvo3

On Mon=2C Nov 10=2C 2014 at 9:41 PM=2C Brian E Carpenter
<=3Bbria=
n.e.carpenter@gmail.com>=3B wrote:

[resend with corrected address=2C sorry]

Hi=2C

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474=2C which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter=2C

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards=2C

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.=
e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '=
111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.=
e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are p=
recedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '=
111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the sa=
me as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, wh=
ich also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the conte=
xt of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this =
way.

I now understand that we confused the two very diff=
erent things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

[resend with corrected address, sorry]

Hi,

 The first three bits (bits 5-7) are precedence bits. They are
 assigned according to [RFC0791]. Precedence values '110' and '111'
 are selected for routing traffic.

 The last three bits (bits 8-10) are class selector bits. Thet are
 assigned as follows:

001 - BK or background traffic

...

As can be seen the markings are the same as in IEEE 802.1p...

This is not in any way compatible with RFC 2474, which also made the
relevant part of RFC 791 obsolete.

If you want to be compatible with RFC 2474 you should not specify the
bits at all - just say that they are exactly as defined in RFC 2474
and the various PHB definitions that have been published.

I think that diffserv is less relevant in the context of VXLAN.

 If you
want to be compatible with IEEE 802.1p that is a different matter,

Yes this is more relevant for VXLAN.

but you cannot mix the two up in this way.

I now understand that we confused the two very different things.

Regards,

Behcet

    Brian

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Hi Tom,One question that may have been discu=
ssed before. What if we directly use UDP-Lite to encapsulate GUE? Then the=
 checksum in UDP-lite could provide similar function as the checksum optio=
n you defined.

Regards
Lizhong
---------- Forwar=
ded message ----------
This=
 draft is based on feedback from Honolulu. This adds a checksum=0Aoption i=
n GUE that should hopefully be adequate to protect against=0Aaddress corru=
ption when using zero checksums with UDP over IPv6. Also,=0Amade it UDP-li=
te like so that some portion of payload can optionally=0Abe checksummed.=
=0AComments are appreciated.=0AThanks,=0ATom=0A---------- Forwarded messag=
e ----------=0AFrom:  <internet-drafts at ietf.org>=0ADate: Wed, Nov=
 26, 2014 at 2:42 PM=0ASubject: New Version Notification for draft-herbert=
-guecsum-00.txt=0ATo: Tom Herbert <therbert at google.com>=0AA new v=
ersion of I-D, draft-herbert-guecsum-00.txt=0Ahas been successfully submit=
ted by Tom Herbert and posted to the=0AIETF repository.=0AName:           =
draft-herbert-guecsum=0ARevision:       00=0ATitle:          Checksum opti=
on for Generic UDP Encapsulation=0ADocument date:  2014-11-26=0AGroup:    =
      Individual Submission=0APages:          8=0AURL:            http://www.ietf.org/internet-drafts/draft-herbert-guecsum-00=
.txt=0AStatus:         https://datatracker.ietf.org/doc/dra=
ft-herbert-guecsum/=0AHtmlized:       http://tools.ietf.org/htm=
l/draft-herbert-guecsum-00=0AAbstract:=0A   This specification defines=
 the Generic UDP Encapsulation (GUE)=0A   checksum and an associated heade=
r option. This checksum covers the=0A   GUE header, IP addresses, UDP port=
s, and optionally all or part of=0A   the encapsulated payload. It provide=
s verification of protocol header=0A   elements, and is particularly relev=
ant in the case where the UDP=0A   checksum is set to zero.=0APlease note =
that it may take a couple of minutes from the time of submission=0Auntil t=
he htmlized version and diff are available at tools.ietf.org.=0AThe IETF S=
ecretariat