Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

--===============0375453127939479996==
Content-Type: multipart/alternative; boundary="001a1137ab20e3175b0565a7c67d"

--001a1137ab20e3175b0565a7c67d
Content-Type: text/plain; charset="UTF-8"

Thanks for the feedback.

There is one additional aspect here that I think needs further
clarification and discussion.

In the current proposed charter, the first work-item says "Operation of
BIER in
non-congruent topologies, i.e. topologies where not all routers are BIER
capable
can also be addressed."

The newly posted individual draft-zzhang-bier-algorithm-00 suggests having
an algorithm
which is doing an SPF after removing from the topology any non-BIER capable
routers.  This is an example of a BIER-specific constraint.

The individual flex-algo drafts also support adding constraints (similar to
the familiar
constraints from RSVP-TE).

I believe that the need for BIER-specific constraints is one factor driving
the requirement
for a BAR that is specified by the BIER WG.

>From an architectural view, the idea of having the IGP/routing layer have
to understand
BIER specifics seems an undesirable coupling.

Could someone walk me through how this would be supported in each of the
different options?

For Option D, where there is a sub-TLV and that sub-TLV can supply the
additional non-BIER
constraints, I understand it.

For Option B - which some folks are preferring, I do not see understand how
it would work.
For Option A, I do not understand how it would work.

Obviously, this is going far out on a design limb - where flex-algo does
not yet have any IETF
support or adoption, but since it is clear that people's perspectives are
being strongly influenced
by what that might morph into, I think this is important for the whole WG
to understand.

Regards,
Alia




On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda <[email protected]>
wrote:

> all the implementations I am aware off can adjust to Option A) with BAR
> registry without problems, neither do I see a problem with option B) given
> we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony
>
> On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <[email protected]> wrote:
>
>> I have one additional question for those with implementations or testing
>> them.
>>
>> What is the impact of going with your preferred option in terms of
>> interoperability?  It may be early enough that changes can happen, but more
>> feedback is needed.
>>
>> For those favoring Option B, could you send email to the list providing
>> exact text so we have the details?
>>
>> For those favoring the current status without an IANA registry, are you
>> able to handle one being imposed during IESG Review?  It is an obvious
>> concern to raise.  Are you just prolonging or postponing the discussion?
>>
>> Regards,
>> Aka
>>
>>
>>
>> On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <[email protected]>
>> wrote:
>>
>>> +1 to Option-B
>>>
>>> Seems future proof to me.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Senthil
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* BIER [mailto:[email protected]] *On Behalf Of *Alia Atlas
>>> *Sent:* 20 February 2018 03:21
>>> *To:* BIER WG <[email protected]>; [email protected] list <[email protected]>
>>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions
>>> and draft-ietf-bier-ospf-extensions
>>>
>>>
>>>
>>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>>> draft-ietf-bier-ospf-extensions-12, I have been following the
>>> discussion on the mailing list with interest.
>>>
>>>
>>>
>>> I have not seen clear consensus for any change.
>>>
>>>
>>>
>>> Let me be clear on what I see the options are from the discussion.  Then
>>> I'll elaborate
>>>
>>> a bit on how you can express your perspective most usefully.
>>>
>>>
>>>
>>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
>>> only value 0 is specified.  The drafts do not have an IANA registry - with
>>> the expectation that one will be created when the first additional use is
>>> clear.  It is possible that there will be objections from the IESG to
>>> progressing without an IANA registry.  Given the lack of clarity for future
>>> use-cases and after discussion, I decided not to force one after my AD
>>> review - but I will not push back against having a BIER IANA registry if
>>> raised by others.
>>>
>>>
>>>
>>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>>> current TLVs.
>>>
>>>    Define an IANA registry for the BAR type.  The meaning of the BAR
>>> sub-type derives
>>>
>>>    from the BAR type.   We can debate over the registration policy for
>>> the BAR type.
>>>
>>>
>>>
>>> 3) Option C: Change the BAR field to be 16 bits and define an IANA
>>> registry.  Part of the range can be FCFS with Expert Review, part can be
>>> Specification Required, and part can be IETF Consensus.
>>>
>>>
>>>
>>> 4) Option D: At some point in the future, if there is an actual
>>> understood and documented need, a BAR sub-type could be added a sub-TLV.
>>> The length of the BAR sub-type could be determined when the sub-TLV is
>>> defined.
>>>
>>>
>>>
>>> Given
>>>
>>>
>>>
>>>   a) option D exists
>>>
>>>   b) there is currently only one defined value for BAR
>>>
>>>   c) I do not see strong consensus for change to one particular other
>>> option
>>>
>>>
>>>
>>> I see no current reason for a change and I certainly see absolutely no
>>> reason for
>>>
>>> a delay in progressing the documents.
>>>
>>>
>>>
>>> I do want to be clear about what the WG wants to do on this issue.
>>> Therefore, here is
>>>
>>> my following request.
>>>
>>>
>>>
>>> Please send your feedback to the mailing list as follows:
>>>
>>>
>>>
>>> IF you prefer or can accept the current status, please say so.  No more
>>> justification
>>>
>>> or reasoning is required. I just don't want the bulk of folks who are
>>> content to be
>>>
>>> overlooked by those suggesting change.
>>>
>>>
>>>
>>> IF you prefer or can accept the current status, but think there should
>>> be an IANA registry
>>>
>>> as is usual for managing code-points, please say so.  No more
>>> justification is needed.
>>>
>>>
>>>
>>> IF you prefer Option B, C, and/or D, please say so with your
>>> explanation.  More technical depth than "'we might need it" would be
>>> helpful; the availability of sub-TLVs already
>>>
>>> provides future proofing.
>>>
>>>
>>>
>>> IF you have a clear technical objection to why the Current Status is not
>>> acceptable,
>>>
>>> please express that - with clear details.
>>>
>>>
>>>
>>> IF you feel that additional code-points should be allocated in a BAR
>>> IANA Registry or
>>>
>>> have thoughts on the appropriate policy, please say so with your
>>> explanation for what
>>>
>>> those should be.
>>>
>>>
>>>
>>> Unless I see clear and strong consensus for something other than the
>>> Current Status,
>>>
>>> that will remain.
>>>
>>>
>>>
>>> IF there is clear and strong consensus for Option B, C, or D, or adding
>>> an IANA registry with particular values, then it will be possible to have a
>>> change up through this Weds night - with a 1 week WGLC on that particular
>>> technical change.
>>>
>>>
>>>
>>> My priority is to have the base BIER specifications published as
>>> Proposed Standards so that more BIER implementations and deployment can be
>>> done.  I would like the WG to wrap up the core work (as expressed in the
>>> proposed recharter) so that you all can look
>>>
>>> at how to use it.
>>>
>>>
>>>
>>> Given this topic was raised last Weds and given that there are no
>>> technical objections raised to the documents as are, there isn't much time
>>> - so please just respond to this email ASAP.  My deadline for a decision is
>>> 6pm EST on Weds.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alia
>>>
>>>
>>>
>>
>> _______________________________________________
>> BIER mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>>
>

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

<div dir=3D"ltr">Thanks for the feedback.<div><br></div><div>There is one a=
dditional aspect here that I think needs further clarification and discussi=
on.</div><div><br></div><div>In the current proposed charter, the first wor=
k-item says &quot;Operation of BIER in=C2=A0</div><div>non-congruent topolo=
gies, i.e. topologies where not all routers are BIER capable=C2=A0</div><di=
v>can also be addressed.&quot;</div><div><br></div><div>The newly posted in=
dividual draft-zzhang-bier-algorithm-00 suggests having an algorithm</div><=
div>which is doing an SPF after removing from the topology any non-BIER cap=
able</div><div>routers.=C2=A0 This is an example of a BIER-specific constra=
int.</div><div><br></div><div>The individual flex-algo drafts also support =
adding constraints (similar to the familiar</div><div>constraints from RSVP=
-TE).</div><div><br></div><div>I believe that the need for BIER-specific co=
nstraints is one factor driving the requirement</div><div>for a BAR that is=
 specified by the BIER WG.</div><div><br></div><div>From an architectural v=
iew, the idea of having the IGP/routing layer have to understand</div><div>=
BIER specifics seems an undesirable coupling.=C2=A0</div><div><br></div><di=
v>Could someone walk me through how this would be supported in each of the =
different options?</div><div><br></div><div>For Option D, where there is a =
sub-TLV and that sub-TLV can supply the additional non-BIER</div><div>const=
raints, I understand it.=C2=A0</div><div><br></div><div>For Option B - whic=
h some folks are preferring, I do not see understand how it would work.</di=
v><div>For Option A, I do not understand how it would work.</div><div><br><=
/div><div>Obviously, this is going far out on a design limb - where flex-al=
go does not yet have any IETF</div><div>support or adoption, but since it i=
s clear that people&#39;s perspectives are being strongly influenced</div><=
div>by what that might morph into, I think this is important for the whole =
WG to understand.</div><div><br></div><div>Regards,</div><div>Alia</div><di=
v><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Tue, Feb 20, 2018 at 10:37 AM, Tony Przyg=
ienda <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">all the implementations I am aware off can a=
djust to Option A) with BAR registry without problems, neither do I see a p=
roblem with option B) given we are talking only 0/0 being in IGP RFC @ this=
 point in time. thanks. tony <br></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Feb 19, 2018 at 9:15 P=
M, Alia Atlas <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" ta=
rget=3D"_blank">[email protected]</a>&gt;</span> wrote:<br></div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"auto">I have =
one additional question for those with implementations or testing them.<div=
 dir=3D"auto"><br></div><div dir=3D"auto">What is the impact of going with =
your preferred option in terms of interoperability?=C2=A0 It may be early e=
nough that changes can happen, but more feedback is needed.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">For those favoring Option B, could yo=
u send email to the list providing exact text so we have the details?</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">For those favoring the curren=
t status without an IANA registry, are you able to handle one being imposed=
 during IESG Review?=C2=A0 It is an obvious concern to raise.=C2=A0 Are you=
 just prolonging or postponing the discussion?</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Regards,</div><div dir=3D"auto">Aka</div><div dir=3D=
"auto"><br></div><div dir=3D"auto"><br></div></div><div class=3D"m_-4489846=
75572822190HOEnZb"><div class=3D"m_-448984675572822190h5"><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Feb 19, 2018 11:53 PM, &quot;Se=
nthil Dhanaraj&quot; &lt;<a href=3D"mailto:[email protected]" tar=
get=3D"_blank">[email protected]</a>&gt; wrote:<br type=3D"attrib=
ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">





<div link=3D"#0563C1" vlink=3D"#954F72" lang=3D"EN-US">
<div class=3D"m_-448984675572822190m_166906979626783871m_-56495395347937057=
73WordSection1">
<p class=3D"MsoNormal">+1 to Option-B<u></u><u></u></p>
<p class=3D"MsoNormal">Seems future proof to me.<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">Thanks,<u></u><u></u></p>
<p class=3D"MsoNormal">Senthil<span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> BIER [mailto:<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>]
<b>On Behalf Of </b>Alia Atlas<br>
<b>Sent:</b> 20 February 2018 03:21<br>
<b>To:</b> BIER WG &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">b=
[email protected]</a>&gt;; <a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a> list &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;<br>
<b>Subject:</b> [Bier] BAR field length in draft-ietf-bier-isis-extension<w=
br>s and draft-ietf-bier-ospf-extension<wbr>s<u></u><u></u></span></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal">As the Sponsoring AD for draft-ietf-bier-isis-extens=
ion<wbr>s-07 and draft-ietf-bier-ospf-extension<wbr>s-12, I have been follo=
wing the discussion on the mailing list with interest.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">I have not seen clear consensus for any change.<u></=
u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Let me be clear on what I see the options are from t=
he discussion.=C2=A0 Then I&#39;ll elaborate<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">a bit on how you can express your perspective most u=
sefully.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">1) Current Status:=C2=A0 Bier Algorithm (BAR) field =
is 8 bits.=C2=A0 Currently, only value 0 is specified.=C2=A0 The drafts do =
not have an IANA registry - with the expectation that one will be created w=
hen the first additional use is clear.=C2=A0 It is possible
 that there will be objections from the IESG to progressing without an IANA=
 registry.=C2=A0 Given the lack of clarity for future use-cases and after d=
iscussion, I decided not to force one after my AD review - but I will not p=
ush back against having a BIER IANA registry
 if raised by others.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">2) Option B:=C2=A0 Add a BAR sub-type of 8 bits.=C2=
=A0 This would modify the current TLVs.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 =C2=A0Define an IANA registry for the BAR typ=
e.=C2=A0 The meaning of the BAR sub-type derives=C2=A0<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 =C2=A0from the BAR type.=C2=A0 =C2=A0We can d=
ebate over the registration policy for the BAR type.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">3) Option C: Change the BAR field to be 16 bits and =
define an IANA registry.=C2=A0 Part of the range can be FCFS with Expert Re=
view, part can be Specification Required, and part can be IETF Consensus.<u=
></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">4) Option D: At some point in the future, if there i=
s an actual understood and documented need, a BAR sub-type could be added a=
 sub-TLV.=C2=A0 The length of the BAR sub-type could be determined when the=
 sub-TLV is defined.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Given<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 a) option D exists=C2=A0<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 b) there is currently only one defined value =
for BAR<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0 c) I do not see strong consensus for change t=
o one particular other option<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">I see no current reason for a change and I certainly=
 see absolutely no reason for<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">a delay in progressing the documents.<u></u><u></u><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">I do want to be clear about what the WG wants to do =
on this issue.=C2=A0 Therefore, here is<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">my following request.<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 send your feedback to the mailing list as fol=
lows:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF you prefer or can accept the current status, plea=
se say so.=C2=A0 No more justification<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">or reasoning is required. I just don&#39;t want the =
bulk of folks who are content to be<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">overlooked by those suggesting change.<u></u><u></u>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF you prefer or can accept the current status, but =
think there should be an IANA registry<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">as is usual for managing code-points, please say so.=
=C2=A0 No more justification is needed.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF you prefer Option B, C, and/or D, please say so w=
ith your explanation.=C2=A0 More technical depth than &quot;&#39;we might n=
eed it&quot; would be helpful; the availability of sub-TLVs already<u></u><=
u></u></p>
</div>
<div>
<p class=3D"MsoNormal">provides future proofing.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF you have a clear technical objection to why the C=
urrent Status is not acceptable,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">please express that - with clear details.<u></u><u><=
/u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF you feel that additional code-points should be al=
located in a BAR IANA Registry or<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">have thoughts on the appropriate policy, please say =
so with your explanation for what<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">those should be.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Unless I see clear and strong consensus for somethin=
g other than the Current Status,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">that will remain.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">IF there is clear and strong consensus for Option B,=
 C, or D, or adding an IANA registry with particular values, then it will b=
e possible to have a change up through this Weds night - with a 1 week WGLC=
 on that particular technical change.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">My priority is to have the base BIER specifications =
published as Proposed Standards so that more BIER implementations and deplo=
yment can be done.=C2=A0 I would like the WG to wrap up the core work (as e=
xpressed in the proposed recharter) so
 that you all can look<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">at how to use it.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Given this topic was raised last Weds and given that=
 there are no technical objections raised to the documents as are, there is=
n&#39;t much time - so please just respond to this email ASAP.=C2=A0 My dea=
dline for a decision is 6pm EST on Weds.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Alia<u></u><u></u></p>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>

</blockquote></div></div>
</div></div><br></div></div><span class=3D"">______________________________=
<wbr>_________________<br>
BIER mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/bier" rel=3D"noreferrer" t=
arget=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/bier</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>

--001a1137ab20e3175b0565a7c67d--


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

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg

--===============0375453127939479996==--