Hi Donald,
many thanks for your clarification. Will wait for the IESG review of the
current version.
Regards,
Greg
On Mon, Aug 10, 2020 at 1:52 PM Donald Eastlake wrote:
> Hi Greg,
>
> You shouldn't put a specific MAC address in the draft until it is
> assigned in the IANA registry.
>
> Request
Hi Greg,
You shouldn't put a specific MAC address in the draft until it is
assigned in the IANA registry.
Requests that only appear in drafts don't take effect until the draft
is approved but if assignment policy for the registry does not require
IESG approval of a draft (for example, First Come
Greg,
Sorry, I was looking at two messages back to back. From a unicast from Donald:
> I'm still working on catching up on the MAC address aspects of this
> discussion so this message may have been overcome by events.
>
> But individual MAC addresses are abundant. I received a request from
> IA
Hi Jeff,
to update the IANA considerations section by replacing TBD1 with the actual
MAC address? I see two small allocation ranges for in the Unicast MAC
addresses:
00-52-02 to 00-52-12 Unassigned (small allocations)
.
00-52-14 to 00-52-FF Unassigned (small allocations)
Also, can we change th
Thank you, Donald.
Greg, would you bump the draft with this assignment?
-- Jeff
> On Aug 10, 2020, at 1:08 PM, Donald Eastlake wrote:
>
> Hi,
>
> My apologies for not responding earlier in this thread.
>
> IANA originally contacted me as a Designated Expert for MAC addresses
> under the IAN
Hi,
My apologies for not responding earlier in this thread.
IANA originally contacted me as a Designated Expert for MAC addresses
under the IANA OUI last year in connection with version -07. At that
time, I approved an assignment for this draft. I'm fine with any
reasonable usage description the
Hi Jeff,
do you think that the record in the Usage filed for the requested MAC
address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM over
NVO3"?
What do you think?
Regards,
Greg
On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas wrote:
> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeff
Hi Jeff, et al.,
attached please find the new working version of BFD over VXLAN and its diff
to -13.
Please let me know if you have any questions.
Regards,
Greg
On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas wrote:
> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> > >> Proposed so
Hi Jeff,
thank you for the proposed text. I'll include it in the working version
with capitalizing VXLAN in the IANA section).
Regards,
Greg
On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas wrote:
> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> > >> Proposed solution: A MAC value
Review of -13 vs. previous open issues.
The short version is the issue list is largely resolved. Summary of
actions:
- Update BFD Echo text as per last comment in this reply.
- We need to resolve MAC address assignment.
- There may be a lingering issue over the loopback network which will be
ad
On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> >> Proposed solution: A MAC value should be chosen that is well known and the
> >> text would become:
> >>
> >> "Destination MAC: A Management VNI, which does not have any tenants, will
> >> have no dedicated MAC address for decapsula
Hi Jeff,
thank you for the additional details. I've top-posted the discussion thread
regarding a firewall, VTEP, and drop rules. I recall that the relevant text
was suggested based on deployment experience. I will try to update it along
the suggested lines:
I think the rewording would include some
Hi Alvaro,
thank you for the clarification. I will update the reference by using the
text you've suggested.
Regards,
Greg
On Wed, Jun 17, 2020 at 12:59 PM Alvaro Retana
wrote:
> Greg:
>
> Rfc5881 already specifies using GTSM…this document depends on rfc5881, so
> the reference should be the BFD
Greg:
Rfc5881 already specifies using GTSM…this document depends on rfc5881, so
the reference should be the BFD behavior.
Alvaro.
On June 17, 2020 at 2:40:52 PM, Greg Mirsky (gregimir...@gmail.com) wrote:
Hi Alvaro,
thank you for the suggestion. I have a question. The current version
references
Greg,
> On Jun 16, 2020, at 9:05 PM, Greg Mirsky wrote:
> thank you for providing continued support and guidance. Please find my
> notes in-lined under tag GIM>>. Attached are the new working version and
> its diff to -12. There are two remaining Open Issues - 7 and 9. I much
> appreciate your c
Hi Alvaro,
thank you for the suggestion. I have a question. The current version
references RFC 5082:
TTL or Hop Limit: MUST be set to 255 in accordance with the
Generalized TTL Security Mechanism [RFC5082].
RFC 5881, while stating the requirement for the TTL or Hop Limit value,
re
On June 16, 2020 at 5:01:57 PM, Jeffrey Haas wrote:
Hi!
> > Open Issue 1: Discussion on TTL/Hop Limit = 1
> >
> > Proposed Action: Greg has proposed text he will send to the working group
> > suggesting GTSM procedures be utilized. The expected concern is how this
> > impacts existing impl
Hi Jeff,
A big "thank you!" for continuing to track the many issues, I think I have
a sense for the effort involved, but it makes a huge difference.
Since I was mentioned, a couple comments inline.
On Tue, Jun 16, 2020 at 05:10:57PM -0400, Jeffrey Haas wrote:
> [Apologies on further delay. The b
Hi Jeff,
thank you for providing continued support and guidance. Please find my
notes in-lined under tag GIM>>. Attached are the new working version and
its diff to -12. There are two remaining Open Issues - 7 and 9. I much
appreciate your considerations and suggestions.
Regards,
Greg
On Tue, Jun
[Apologies on further delay. The best way to cause unexpected work is to
offer a personal deadline to have something done.]
Greg and the IESG,
This update is vs. version -12 of the draft.
General summary: Almost ready to go. Multiple issues are resolved. Pending
items flagged here should be a
Hi Alvaro,
thank you for your suggestion. I'll update the reference to RFC 5881. And
I've realized that GTSM is not used anywhere else in the document. Cleaned
it up.
I will try to make the new update before the cut-off date.
Regards,
Greg
On Tue, Feb 25, 2020 at 11:25 AM Alvaro Retana
wrote:
>
On January 27, 2020 at 5:44:24 PM, Greg Mirsky wrote:
Greg:
Hi!
> below are the proposed changes to address the IP TTL/Hop Limit open issue
I didn't see a discussion on the list, but since I'm holding the DISCUSS...
Your proposed changes are fine, just one nit:
> NEW TEXT:
> TTL or Hop
Dear All,
I've looked at:
Open Issue 4: "multicast service node" text (COMMENT via Benjamin K.)
Proposed Action: Incorporate suggested text from Benjamin K. to clarify text
in -10.
Below is the COMMENT by Benjamin Kaduk:
Section 1
In the case where a Multicast Service Node (MSN) (as described
Dear Jeff,
thank you for the most detailed caption of the IESG reviews and clear
action points to address the outstanding issues.
Dear All,
below are the proposed changes to address the IP TTL/Hop Limit open issue
(also could be reviewed in the attached diff or the new working version of
the draft
24 matches
Mail list logo
