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

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sun, 27 Apr 2008 11:42:41 +0200

Forwarding to IETF wide list and authors/editors

Bert Wijnen

-----Oorspronkelijk bericht-----
Van: Bert Wijnen - IETF [mailto:[email-masked]]
Verzonden: donderdag 24 april 2008 13:55
Aan: [email-masked]
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.

Nits:

- There are several/many acronyms in this document that never get
  expanded. It is good pratice to always expand an acronym when
  it is used for the first time.

- Abstract

   To facilitate the establishment of Label Switched Paths (LSP) that
   would span multiple IGP areas in a given Autonomous System (AS), this
   document proposes a new optional label mapping procedure for the
   Label Distribution Protocol (LDP).

  s/proposes/describes/ (at least once this comes out as RFC, right?)

- need to add citation to RFC2119 in section 1.
  And add a normative reference for RFC2119.

- 2nd para section 4:

   To set up the required MPLS LSPs between PEs in different IGP areas,
   services providers have currently three solutions: LDP with IGP route

  s/services/service/ I think.

- consistency: I see
    Service providers
    service providers
    Service Providers
  I suggest to use consistent capitalization

- 1st para sect 5:

   This document defines a new label mapping procedure for [LDP]. It is
   applicable to IPv4 and IPv6 prefix FEC elements (addresses families 1
   and 2 as per [ASSIGNED_AF]). It MUST be possible to activate / ^M

  I believe it is "address families" (or maybe "addressing families") but
  not "addresses families". So I would: s/addresses/address/

- sect 5, I see
     longest match label mapping procedure
     longest match Label Mapping Procedure
     "Longest Match" label mapping procedure
     longest match procedure
  you might want to be a bit moire consistent

- Section 5:

     - next-hop change when an existing prefix have new next hop
        following a routing change.

   s/have new/has a new/ ??

     - When the next-hop of a RIB prefix change, the LSR must change

   change the first "change": s/change/changes/ or so I think.

- 2nd para section 7.2

   In case of failure of the egress LER node, given that the IGP
   aggregates IP route on ABRs, the routing convergence behavior is
   changed compared to [LDP]. As the IGP does not carry specifics
   prefixes outside of the egress area, the IGP will not propagate the

  s/specifics prefices/specific prefixes/ (or so I think)

- Last para sect 7.2
   For all others failures

  s/others/other/
Bert Wijnen

-----Oorspronkelijk bericht-----
Van: Seely, Ted A [CTO] [mailto:[email-masked]]
Verzonden: donderdag 17 april 2008 13:42
Aan: Bert Wijnen
Onderwerp: OPS DIR Review Request

Hello Bert,

As a member of the Operations Directorate you are being asked to review the
following IESG work item for it¹s operational impact.

IETF Last Call:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-interarea-03.txt
BTW - This is a very short draft.

If possible please provide comments and review to the Ops-dir mailing list
([email-masked]), preferably before next Wednesday if possible.

Thank you Bert,

Ted

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 28 Apr 2008 12:53:17 +0200

Inline

Bert Wijnen

> Van: [email-masked]
> [mailto:[email-masked]]
> Verzonden: maandag 28 april 2008 12:18
> Aan: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> 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:[email-masked]]
> > Envoyé : dimanche 27 avril 2008 11:43
> > À : [email-masked]; [email-masked]; 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
> >
> 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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 28 Apr 2008 15:46:23 +0200

Thanks. Looks good to me.

Bert Wijnen

> Verzonden: maandag 28 april 2008 14:07
> Inline,
> So would I.
> 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.

---

From: <[email-masked]>
Date: Mon, 28 Apr 2008 12:17:55 +0200

Bert,

Bruno

> À : [email-masked]; [email-masked]; LE ROUX Jean-Louis RD-SIRP-LAN; DECRAENE Bruno RD-CORE-ISS

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.")

Thanks.

---

From: <[email-masked]>
Date: Mon, 28 Apr 2008 14:07:17 +0200

Inline,

Bruno

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."