Thanks. Looks good to me. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: bruno.decraene@xxxxxxxxxxxxxxxxxx > [mailto:bruno.decraene@xxxxxxxxxxxxxxxxxx] > Verzonden: maandag 28 april 2008 14:07 > Aan: bertietf@xxxxxxxxxxx > CC: ietf@xxxxxxxx; ina@xxxxxxxxxxx; jeanlouis.leroux@xxxxxxxxxxxxxxxxxx > Onderwerp: RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt > > > 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