Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Miz

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Robert, > Where say in draft draft-quinn-vxlan-gpe do you see such statement that would > imply > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any > other type > of extension header further followed by UDP ? The following text is from Figure 4 in draft-ietf-nvo3-vx

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Tal, Indeed .. I saw the figures, but figures are non normative in any draft/rfc unless text below specifically spells it out. For example from vxlan-gpe: "When the outer IP header is IPv4, VTEPs MUST set the DF bit." Besides it is pretty challenging to add animation to the current draft for

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Robert, That makes sense. However, in this case the figures may be a bit confusing WRT the possible existence of extension headers. This confusion is what led to the discussion in this thread about whether segment routing is possible with VXLAN/VXLAN-GPE/Geneve encapsulations. In order to a

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Tal, > In order to avoid ambiguity, it would be great if the > authors could explicitly mention that IPv6 extension > headers are permitted. Well the drafts are complaint to RFC2119 (normative reference) so unless the text excludes elements with MUST/MUST NOT - everything else defined in the b

[spring] New draft for data center gateways

Hi, Just posted https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ We think this covers an important hole. The document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the data center site

Re: [spring] [Idr] New draft for data center gateways

Hi Adrian, Many thx for sharing the document. Just starting to read it one assertion repeated at least twice got my attention: "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular protocol mechanism for operating within a DC" By "popular protocol mechanism" when building non bloc

Re: [spring] [Idr] New draft for data center gateways

Dear Authors, Question 1: Assume that prefix X has been advertised with tunnel attribute as described in the draft with both GW1 and GW2 entry points to Egress DC site. So remote GW in Ingress DC site receives at least one such advertisement and as each contains both GW1 and GW2 entries it can e

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

I agree that I don’t believe that there is anything in these drafts that precludes the use of extension headers or segment routing – IP is simply the layer underneath that these protocols are building on. The figures are definitely just examples – they also show outer Ethernet headers, which is

Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

I agree with Robert and Jesse. - Larry From: Jesse Gross mailto:jgr...@vmware.com>> Date: Monday, May 23, 2016 at 1:19 PM To: Robert Raszuk mailto:rob...@raszuk.net>>, Tal Mizrahi mailto:ta...@marvell.com>> Cc: "draft-ietf-nvo3-gen...@tools.ietf.org"