RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt

Thanks. Looks good to me.

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: bruno.decraene@orange-ftgroup.com
> [mailto:bruno.decraene@orange-ftgroup.com]
> Verzonden: maandag 28 april 2008 14:07
> Aan: bertietf@bwijnen.net
> CC: ietf@ietf.org; ina@juniper.net; jeanlouis.leroux@orange-ftgroup.com
> Onderwerp: RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
>
>
> Inline,
>
> Bruno
>
> > De : Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]
> >
> > Inline
> >
> > Bert Wijnen
> >
> > > Van: bruno.decraene@orange-ftgroup.com
> > >
> > >
> > > Bert,
> > >
> > > Many thanks for your comments.
> > > More inlined.
> > >
> > > Bruno
> > >
> > > > De : Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]
> > > >
> > > > Forwarding to IETF wide list and authors/editors
> > > >
> > > > Bert Wijnen
> > > >
> > > > Van: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]
> > > >
> > > >
> > > > 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf