Re: WG LC draft-ietf-idr-flowspec-path-redirect-10 .txt [11/17/2019 to 12/2/2019]
Gunter Van De Velde <[email protected]> Fri, 29 Nov 2019 10:13:39 -0000
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <[email protected]> |
--===============2545798552715757055==
Content-Type: multipart/alternative;
boundary=Apple-Webmail-42--2cad2693-41d6-4665-8d59-4df09d4c2fe0
--Apple-Webmail-42--2cad2693-41d6-4665-8d59-4df09d4c2fe0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8;
format=flowed
Hi Robert,=0A=0A=0AWhile understanding your point, it does feel like openi=
ng a=C2=A0potential can of worms=C2=A0with respect to validation of all po=
ssible combinations humanly possible. Is the use-case for this capability =
solid enough that we need this complication? There seems nothing broken wi=
th keeping things simple.=C2=A0=0A=0A=0AG/=0A=0A=0ASent from iCloud=0A=0AO=
n November 29, 2019 at 10:34 AM, Robert Raszuk <[email protected]> wrote:=0A=
=0A=0AGunter,=0A=0A=0ATo your and Jeff's point regarding multiple redirect=
rules I have a bit different perspective.=C2=A0=0A=0A=0AFirst let's obser=
ve that redirect could be realized in two forms (both are valid and used i=
n practice):=C2=A0=0A=0A=0A-A- redirect=C2=A0of the original flow=C2=A0=0A=
-B- redirect of copy of the flow=C2=A0=0A=0A=0ASee while in -A- clearly on=
e redirect must be used, in -B- on the other=C2=A0hand multiple redirects =
should be supported. One span, one security TAP, one TCP analyzer etc ...=C2=
=A0=0A=0A=0AYour draft defines -A-. To add -B- all what is needed is just =
one bit flag.=C2=A0=0A=0A=0AWould you consider it ?=C2=A0=0A=0A=0ACheers,=0A=
R.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Fri, Nov 29, 2019 at 4:51 AM Van De =
Velde, Gunter (Nokia - BE/Antwerp) <[email protected]> wrote:=0A=
=0AHi Jeff,=0A=C2=A0=0AThanks for the feedback and suggestions.=0A=C2=A0=0A=
See inline: GV>=0A=C2=A0=0A-----Original Message-----=0AFrom: Idr <idr-bou=
[email protected]> On Behalf Of Jeffrey Haas=0ASent: Thursday, November 28, 20=
19 20:21=0ATo: Sue Hares <[email protected]>=0ACc: [email protected]=0ASubject: R=
e: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to=
12/2/2019]=0A=C2=A0=0ASue,=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A> On Nov 18, 2019=
, at 12:41 AM, Susan Hares <[email protected]> wrote:=0A>=0A> This begins a =
2 week WG Last call on draft-idr-flowspec-path-redirect-10.txt from [11/17=
/2019 to 12/2/2019].=0A>=C2=A0=0A> You can obtain the draft at:=0A>=C2=A0=0A=
> https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/=0A=
>=C2=A0=0A> Consider in your review whether this draft:=0A>=C2=A0=0A> 1)=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is compatible with draft-ietf-rfc5575bis-17.tx=
t?=0A=C2=A0=0AYes.=C2=A0 (Close enough.)=C2=A0 The current version of the =
draft is implementable.=0A=C2=A0=0A> 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Whet=
her the draft is useful for deployments of flow specification=0A=C2=A0=0AI=
t can be useful.=0A=C2=A0=0A> 3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this tec=
hnology ready for deployment?=0A> 4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the =
write-up of this technology in draft-ietf-idr-flowspec-path-redirect clear=
ly written and ready for publication?=0A=C2=A0=0AReady with minor issues, =
IMO:=0A=C2=A0=0AProcedure-wise, there needs to be a bit more text covering=
cases about interactions with other traffic actions.=C2=A0 This was a kno=
wn headache for similar drafts such as redirect-to-ip.=C2=A0 In particular=
, interaction with redirect-to-ip and redirect-to-vrf is needed.=0A=C2=A0=0A=
GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D gives input on this=
.. We discussed this with you long ago and hence this text was added.=0A=C2=
=A0=0A=E2=80=9C=0A=C2=A0=C2=A0 While it MUST NOT happen, and is seen as in=
valid combination, it is=0A=C2=A0=C2=A0 possible from a semantics perspect=
ive to have multiple clashing=0A=C2=A0=C2=A0 redirect actions defined with=
in a single flowspec rule.=C2=A0 For best and=0A=C2=A0=C2=A0 consistant co=
mpatibility with legacy implementations, the redirect=0A=C2=A0=C2=A0 funct=
ionality as documented by rfc5575bis MUST NOT be broken, and=0A=C2=A0=C2=A0=
hence when a clash occurs, then rfc5575bis based redirect MUST take=0A=C2=
=A0=C2=A0 priority.=0A=E2=80=9C=0A=C2=A0=0AThis means that redirect-to-VRF=
will take absolute priority to not break rfc5575bis behavior.=0AHaving al=
so redirect-to-ip will result in an invalid=0A=C2=A0=0A=C2=A0=0AThe text "=
A single flowspec rule MUST NOT have more as one indirection-id per S-ID.=C2=
=A0 On a flowspec client the indirection-id with lowest S-ID MUST be impos=
ed first for any given flowspec entry."=C2=A0 There's no procedure for wha=
t happens in error handling when you do have more than one of the same S-I=
D.=C2=A0 The text about the case for S-ID of 0 is also a bit ambiguous.=C2=
=A0 It feels like it's reading "there is no sequence", but what do you do =
when you then have ones that do?=0A=C2=A0=0AGV> What about the following r=
ewrite:=0A=C2=A0=0AOriginal:=0A=C2=A0=C2=A0 The 'S-ID' field identifies a =
4 bit Sequence ID field.=C2=A0 This field is=0A=C2=A0=C2=A0 used to provid=
e a flowspec client an indication how and where to=0A=C2=A0=C2=A0 sequence=
the received indirection-ids.=C2=A0 The Sequence ID value 0=0A=C2=A0=C2=A0=
indicates that Sequence ID field is NOT set and SHOULD be ignored.=C2=A0 =
A=0A=C2=A0=C2=A0 single flowspec rule MUST NOT have more as one indirectio=
n-id per=0A=C2=A0=C2=A0 S-ID.=C2=A0 On a flowspec client the indirection-i=
d with lowest S-ID MUST=0A=C2=A0=C2=A0 be imposed first for any given flow=
spec entry.=0A=C2=A0=0ANew:=0A=C2=A0=C2=A0 The 'S-ID' field identifies a 4=
bit Sequence ID field.=C2=A0 This field is=0A=C2=A0=C2=A0 used to provide=
a flowspec client an indication how and where to=0A=C2=A0=C2=A0 sequence =
the received indirection-ids.=C2=A0 The Sequence ID value 0=0A=C2=A0=C2=A0=
indicates that Sequence ID field is NOT set and **all other sequence ID's=
**=0A=C2=A0=C2=A0 SHOULD be ignored.=C2=A0 A=0A=C2=A0=C2=A0 single flowspe=
c rule MUST NOT have more as one indirection-id per=0A=C2=A0=C2=A0 S-ID.=C2=
=A0 On a flowspec client the indirection-id with lowest S-ID MUST=0A=C2=A0=
=C2=A0 be imposed first for any given flowspec entry.=0A=C2=A0=0AGV> In se=
ction *6. Validation procedure" there is text to handle the error conditio=
n when the flowspec rule results in an invalid redirection, that prescribe=
what needs to happen when the =E2=80=9Credirect to indirection-id=E2=80=9D=
does not result in a valid redirection:=0A=C2=A0=0A"=0A=C2=A0=C2=A0 While=
it MUST NOT happen, and is seen as invalid combination, it is=0A=C2=A0=C2=
=A0 possible from a semantics perspective to have multiple clashing=0A=C2=A0=
=C2=A0 redirect actions defined within a single flowspec rule.=C2=A0 For b=
est and=0A=C2=A0=C2=A0 consistant compatibility with legacy implementation=
s, the redirect=0A=C2=A0=C2=A0 functionality as documented by rfc5575bis M=
UST NOT be broken, and=0A=C2=A0=C2=A0 hence when a clash occurs, then rfc5=
575bis based redirect MUST take=0A=C2=A0=C2=A0 priority.=C2=A0 Additionall=
y, if the "Redirect to indirection-id" does not=0A=C2=A0=C2=A0 result in a=
valid redirection, then the flowspec rule MUST be=0A=C2=A0=C2=A0 processe=
d as if the "Redirect to indirection-id" community was not=0A=C2=A0=C2=A0 =
attached to the flowspec route.=0A"=0A=C2=A0=0AGV> Is there more to add to=
this? (We could add a line to detail that =E2=80=9Credirect-to-ip=E2=80=9D=
is incompatible with =E2=80=9Credirect to indirection-id=E2=80=9D and res=
ult in invalid redirection rule, however to me that is already implied wit=
h enough detail in the text above)=0A=C2=A0=0AA few IANA issues:=0AI see t=
he type registry is currently registered with IANA (code point 0x09).=C2=A0=
However, the sub-type registry is not established for some reason?=0AThe =
ID-Type field likely needs its own IANA registry.=C2=A0 Values 1-5 are def=
ined in this draft.=0A=C2=A0=0AGV> Correct. There is a reason for this. Wh=
en we asked IANA the code-points they informed me that once the document g=
et to RFC the sub-type registry will be established by IANA.=0A=C2=A0=0ATh=
e flags field (one octet) currently has 3 bits reserved.=C2=A0 In the past=
, we've not done a registry for such cases (c.f. graceful restart) until w=
e need to start carving out those reserved bits for future extensions.=C2=A0=
I leave it to the chairs' opinion whether we want this a priori or not.=0A=
=C2=A0=0AG/=0A=C2=A0=0A=C2=A0=0A>=C2=A0=0A> Thank you for considering this=
draft.=0A>=C2=A0=0A> Cheerily, Susan Hares=0A>=C2=A0=0A> ________________=
_______________________________=0A> Idr mailing list=0A> [email protected]=0A> =
https://www..ietf.org/mailman/listinfo/idr=0A=C2=A0=0A____________________=
___________________________=0AIdr mailing [email protected]=0Ahttps://ww=
w.ietf..org/mailman/listinfo/idr=0A=C2=A0=0A______________________________=
_________________=0AIdr mailing [email protected]=0Ahttps://www.ietf.org=
/mailman/listinfo/idr=0A=0A_______________________________________________=
=0AIdr mailing [email protected]=0Ahttps://www.ietf.org/mailman/listinfo=
/idr=0A
--Apple-Webmail-42--2cad2693-41d6-4665-8d59-4df09d4c2fe0
Content-Type: multipart/related; type="text/html";
boundary=Apple-Webmail-86--2cad2693-41d6-4665-8d59-4df09d4c2fe0
--Apple-Webmail-86--2cad2693-41d6-4665-8d59-4df09d4c2fe0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8;
<html><body><div>Hi Robert,</div><div><br data-mce-bogus=3D"1"></div><div>While unders=
tanding your point, it does feel like opening a potential can of worm=
s with respect to validation of all possible combinations humanly pos=
sible. Is the use-case for this capability solid enough that we need this =
complication? There seems nothing broken with keeping things simple. =
</div><div><br></div><div>G/</div><div><br data-mce-bogus=3D"1"></div><div=
class=3D"x-apple-signature">Sent from iCloud</div><div><br>On November 29=
, 2019 at 10:34 AM, Robert Raszuk <[email protected]> wrote:<br><br>=
</div><div><blockquote type=3D"cite"><div class=3D"msg-quote"><div dir=3D"=
ltr">Gunter,<div><br></div><div>To your and Jeff's point regarding multipl=
e redirect rules I have a bit different perspective. </div><div><br><=
/div><div>First let's observe that redirect could be realized in two forms=
(both are valid and used in practice): </div><div><br></div><div>-A-=
redirect of the original flow </div><div>-B- redirect of copy o=
f the flow </div><div><br></div><div>See while in -A- clearly one red=
irect must be used, in -B- on the other hand multiple redirects shoul=
d be supported. One span, one security TAP, one TCP analyzer etc ... =
</div><div><br></div><div>Your draft defines -A-. To add -B- all what is n=
eeded is just one bit flag. </div><div><br></div><div>Would you consi=
der it ? </div><div><br></div><div>Cheers,</div><div>R.</div><div><br=
></div><div><br></div><div><br></div><div><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 29, 2019 a=
t 4:51 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <<a href=3D"mailto:=
[email protected]" data-mce-href=3D"mailto:gunter.van_de_velde=
@nokia.com">[email protected]</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
1px solid #cccccc; padding-left: 1ex;" data-mce-style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;"><div><span =
face=3D"Calibri" size=3D"2" data-mce-style=3D"font-family: Calibri; font-s=
ize: small;" style=3D"font-family: Calibri; font-size: small;"><span style=
=3D"font-size: 11pt;" data-mce-style=3D"font-size: 11pt;"><div>Hi Jeff,</d=
iv><div> </div><div>Thanks for the feedback and suggestions.</div><di=
v> </div><div>See inline: <span color=3D"#4472C4" data-mce-style=3D"c=
olor: #4472c4;" style=3D"color: #4472c4;"><b>GV></b></span></div><a nam=
e=3D"m_-6399825029355686769__MailEndCompose" class=3D"mce-item-anchor"></a=
><div> </div><div>-----Original Message-----<br> From: Idr <<a hre=
f=3D"mailto:[email protected]" data-mce-href=3D"mailto:idr-bounces@ietf=
..org">[email protected]</a>> On Behalf Of Jeffrey Haas<br> Sent: Thu=
rsday, November 28, 2019 20:21<br> To: Sue Hares <<a href=3D"mailto:sha=
[email protected]" data-mce-href=3D"mailto:[email protected]">[email protected]</a>=
><br> Cc: <a href=3D"mailto:[email protected]" data-mce-href=3D"mailto:idr@i=
etf.org">[email protected]</a><br> Subject: Re: [Idr] WG LC draft-ietf-idr-flow=
spec-path-redirect-10.txt [11/17/2019 to 12/2/2019]</div><div> </div>=
<div>Sue,</div><div> </div><div> </div><div> </div><div>>=
; On Nov 18, 2019, at 12:41 AM, Susan Hares <<a href=3D"mailto:shares@n=
dzh.com" data-mce-href=3D"mailto:[email protected]">[email protected]</a>> =
wrote:</div><div>></div><div>> This begins a 2 week WG Last call on =
draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019].</d=
iv><div>> </div><div>> You can obtain the draft at:</div><div>&=
gt; </div><div>> <a href=3D"https://datatracker.ietf.org/doc/draft=
-ietf-idr-flowspec-path-redirect/" data-mce-href=3D"https://datatracker.ie=
tf.org/doc/draft-ietf-idr-flowspec-path-redirect/">https://datatracker.iet=
f.org/doc/draft-ietf-idr-flowspec-path-redirect/</a></div><div>> <=
/div><div>> Consider in your review whether this draft:</div><div>>&=
nbsp;</div><div>> 1) Is compatible with d=
raft-ietf-rfc5575bis-17.txt?</div><div> </div><div>Yes. (Close =
enough.) The current version of the draft is implementable.</div><di=
v> </div><div>> 2) Whether the draft=
is useful for deployments of flow specification</div><div> </div><di=
v>It can be useful.</div><div> </div><div>> 3) &n=
bsp; Is this technology ready for deployment?</div><div>> 4) =
; Is the write-up of this technology in draft-ietf=
-idr-flowspec-path-redirect clearly written and ready for publication?</di=
v><div> </div><div>Ready with minor issues, IMO:</div><div> </di=
v><div>Procedure-wise, there needs to be a bit more text covering cases ab=
out interactions with other traffic actions. This was a known headac=
he for similar drafts such as redirect-to-ip. In particular, interac=
tion with redirect-to-ip and redirect-to-vrf is needed.</div><div> </=
div><div>GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D gives i=
nput on this. We discussed this with you long ago and hence this text was =
added.</div><div> </div><div>=E2=80=9C</div><div> While i=
t MUST NOT happen, and is seen as invalid combination, it is</div><div>&nb=
sp; possible from a semantics perspective to have multiple clashing<=
/div><div> redirect actions defined within a single flowspec r=
ule. For best and</div><div> consistant compatibility wi=
th legacy implementations, the redirect</div><div> functionali=
ty as documented by rfc5575bis MUST NOT be broken, and</div><div> &nb=
sp; hence when a clash occurs, then rfc5575bis based redirect MUST take</d=
iv><div> priority.</div><div>=E2=80=9C</div><div> </div><=
div>This means that redirect-to-VRF will take absolute priority to not bre=
ak rfc5575bis behavior.</div><div>Having also redirect-to-ip will result i=
n an invalid</div><div> </div><div> </div><div>The text "A singl=
e flowspec rule MUST NOT have more as one indirection-id per S-ID. O=
n a flowspec client the indirection-id with lowest S-ID MUST be imposed fi=
rst for any given flowspec entry." There's no procedure for what hap=
pens in error handling when you do have more than one of the same S-ID.&nb=
sp; The text about the case for S-ID of 0 is also a bit ambiguous. I=
t feels like it's reading "there is no sequence", but what do you do when =
you then have ones that do?</div><div> </div><div><span color=3D"#447=
2C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"><b>GV>=
;</b> What about the following rewrite:</span></div><div><span color=3D"#4=
472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> =
</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4=
;" style=3D"color: #4472c4;">Original:</span></div><div><span color=3D"#44=
72C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> =
The 'S-ID' field identifies a 4 bit Sequence ID field. This f=
ield is</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: =
#4472c4;" style=3D"color: #4472c4;"> used to provide a flowspe=
c client an indication how and where to</span></div><div><span color=3D"#4=
472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> =
sequence the received indirection-ids. The Sequence ID value =
0</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c=
4;" style=3D"color: #4472c4;"> indicates that Sequence ID fiel=
d is NOT set and SHOULD be ignored. A</span></div><div><span color=3D=
"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;">&nb=
sp; single flowspec rule MUST NOT have more as one indirection-id pe=
r</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c=
4;" style=3D"color: #4472c4;"> S-ID. On a flowspec clien=
t the indirection-id with lowest S-ID MUST</span></div><div><span color=3D=
"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;">&nb=
sp; be imposed first for any given flowspec entry.</span></div><div>=
<span color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color:=
#4472c4;"> </span></div><div><span color=3D"#4472C4" data-mce-style=3D=
"color: #4472c4;" style=3D"color: #4472c4;">New:</span></div><div><span co=
lor=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4=
;"> The 'S-ID' field identifies a 4 bit Sequence ID field.&nbs=
p; This field is</span></div><div><span color=3D"#4472C4" data-mce-style=3D=
"color: #4472c4;" style=3D"color: #4472c4;"> used to provide a=
flowspec client an indication how and where to</span></div><div><span col=
or=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;=
"> sequence the received indirection-ids. The Sequence I=
D value 0</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color=
: #4472c4;" style=3D"color: #4472c4;"> indicates that Sequence=
ID field is NOT set and <b>**</b><b>all</b><b> other sequence ID's**</b> =
</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4=
;" style=3D"color: #4472c4;"> SHOULD be ignored. A</span=
></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" sty=
le=3D"color: #4472c4;"> single flowspec rule MUST NOT have mor=
e as one indirection-id per</span></div><div><span color=3D"#4472C4" data-=
mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> S-ID.=
On a flowspec client the indirection-id with lowest S-ID MUST</span=
></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" sty=
le=3D"color: #4472c4;"> be imposed first for any given flowspe=
c entry.</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color:=
#4472c4;" style=3D"color: #4472c4;"> </span></div><div><span color=3D=
"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"><b>=
GV></b> In section *6. Validation procedure" there is text to handle th=
e error condition when the flowspec rule results in an invalid redirection=
, that prescribe what needs to happen when the =E2=80=9Credirect to indire=
ction-id=E2=80=9D does not result in a valid redirection:</span></div><div=
><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color=
: #4472c4;"> </span></div><div><span color=3D"#4472C4" data-mce-style=
=3D"color: #4472c4;" style=3D"color: #4472c4;">"</span></div><div><span co=
lor=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4=
;"> While it MUST NOT happen, and is seen as invalid combinati=
on, it is</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color=
: #4472c4;" style=3D"color: #4472c4;"> possible from a semanti=
cs perspective to have multiple clashing</span></div><div><span color=3D"#=
4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> =
; redirect actions defined within a single flowspec rule. For =
best and</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color:=
#4472c4;" style=3D"color: #4472c4;"> consistant compatibility=
with legacy implementations, the redirect</span></div><div><span color=3D=
"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"><b>=
functionality as documented by rfc5575bis MUST NOT be broken<=
/b>, and</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color:=
#4472c4;" style=3D"color: #4472c4;"> hence when a clash occur=
s, then <b>rfc5575bis based redirect MUST take</b></span></div><div><span =
color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472=
c4;"><b> priority</b>. Additionally, if the "Redirect to=
indirection-id" does not</span></div><div><span color=3D"#4472C4" data-mc=
e-style=3D"color: #4472c4;" style=3D"color: #4472c4;"> result =
in a valid redirection, then the flowspec rule MUST be</span></div><div><s=
pan color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #=
4472c4;"> processed as if the "Redirect to indirection-id" com=
munity was not</span></div><div><span color=3D"#4472C4" data-mce-style=3D"=
color: #4472c4;" style=3D"color: #4472c4;"> attached to the fl=
owspec route.</span></div><div><span color=3D"#4472C4" data-mce-style=3D"c=
olor: #4472c4;" style=3D"color: #4472c4;">"</span></div><div><span color=3D=
"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;">&nb=
sp;</span></div><div><span color=3D"#4472C4" data-mce-style=3D"color: #447=
2c4;" style=3D"color: #4472c4;"><b>GV></b> Is there more to add to this=
? (We could add a line to detail that =E2=80=9Credirect-to-ip=E2=80=9D is =
incompatible with =E2=80=9Credirect to indirection-id=E2=80=9D and result =
in invalid redirection rule, however to me that is already implied with en=
ough detail in the text above)</span></div><div> </div><div>A few IAN=
A issues:</div><div>I see the type registry is currently registered with I=
ANA (code point 0x09). However, the sub-type registry is not establi=
shed for some reason?</div><div>The ID-Type field likely needs its own IAN=
A registry. Values 1-5 are defined in this draft.</div><div> </=
div><div><span color=3D"#4472C4" data-mce-style=3D"color: #4472c4;" style=3D=
"color: #4472c4;"><b>GV></b> Correct. There is a reason for this. When =
we asked IANA the code-points they informed me that once the document get =
to RFC the sub-type registry will be established by IANA. </span></div><di=
v> </div><div>The flags field (one octet) currently has 3 bits reserv=
ed. In the past, we've not done a registry for such cases (c.f. grac=
eful restart) until we need to start carving out those reserved bits for f=
uture extensions. I leave it to the chairs' opinion whether we want =
this a priori or not.</div><div> </div><div><span color=3D"#4472C4" d=
ata-mce-style=3D"color: #4472c4;" style=3D"color: #4472c4;"><b>G/</b></spa=
n></div><div> </div><div> </div><div>> </div><div>> T=
hank you for considering this draft.</div><div>> </div><div>> C=
heerily, Susan Hares</div><div>> </div><div>> _________________=
______________________________</div><div>> Idr mailing list</div><div>&=
gt; <a href=3D"mailto:[email protected]" data-mce-href=3D"mailto:[email protected]">=
[email protected]</a></div><div>> <a href=3D"https://www.ietf.org/mailman/li=
stinfo/idr" data-mce-href=3D"https://www.ietf.org/mailman/listinfo/idr">ht=
tps://www..ietf.org/mailman/listinfo/idr</a></div><div> </div><div>__=
_____________________________________________</div><div>Idr mailing list</=
div><div><a href=3D"mailto:[email protected]" data-mce-href=3D"mailto:Idr@ietf.=
org">[email protected]</a></div><div><a href=3D"https://www.ietf.org/mailman/li=
stinfo/idr" data-mce-href=3D"https://www.ietf.org/mailman/listinfo/idr">ht=
tps://www.ietf..org/mailman/listinfo/idr</a></div><div> </div></span>=
</span></div>_______________________________________________<br> Idr maili=
ng list<br> <a href=3D"mailto:[email protected]" data-mce-href=3D"mailto:Idr@ie=
tf.org">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listi=
nfo/idr" data-mce-href=3D"https://www.ietf.org/mailman/listinfo/idr">https=
://www.ietf.org/mailman/listinfo/idr</a><br></blockquote></div><div class=3D=
"_stretch"><span class=3D"body-text-content">_____________________________=
__________________<br>Idr mailing list<br><a href=3D"mailto:[email protected]" =
data-mce-href=3D"mailto:[email protected]">[email protected]</a><br><a href=3D"https=
://www.ietf.org/mailman/listinfo/idr" data-mce-href=3D"https://www.ietf.or=
g/mailman/listinfo/idr">https://www.ietf.org/mailman/listinfo/idr</a><br><=
/span></div></div></blockquote></div></body></html>
--Apple-Webmail-86--2cad2693-41d6-4665-8d59-4df09d4c2fe0--
--Apple-Webmail-42--2cad2693-41d6-4665-8d59-4df09d4c2fe0--
--===============2545798552715757055==
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
--===============2545798552715757055==--