[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [OSPF] [Bier] early AD review of draft-ietf-bier-ospf-bier-extensions-07
From: Tony Przygienda <tonysietf () gmail ! com>
Date: 2017-09-28 0:13:03
Message-ID: CA+wi2hMMhW7EEiGreUTJ2miqqoeMmiGrU+8+_qachihuexy+ag () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
inlined into inlines ;-)
On Tue, Sep 26, 2017 at 7:45 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
andrew.dolganow@nokia.com> wrote:
> Alia,
>
>
>
> Thanks, so quick comments:
>
>
>
> *From: *Alia Atlas <akatlas@gmail.com>
> *Date: *Wednesday, September 27, 2017 at 6:12 AM
> *To: *"bier@ietf.org" <bier@ietf.org>, OSPF List <ospf@ietf.org>, "
> draft-ietf-bier-ospf-bier-extensions@ietf.org" <draft-ietf-bier-ospf-bier-
> extensions@ietf.org>
> *Subject: *early AD review of draft-ietf-bier-ospf-bier-extensions-07
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Peter Psenak <ppsenak@cisco.com>, <naikumar@cisco.com>,
> "(Ice) IJsbrand Wijnands" <ice@cisco.com>, Andrew Dolganow <
> andrew.dolganow@nokia.com>, <prz@juniper.net>, Jeffrey Zhang <
> zzhang@juniper.net>, <aldrin.ietf@gmail.com>
> *Resent-Date: *Wednesday, September 27, 2017 at 6:12 AM
>
>
>
> I have done an early AD review of draft-ietf-bier-ospf-bier-extensions-07
> in preparation for the publication request.
>
>
>
> First, I would like to thank the many authors for their work on this
> draft. Given that there are currently 7 authors listed, I'd recommend
> appointing a few editors or otherwise reducing down to 5 or fewer. Of
> course, I am also willing to consider extraordinary circumstances where the
> shepherd can explain to me privately the deep technical contribution made
> by each author.
>
>
>
> I do see a number of major issues.
>
>
>
> Major Issues:
>
>
>
> 1) RFC7684 is just for OSPFv2. How is the information carried for
> OSPFv3? We need a mechanism that works for IPv6 also.
>
> ad> agree – the way the draft is written is v2 only. need to address that.
>
>
>
+1
> 2) In Sec 2.1, the Length is defined as variable and the figure includes
> additional sub-TLVs. Please clarify in the text what other sub-TLVs can be
> carried & how the length is calculated (yes, same as always - but clarity
> helps with interoperability).
>
>
>
> ad> Repeating may not be clarifying. How about we say "Variable, dependent
> on sub-TLVs" to use RFC7684-like text for the Extended prefix TLV. I could
> not find a single example where we list what sub-TLVs are carried either.
> That is done – as in this draft – in sub-TLV sections.
>
+1 RFC7684-like text is good. Allegedly it's tad underspecified (unless you
know other drafts), i.e. it should mention whether TLV header is included
in the length or not. That's the most common implementation disagreement
>
>
> 3) Sec 2.2 "The size of the label range is determined by the number of Set
> Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that
> are used in the network. Each SI maps to a single label in the
> label range. The first label is for SI=0, the second label is for
> SI=1, etc.:
>
>
>
> This implies that there is no way to indicate only a label for SI=1 or a
> range for SI=1 to 3. That seems unfortunate and assumes that the BFR-ids
> are always allocated from SI=0 up. Is there a reason not to use some of
> the reserved bits to indicate the starting SI value?
>
>
>
> ad>set-identifiers provide a scaling for BIER sub-domains based on
> supported BitString lengths. Conceptually we forward in sub-domains, thus
> advertising label ranges for a sub-domain (as a base "unit" of forwarding)
> makes sense. The extra level of granularity would break that sub-domain
> consistency. Sometimes just because we could provide a higher granularity I
> do not think we should. This sub-domain granularity makes advertising and
> processing simpler.
>
>
>
Yes, to keep sub-TLVs compact and computation simple (missing labels would
create complex error criteria) we agreed to base @ SI=0 always and require
that all BFER-ids are covered by the range.
> 4) Sec 2.3: The Tree type is a 1 octet value - that doesn't appear to have
> any IANA allocation or meaning clearly indicated - beyond the parenthetical
> that 0=SPF. Please fix this.
>
>
>
> ad> agree this would need to be fixed
>
yes, parallel to ISIS draft. Right now missing or value = 0 is SPF. Needs
in IANA section a registry request
>
>
> 5) Sec 2.5: This section could benefit greatly from a diagram - showing
> the advertising router for a prefix, the ABR, and what is then flooded for
> the BIER MPLS Sub-TLV for the new areas.
>
>
>
> ad> again without arguing against diagram, I can only say this text is
> consistent with other similar paragraphs in other drafts/RFCs (like 7684).
> I could not find an example when we do put a diagram (but only looked at
> about 5 OSPF RFCs.
>
>
>
I don't consider it particularly necessary given it's basically RFC7684
behavior and easily understood by anyone who implemented type-3, type-1
behavior in OSPF. We don't summarize or play any tricks (given the draft
mandates /32 and N bit).
> Minor:
>
>
>
> 4) Sec 2.3: "Label Range Base: A 3 octet field, where the 20 rightmost
> bits represent the first label in the label range." What about the top 4
> bits? Are they Must Be Zero (MBZ)? How about making that explicit? Are
> they potential future flags?/
>
>
>
> ad> I assume you mean 2.2 section, yes MBZ.
>
>
>
yepp, needs adding
Ultimate observation: We should add that if the BML translation TLV is
present, it indicates that the node CAN translate between all BMLs it
advertised itself in SD and NOT all possible downstream BMLs. Important
clarification if we end up running multi-BML computations or a BFER has to
decide which BML to inject in a mix environ (doesn't look like we go there
but it's better be safe than sorry and it's a small addition making the
spec water-tighter).
Overall, stuff doesn't look like any major items popped up and too much
work overall. Given Les made noises to rev ISIS BIER towards start next
week I'm sure Peter as editor of OSPF BIER doesn't want to be bested
(nudge, nudge ;-P
--- tony
[Attachment #5 (text/html)]
<div dir="ltr">inlined into inlines ;-)<div><br><div class="gmail_extra"><br><div \
class="gmail_quote">On Tue, Sep 26, 2017 at 7:45 PM, Dolganow, Andrew (Nokia - \
SG/Singapore) <span dir="ltr"><<a href="mailto:andrew.dolganow@nokia.com" \
target="_blank">andrew.dolganow@nokia.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="white" lang="EN-US">
<div class="gmail-m_-1252074863702401667WordSection1">
<p class="MsoNormal"><span \
style="font-size:11pt;font-family:Calibri">Alia,<u></u><u></u></span></p> <p \
class="MsoNormal"><span style="font-size:11pt;font-family:Calibri"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11pt;font-family:Calibri">Thanks, so quick \
comments:<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11pt;font-family:Calibri"><u></u> <u></u></span></p> <div \
style="border-style:solid none \
none;border-top-width:1pt;border-top-color:rgb(181,196,223);padding:3pt 0cm 0cm"> <p \
class="MsoNormal" style="margin-left:36pt"><b><span \
style="font-family:Calibri;color:black">From: </span></b><span \
style="font-family:Calibri;color:black">Alia Atlas <<a \
href="mailto:akatlas@gmail.com" target="_blank">akatlas@gmail.com</a>><br> \
<b>Date: </b>Wednesday, September 27, 2017 at 6:12 AM<br> <b>To: </b>"<a \
href="mailto:bier@ietf.org" target="_blank">bier@ietf.org</a>" <<a \
href="mailto:bier@ietf.org" target="_blank">bier@ietf.org</a>>, OSPF List <<a \
href="mailto:ospf@ietf.org" target="_blank">ospf@ietf.org</a>>, "<a \
href="mailto:draft-ietf-bier-ospf-bier-extensions@ietf.org" \
target="_blank">draft-ietf-bier-ospf-bier-<wbr>extensions@ietf.org</a>" <<a \
href="mailto:draft-ietf-bier-ospf-bier-extensions@ietf.org" \
target="_blank">draft-ietf-bier-ospf-bier-<wbr>extensions@ietf.org</a>><br> \
<b>Subject: </b>early AD review of draft-ietf-bier-ospf-bier-<wbr>extensions-07<br> \
<b>Resent-From: </b><<a href="mailto:alias-bounces@ietf.org" \
target="_blank">alias-bounces@ietf.org</a>><br> <b>Resent-To: </b>Peter Psenak \
<<a href="mailto:ppsenak@cisco.com" target="_blank">ppsenak@cisco.com</a>>, \
<<a href="mailto:naikumar@cisco.com" target="_blank">naikumar@cisco.com</a>>, \
"(Ice) IJsbrand Wijnands" <<a href="mailto:ice@cisco.com" \
target="_blank">ice@cisco.com</a>>, Andrew Dolganow <<a \
href="mailto:andrew.dolganow@nokia.com" \
target="_blank">andrew.dolganow@nokia.com</a>>, <<a \
href="mailto:prz@juniper.net" target="_blank">prz@juniper.net</a>>, Jeffrey Zhang \
<<a href="mailto:zzhang@juniper.net" target="_blank">zzhang@juniper.net</a>>, \
<<a href="mailto:aldrin.ietf@gmail.com" \
target="_blank">aldrin.ietf@gmail.com</a>><br> <b>Resent-Date: </b>Wednesday, \
September 27, 2017 at 6:12 AM<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div><span class="gmail-">
<div>
<p class="MsoNormal" style="margin-left:36pt">I have done an early AD review of \
draft-ietf-bier-ospf-bier-<wbr>extensions-07 in preparation for the publication \
request.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">First, I would like to thank the many \
authors for their work on this draft. Given that there are currently 7 authors \
listed, I'd recommend appointing a few editors or otherwise reducing down to 5 or \
fewer. Of course, I am also willing to consider extraordinary circumstances where \
the shepherd can explain to me privately the deep technical contribution made by each \
author.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">I do see a number of major \
issues.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">Major Issues:<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</span><div><span class="gmail-">
<p class="gmail-m_-1252074863702401667MsoListParagraph" style="margin-left:54pt">
<u></u><span>1)<span \
style="font-style:normal;font-variant-caps:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times \
New Roman""> </span></span><u></u>RFC7684 is just for OSPFv2. How is \
the information carried for OSPFv3? We need a mechanism that works for IPv6 \
also.<u></u><u></u></p> </span><p class="MsoNormal" style="margin-left:36pt">ad> \
agree – the way the draft is written is v2 only. need to address \
that.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> \
</p></div></div></div></div></blockquote><div><br></div><div>+1</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="white" lang="EN-US"><div \
class="gmail-m_-1252074863702401667WordSection1"><div><div><p class="MsoNormal" \
style="margin-left:36pt"><u></u></p> </div>
<div><span class="gmail-">
<p class="MsoNormal" style="margin-left:36pt">2) In Sec 2.1, the Length is defined as \
variable and the figure includes additional sub-TLVs. Please clarify in the text what \
other sub-TLVs can be carried & how the length is calculated (yes, same as always \
- but clarity helps with interoperability).<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</span><p class="MsoNormal" style="margin-left:36pt">ad> Repeating may not be \
clarifying. How about we say "Variable, dependent on sub-TLVs" to use RFC7684-like \
text for the Extended prefix TLV. I could not find a single example where we list \
what sub-TLVs are carried either. That is done – as in this draft – in sub-TLV \
sections.</p></div></div></div></div></blockquote><div><br></div><div>+1 RFC7684-like \
text is good. Allegedly it's tad underspecified (unless you know other drafts), \
i.e. it should mention whether TLV header is included in the length or not. \
That's the most common implementation disagreement</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="white" lang="EN-US"><div \
class="gmail-m_-1252074863702401667WordSection1"><div><div><p class="MsoNormal" \
style="margin-left:36pt"><u></u><u></u></p> </div><span class="gmail-">
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">3) Sec 2.2 "The size of the label \
range is determined by the number of Set<br>
Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that<br>
are used in the network. Each SI maps to a single label in the<br>
label range. The first label is for SI=0, the second label is for<br>
SI=1, etc.:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
</span><div><span class="gmail-">
<p class="MsoNormal" style="margin-left:36pt">This implies that there is no way to \
indicate only a label for SI=1 or a range for SI=1 to 3. That seems unfortunate and \
assumes that the BFR-ids are always allocated from SI=0 up. Is there a reason not \
to use some of the reserved bits to indicate the starting SI \
value?<u></u><u></u></p> <p class="MsoNormal" style="margin-left:36pt"><u></u> \
<u></u></p> </span><p class="MsoNormal" \
style="margin-left:36pt">ad>set-identifiers provide a scaling for BIER sub-domains \
based on supported BitString lengths. Conceptually we forward in sub-domains, thus \
advertising label ranges for a sub-domain (as a base "unit" of forwarding) makes \
sense. The extra level of granularity would break that sub-domain consistency. \
Sometimes just because we could provide a higher granularity I do not think we \
should. This sub-domain granularity makes advertising and processing \
simpler.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> \
</p></div></div></div></div></blockquote><div><br></div><div>Yes, to keep sub-TLVs \
compact and computation simple (missing labels would create complex error criteria) \
we agreed to base @ SI=0 always and require that all BFER-ids are covered by the \
range.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="white" lang="EN-US"><div \
class="gmail-m_-1252074863702401667WordSection1"><div><div><p class="MsoNormal" \
style="margin-left:36pt"><u></u></p> </div>
<div><span class="gmail-">
<p class="MsoNormal" style="margin-left:36pt">4) Sec 2.3: The Tree type is a 1 octet \
value - that doesn't appear to have any IANA allocation or meaning clearly \
indicated - beyond the parenthetical that 0=SPF. Please fix this.<u></u><u></u></p> \
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p> </span><p \
class="MsoNormal" style="margin-left:36pt">ad> agree this would need to be \
fixed</p></div></div></div></div></blockquote><div><br></div><div>yes, parallel to \
ISIS draft. Right now missing or value = 0 is SPF. Needs in IANA section a registry \
request </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="white" lang="EN-US"><div \
class="gmail-m_-1252074863702401667WordSection1"><div><div><p class="MsoNormal" \
style="margin-left:36pt"><u></u><u></u></p> </div><span class="gmail-">
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">5) Sec 2.5: This section could benefit \
greatly from a diagram - showing the advertising router for a prefix, the ABR, and \
what is then flooded for the BIER MPLS Sub-TLV for the new areas. \
<u></u><u></u></p> </div>
</span><div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:36pt">ad> again without arguing against \
diagram, I can only say this text is consistent with other similar paragraphs in \
other drafts/RFCs (like 7684). I could not find an example when we do put a diagram \
(but only looked at about 5 OSPF RFCs.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt"><u></u> \
</p></div></div></div></div></blockquote><div><br></div><div>I don't consider it \
particularly necessary given it's basically RFC7684 behavior and easily \
understood by anyone who implemented type-3, type-1 behavior in OSPF. We don't \
summarize or play any tricks (given the draft mandates /32 and N bit). </div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="white" lang="EN-US"><div \
class="gmail-m_-1252074863702401667WordSection1"><div><div><p class="MsoNormal" \
style="margin-left:36pt"><u></u></p> </div><span class="gmail-">
<div>
<p class="MsoNormal" style="margin-left:36pt">Minor: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">4) Sec 2.3: "Label Range Base: A \
3 octet field, where the 20 rightmost bits represent the first label in the label \
range." What about the top 4 bits? Are they Must Be Zero (MBZ)? How about \
making that explicit? Are they potential future flags?/<u></u><u></u></p>
</div>
</span><div>
<p class="MsoNormal" style="margin-left:36pt"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:36pt">ad> I assume you mean 2.2 section, \
yes MBZ.<u></u><u></u></p> <p class="MsoNormal" style="margin-left:36pt"><u></u> \
</p></div></div></div></div></blockquote><div><br></div><div>yepp, needs adding \
</div><div><br></div><div>Ultimate observation: We should add that if the BML \
translation TLV is present, it indicates that the node CAN translate between all BMLs \
it advertised itself in SD and NOT all possible downstream BMLs. Important \
clarification if we end up running multi-BML computations or a BFER has to decide \
which BML to inject in a mix environ (doesn't look like we go there but it's \
better be safe than sorry and it's a small addition making the spec \
water-tighter). </div><div><br></div><div>Overall, stuff doesn't look like any \
major items popped up and too much work overall. Given Les made noises to rev ISIS \
BIER towards start next week I'm sure Peter as editor of OSPF BIER doesn't \
want to be bested (nudge, nudge ;-P </div><div><br></div><div>--- tony \
</div></div></div></div></div>
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic