Hi Acee, On Tue, Oct 3, 2017 at 10:56 AM, Acee Lindem (acee) <a...@cisco.com> wrote:
> Hi Alia, > > I spoke to Peter and I think the OSPFv3 Bier Extensions should go into a > separate OSPFv3 draft. Heretofore, all the work has been done in the BIER > working group and it seems it would make sense to do it here rather than > mix much into the overflow draft. As for the OSPF WG, the priority needs to > be to publish the OSPFv3 Extended LSA draft. I’ll ask Abhay to start the WG > last call and concurrently post the implementation information. > Ok - that works for BIER. For OSPF, getting that draft done will help a great deal with enabling feature parity for IPv6. Thanks for all your work on it. Regards, Alia > Thanks, > Acee > > From: Alia Atlas <akat...@gmail.com> > Date: Monday, October 2, 2017 at 2:32 PM > To: "Peter Psenak (ppsenak)" <ppse...@cisco.com>, Acee Lindem < > a...@cisco.com> > Cc: "b...@ietf.org" <b...@ietf.org>, OSPF WG List <ospf@ietf.org>, " > draft-ietf-bier-ospf-bier-extensi...@ietf.org" <draft-ietf-bier-ospf-bier- > extensi...@ietf.org> > Subject: Re: early AD review of draft-ietf-bier-ospf-bier-extensions-07 > > > > 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
