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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Inline

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: bruno.decraene@xxxxxxxxxxxxxxxxxx
> [mailto:bruno.decraene@xxxxxxxxxxxxxxxxxx]
> Verzonden: maandag 28 april 2008 12:18
> Aan: bertietf@xxxxxxxxxxx
> CC: ietf@xxxxxxxx; ina@xxxxxxxxxxx; jeanlouis.leroux@xxxxxxxxxxxxxxxxxx
> Onderwerp: RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
>
>
> Bert,
>
> Many thanks for your comments.
> More inlined.
>
> Bruno
>
> > -----Message d'origine-----
> > De : Bert Wijnen - IETF [mailto:bertietf@xxxxxxxxxxx]
> > Envoyé : dimanche 27 avril 2008 11:43
> > À : ietf@xxxxxxxx; ina@xxxxxxxxxxx; LE ROUX Jean-Louis
> RD-SIRP-LAN; DECRAENE Bruno RD-CORE-ISS
> > Objet : FW: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
> >
> > Forwarding to IETF wide list and authors/editors
> >
> > Bert Wijnen
> >
> > -----Oorspronkelijk bericht-----
> > Van: Bert Wijnen - IETF [mailto:bertietf@xxxxxxxxxxx]
> > Verzonden: donderdag 24 april 2008 13:55
> > Aan: ops-dir@xxxxxxxx
> > Onderwerp: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
> >
> >
> > 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.

Making it clearer is always good I think. Up to you.

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]