On Mon, Oct 2, 2017 at 11:07 AM, Peter Psenak <ppse...@cisco.com> 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 <ppse...@cisco.com >> <mailto:ppse...@cisco.com>> 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. > >> 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. > 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 OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
