Re: [Gen-art] Genart telechat review of draft-ietf-bfd-vxlan-09

[Alissa Cooper]

Erik, thanks for your review. Greg, thanks for addressing Erik’s comments. I 
entered a No Objection ballot.

Alissa


> On Dec 17, 2019, at 6:17 PM, Greg Mirsky  wrote:
> 
> Hi Erik,
> thank you for your reviews and for sharing thoughts on the selection of the 
> destination IPv6 address. Following recommendations from Adam, I've updated 
> the document to use the proper representation of IPv6 addresses and refer to 
> them as "IPv4-mapped IPv4 loopback addresses". These updates are in the 
> attached diff.. Adam also noted that RFC 8504 doesn't have a similar wording 
> regarding the handling of packets addressed to an address from 127/8 network 
> as RFC 1812 (of course, referring to IPv4-mapped 127/8 addresses):
>   A router SHOULD NOT forward, except over a loopback interface, any
>   packet that has a destination address on network 127.  A router
>   MAY have a switch that allows the network manager to disable these
>   checks.  If such a switch is provided, it MUST default to
>   performing the checks.
> I'd note, that the egress BFD system is expected to accept a BFD packet with 
> the destination IP address from the specified range without being provisioned 
> for the specific address from that range. Perhaps that makes the use of this 
> range possible even though its special handling is not explicitly documented.
> 
> Best regards,
> Greg
> 
> 
> On Mon, Dec 16, 2019 at 9:19 PM Erik Kline via Datatracker  > wrote:
> Reviewer: Erik Kline
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-bfd-vxlan-??
> Reviewer: Erik Kline
> Review Date: 2019-12-16
> IETF LC End Date: None
> IESG Telechat date: 2019-12-19
> 
> Summary:
> 
> -09 addresses my concerns from -07.  Thank you for this.
> 
> The one "nit" is that it seems to have introduced a recommendation to use
> :::7f00:0/104 as an IPv6 loopback prefix.  (a) This document should follow
> the format recommendations of RFC 5952 section 4.3 and lowercase the "F"s.  
> But
> (b) more importantly, I'm not sure how implementations may treats this space.
> 
> The use of an RFC4291 section-2.5.5.2 mapped v4 address doesn't necessarily
> make the packet a part of an IPv6 connection.  Nevertheless, I'm not sure I
> have a strong feeling about this as it may still exercise enough of the IPv6
> stack in a VTEP.
> 
> I definitely do think that in the case of BFD on the management VNI targeting
> an IPv6 link-local address of the VTEP would be better.  However, I expect 
> that
> if :::127.0.0.0 does prove to have some issues in the future a -bis can be
> written quickly with a recommendation.
> 
> Also, Suresh may have ideas for a solution.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
>  draft-ietf-bfd-vxlan-10.txt.html>___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-bfd-vxlan-09

[Greg Mirsky]

Hi Erik,
thank you for your reviews and for sharing thoughts on the selection of the
destination IPv6 address. Following recommendations from Adam, I've updated
the document to use the proper representation of IPv6 addresses and refer
to them as "IPv4-mapped IPv4 loopback addresses". These updates are in the
attached diff. Adam also noted that RFC 8504 doesn't have a similar wording
regarding the handling of packets addressed to an address from 127/8
network as RFC 1812 (of course, referring to IPv4-mapped 127/8 addresses):
  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.  A router
  MAY have a switch that allows the network manager to disable these
  checks.  If such a switch is provided, it MUST default to
  performing the checks.
I'd note, that the egress BFD system is expected to accept a BFD packet
with the destination IP address from the specified range without being
provisioned for the specific address from that range. Perhaps that makes
the use of this range possible even though its special handling is not
explicitly documented.

Best regards,
Greg


On Mon, Dec 16, 2019 at 9:19 PM Erik Kline via Datatracker 
wrote:

> Reviewer: Erik Kline
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-bfd-vxlan-??
> Reviewer: Erik Kline
> Review Date: 2019-12-16
> IETF LC End Date: None
> IESG Telechat date: 2019-12-19
>
> Summary:
>
> -09 addresses my concerns from -07.  Thank you for this.
>
> The one "nit" is that it seems to have introduced a recommendation to use
> :::7f00:0/104 as an IPv6 loopback prefix.  (a) This document should
> follow
> the format recommendations of RFC 5952 section 4.3 and lowercase the
> "F"s.  But
> (b) more importantly, I'm not sure how implementations may treats this
> space.
>
> The use of an RFC4291 section-2.5.5.2 mapped v4 address doesn't necessarily
> make the packet a part of an IPv6 connection.  Nevertheless, I'm not sure I
> have a strong feeling about this as it may still exercise enough of the
> IPv6
> stack in a VTEP.
>
> I definitely do think that in the case of BFD on the management VNI
> targeting
> an IPv6 link-local address of the VTEP would be better.  However, I expect
> that
> if :::127.0.0.0 does prove to have some issues in the future a -bis
> can be
> written quickly with a recommendation.
>
> Also, Suresh may have ideas for a solution.
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-09.txt - draft-ietf-bfd-vxlan-10.txt.html": Unrecognized >>>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-bfd-vxlan-09

[Erik Kline via Datatracker]

Reviewer: Erik Kline
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-bfd-vxlan-??
Reviewer: Erik Kline
Review Date: 2019-12-16
IETF LC End Date: None
IESG Telechat date: 2019-12-19

Summary:

-09 addresses my concerns from -07.  Thank you for this.

The one "nit" is that it seems to have introduced a recommendation to use
:::7f00:0/104 as an IPv6 loopback prefix.  (a) This document should follow
the format recommendations of RFC 5952 section 4.3 and lowercase the "F"s.  But
(b) more importantly, I'm not sure how implementations may treats this space.

The use of an RFC4291 section-2.5.5.2 mapped v4 address doesn't necessarily
make the packet a part of an IPv6 connection.  Nevertheless, I'm not sure I
have a strong feeling about this as it may still exercise enough of the IPv6
stack in a VTEP.

I definitely do think that in the case of BFD on the management VNI targeting
an IPv6 link-local address of the VTEP would be better.  However, I expect that
if :::127.0.0.0 does prove to have some issues in the future a -bis can be
written quickly with a recommendation.

Also, Suresh may have ideas for a solution.

Major issues:

Minor issues:

Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art