Re: WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
Robert Raszuk <[email protected]> Tue, 3 Dec 2019 15:20:53 +0100
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <CAOj+MMGpiDtW-HRahyFWLHag0MoqHLeEMFsNsEMtc3E=DyAwRQ@mail.gmail.com> |
--===============4298075203850608334== Content-Type: multipart/alternative; boundary="00000000000024c9cd0598cd68be" --00000000000024c9cd0598cd68be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Gunter, > That means we keep current proposed Type 0 and Type 5 > (and rename Type 5 to something more sensible in that case). Yes and that would be a great fix. To sort of cover more explicitly then via type 0 types 2,3 & 4 you may define new type to carry the "color". The same color as carried in BGP SR Policy document if you want to be SR friendly :). Then we should be fine. Cheers, R., On Tue, Dec 3, 2019 at 11:20 AM Van De Velde, Gunter (Nokia - BE/Antwerp) < [email protected]> wrote: > BGP SR policy is different in such a way that it can not steer based upon > a flowspec tupple match. It uses a payload prefix and NH to select a > particular path policy. > > > > The original path-redirect had no additional assumptions associated and i= t > referenced a 32bit number (Type 0 Seq-ID). > > This 32bit number was used as opaque value to lookup forwarding > information. If enabled, this is what I have in running code. > > > > > > *** > > ID-Type: 1 octet value. This draft defines following Context Types: > > > > 0 - Localised ID (The flowspec client uses the received 32-bit > > indirection-id to lookup forwarding information within the > > localised indirection-id table. The allocation and programming of > > the localised indirection-id table is outside scope of the > > document) > > > > 1 - Node ID with SID/index in MPLS-based Segment Routing (This > > means the 32-bit indirection-id is mapped to an MPLS label using > > the index as a global offset in the SID/label space) > > > > 2 - Node ID with SID/label in MPLS-based Segment Routing (This > > means the 32-bit indirection-id is mapped to an MPLS label using > > the 32-bit indirection-id as global label) > > > > 3 - Binding Segment ID with SID/index in MPLS-based Segment > > Routing (This means the 32-bit indirection-id is mapped to an MPLS > > binding label using the indirection-id as index for global offset > > in the SID/label space) [I-D.draft-ietf-spring-segment-routing] > > [6] > > > > 4 - Binding Segment ID with SID/label in MPLS-based Segment > > Routing (This means 32-bit indirection-id is mapped to an MPLS > > binding label using the 32-bit indirection-id as global label) [I- > > D.draft-ietf-spring-segment-routing] [6] > > > > 5 - Tunnel ID (Tunnel ID is within a single administrative domain > > a 32-bit globally unique tunnel identifier. The allocation and > > programming of the Tunnel ID within the localised indirection-id > > table is outside scope of the document) > > > > Generalized indirection_id: 32-bit identifier used as indirection_id > > > > *** > > > > I do have sympathy for your suggestion to simplify assuming if the genera= l > WG feels that there is too much overlap between the BGP SR Policy > propagation and the current indirection Type 1, 2, 3, 4? We could drop > those Type=E2=80=99s from the current draft and simplify interop complexi= ty? That > means we keep current proposed Type 0 and Type 5 (and rename Type 5 to > something more sensible in that case). > > > > G/ > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Monday, December 2, 2019 19:30 > *To:* Jeffrey Haas <[email protected]>; Van De Velde, Gunter (Nokia - > BE/Antwerp) <[email protected]> > *Cc:* [email protected]; Sue Hares <[email protected]> > *Subject:* Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt > [11/17/2019 to 12/2/2019] > > > > > > I suspect in the majority of the cases that path-redirect is intended > involving segment routing that following a segment path from a VRF contex= t > doesn't make much sense. However, some of the cases are left as much mor= e > 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 ? Rout= er > 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/ > > > --00000000000024c9cd0598cd68be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hey Gunter,<div><br></div><div>> That means we keep cur= rent proposed Type 0 and Type 5=C2=A0</div><div>> (and rename Type 5 to = something more sensible in that case).=C2=A0=C2=A0<br></div><div><br></div>= <div>Yes and that would be a great fix.=C2=A0</div><div><br></div><div>To s= ort of cover more explicitly=C2=A0then via type 0 types 2,3 & 4 you may= define new type to carry the "color". The same color as carried = in BGP SR Policy document if you want to be SR friendly :).=C2=A0</div><div= ><br></div><div>Then we should be fine.=C2=A0</div><div><br></div><div>Chee= rs,</div><div>R.,</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr= " class=3D"gmail_attr">On Tue, Dec 3, 2019 at 11:20 AM Van De Velde, Gunter= (Nokia - BE/Antwerp) <<a href=3D"mailto:[email protected]">= [email protected]</a>> wrote:<br></div><blockquote class=3D"= gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= 4,204,204);padding-left:1ex"> <div lang=3D"EN-US"> <div class=3D"gmail-m_-6760708744570272191WordSection1"> <p class=3D"MsoNormal">BGP SR policy is different in such a way that it can= not steer based upon a flowspec tupple match. It uses a payload prefix and= NH to select a particular path policy.<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">The original path-redirect had no additional assumpt= ions associated and it referenced a 32bit number (Type 0 Seq-ID).<u></u><u>= </u></p> <p class=3D"MsoNormal">This 32bit number was used as opaque value to lookup= forwarding information. If enabled, this is what I have in running code.<u= ></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">***<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0 ID-Type: 1 octet value.=C2=A0 This draf= t defines following Context Types:<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 - Localised ID (The= flowspec client uses the received 32-bit<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indirection-id to loo= kup forwarding information within the<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 localised indirection= -id table.=C2=A0 The allocation and programming of<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the localised indirec= tion-id table is outside scope of the<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document)<u></u><u></= u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 - Node ID with SID/= index in MPLS-based Segment Routing (This<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 means the 32-bit indi= rection-id is mapped to an MPLS label using<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the index as a global= offset in the SID/label space)<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 - Node ID with SID/= label in MPLS-based Segment Routing (This<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 means the 32-bit indi= rection-id is mapped to an MPLS label using<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the 32-bit indirectio= n-id as global label)<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3 - Binding Segment I= D with SID/index in MPLS-based Segment<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Routing (This means t= he 32-bit indirection-id is mapped to an MPLS<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binding label using t= he indirection-id as index for global offset<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the SID/label spac= e) [I-D.draft-ietf-spring-segment-routing]<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [6]<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4 - Binding Segment I= D with SID/label in MPLS-based Segment<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Routing (This means 3= 2-bit indirection-id is mapped to an MPLS<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binding label using t= he 32-bit indirection-id as global label) [I-<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D.draft-ietf-spring-s= egment-routing] [6]<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5 - Tunnel ID (Tunnel= ID is within a single administrative domain<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a 32-bit globally uni= que tunnel identifier.=C2=A0 The allocation and<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 programming of the Tu= nnel ID within the localised indirection-id<u></u><u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 table is outside scop= e of the document)<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">=C2=A0=C2=A0 Generalized indirection_id: 32-bit iden= tifier used as indirection_id<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">***<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">I do have sympathy for your suggestion to simplify a= ssuming if the general WG feels that there is too much overlap between the = BGP SR Policy propagation and the current indirection Type 1, 2, 3, 4? We c= ould drop those Type=E2=80=99s from the current draft and simplify interop complexity? That means we keep current proposed= Type 0 and Type 5 (and rename Type 5 to something more sensible in that ca= se).<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">G/<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal"><b>From:</b> Robert Raszuk <<a href=3D"mailto:rob= [email protected]" target=3D"_blank">[email protected]</a>> <br> <b>Sent:</b> Monday, December 2, 2019 19:30<br> <b>To:</b> Jeffrey Haas <<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>>; Van De Velde, Gunter (Nokia - BE/Antwerp) <= <a href=3D"mailto:[email protected]" target=3D"_blank">gunter.v= [email protected]</a>><br> <b>Cc:</b> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a>; Sue Hares <<a href=3D"mailto:[email protected]" target=3D"_blank">shar= [email protected]</a>><br> <b>Subject:</b> Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.tx= t [11/17/2019 to 12/2/2019]<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <div> <div> <div> <p class=3D"MsoNormal">=C2=A0<u></u><u></u></p> </div> <blockquote style=3D"border-top:none;border-right:none;border-bottom:none;b= order-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4= ..8pt;margin-right:0in"> <p class=3D"MsoNormal">I suspect in the majority of the cases that path-red= irect is intended<br> involving segment routing that following a segment path from a VRF context<= br> doesn't make much sense.=C2=A0 However, some of the cases are left as m= uch more<br> abstract and perhaps they could?<u></u><u></u></p> </blockquote> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IMO using flow spec extension to specify a binding S= ID which in turn will be replaced by explicit path is a huge mistake this d= raft is proposing. Sure text can take everything but the operational comple= xity to troubleshoot such network will be a nightmare. And if you would just specify a single SID why not to= specify the=C2=A0IP address and be done ? Router will reach such IP via pr= oper path.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Please observe that you are now trying to mimic BGP = SR Policy propagation which also includes mapping via color and policy to b= e used.=C2=A0<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">What happens when router will receive both in a conf= licting manner ?=C2=A0<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Btw what practical application is this draft trying = to accomplish other then pretty badly redo subset of BGP SR Policy work=C2= =A0?=C2=A0<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Thx,<br> R/<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> </div> </div> </div> </div> </blockquote></div> --00000000000024c9cd0598cd68be-- --===============4298075203850608334== 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 --===============4298075203850608334==--