Hi Alia,
please see inline:
On 02/10/17 17:33 , Alia Atlas wrote:
On Mon, Oct 2, 2017 at 11:07 AM, Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Hi Alia,
please see inline:
On 02/10/17 16:41 , Alia Atlas wrote:
Hi Peter,
On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi Alia,
please see inline:
On 27/09/17 00:12 , Alia Atlas wrote:
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.
BIER extension for OSPFv3 will be covered in a separate
draft. It
will be based on draft-ietf-ospf-ospfv3-lsa-extend draft.
This is
similar to what we did for SR and other extensions.
I understand that theory - but I think it is getting less tractable.
How far along is that draft? I'll need to at least
reference it and discuss the IPv6 support in the write-up. Once
draft-ietf-ospfv3-lsa-extend is published as an RFC, I would really
expect this to stop happening.
given that the encoding of the OSPFv3 is way different to OSPFv2 and
the fact that the draft-ietf-ospfv3-lsa-extend is still a work in
progress I would tend to keep the v2 and v3 extensions separate.
Given the second, that's ok - but usually the difference in encoding
isn't enough to require a different draft.
Please do talk to Acee about this. He's collecting OSPFv3 LSA extensions
to add to a separate draft when
draft-ietf-osfpv3-lsa-extend progresses - and that draft is just waiting
on the implementations (and there are
finally 2 of them) so I expect it to move along soon.
When you say "discuss the IPv6 support in the write-up" do you mean
to mention it in draft-ietf-bier-ospf-bier-extensions? If yes, why?
This documents only specifies OSPFv2 extension.
No - I mean in the shepherd's write-up - though an informative reference
to an OSPFv3 draft or a common one would help. At the moment, there's
NOTHING about IPv6 and that's going to make it harder to get IESG
agreement on.
would stating in this document that OSPFv3 BIER extension will be
covered in a separate draft help?
I don't know if you noticed that draft-ietf-sunset4-ipv6-ietf-01
("IETF:
End Work on IPv4") is in IETF Last Call.
Of course, it has lots of caveats and is getting a number of
concerned
comments - but the trend is obvious
as is the deployment of IPv6 and the need for feature parity.
not that I disagree, but let's not get into that discussion here :)
Just calling your attention to the current atmosphere :-)
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).
will change to "Variable, dependent on sub-TLVs" language
as we did
in SR draft.
Sounds good - Variable, 4 + length of sub-TLVs I think. I.e.,
be clear
on the length
contributed by this TLV as well as the included sub-TLVs.
not that I care too much, but I would like to keep the language same
between documents. Unless you insist otherwise, keeping the
"Variable, dependent on sub-TLVs" would make it consistent with
other docs.
Well, I don't deeply care either (beyond bike-shed painting) - but there
is content to the TLV so it has length to be included in the calculation.
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?
I hope this has been clarified by Andrew and Tony already.
Sure - I'm fine with what the WG wants here - and labels aren't too
limited. My concern
was about efficiency and future flexibility.
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.
will add description for value 0. Will also add the need
for new
registry in "IANA Considerations" section.
Cool - unless there's a reason, could it be a BIER-related
registry that
both the IS-IS work and OSPF work
can refer to?
right, that make sense. In such case, it should be defined outside
of IGP BIER drafts, shouldn't it?
It's ok to have it here. This is a BIER WG draft and it isn't needed
until this or the ISIS one.
Either can work. It could be in the mpls-encap draft, but that's ready
for IETF Last Call and it isn't
used there - so it would need more explanation.
ok, I define it here.
thanks,
Peter
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.
can you please clarify what type of diagram do you have in
mind?
A fairly simple one :-) where there are 3 areas - with the
middle being
the backbone.
Have a BFER in each area. Describe what is advertised by each
BFER and
then by
the ABR.
I tend to agree with Andrew that we have similar section in
many
other documents and we've never included any diagram
really. Anyway,
I don't have a problem adding it if it helps.
Frankly, the language/phrasing was such that I had to stop and think
about it for 5 minutes or so to be
confident that I understood and agreed with what was there. That's
generally my sign that added clarity
could be useful - but it could just be me or a bad day.
let me try.
Thanks,
Alia
thanks,
Peter
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?/
top for bits are ignored. I'll spell that out explicitly.
Sounds good.
I look forward to getting these from the WG. If I can put them into
IETF Last Call by the end of the
week, then we can have them on the Oct 26 telechat and hopefully
approved before IETF 100.
Regards,
Alia
thanks,
Peter
Thanks,
Alia
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
