Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-06.txt

From: [email-masked]
Date: Sun, 15 Dec 2019 16:08:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : Segment Routing Policy Architecture
        Authors         : Clarence Filsfils
                          Siva Sivabalan
                          Daniel Voyer
                          Alex Bogdanov
                          Paul Mattes
	Filename        : draft-ietf-spring-segment-routing-policy-06.txt
	Pages           : 35
	Date            : 2019-12-15

Abstract:
   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path.  Intermediate per-flow states are eliminated thanks
   to source routing.  The headend node steers a flow into an SR Policy.
   The header of a packet steered in an SR Policy is augmented with an
   ordered list of segments associated with that SR Policy.  This
   document details the concepts of SR Policy and steering into an SR
   Policy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Dec 2019 12:05:37 +1100

"The endpoint indicates the destination of the policy.  The endpoint
   is specified as an IPv4 or IPv6 address and is expected to be unique
   in the domain.  In a specific case (refer to Section 8.8.1), the
   endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6)."

Per Internet Standard 3 / RFC 1122, 0.0.0.0 is an illegal IPv4
destination address.*

Per RFC 4291, ::0 is an illegal IPv6 destination address.

Regards,
Mark.

*People doing tricky things with 0.0.0.0 has cost me and a past
employer 2 weeks of needless troubleshooting, delaying a
product/service launch.

http://lists.ausnog.net/pipermail/ausnog/2017-July/039402.html

On Mon, 16 Dec 2019 at 11:08, <[email-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 16 Dec 2019 05:43:37 +0000

Hi Mark,

The draft talks about "destination of the policy" as in the tail-end node of the SR Policy. It does not talk about the destination IP address in the packet.

You can consider this as a "default policy" on similar lines as a default route.

Please see the section below which will cover one of the use-cases for steering over such SR policies to the null endpoint.
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06#section-8.8.1

Hope that clarifies.

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Mark Smith
Sent: 16 December 2019 06:36
To: SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-06.txt

Per Internet Standard 3 / RFC 1122, 0.0.0.0 is an illegal IPv4 destination address.*

Regards,
Mark.

*People doing tricky things with 0.0.0.0 has cost me and a past employer 2 weeks of needless troubleshooting, delaying a product/service launch.

On Mon, 16 Dec 2019 at 11:08, <[email-masked]> wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Dec 2019 17:56:54 +1100

On Mon, 16 Dec 2019, 16:43 Ketan Talaulikar (ketant), <[email-masked]>
wrote:

> Hi Mark,
>
> The draft talks about "destination of the policy" as in the tail-end node
> of the SR Policy. It does not talk about the destination IP address in the
> packet.
>
> Please see the section below which will cover one of the use-cases for
> steering over such SR policies to the null endpoint.
>

I don't think it does.

If this text is true - "The endpoint
   is specified as an IPv4 or IPv6 address" - then those are illegal IPv4
and IPv6 addresses.

If these are not being used as IPv4 or IPv6 addresses, then they cannot be
referred to as IPv4 or IPv6 addresses. It is confusing and inaccurate if
they are.

> Subject: Re: [spring] I-D Action:
> draft-ietf-spring-segment-routing-policy-06.txt
>
> *People doing tricky things with 0.0.0.0 has cost me and a past employer 2
> weeks of needless troubleshooting, delaying a product/service launch.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 16 Dec 2019 10:06:40 +0000

Hi Mark,

Could you share references which says it is illegal to refer to 0.0.0.0 or :: as IP addresses?

Many (if not most) implementations use these representations of IP addresses when provisioning a default static route and there is nothing wrong with doing so.

The link you shared previously that indicated an issue because someone was using these zero addresses as destination IP in the packets. That would be an incorrect analogy since there is no such proposal in this document.

Thanks,
Ketan

From: Mark Smith <[email-masked]>
Sent: 16 December 2019 12:27
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-06.txt

On Mon, 16 Dec 2019, 16:43 Ketan Talaulikar (ketant), <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,

Hope that clarifies.

I don't think it does.

If this text is true - "The endpoint
   is specified as an IPv4 or IPv6 address" - then those are illegal IPv4 and IPv6 addresses.

If these are not being used as IPv4 or IPv6 addresses, then they cannot be referred to as IPv4 or IPv6 addresses. It is confusing and inaccurate if they are.

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: 16 December 2019 06:36
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-06.txt

Regards,
Mark.

On Mon, 16 Dec 2019 at 11:08, <[email-masked]<mailto:[email-masked]>> wrote:
> submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Dec 2019 11:45:31 +0100

Hi Ketan,

I think Mark is right here.

I went through this document again and it seems that it defines endpoint to
be used as either "address" or "prefix". See there is nothing wrong with
using prefix ... but "address" is normally referred to what is in the
packet.

Moreover your examples of default routes specify special prefixes of
0.0.0.0 not addresses.

Honestly if you re-define all endpoint use as prefix you will nicely cover
over all of your cases. Even more ... you will also nicely cover SR anycast
case. So my suggestion would be to encode endpoint as prefix+mask in all
cases here.

Thx,
R.

On Mon, Dec 16, 2019 at 11:07 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Many (if not most) implementations use these representations of IP
> addresses when provisioning a default static route and there is nothing
> wrong with doing so.
>
>
>
> The link you shared previously that indicated an issue because someone was
> using these zero addresses as destination IP in the packets. That would be
> an incorrect analogy since there is no such proposal in this document.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Mark Smith <[email-masked]>
> *Sent:* 16 December 2019 12:27
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; [email-masked]
> *Subject:* Re: [spring] I-D Action:

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Dec 2019 08:18:45 +1100

> an incorrect analogy since there is no such proposal in this document.
I read "end point" as a synonym for "destination". I don't see how it could
be describing anything else.

E.g., a tunnel "end point" IP address identifies where a tunnel finishes,
and that  is going result in that IP address placed in an outer tunnel
packet's destination address field at some point in time.

A destination address identifies the point at the end (end point) of a
packet's path across the network. (In RFC8200 this is always a receiving
host function, per RFC8200's definition of host and router.)

0.0.0.0 and ::0 are prohibited destination or end point addresses as the
don't identify one - they're the 'unspecified' addresses.

If, as Robert said, you're describing routes or prefixes, then that is the
terminology that should be used.

Supplying the prefix length in all instances would also make it much
clearer that routes are being described.

Regards,
Mark.