Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

[Greg Mirsky <[e-mail]>]

Hi Jesse,
I have some concerns with what is proposed in
draft-brockners-ippm-ioam-geneve. The main - it requires additional
capability negotiation to avoid the data packets being dropped because of
the egress Geneve node not supporting iOAM and fails to parse the iOAM
message. Second - inconsistency in the use of O-bit. The draft states
(though without proper use of the normative language):
   Packets that carry IOAM
   data fields in addition to regular data payload / customer traffic
   must not set the O bit.  Packets that carry only IOAM data fields
   without any payload must set the O bit.
That, in my opinion, is confusing and inconsistent. iOAM requests
allocation of two Next Protocol values and that should be sufficient. Why
the value of O-bit depends on whether there is or there is no data payload
immediately following iOAM message? How does that help in processing?

Regards,
Greg

On Thu, Oct 25, 2018 at 3:44 PM Jesse Gross <[e-mail]> wrote:

> Hi Greg,
>
> One example of this use case is described in
> draft-brockners-ippm-ioam-geneve
>
> Jesse
>
> On Mon, Oct 22, 2018 at 2:34 AM Greg Mirsky <[e-mail]> wrote:
> >
> > Hi Ilango, et al.,
> > if I understand the text you're proposing:
> > Transit devices not interpreting Geneve headers (that may or may not
> include Options)
> >    SHOULD process Geneve packets as any other UDP packet and maintain
> >    consistent forwarding behavior.
> > a transit node MAY process Geneve packets using Geneve layer
> information. What are scenarios that would require such an option? How that
> functionality controlled, advertised, and traceable by OAM?
> >
> > Regards,
> > Greg
> >
> > On Sun, Oct 21, 2018 at 9:22 PM Ganga, Ilango S <
> [e-mail]> wrote:
> >>
> >> Hi Daniel,
> >>
> >>
> >>
> >> Please see my responses inline. I think this should address all your
> comments.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Ilango
> >>
> >>
> >>
> >>
> >>
> >> From: Daniel Migault [mailto:[e-mail]]
> >> Sent: Wednesday, October 17, 2018 7:28 AM
> >> To: Ganga, Ilango S <[e-mail]>
> >> Cc: Bocci, Matthew (Nokia - GB) <[e-mail]>;
> [e-mail]; [e-mail]; T. Sridhar <
> [e-mail]>
> >> Subject: RE: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
> >>
> >>
> >>
> >> Hi Illango,
> >>
> >>
> >>
> >> Thanks for the response, please see my comments. I believe they can be
> easily addressed in the next version.
> >>
> >>
> >>
> >> Yours,
> >> Daniel
> >>
> >>
> >>
> >> From: Ganga, Ilango S <[e-mail]>
> >> Sent: Wednesday, October 17, 2018 1:45 AM
> >> To: Daniel Migault <[e-mail]>
> >> Cc: Bocci, Matthew (Nokia - GB) <[e-mail]>;
> [e-mail]; [e-mail]; T. Sridhar <
> [e-mail]>
> >> Subject: RE: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
> >>
> >>
> >>
> >> Hi Daniel,
> >>
> >>
> >>
> >> Thanks for your review and comments. Please see my responses inline.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Ilango
> >>
> >>
> >>
> >>
> >>
> >> From: Daniel Migault [mailto:[e-mail]]
> >> Sent: Friday, October 12, 2018 2:57 PM
> >> To: Ganga, Ilango S <[e-mail]>
> >> Cc: Bocci, Matthew (Nokia - GB) <[e-mail]>;
> [e-mail]; [e-mail]
> >> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >>
> >> I reviewed the document. Please find my comments below.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >> 3.4.  Tunnel Header Fields
> >>
> >>    C (1 bit):  Critical options present.  One or more options has the
> >>       critical bit set (see Section 3.5).  If this bit is set then
> >>       tunnel endpoints MUST parse the options list to interpret any
> >>       critical options.  On endpoints where option parsing is not
> >>       supported the packet MUST be dropped on the basis of the 'C' bit
> >>       in the base header.  If the bit is not set tunnel endpoints MAY
> >>       strip all options using 'Opt Len' and forward the decapsulated
> >>       packet.
> >> <mglt>
> >> I am fine with the text, but this may contradict that Opt Len is
> compared to the sum of option len. (see my comment next section). I guess
> that is a clarification to be made next section.
> >> </mglt>
> >>
> >> <Ilango> The text in this section reads fine; since the option header
> is defined in next section 3.5, it is appropriate to keep the text in that
> section. Also, please see response to next section.
> >>
> >> </>
> >>
> >> <mglt2>I will see the next section. </mglt2>
> >>
> >>
> >> 3.5.  Tunnel Options
> >>
> >>
> >>    Type (8 bits):  Type indicating the format of the data contained in
> >>       this option.  Options are primarily designed to encourage future
> >>       extensibility and innovation and so standardized forms of these
> >>       options will be defined in a separate document.
> >>
> >>       The high order bit of the option type indicates that this is a
> >>       critical option.  If the receiving endpoint does not recognize
> >>       this option and this bit is set then the packet MUST be dropped.
> >>       If the critical bit is set in any option then the 'C' bit in the
> >>       Geneve base header MUST also be set.  Transit devices MUST NOT
> >>       drop packets on the basis of this bit.  The following figure shows
> >>       the location of the 'C' bit in the 'Type' field:
> >>
> >>       0 1 2 3 4 5 6 7 8
> >>       +-+-+-+-+-+-+-+-+
> >>       |C|    Type     |
> >>       +-+-+-+-+-+-+-+-+
> >>
> >>       The requirement to drop a packet with an unknown critical option
> >> <mglt>
> >> maybe s/an unknown critical option/an unknown option with the critical
> bit set would be clearer.
> >> </mglt>
> >>
> >>
> >>
> >> <Ilango> The term critical option is described in section 3.4 and used
> in 3.5, so use of this term here to refer to an unknown critical option
> reads fine.  Though for consistency with the sentence in section 3.5.1, we
> could also say “unknown options with C-bit set”.
> >>
> >> </>
> >>
> >> <mglt2> I am fine with your proposed change. </mglt>
> >>
> >>
> >>       applies to the entire tunnel endpoint system and not a particular
> >>       component of the implementation.  For example, in a system
> >>       comprised of a forwarding ASIC and a general purpose CPU, this
> >>       does not mean that the packet must be dropped in the ASIC.  An
> >>       implementation may send the packet to the CPU using a rate-limited
> >>       control channel for slow-path exception handling.
> >>
> >>    R (3 bits):  Option control flags reserved for future use.  MUST be
> >>       zero on transmission and ignored on receipt.
> >>
> >>    Length (5 bits):  Length of the option, expressed in four byte
> >>       multiples excluding the option header.  The total length of each
> >>       option may be between 4 and 128 bytes.  A value of 0 in the Length
> >>       field implies an option with only the option header without the
> >>       variable option data.
> >>
> >>
> >>
> >> <mglt>
> >> I understand the sentence below as a check between the sum of option
> length and Opt len. This does not seems related to the treatment of one
> option, and maybe should be moved up to the description of Opt Len in the
> Geneve Header section.
> >>
> >>
> >>
> >> <Ilango> This section is where the Tunnel Options are defined hence
> this is the most appropriate and right place for this text.
> >>
> >> </>
> >>
> >>
> >>
> >> <mglt2>I am fine with that as well, as long as you believe that is the
> right place.</mglt2>
> >>
> >>
> >> I also have an issue on how to interpret that sentence. When receiving
> a Geneve Packet, the following sentence prevent from jumping to Opt Len
> skipping off options. It could be understood as a mandatory check in which
> case (whether there is a C bit set in the Geneve Header or not) the
> terminating node to go through all options, read the Length sum them and
> them compare it to the Opt Len. If such check is mandatory, I am wondering
> if Opt Len in the Geneve Header is then limited for internal use of the
> terminating node. If that is something optional, maybe we should explicitly
> say it, or maybe detail when such comparison is expect to happen.
> >> </mglt>
> >>
> >>
> >>
> >> <Ilango> No, it does not prevent the nodes from skipping the options to
> reach the start of encapsulated payload. For example a transit node that
> does not process the options can skip over the options by using the Option
> length field in the Geneve header. The endpoints that process the options
> are the ones that need to do this check as stated in this sentence.
> >>
> >> For better clarity, we could add clarifying text to the sentence as
> follows:
> >>
> >> “…. invalid and MUST be silently dropped if received by an endpoint
> that processes the options.”
> >>
> >> </>
> >>
> >> <mglt2>I believe that is clarifying to add the text you
> proposed.</mglt2>
> >>
> >>
> >> Packets in which the total length of all
> >>       options is not equal to the 'Opt Len' in the base header are
> >>       invalid and MUST be silently dropped if received by an endpoint.
> >>
> >>
> >>
> >>
> >> Gross, et al.            Expires April 10, 2019                [Page 15]
> >>
> >> Internet-Draft               Geneve Protocol                October 2018
> >>
> >>
> >>    Variable Option Data:  Option data interpreted according to 'Type'.
> >>
> >>
> >> 3.5.1.  Options Processing
> >>
> >>    Geneve options are intended to be originated and processed by tunnel
> >>    endpoints.  However, options MAY be interpreted by transit devices
> >>    along the tunnel path.  Transit devices not processing Geneve headers
> >> <mglt>
> >> I am reading Genve header as a Geneve option of the Genve header, but
> not the fixed Geneve header. If that is correct, It may be clearer to use
> Genve option instead of Geneve header as to avoid confusion on the scope of
> transit device. From the text above, using Geneve header could mean the fix
> header, in which case it may make easier to figure out  the difference
> between transit device and tunnel endpoint.
> >> </mglt>
> >>
> >> <Ilango> As illustrated clearly in sections 3.1 and 3.2 Geneve header
> includes fixed length headers and options. So in this statement, Geneve
> header includes options.
> >>
> >> </>
> >>
> >> <mglt2>
> >>
> >> This is I believe English clarification and English is not my native
> language, so I am only providing my feed back, but differ to others on what
> to do.
> >>
> >>
> >>
> >> The statement as I read it says that transit devices MAY interpret
> options. Which I interprete as the scope of transit device is limited to
> these options and transit device are not supposed to interprete the fix
> header.
> >>
> >>
> >>
> >> The following sentence says transit devices not interpreting the Geneve
> Header….” Which I read as fix header and option. While the statement is
> true, as header include option, I found it somehow confusing to introduce
> the fix header at that stage, as my understanding is that transit device
> are limited to the options.
> >>
> >>
> >>
> >> Re-reading the text I also believe - if that is correct -, we should
> specify that transit devices MAY treat a subset of the options. </mglt2>
> >>
> >>
> >>
> >> <Ilango2> The header may include options, and a transit device has to
> interpret the header to get to the options. We will rephrase the text to
> the following for clarity.
> >>
> >> Transit devices not interpreting Geneve headers (that may or may not
> include Options)
> >>
> >>    SHOULD process Geneve packets as any other UDP packet and maintain
> >>
> >>    consistent forwarding behavior.
> >>
> >> </Ilango2>
> >>
> >>
> >>    SHOULD process Geneve packets as any other UDP packet and maintain
> >>    consistent forwarding behavior.
> >>
> >>    In tunnel endpoints, the generation and interpretation of options is
> >>    determined by the control plane, which is out of the scope of this
> >>    document.  However, to ensure interoperability between heterogeneous
> >>    devices some requirements are imposed on options and the devices that
> >>    process them:
> >>
> >>    o  Receiving endpoints MUST drop packets containing unknown options
> >>       with the 'C' bit set in the option type.  Conversely, transit
> >>       devices MUST NOT drop packets as a result of encountering unknown
> >>       options, including those with the 'C' bit set.
> >>
> >>    o  Some options may be defined in such a way that the position in the
> >>       option list is significant.  Options or their ordering, MUST NOT
> >>       be changed by transit devices.
> >>
> >>    o  An option MUST NOT affect the parsing or interpretation of any
> >>       other option.
> >>
> >>
> >>
> >>
> >> <mglt>
> >> In case we have a option providing authentication, such option may
> affect the interpretation of the other options.
> s/interpretation/ndependance may not be better.... I think what we want to
> say is that option MUST be able to be processed in any order or in
> parallel.  I am fine with the text if we do not find something better.
> >> </mglt>
> >>
> >> <Ilango> This is a good point, however we believe that this text
> captures the intent.
> >> </>
> >>
> >> <mglt2>The problem I have is that the current text prevents security
> options, so I guess some clarification should be brought to clarify the
> intent.</mglt2>
> >>
> >> <Ilango2> The intent of this statement is, parsing and interpretation
> of options is not dependent on one another. It does not preclude processing
> of any security option.
> >>
> >> </Ilango2>
> >>
> >>
> >> 6.  Security Considerations
> >>
> >>    As encapsulated within an UDP/IP packet, Geneve does not have any
> >>    inherent security mechanisms.  As a result, an attacker with access
> >>    to the underlay network transporting the IP packets has the ability
> >>    to snoop or inject packets.
> >>
> >>
> >> <mglt>
> >> I believe that monitoring is also an attack that should be mentioned.
> >> </mglt>
> >>
> >> <Ilango> Snooping covers the case of monitoring as well, so I don’t see
> a need for additional text.
> >>
> >> </>
> >>
> >>
> >>
> >> <mglt2>I  understood “snoop” as being more active  than passive
> monitoring. I am fine with the text.</mglt2>
> >>
> >>
> >>
> >>
> >>  Legitimate but malicious tunnel
> >>    endpoints may also spoof identifiers in the tunnel header to gain
> >>    access to networks owned by other tenants.
> >>
> >> <mglt>
> >> I think Legitimate and malicious are not compatible. This is probably a
> "corrupted legitimate tunnel endpoint. I think we should also add that
> securing the geneve tunnel cannot prevent this type of threat.
> >> </mglt>
> >>
> >> <Ilango> Yes, we could change this to “Compromised endpoints may also
> spoof ….”.
> >>
> >> The next paragraph states that tunnel endpoints should only be operated
> in environments controlled by the service provider, this could potentially
> mitigate the threat of endpoints from getting compromised.
> >>
> >> </>
> >>
> >>
> >>
> >>
> >>    Within a particular security domain, such as a data center operated
> >>    by a single service provider, the most common and highest performing
> >>    security mechanism is isolation of trusted components.  Tunnel
> >>    traffic can be carried over a separate VLAN and filtered at any
> >>    untrusted boundaries.  In addition, tunnel endpoints should only be
> >>    operated in environments controlled by the service provider, such as
> >>    the hypervisor itself rather than within a customer VM.
> >>
> >>
> >>    When crossing an untrusted link, such as the public Internet, IPsec
> >>    [RFC4301] may be used to provide authentication and/or encryption of
> >>    the IP packets formed as part of Geneve encapsulation.
> >>
> >> <mglt>
> >> I understand the first paragraph as the one where the service provider
> owns the tenant, the geneve overlay as well as the infrastructure in which
> case, isolation and separation is performed by VLAN. The second paragraph
> mentions that the previously described data centers can be interconnected
> using a secure link. I consider this case as the one building a trusted
> environment to run Geneve overlay.
> >>
> >>
> >>
> >> I believe the security considerations for Geneve may be more focused on
> Genve itself, that is how the Geneve overlay network may remain secure
> while not relying on the security provided by the infrastructure. In that
> extent it help to consider the case where tenants, Geneve overlay provider,
> infrastructure providers are different entities.
> >> </mglt>
> >>
> >> <Ilango>The operator could use multiple security mechanisms, which
> could span across layers. For example, the operator could very well choose
> security mechanisms already provided by the underlay to secure their
> overlay networks.  </>
> >>
> >> <mglt2>I understand, but it seems to me that the important things here
> are :
> >>
> >> Corrupted legitimate tunnel endpoint is not expected to be addressed by
> Geneve security mechanisms.
> >> Geneve overlay deployment relies on reliable (trusted) tunnel
> endpoints. This later point may be achieved in one or the other ways. You
> provide one way to do it, another way could be simply trusting your
> infrastructure provider.
> >>
> >> I believe that it may be more helpful to explicitly provide a trust
> model, illustrating it and leave the door open to other solutions. My
> current reading is that one way is proposed, but we may lack some
> information to evaluate if other ways can be acceptable as well.</mglt2>
> >>
> >> <Ilango2> I am not sure where you are going with this. The intent is to
> highlight potential risks and outline how to mitigate such risks, this
> paragraph describes the best practices used to secure a tunnel endpoint. We
> believe that this is sufficiently illustrated in the description.
> >>
> >> </Ilango2>
> >>
> >>
> >>
> >>    Geneve does not otherwise affect the security of the encapsulated
> >>    packets.  As per the guidelines of BCP72 [RFC3552], the following
> >>    sections describe potential security risks that may be applicable to
> >>    Geneve deployments and approaches to mitigate such risks.  It is also
> >>    noted that not all such risks are applicable to all Geneve deployment
> >>    scenarios, i.e., only a subset may be applicable to certain
> >>    deployments.  So an operator has to make an assessment based on their
> >>    network environment and determine the risks that are applicable to
> >>    their specific environment and use appropriate mitigation approaches
> >>    as applicable.
> >>
> >>
> >>
> >> Gross, et al.            Expires April 10, 2019                [Page 21]
> >>
> >> Internet-Draft               Geneve Protocol                October 2018
> >>
> >>
> >> 6.1.  Data Confidentiality
> >>
> >>    Geneve is a network virtualization overlay encapsulation protocol
> >>    designed to establish tunnels between network virtualization end
> >>    points (NVE) over an existing IP network.  It can be used to deploy
> >>    multi-tenant overlay networks over an existing IP underlay network in
> >>    a public or private data center.  The overlay service is typically
> >>    provided by a service provider, for example a cloud services provider
> >>    or a private data center operator.
> >>
> >> <mglt>
> >> The text above seems to assume that the service overlay is always
> provided by the cloud provider (i.e. infrastructure provider). I do not
> believe this assumption is always true.
> >>
> >> A company may sell a system based on Geneve and may be willing to
> provide some protection against the infrastructure provider.
> >> </mglt>
> >>
> >> <Ilango> Yes, “typically” means not always, but it is the most common
> use case.</>
> >>
> >> <mglt2> I believe it is good we mention a use case we envisioned as
> being the most common use case, but I also think the security consideration
> should not only be based on one deployment. </mglt2>
> >>
> >> <Ilango2> We will add the following statement to the end of this
> paragraph for clarification.
> >>
> >> “This may or not may be the same provider as an underlay service
> provider”
> >>
> >> </Ilango2>
> >>
> >>
> >>    Due to the nature of multi-
> >>    tenancy in such environments, a tenant system may expect data
> >>    confidentiality to ensure its packet data is not tampered with
> >>    (active attack) in transit or a target of unauthorized monitoring
> >>    (passive attack).  A tenant may expect the overlay service provider
> >>    to provide data confidentiality as part of the service or a tenant
> >>    may bring its own data confidentiality mechanisms like IPsec or TLS
> >>    to protect the data end to end between its tenant systems.
> >> <mglt>
> >> When a tenant is securing its communication using TLS or IPsec, there
> are still some metadata that the Geneve overlay MAY protect - typically
> (IP, ports).
> >> </mglt>
> >>
> >> <Ilango> The intent of this statement is a tenant may bring its own
> data confidentiality mechanism to protect its data without relying on the
> service provider. This is irrespective of security mechanisms provided by
> the service provider.</>
> >>
> >>
> >>
> >> <mglt2>I would suggest that we clearly state that data confidentiality
> provided by the tenant does not prevent the geneve overlay to provide it.
> From my reading of the text, it seems that tenant security is sufficient.I
> believe that is a bit misleading. </mglt2>
> >>
> >> <Ilango2>The text does not preclude a service provider to provide
> security mechanisms when the tenant brings its own security. I am not sure
> where you are getting this interpretation. If needed we can remove the last
> sentence of the second paragraph, if that addresses your concern.
> >>
> >> <Delete the following sentence from the end of next paragraph>
> >>
> >> The operator may choose not to enable the encryption if,
> >>
> >>    for example, the packet data is already encrypted by the tenant
> >>
> >>    system.
> >>
> >> </Ilango2>
> >>
> >>    If an operator determines data confidentiality is necessary in their
> >>    environment based on their risk analysis, for example as in multi-
> >>    tenant environments, then an encryption mechanism SHOULD be used to
> >>    encrypt the tenant data end to end between the NVEs.  The NVEs may
> >>    use existing well established encryption mechanisms such as IPsec,
> >>    DTLs, etc., The operator may choose not to enable the encryption if,
> >>    for example, the packet data is already encrypted by the tenant
> >>    system.
> >>
> >> 6.1.1.  Inter-data center traffic
> >>
> >>    A tenant system in a customer premises (private data center) may want
> >>    to connect to tenant systems on their tenant overlay network in a
> >>    public cloud data center or a tenant may want to have its tenant
> >>    systems located in multiple geographically separated data centers for
> >>    high availability.  Geneve data traffic between tenant systems across
> >>    such separated networks should be protected from threats when
> >>    traversing public networks.  Any Geneve overlay data leaving the data
> >>    center network beyond the operator's security domain, for example
> >>    over the public Internet, SHOULD be secured by encryption mechanisms
> >>    such as IPsec or other VPN mechanisms to protect the communications
> >>    between the NVEs when they are geographically separated over
> >>    untrusted network links.  Implementation of specific data protection
> >>    mechanisms employed between data centers is beyond the scope of this
> >>    document.
> >>
> >> <mglt>
> >> I see that inter-data center traffic protection is more IP traffic
> protection than specific to Geneve. I think we can also safely go for a
> MUST be secured when the traffic is sent to the wild Internet.
> >> </mglt>
> >>
> >> <Ilango> Inter-data center need not always mean internet, for example
> it could be dedicated secure links. In which case the operator may decide
> to rely on the underlying security of the dedicated links, so we believe
> “SHOULD” is more appropriate here.</>
> >>
> >> <mglt2>I am reading this as two different implementations of a secure
> link between the data center. The requirement is that this link MUST be
> secured. One way to provide a secure link is to have a dedicated line in
> which case we SHOULD encrypt the traffic. Another way to establish a
> connection over the internet in which case the traffic MUST be encrypted.
> >>
> >> I believe it would help to clarify why SHOULD is mentioned here. One
> reason of the confusion is that only the link over internet is mentioned.
> </mglt2>
> >>
> >> <Ilango2>The operator based on their risk assessment should enable
> appropriate security mechanism.
> >>
> >> We could remove “for example over public Internet” from this sentence
> and this should address your concern.
> >>
> >> </Ilango2>
> >>
> >>
> >> 6.2.  Data Integrity
> >>
> >>    Geneve encapsulation is used between NVEs to establish overlay
> >>    tunnels over an existing IP underlay network.  In a multi-tenant data
> >>    center, a rogue or compromised tenant system may try to launch a
> >>
> >>
> >>
> >> Gross, et al.            Expires April 10, 2019                [Page 22]
> >>
> >> Internet-Draft               Geneve Protocol                October 2018
> >>
> >>
> >>    passive attack such as monitoring the traffic of other tenants, or an
> >>    active attack such as spoofing or trying to inject unauthorized
> >>    Geneve encapsulated traffic into the network.  To prevent such
> >>    attacks, an NVE MUST not propagate Geneve packets beyond the NVE to
> >>    tenant systems and SHOULD employ packet filtering mechanisms so as
> >>    not to forward unauthorized traffic between TSs in different tenant
> >>    networks.
> >>
> >> <mglt>I believe that replayed traffic is also unauthorized in this case
> and may be considered in the description.</mglt>
> >>
> >> <Ilango> Unauthorized traffic should include all type of unauthorized
> traffic including traffic such as spoofing, replay, etc.,. This is minor
> editorial, if need be we could rephrase to provide clarity  “unauthorized
> traffic such as spoofing, replay, etc.”
> >>
> >> </>
> >>
> >> <mglt2>I agree this is minor editorial, but the use of UDP eases such
> attacks, so I think it is important this appears in the security
> consideration.</mglt2>
> >>
> >> <Ilango2> Ok, we will rephrase to provide clarity
> >>
> >> “unauthorized traffic such as spoofing, replay, etc.”
> >>
> >> </Ilango2>
> >>
> >>
> >>
> >> <END>
> >>
> >>
> >>
> >> On Thu, Oct 11, 2018 at 1:34 PM Ganga, Ilango S <
> [e-mail]> wrote:
> >>
> >> As a co-author, I believe the document is ready for publication as a
> standards track RFC.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Ilango
> >>
> >>
> >>
> >>
> >>
> >> From: Bocci, Matthew (Nokia - GB) [mailto:[e-mail]]
> >> Sent: Tuesday, October 9, 2018 2:08 AM
> >> To: NVO3 <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
> >>
> >>
> >>
> >> This email begins a two-week working group last call for
> draft-ietf-nvo3-geneve-08.txt.
> >>
> >>
> >>
> >> Please review the draft and post any comments to the NVO3 working group
> list. If you have read the latest version of the draft but have no comments
> and believe it is ready for publication as a standards track RFC, please
> also indicate so to the WG email list.
> >>
> >>
> >>
> >> We are also polling for knowledge of any undisclosed IPR that applies
> to this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> >>
> >> If you are listed as an Author or a Contributor of this document,
> please respond to this email and indicate whether or not you are aware of
> any relevant undisclosed IPR. The Document won't progress without answers
> from all the Authors and Contributors.
> >>
> >>
> >>
> >> Currently there are two IPR disclosures against this document.
> >>
> >>
> >>
> >> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
> >>
> >>
> >>
> >> This poll will run until Friday 26th October.
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> Matthew and Sam
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nvo3
>