Inline, Bruno > De : Bert Wijnen - IETF [mailto:bertietf@xxxxxxxxxxx] > > Inline > > Bert Wijnen > > > Van: bruno.decraene@xxxxxxxxxxxxxxxxxx > > > > > > Bert, > > > > Many thanks for your comments. > > More inlined. > > > > Bruno > > > > > De : Bert Wijnen - IETF [mailto:bertietf@xxxxxxxxxxx] > > > > > > Forwarding to IETF wide list and authors/editors > > > > > > Bert Wijnen > > > > > > Van: Bert Wijnen - IETF [mailto:bertietf@xxxxxxxxxxx] > > > > > > > > > I reveied this document for the OPS Directorate > > > > > > In general, I think the document is ready for publication. > > > > > > In sect 7.1 I read: > > > > > > For the successful establishment of end-to-end MPLS LSPs whose FEC > > > are aggregated in the RIB, this specification must be implemented on > > > all LSRs in all areas where IP aggregation is used. If an LSR on the > > > path does not support this procedure, then the LSP initiated on the > > > egress LSR stops at this non compliant LSR. There are no other > > > adverse effects. > > > > > > I think/hope (but it would be good to see this confirmed) that this does > > > not mean that all LSRs in the set of IGPs that are involved need to be > > > upgraded with the new protocol at exactly the same time. > > > > > > The way I understand it, one can upgrade the LSRs at different times, > > > but should only activate this new mechnaism once all LSRs have > > > ineeded been upgraded with the new capability. > > > > You're right: all LSRs do not need to be upgraded at the same time: > > - deployment in each IGP (area) is independent > > - LSRs can be upgraded at any time in any order, > > - This new mechanism can be activated on the LSR at any time in > > any order, (upgrade and activation can be done at same step if > > it's considered easier) > > - Then, if the FEC/LSP were used, we need a non disruptive deployment: > > (As a reminder, the ABRs used to leak all specific prefixes > > in the IGP area.) > > The ABRs can advertise the (new) aggregate prefix at any > > time and any order. > > However, the specific prefixes in the IGP area should only > > be withdrawn (by the ABRs) once all the LSR of this IGP area have > > been upgraded. (Otherwise "If an LSR on the path does not support > > this procedure, then the LSP initiated on the egress LSR stops at > > this non compliant LSR.") > > > > Do you think this should be clarified in the document? > > > > Up to you. > Apparently I understood it correctly. > The fact that is it not needed to upgrade all at the same time > is the important point for me. If I had understood it incorrectly, > I would have had a bigger concern. So would I. > Making it clearer is always good I think. Up to you. I've updated the section 7.1 "Deployment considerations" with the following: "This extension can be deployed incrementally: - It can be deployed on a per area or routing domain basis and does not necessarily require an AS wide deployment. For example, if all specific IP prefixes are leaked in the IGP backbone area and only stub areas use IP aggregation, LSRs in the backbone area don't need to be compliant with this document. - Within each routing area, LSRs can be upgraded independently, at any time, in any order and without service disruption. During deployment, if those LSPs are used, one should only make sure that ABRs keep advertising the specific IP prefixes in the IGP until all LSR of this area are successfully upgraded. Then, the ABRs can only advertise the aggregated prefix and stop advertising the specific ones." Please feel free to amend/correct/comment if needed. > Bert > > > > > Nits: > > > > Thanks. > > All corrections are done and will appear in the next revision. > > > Thanks, > > Bert _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf