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) <ket...@cisco.com> wrote: > 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 <markzzzsm...@gmail.com> > *Sent:* 16 December 2019 12:27 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> > *Cc:* SPRING WG <spring@ietf.org>; i-d-annou...@ietf.org > *Subject:* Re: [spring] I-D Action: > draft-ietf-spring-segment-routing-policy-06.txt > > > > > > On Mon, 16 Dec 2019, 16:43 Ketan Talaulikar (ketant), <ket...@cisco.com> > 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. > > 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. > > > > > > 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 <spring-boun...@ietf.org> On Behalf Of Mark Smith > Sent: 16 December 2019 06:36 > To: SPRING WG <spring@ietf.org> > Cc: i-d-annou...@ietf.org > Subject: Re: [spring] I-D Action: > draft-ietf-spring-segment-routing-policy-06.txt > > "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, <internet-dra...@ietf.org> wrote: > > > > > > 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-pol > > icy/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-0 > > 6 > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routin > > g-policy-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-po > > licy-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/ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
