Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks
draft-ietf-bess-evpn-proxy-arp-nd-16

[Ballot comment]
This seems much improved in many ways; thanks very much.

[S3.5] [comment]

* For send-refresh of IPv6 addresses, I suspect the PE might use
  an IPv6 SA == unspecified address and an SLLA option with the
  MAC address equal to the PE sender MAC.  Alternatively, if the
  PE has an IPv6 link-local address in the BD then it can just do
  the normal NS dance.

  But I'll defer to Eric Vyncke as I'm sure he has more experience
  in this area (where a device wishes to be "transparent" at the IP
  layer).

  Ah, I see in section 3.7 it's assumed that the PE has an IPv6
  link-local address configured in the BD.

[S3.7] [nit]

* "legit" -> "legitimate"

[Ballot discuss]
Thank you for the work put into this document. This system could indeed be very useful but I am afraid that this is a very complex system especially for IPv6 NDP.

Minor regret in the shepherd write-up as the WG summary did not include any comment on the WG consensus.

Thanks to Jean-Michel Combes for its Internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-proxy-arp-nd-11-intdir-telechat-combes-2021-01-20/
as Jean-Michel added some important comments, please review them as well as I support them especially those around DAD that should be a blocking DISCUSS point.

I also second Erik Kline's DISCUSS points.

Question to the authors and BESS WG chairs: was this document submitted to a 6MAN/V6OPS WGs review ? This is where all IPv6 experts live :-)

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Would RFC 8929 be enough to solve the problem ?

-- Section 3 --
"A Proxy-ARP/ND implementation MAY support all those sub-functions or only a subset of them.", I am afraid that it is mandatory that the reply and duplicate-ip must be coupled: either both of them are active or none of them are active else the system allows for duplicate IP addresses.

-- Section 3.1 --
"A Proxy-ARP/ND implementation SHOULD support static, dynamic and EVPN-learned entries." why not a MUST ? Or at least for dynamic & EVPN-learned ? or at least one ?

"Upon receiving traffic from the CE... the PE will activate the IP->MAC and advertise it in EVPN" it is unspecified how many bindings can be advertised in the case of multiple static MAC for one IP... only one or all ?

-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be safer.

-- Section 3.6 --
This function MUST be a mandatory part of the list of functions of section 3.

-- Section 5.2 --
An easy to fix: "Any unknown source MAC->IP entries" isn't it IP->MAC as in the rest of the document including the terminology section ?

-- Section 5.4 --
"traffic to unknown entries is discarded" which traffic (section 5.5 is much better to this point suggest to copy the text)? The NDP/ARP or normal data plane traffic ? Where is this behavior specified in the 6 sub-functions of section 3 ?

[Ballot comment]
Consider adding a section about host not doing GARP or doing no DAD or optimistic DAD.

-- Section 1 --
Is there any reason why the terminology section is not alphabetically sorted ?

-- Section 2.1 --
I would have assumed that the multicast nature of IPv6 address resolution would cause more problems than IPv4 ARP. The use of link-local multicast groups do not usually help as MLD snooping is often disabled in switches for link-local. Not to mention that there could be more IPv6 addresses per node than IPv4 address and IPv6 addresses keep changing. Do the authors have data to back this section ?

-- Section 2.2 --
Unsure about the meaning of "large layer-2 peering network"... Do we peer at layer-2 ? Now, I understand what is meant of course but the wording appears strange to me (not being an English native), may I suggest "large layer-2 network for peering" ?

Please expand GARP in "Unsolicited GARP". Also, this is a pleonasm as gratuitous ARP are by definition "unsolicited" ;-)

The definition of a CE in an IXP network would be welcome.

I am afraid that I do not agree with "The issue may be better in IPv6 routers" even if the IPv6 addresses are static in this environment (i.e., no RFC 4941 addresses).

-- Section 3 --
An IPv6 example would also be useful as NS is not like ARP.

Should the default behavior/sub-function of flooding be added to the list of 1) to 6) ?

-- Section 3.1 --
"Upon receiving traffic from the CE"... but with which IP address ? (OK guessable but let's be clear in a standard specification). It also seems to me like a local policy / feature that do not require standardization.

"Note that MAC and IPs with value 0 SHOULD NOT be learned" unsure why it is a singular MAC and plural IP ;-)

"only if the ARP/NA message creating the entry was NOT flooded before" what is meant by 'flooded' ?

Suggestion to add some descriptions of the impact of a rebooting/new PE with an empty cache while other PE have caches.

-- Section 3.1.1 --
Should RFC 4861 also be mentioned in "The use of the R Flag in NA messages has an impact on how hosts select their default gateways when sending packets off-link" ?

"Static entries SHOULD have the R Flag information added by the management interface.", else what is the default setting of te R-flag ?

"This configured R Flag SHOULD be an administrative choice with a default value of 1", so all other CE will appear as a router ? Not critical in the case of IXP as it is a default free zone but in a DC (suggest s/SHOULD/MAY/)?

Is there a recommended setting for the O-flag?

-- Section 3.2 --
Is "'anycast' is enabled in the BD" specified somewhere in this document ?

Suggest to split the point d) in three items: one for each flag.

Why is there no IPv6 equivalent of e) ?

In point f), "or discarded" can a packet with known IP->MAC mapping be discarded as well ?

-- Section 3.4 --
Please expand "IRB"

Should "flushed if the owner is no longer in the network" be complemented with a BGP withdrawal ?

Is there any security exposure (control plane DoS) by forcing the PE without IRB to have an IPv6 LLA ?

-- Section 3.6 --
Strong suggestion to s/the PE MAY send a CONFIRM message to the former owner of the IP/the PE SHOULD send a CONFIRM message to the former owner of the IP/

Unsure why CONFIRM is in uppercase BTW.

"If the PE does not receive an answer within a given timer" is there a recommended value for this timer ?

I have re-read three times the "anti-spoofing MAC" part, and, I still do not understand it... Is MAC-AS the black-hole address (then why not using a all 0 MAC address) or an alternative MAC address (but then who modifies the frame header to the CE) ?

-- Section 5.1 --
"in the peering network" is this use case only valid in the case of IXP ?

-- Section 5.2 --
"The Proxy-ARP/ND function is enabled" but what about the sub-functions enumerated in section 3 ?

"by snooping ARP/ND messages issued by the CEs" isn't the learning sub-function ?

-- Section 5.3 (and others) --
Why is this section apparently limited to IXP only ?

-- Section 5.5 --
There is a big overlap between this clear/good sub-sections and the previous ones. Suggest to keep only this one + section 5.6.

-- Section 5.6 --
"IPv6 'anycast' may be required in DCs, while it is not a requirement in IXP networks." I have doubts that anycast is never used in IXP networks. Let's rather say "seldom used in IXP networks".

-- Section 6 --

Nothing is said about putting some limits on the number of entries for an IP address... Else, this could lead to a DoS against the proxy & BGP sessions.

  "For example, IXPs should disable all unneeded control protocols, and
  block unwanted protocols from CEs so that only IPv4, ARP and IPv6
  Ethertypes are permitted on the peering network.  In addition, port
  security features and ACLs can provide an additional level of
  security."
While the above text is a good recommendation, I wonder what it the relationship with this document ?
 
== NITS ==

-- Abstract --
s/(DBs)/(BDs)/
 
-- Section 2.2 --
s/IPv4 layer-3 addresses/IPv4 addresses/

-- Section 3.1 --
Please use lower hexadecimal number, e.g., s/0x86dd/0x86dd/

-- Section 5.5 --
The "IXP-LAN" terminology is only used in this section while others are using "peering network" or "IXP networks". Let's choose only one ;-)

[Ballot discuss]
[ meta ]

* I appreciate the attempt to explicitly discuss handling NS/NA messages with
  not-previously-seen options.  Thank you for that.

  It seems to me, however, that the proposed approach to proceed with
  setting the current capabilities in concrete but point to things like
  "unicast-forward" as a relief valve, even though 3.2-f seems to say the
  multicast packets (i.e. on cache miss) should be discarded (implying the
  unicast mapping might never be learned in the first place?).

[ general ]

* When a PE reboots, should it do MLD (e.g. 2710, 3810, ...) of some kind to
  gather critical state so that it doesn't have to wait for CEs to have
  problems?

[ section 3.1 ]

* To my knowledge there is no concept in IPv6 of a link where anycast/O=0
  NAs only propagate partway through a broadcast domain.  In practice, if I
  understand the architecture correctly, O=0 NAs will propagate to all CEs
  "behind" a given PE but, if anycast=false, no further.

  This could lead to a difficult to debug scenario (though I admit this is
  probably quite rare).

  Note that 4861-7.2.4 implies that most nodes sending NAs for their own
  addresses will adhere to "the Override flag SHOULD be set to one".  This
  is not a MUST, though.  Dropping all O=0 NAs might affect some
  implementations that don't comply with this SHOULD.  I have no idea how
  many implementations this might affect (in practice, I suspect none?), but...
  I think it might need to be considered.

[ section 3.1.1/3.2 ]

* I was not able to understand what the typical disposition of the O bit
  is supposed to be in these proxied NAs.  Is the intent to default to O=0 so
  that local O=1 can be preferred (vis. 4861-7.2.4 and 4389)?  Or will it
  more typically be set to O=1 (as if just replaying the NA that was learned
  by another PE)?

[ section 3.2 ]

* Item (f) as currently written would break Enhanced DAD (RFC 7527),
  would it not?

[ section 3.6 ]

* "Duplicate IP Detection for IPv6 SHOULD be disabled when IPv6
  'anycast' is activated in a given EVI."

  This doesn't seem like the right response to me.  It should be okay to keep
  doing DAD for O=1 addresses regardless of the setting of this 'anycast'
  option, I would have thought.

[ section 5.5 ]

* I think that recommending Reply Sub-Functions discard NS packets of
  unexpected for means, in practice, no new NS option or flag can ever really
  be made to work.  The PE(s) serving the CE(s) that make "new NS"
  solicitations will all need to be upgraded, and it's not immediately clear
  to me that remote PEs wouldn't also need to be upgraded (to support a
  possible "new NA"in response).

  If this is in fact likely to be the operational reality then I think this
  limitation probably needs to be noted explicitly.

[Ballot comment]
[[ comments ]]

[ section 3.1.1 ]

* "                                  ... If no ARP/ND Extended
  Community is received, the PE will add a configured R Flag/O Flag
  to the entry.  This configured R Flag SHOULD be an administrative
  choice with a default value of 1."

  This reads as though the R flag should be added essentially by default?
  I realize that might seem reasonable on a broadcast domain populated by
  almost entirely by routers but it might cause confusion w.r.t. any
  hosts/servers added to the broadcast domain.  It seems like it might be
  better if the flags were always learned reliably, propagated reliably,
  and never presumed?

  I guess a host being mistaken for a router that never actually sends an
  RA doesn't cause any real problems in other nodes' ND tables.  I would
  think, though, that if R were presumed to be 0 then it would force R bit
  learning and propagation to be made to work reliably and be more easily
  detected if it doesn't.

[ section 5.6 ]

* Saying that anycast is not a requirement for IXPs seems like maybe a bit
  presumptuous speaking for all IXPs (maybe someone wants an anycast on-link
  NTP/PTP service?).  Perhaps just say that it's not /typically/ a requirement
  for IXPs?


[[ nits ]]

[ section 1 ]

* "BD: Broadcast Domain" is listed twice.

[ section 2.2 ]

* s/go worse/grow worse/, perhaps

[ section 3.1 ]

* s/to the all/to all/

[Ballot comment]
In addition to Barry's comments, I found that "BD" appears in the glossary twice, and "SLLA" appears in the glossary but nowhere else in the document.

Are "Address Resolution" and "Large Data Center" formal terms?  If not, they should be lowercase.

Alluding to a lot of things Alvaro pointed out: Many of the SHOULDs in this document are bare, in that they give the implementer a choice but no guidance on how to make that choice.  For instance:

  A Proxy-ARP/ND implementation SHOULD support static, dynamic and
  EVPN-learned entries.

How would I decide whether I've got a use case that justifies not doing one of those, and what are the interoperability implications of that decision?

I suggest reviewing these.

[Ballot comment]
Thanks to Russ Housley for the SECDIR review.

A few editorial nits:
** Abstract.  Please remove the reference [I-D.ietf-bess-evpn-na-flags] from the abstract as this section of the document is not permitted to have references.

** Section 3.1.b.  s/They SHOULD be learned out of/They SHOULD be learned from/

** Section 5.5.  s/almost all IXPs installed/almost all IXPs install/

[Ballot comment]
Thanks for this clear and well-written document; the effort that went
into presenting the information really comes through.  I basically just
have editorial nits as comments, with a few substantive notes on the
security considerations section.

For most of the document I was convinced that I understood this point,
but then Section 5.5 led me to question myself: in the "static
provisioning" learning mode, is the IP->MAC mapping configured only at
the PE that the CE using those addresses will attach to, or at all PEs
in the BD?  I can follow up out-of-band with some editorial suggestions
either way.

Abstract (and Introduction)

  This document describes the EVPN Proxy-ARP/ND function, augmented by
  the capability of the ARP/ND Extended Community
  [I-D.ietf-bess-evpn-na-flags].  From that perspective this document
  updates [RFC7432].  [...]

nit: this paragraph doesn't do very much to tell me what the nature of
the update is.  If it's just to clarify how all the pieces fit together
we might add a clause at the end ", to provide more comprehensive
documentation of the operation of the system as a whole" or similar.
(Some parts of it might also have worked as an RFC 2026 Applicability
Statement, but it is probably not worth the trouble of trying to rework
things at this stage, especially since what we have is already nicely
laid out.)

Section 3

There's a lot of information packed into the Figure, and the surrounding
text does a great job describing it.  Thank you!

  The Proxy-ARP/ND function can be structured in six sub-functions or
  procedures:

(editorial) the text from here to the end of the section feels distinct
from the explanation of the figure; it might benefit from getting
promoted into a (sub)section of its own.

Section 3.1

  An entry MAY associate a configured static IP to a list of potential
  MACs, i.e. IP1->(MAC1,MAC2..MACN).  When there is more than one MAC
  in the list of allowed MACs, the PE will not advertise any IP->MAC in
  EVPN until a local ARP/NA message or any other frame is received from
  the CE.  [...]

(nit) would it be better to phrase this as "until a frame (including
local ARP/NA message) is received from the CE"?  That seems to emphasize
that any traffic will do, even if we expect that traffic to be ARP/NA.

Section 3.1.1

  o  Hosts build a Default Router List based on the received RAs and
      NAs with R Flag=1.  Each cache entry has an IsRouter flag, which
      must be set based on the R Flag in the received NAs.  A host can

nit: maybe "must be set for received RAs and is set based on the R flag
[...]"

Section 3.6

  The distributed nature of EVPN and Proxy-ARP/ND allows the easy
  detection of duplicated IPs in the network, in a similar way to the
  MAC duplication function supported by [RFC7432] for MAC addresses.

nit: is this "MAC duplication detection function"?

      IP1->MAC2 in the Proxy-ARP/ND table.  Static IP->MAC entries,
      that is, locally provisioned or EVPN-learned entries (with I=1 in
      the ARP/ND Extended Community), are not subject to this
      procedure.  [...]

nit: I think the sentence is better without the parentheses, since the
presence of I=1 is critical for correct functioning and not intrinsic to
the entries being EVPN-learned.

      1.  The entry in duplicate detected state cannot be updated with
          new dynamic or EVPN-learned entries for the same IP.  The
          operator MAY override the entry though with a static IP->MAC.

nit: commas before and after "though".

      2.  The PE SHOULD alert the operator and stop responding ARP/NS
          for the duplicate IP until a corrective action is taken.

nit: "stop responding to".

          for IP1.  Since the AS-MAC is a managed MAC address known by
          all the PEs in the EVI, all the PEs MAY apply filters to drop

nit: this seems to be the first time that we talk about the AS-MAC being
a managed address and being known to all PEs in the EVI; it might be
worth rewording in light of that or mentioning that in the definition of
AS-MAC.

Section 5.2

  This scenario minimizes flooding while enabling dynamic learning of
  IP->MAC entries.  The Proxy-ARP/ND function is enabled in the BDs of
  the EVPN PEs, so that the PEs intercept and respond to CE requests.

nit: from context it seems like the "dynamic learning" here refers to
the EVPN-learned entries, but in §3.1 we reserved the term "dynamic" for
entries learned by local snooping.  Since the next paragraph talks about
snooping as an optional addition, we run into semi-conflicting usage of
the term "dynamic".  I would suggest (assuming the above is correct)
rewording this to "while enabling learning of IP->MAC entries over the
EVPN" or similar.

Section 5.5

                        These rules are often called port security.
  Port security summarizes different operational steps that limit the
  access to the IXP-LAN, to the customer router and controls the kind
  of traffic that the routers are allowed to exchange (e.g., Ethernet,

nit: this list lacks parallel structure; going with "limit the access to
the IXP-LAN and the customer router, and controls the kind of traffic"
would be okay.

Section 6

I think it would be useful to reiterate that the security considerations
of RFC 7432 and draft-ietf-bess-evpn-na-flags continue to apply (in
addition to the useful text that is already present here).  I guess ARP
and IPv6 ND are arguably also applicable (AFAICT the security properties
of the proxied scheme are very similar to those of native usage, in an
environment that already has to trust the PEs and provider network that
supply the EVPN to the same extent that one would otherwise trust an IP
router).

It would also be my personal preference (though I do not insist upon it)
to note that EVPN does not inherently provide cryptographic protection
(including confidentiality protection) despite the word "private"
appearing in the name.  (This is really a topic that should be addressed
via a long-term IETF-wide shift towards just "virtual network" instead
of "virtual private network", but I try to mention it when I can so as
to socialize the idea.)

I appreciate the discussion (earlier in the document) of the use of
dummy MACs to suppress unknown ARP-Request/NS flooding, added in
response to the opsdir review.  Is it worth calling out the
security/availability considerations of that technique from this
section?  ("No" is a perfectly fine answer.)

Is it too banal to repeat that configuring the unicast-forwarding and/or
flooding sub-functions to be disabled risks blocking service for a CE if
the static configuration is broken?

  The solution also provides protection against Denial Of Service
  attacks that use ARP/ND-spoofing as a first step.  [...]

Are these DoS attacks described anywhere that we might reference for
further reading?  ("No" is a perfectly fine answer.)

  When EVPN and its associated Proxy-ARP/ND function are used in IXP
  networks, they provide ARP/ND security and mitigation.  IXPs MUST

If I understand correctly, this security/mitigation is provided in the
face of malicious CE devices, but the system still requires that PEs are
trusted and does not provide cryptographic or independently verifiable
assurances of correct IP->MAC bindings.  I would suggest being explicit
about the threat that is being protected against, since by itself
the term "security" is so vague so as to become almost meaningless.

  For example, IXPs should disable all unneeded control protocols, and
  block unwanted protocols from CEs so that only IPv4, ARP and IPv6

I suggest the parenthetical "so that (for example) only"; we do not
really have much reason to preclude other ethertypes if desired by the
IXP.

[Ballot comment]
Just some very small points; please consider them, but there’s no need to respond.

Please expand “EVPN” in the title, abstract, and introduction.

It’s also not necessary to include the abbreviations for IXP, DC, and BD (which is misspelled as “DB”) in the abstract, as they’re each only used once there and are included in Section 1.

Even after having “DC” and “IXP” defined, it seems better to me to spell them out in the section titles of 2.1 (“The Data Center Use Case”) and 2.2 (“The Internet Exchange Point Use Case”).  Maybe consider that for Sections 5.5 and 5.6 as well.

And throughout the document, “use case” doesn’t need a hyphen and shouldn’t have one.

[Ballot comment]
As mentioned in the Introduction:

  This document describes the Proxy-ARP/ND function in [RFC7432]
  networks, augmented by the capability of the ARP/ND Extended
  Community [I-D.ietf-bess-evpn-na-flags].  From that perspective this
  document updates [RFC7432].

Even with this statement, the purpose of this document and the relationship
between it, rfc7432 and I-D.ietf-bess-evpn-na-flags is not completely clear to
me.  I would like to understand the following:

- Why isn't this description included in I-D.ietf-bess-evpn-na-flags if the
  functionality is introduced there?

- This document formally Updates rfc7432, but I-D.ietf-bess-evpn-na-flags
  didn't. How can the description of the function Update rfc7432 if the
  functionality doesn't?  What exactly is the update to rfc7432? 

- The WG developed this document alongside I-D.ietf-bess-evpn-na-flags, but it
  is not referenced from there.  Why?


Besides those high-level questions, I have a set of comments that are mostly
related to the normative language used.  I would like to see these issues
addressed before publication.


(1) §3.1 recommends this:

  The provisioned static IP->MAC entry SHOULD be advertised in EVPN with an
  ARP/ND Extended Community where the Immutable ARP/ND Binding Flag flag (I)
  is set to 1, as per [I-D.ietf-bess-evpn-na-flags].

...but I-D.ietf-bess-evpn-na-flags requires the behavior, from §3.1:

  o  If an IP->MAC pair is static (it has been configured) the
      corresponding MAC/IP Advertisement route MUST be sent along with
      an ARP/ND Extended Community with the I Flag set.


(2) §3.1: "An entry MAY associate a configured static IP to a list of
potential MACs, i.e. IP1->(MAC1,MAC2..MACN)."  s/MAY/may  This is not a
normative statement, but just a fact.


(3) The phrase "MUST/SHOULD be learned" is used several times, but the
normative action doesn't seem to apply to learning, but to what is required
to learn.  For example, from §3.1:

  a.  Proxy-ARP dynamic entries:

          They SHOULD be learned by snooping any ARP packet (Ethertype
          0x0806) received from the CEs attached to the BD.

A better wording would be something like: "The PE SHOULD snoop all ARP packets
received from the CEs in order to learn dynamic entries."  The normative
action is clear: snoop!

Please review/update other places where this phrase is used.


(4) §3.1: "They SHOULD be learned by snooping any ARP packet..."  Why is this
action only recommended? When would a PE not snoop the ARP packets? IOW, why
is MUST not used?  Note that neither rfc7432/I-D.ietf-bess-evpn-na-flags use
Normative language then talking about snooping.


(5) §3.1: "They SHOULD be learned out of the Target Address and TLLA information
in NA messages (Ethertype 0x86DD, ICMPv6 type 136) received from the CEs
attached to the BD."  Same questions...


(6) §3.1: "A Proxy-ND implementation SHOULD NOT learn IP->MAC entries from NS
messages, since they don't contain the R Flag required by the Proxy-ND reply
function."  If the R flag is required, when is it ok to learn from NS messages?
IOW, why is this action not a requirement?


(7) §3.1.1: "the node MUST remove that router from the Default Router
List...as specified in [RFC4861] section 7.3.3."  This is in fact already
specified in rfc4861, there's no need to specify it here again.  s/MUST/must


(8) §3.1.1: "Static entries SHOULD have the R Flag information added by the
management interface.  The O Flag information MAY also be added by the
management interface."  It sounds as if the action here is to add the flag,
right?  Perhaps: "The R Flag information SHOULD be added...for static
entries. ..."

When is it ok to not configure the flags?  Why is the configuration not
required?  The text in I-D.ietf-bess-evpn-na-flags seems to assume that it is
a requirement (but no normative language is used there): "R and O Flag
values...are...configured in case of static entries." (§3.1)  What if the
value is not configured, what is the default?


(9) §3.2:

  a.  When replying to ARP Request or NS messages, the PE SHOULD use
      the Proxy-ARP/ND entry MAC address as MAC SA.  This is
      RECOMMENDED so that the resolved MAC can be learned in the MAC
      FIB of potential layer-2 switches sitting between the PE and the
      CE requesting the Address Resolution.

It seems to me that the use as MAC SA should be required and not just
recommended "so that the resolved MAC can be learned in...layer-2 switches".
Why is that not the case?


(10) §3.2: "A PE SHOULD NOT reply to ARP probes received from the CEs."  When
is it ok for the PE to reply?  IOW, why is the behavior recommended and not
required?


(11) §3.2: "A PE SHOULD only reply to ARP-Request and NS messages with the
format specified in [RFC0826] and [RFC4861] respectively."  When is it ok to
reply using a different format, and what format would that be? 


(12) §3.3: "The operator SHOULD be able to activate this option with one of
the following parameters..."  For the operator to be able to do anything, the
implementation has to support the functionality.  It might be better to
recommend the implementation...


(13) §5.1: "Existing mitigation solutions, such as the ARP-Sponge daemon
[ARP-Sponge] MAY also be used in this scenario."  This seems to just be an
example: s/MAY/may


(14) §6: "IXPs MUST still employ additional security mechanisms that protect the
peering network..."  Which are the required mechanisms?


(15) §6: "IXPs...SHOULD follow established BCPs such as the ones described in
[Euro-IX-BCP]."  When is it ok to not follow "established BCPs"?  Seeing that
you are normatively recommending something, please add specific mechanisms,
not just an example.


(16) The references to ARP-Sponge and Euro-IX-BCP don't include enough
information to access the documents.  Is there a stable link that can be
included?

[Ballot comment]
Please expand the following acronyms on first use, or in Section 1: EVPN, PE, EVI, VPLS.

Similarly, CE is expanded in Section 2.2, which is not the first use.

In Section 5.5, you use the term "white-listed". While not required, I ask that you change this to "allow-listed", which some have argued is a more inclusive term.

draft-ietf-bess-evpn-proxy-arp-nd-08

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard
 
  The document was originally Informational but as part of the AD review this was changed primarily
  because the description of the proxy function is much more detailed than the one of 7432. As such it would make sense
  for implementers to be aware of such detailed specification. Furthermore the 7432 proxy function is augmented with the use of NA Flags.
  Therefore the document was moved to Standard Track and Updates 7432. Below is the original text of the write-up.

  ---
  This is appropriate as it describes operational implications of address resolution using
  proxy-ARP/ND in EVPN networks. It makes recommendations for procedures that help to
  reduce address resolution traffic flooding in EVPN, as well as some examples of
  different deployment scenarios. It does not specify new mandatory protocol procedures
  or make any IANA registry requests.
  ---

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
  IPv6 addresses associated with a MAC address. Remote PEs can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
  owner of the MAC) and reduce/suppress the flooding produced by the
  Address Resolution procedure. This EVPN capability is extremely
  useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
  large broadcast domains, where the amount of ARP/ND flooded traffic
  causes issues on routers and CEs. This document describes how the
  EVPN Proxy-ARP/ND function may be implemented to help IXPs and other
  operators deal with the issues derived from Address Resolution in
  large broadcast domains.


Working Group Summary

  The document was developed to address the desire to minimise flooding of traffic
  associated with address resolution in EVPN. It is particularly important due to the
  large size that EVPN networks can grow to, partucularly in terms of the numbers of CEs
  and hosts. It makes recommendations for implementations of Proxy-ARP/ND to help
  operators deal with the issues derived from Address Resolution in large broadcast
  domains.

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The document was also reviewed by the IETF Ops area and comments
  addressed
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v06 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 07.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs. v04 of the document was also reviewed by the IETF Ops
  directorate and comments addressed

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR declarations on the draft.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants.
    There were no objections during last call.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document makes no requests of IANA.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no IANA actions.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bess-evpn-proxy-arp-nd-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-12-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-bess-evpn-proxy-arp-nd@ietf.org, bess-chairs@ietf.org, matthew.bocci@nokia.com, bess@ietf.org, martin.vigoureux@nokia.com, Matthew Bocci
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Operational Aspects of Proxy-ARP/ND in EVPN Networks) to Informational RFC


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Operational Aspects of Proxy-ARP/ND in
EVPN Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
  IPv6 addresses associated with a MAC address.  Remote PEs importing
  those routes in the same Broadcast Domain (BD) can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
  owner of the MAC) and reduce/suppress the flooding produced by the
  Address Resolution procedure.  This EVPN capability is extremely
  useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
  large BDs, where the amount of ARP/ND flooded traffic causes issues
  on connected routers and CEs.  This document describes the EVPN
  Proxy-ARP/ND function augmented by the capability of the ARP/ND
  Extended Community, which together help IXPs and other operators to
  deal with the issues derived from Address Resolution in large BDs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/



No IPR declarations have been submitted directly on this I-D.

draft-ietf-bess-evpn-proxy-arp-nd-08

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Informational.
 
  This is appropriate as it describes operational implications of address resolution using
  proxy-ARP/ND in EVPN networks. It makes recommendations for procedures that help to
  reduce address resolution traffic flooding in EVPN, as well as some examples of
  different deployment scenarios. It does not specify new mandatory protocol procedures
  or make any IANA registry requests.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
  IPv6 addresses associated with a MAC address. Remote PEs can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
  owner of the MAC) and reduce/suppress the flooding produced by the
  Address Resolution procedure. This EVPN capability is extremely
  useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
  large broadcast domains, where the amount of ARP/ND flooded traffic
  causes issues on routers and CEs. This document describes how the
  EVPN Proxy-ARP/ND function may be implemented to help IXPs and other
  operators deal with the issues derived from Address Resolution in
  large broadcast domains.


Working Group Summary

  The document was developed to address the desire to minimise flooding of traffic
  associated with address resolution in EVPN. It is particularly important due to the
  large size that EVPN networks can grow to, partucularly in terms of the numbers of CEs
  and hosts. It makes recommendations for implementations of Proxy-ARP/ND to help
  operators deal with the issues derived from Address Resolution in large broadcast
  domains.

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The document was also reviewed by the IETF Ops area and comments
  addressed
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v06 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 07.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs. v04 of the document was also reviewed by the IETF Ops
  directorate and comments addressed

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR declarations on the draft.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants.
    There were no objections during last call.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document makes no requests of IANA.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no IANA actions.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.

draft-ietf-bess-evpn-proxy-arp-nd-08

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Informational.
 
  This is appropriate as it describes operational implications of address resolution using
  proxy-ARP/ND in EVPN networks. It makes recommendations for procedures that help to
  reduce address resolution traffic flooding in EVPN, as well as some examples of
  different deployment scenarios. It does not specify new mandatory protocol procedures
  or make any IANA registry requests.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
  IPv6 addresses associated with a MAC address. Remote PEs can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
  owner of the MAC) and reduce/suppress the flooding produced by the
  Address Resolution procedure. This EVPN capability is extremely
  useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
  large broadcast domains, where the amount of ARP/ND flooded traffic
  causes issues on routers and CEs. This document describes how the
  EVPN Proxy-ARP/ND function may be implemented to help IXPs and other
  operators deal with the issues derived from Address Resolution in
  large broadcast domains.


Working Group Summary

  The document was developed to address the desire to minimise flooding of traffic
  associated with address resolution in EVPN. It is particularly important due to the
  large size that EVPN networks can grow to, partucularly in terms of the numbers of CEs
  and hosts. It makes recommendations for implementations of Proxy-ARP/ND to help
  operators deal with the issues derived from Address Resolution in large broadcast
  domains.

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The document was also reviewed by the IETF Ops area and comments
  addressed
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v06 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 07.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs. v04 of the document was also reviewed by the IETF Ops
  directorate and comments addressed

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR declarations on the draft.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants.
    There were no objections during last call.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document makes no requests of IANA.
 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no IANA actions.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , Daniel Melzer , Erik Nordmark , Jorge Rabadan , Greg Hankins , Thomas King , Wim Henderickx , bess-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Wim Henderickx , Daniel Melzer , Erik Nordmark , Jorge Rabadan , Greg Hankins , Thomas King , Senthil Sathappan

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Wim Henderickx , Daniel Melzer , Erik Nordmark , Jorge Rabadan , Greg Hankins , Thomas King , Senthil Sathappan

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Wim Henderickx , Daniel Melzer , Erik Nordmark , Jorge Rabadan , Greg Hankins , Thomas King , Senthil Sathappan

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , Erik Nordmark , Daniel Melzer , Jorge Rabadan , Greg Hankins , Thomas King , Wim Henderickx , bess-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Wim Henderickx , Erik Nordmark , Daniel Melzer , Jorge Rabadan , Greg Hankins , Thomas King , Senthil Sathappan

Request for posting confirmation emailed to previous authors: "Jorge Rabadan" , "Senthil Sathappan" , "Kiran Nagaraj" , "Greg Hankins" , "Daniel Melzer" , "Thomas King" , "Erik Nordmark" , "Wim Henderickx"