[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05
From: Antoni Przygienda <prz () juniper ! net>
Date: 2017-09-27 3:10:25
Message-ID: 0E80CAB4-D769-4912-B432-99E48CC92143 () juniper ! net
[Download RAW message or body]
[Attachment #2 (text/plain)]
2) Sec 5.1: This section has concern about restricting the advertisement of BIER \
information in IS-IS for scalability - but it doesn't discuss at all when a router \
would stop advertising the BIER sub-TLVs. It feels like the section is hunting for a \
bit of a manageability or operational considerations section. I'm not comfortable \
with the interoperability issues posed by not indicating what triggers should cause \
advertisements or withdrawals. Receiving an advertisement from a BFER seems like a \
reasonable trigger to me, since it indicates an active receiver for the <MT, SD>.
Have to disagree to large extent:
a) Section is basically saying "it's outside the scope of this doc but here's a \
couple of hints". We should probably say "those are all _optional_ extensions". We \
may be better off moving it into "operational considerations" section, that's true.
b) Suggested trigger is possible one but smarter ones are possible, e.g. a node \
may know it's not on any BIER computed tree (SPF or other) and save memory by not \
advertising. All that are implementation techniques and the draft is kind of \
overspecifying here a bit.
c) I don't see how any _valid_ trigger will cause interoperability problems with \
other possible triggers.
In summary, let's say "it's all optional" and generate an "operational \
considerations" section with this text?
3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in \
draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, labels only \
have to be assigned if they are going to be used. If a particular BIER domain \
supports BSLs 256 and 512, but some SD, say SD 1, only uses BSL 256, then it is not
necessary to assign labels that correspond to the combination of SD 1
and BSL 512."
Actually, I don't think so. The encaps draft talks about BIER _domain_ doing 256+512 \
while _sub_domain_1 does only 256. The ISIS draft talks about the _sub_domain, i.e. \
in a subdomain everyone must advertise enough labels for BSLs they support while in \
a _domain_ each _subdomain_ may do different things. Observe that we have the future \
capability of converting BSLs in a subdomain and it may come handy later (we can send \
smaller BMLs if we see lots zeroes or bunch things up together if we see really small \
BSLs flying or support BSL migration in a subdomain). For now we don't have \
conversion and with that we may blackhole if people disagree on the BSLs they support \
in a subdomain.
4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of the BIER \
advertisments." This doesn't leave scope for expanding to inter-area in the future \
because the issue is not the flooding scope but rather the distribution.
? within the scope the BFR-ids must be unique per BFER says it all. I think that's \
consistent with any scope, inter-, intra- or planetary reach … ;-)
5) Sec 6.1: " The sub-TLV advertises a single <MT,SD> combination followed by
optional sub-sub-TLVs as described in the following sections."
The figure and field descriptions do not include the MT-ID. There is clearly the \
reserved octet intended for that??
Nope. ISIS MT is built very, very cleanly in this respect, i.e. the TLVs are all \
already annotated and provide the MT scope. Hence it doesn't show up anywhere here. \
Did I say ISIS is very, very clean when it comes to MT ;-)
6) Sec 6.2: This section needs to clearly define the relationship between the labels \
and the Set Index in the specified <MT, SD>. It's also unclear whether it is better \
to advertise all the labels ever needed or be able to advertise only labels for a \
particular sequential number of SIs. The restriction that only one sub-sub-TLV with \
the same BitStringLength makes that impossible (but so does the lack of explicit \
starting SI).
That goes far back. We agreed to use a set-0-based range covering all BFR-ids. IGP \
TLVs are scarce resource and it makes for a much simpler processing on computation. \
Labels are not _that_ scarce given how many routers we cover by each label. I don't \
think we'll move that.
7) Sec 6.3: The values for the Length & Tree Type field need to be clearer after the \
figure. Also, is Tree Type an IANA-managed field?? I don't see it in the IANA \
considerations. Ca it be different between IS-IS and OSPF?
Good catch, needs adding in IANA section.
Another one:
6.4 is possibly underspecified. It should explicitly state that \cap_C implies that \
the router can convert only between _all_ the BSLs that it advertises (and not any \
arbitrary downstream BSL from it).
[Attachment #3 (text/html)]
<html xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1900365608;
mso-list-type:hybrid;
mso-list-template-ids:1646326744 -195131996 67698713 67698715 67698703 67698713 \
67698715 67698703 67698713 67698715;} @list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.75in;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.25in;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.75in;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">2) Sec 5.1: This section has concern \
about restricting the advertisement of BIER information in IS-IS for scalability - \
but it doesn't discuss at all when a router would stop advertising the BIER \
sub-TLVs. It feels like the section is hunting for a bit of a manageability or \
operational considerations section. I'm not comfortable with the \
interoperability issues posed by not indicating what triggers should cause \
advertisements or withdrawals. Receiving an advertisement from a BFER \
seems like a reasonable trigger to me, since it indicates an active receiver for the \
<MT, SD>.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">Have to disagree to large \
extent:<o:p></o:p></span></p> <p class="MsoListParagraph" \
style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1"> <![if \
!supportLists]><span style="color:red"><span style="mso-list:Ignore">a)<span \
style="font:7.0pt "Times New Roman""> \
</span></span></span><![endif]><span style="color:red">Section is basically saying \
"it's outside the scope of this doc but here's a couple of hints". We should probably \
say "those are all _<i>optional</i>_ extensions". We may be better off moving it into \
"operational considerations" section, that's true. <o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 \
level1 lfo1"> <![if !supportLists]><span style="color:red"><span \
style="mso-list:Ignore">b)<span style="font:7.0pt "Times New \
Roman""> </span></span></span><![endif]><span \
style="color:red">Suggested trigger is possible one but smarter ones are possible, \
e.g. a node may know it's not on any BIER computed tree (SPF or other) and save \
memory by not advertising. All that are implementation techniques and the draft is \
kind of overspecifying here a bit. <o:p></o:p></span></p> <p class="MsoListParagraph" \
style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1"> <![if \
!supportLists]><span style="color:red"><span style="mso-list:Ignore">c)<span \
style="font:7.0pt "Times New Roman""> \
</span></span></span><![endif]><span style="color:red">I don't see how any \
_<i>valid</i>_ trigger will cause interoperability problems with other possible \
triggers. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">In summary, let's say "it's all \
optional" and generate an "operational considerations" section with this text? \
<o:p></o:p></span></p> <p class="MsoNormal" \
style="margin-left:.5in"><o:p> </o:p></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in">3) Sec 5.5 contradicts the last \
paragraph in Sec 2.1.1.1 in draft-ietf-bier-mpls-encapsulation-08 which says" \
Note that in practice, labels only have to be assigned if they are<br> \
going to be used. If a particular BIER domain supports BSLs 256 and<br> \
512, but some SD, say SD 1, only uses BSL 256, then it is not<br> \
necessary to assign labels that correspond to the combination of SD 1<br> \
and BSL 512."<o:p></o:p></p> <p class="MsoNormal" \
style="margin-left:.5in"><o:p> </o:p></p> <p class="MsoNormal" \
style="margin-left:.5in"><o:p> </o:p></p> </div>
<div>
<p class="MsoNormal"><span style="color:red">Actually, I don't think so. The encaps \
draft talks about BIER _<i>domain</i>_ doing 256+512 while _<i>sub</i>_domain_1 \
does only 256. The ISIS draft talks about the _<i>sub</i>_domain, i.e. in a subdomain \
everyone must advertise enough labels for BSLs they support while in a \
_<i>domain</i>_ each _<i>subdomain</i>_ may do different things. Observe that we have \
the future capability of converting BSLs in a subdomain and it may come handy later \
(we can send smaller BMLs if we see lots zeroes or bunch things up together if we \
see really small BSLs flying or support BSL migration in a subdomain). For now we \
don't have conversion and with that we may blackhole if people disagree on the BSLs \
they support in a subdomain. <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">4) Sec 5.6: "A valid BFR-id \
MUST be unique within the flooding scope of the BIER advertisments." This \
doesn't leave scope for expanding to inter-area in the future because the issue is \
not the flooding scope but rather the distribution.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">? within the scope the BFR-ids must be \
unique per BFER says it all. I think that's consistent with any scope, inter-, intra- \
or planetary reach … ;-)<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">5) Sec 6.1: " The sub-TLV \
advertises a single <MT,SD> combination followed by<br> optional \
sub-sub-TLVs as described in the following sections."<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The figure and field descriptions do \
not include the MT-ID. There is clearly the reserved octet intended for \
that?? <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">Nope. ISIS MT is built very, very \
cleanly in this respect, i.e. the TLVs are all already annotated and provide the MT \
scope. Hence it doesn't show up anywhere here. Did I say ISIS is very, very clean \
when it comes to MT ;-)<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">6) Sec 6.2: This section needs to \
clearly define the relationship between the labels and the Set Index in the specified \
<MT, SD>. It's also unclear whether it is better to advertise all the \
labels ever needed or be able to advertise only labels for a particular sequential \
number of SIs. The restriction that only one sub-sub-TLV with the same \
BitStringLength makes that impossible (but so does the lack of explicit starting \
SI).<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">That goes far back. We agreed to use a \
set-0-based range covering all BFR-ids. IGP TLVs are scarce resource and it makes for \
a much simpler processing on computation. Labels are not _<i>that</i>_ scarce given \
how many routers we cover by each label. I don't think we'll move that. \
<o:p></o:p></span></p> <p class="MsoNormal" \
style="margin-left:.5in"><o:p> </o:p></p> </div>
<div>
<p class="MsoNormal" style="margin-left:.5in">7) Sec 6.3: The values for the Length \
& Tree Type field need to be clearer after the figure. Also, is Tree Type \
an IANA-managed field?? I don't see it in the IANA considerations. Ca it \
be different between IS-IS and OSPF?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:red">Good catch, needs adding in IANA \
section. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">Another one: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">6.4 is possibly underspecified. It \
should explicitly state that \cap_C implies that the router can convert only between \
_<i>all</i>_ the BSLs that it advertises (and not any arbitrary downstream BSL from \
it). <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
--===============0743392588254472536==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic