On Mon, Oct 2, 2017 at 2:26 PM, Peter Psenak <ppse...@cisco.com> wrote:
> 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 <ppse...@cisco.com >> <mailto: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> >> <mailto: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. >> > > would stating in this document that OSPFv3 BIER extension will be covered > in a separate draft help? It would need more than that. Let's see what Acee thinks is a reasonable approach. My tendency would be to reference the draft that is collecting OSPV3 Extended LSA TLVs - but I'm not sure if that draft is still merely conceptual. > 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. > Sounds good. Thanks! Alia > > 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 OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
