Re: WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Robert Raszuk <[email protected]> Mon, 2 Dec 2019 19:29:40 +0100
Newsgroups gmane.ietf.idr
Message-ID <CAOj+MMHbHVARhpDasx6e=Q8f3Q8HNG8JQ4Wn7mwAyaDPA6wvRQ@mail.gmail.com>
--===============4097962639634618498==
Content-Type: multipart/alternative; boundary="000000000000c5f3610598bcc391"

--000000000000c5f3610598bcc391
Content-Type: text/plain; charset="UTF-8"

> I suspect in the majority of the cases that path-redirect is intended
> involving segment routing that following a segment path from a VRF context
> doesn't make much sense.  However, some of the cases are left as much more
> abstract and perhaps they could?
>

IMO using flow spec extension to specify a binding SID which in turn will
be replaced by explicit path is a huge mistake this draft is proposing.
Sure text can take everything but the operational complexity to
troubleshoot such network will be a nightmare. And if you would just
specify a single SID why not to specify the IP address and be done ? Router
will reach such IP via proper path.

Please observe that you are now trying to mimic BGP SR Policy propagation
which also includes mapping via color and policy to be used.

What happens when router will receive both in a conflicting manner ?

Btw what practical application is this draft trying to accomplish other
then pretty badly redo subset of BGP SR Policy work ?

Thx,
R/

--000000000000c5f3610598bcc391
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">I suspect in the majority of the cases =
that path-redirect is intended<br>
involving segment routing that following a segment path from a VRF context<=
br>
doesn&#39;t make much sense.=C2=A0 However, some of the cases are left as m=
uch more<br>
abstract and perhaps they could?<br></blockquote><div><br></div><div>IMO us=
ing flow spec extension to specify a binding SID which in turn will be repl=
aced by explicit path is a huge mistake this draft is proposing. Sure text =
can take everything but the operational complexity to troubleshoot such net=
work will be a nightmare. And if you would just specify a single SID why no=
t to specify the=C2=A0IP address and be done ? Router will reach such IP vi=
a proper path.</div><div><br></div><div>Please observe that you are now try=
ing to mimic BGP SR Policy propagation which also includes mapping via colo=
r and policy to be used.=C2=A0</div><div><br></div><div>What happens when r=
outer will receive both in a conflicting manner ?=C2=A0</div><div><br></div=
><div>Btw what practical application is this draft trying to accomplish oth=
er then pretty badly redo subset of BGP SR Policy work=C2=A0?=C2=A0</div><d=
iv><br></div><div>Thx,<br>R/</div><div><br></div></div></div>

--000000000000c5f3610598bcc391--


--===============4097962639634618498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr

--===============4097962639634618498==--