[Pce] Comments draft-crabbe-pce-stateful-pce-mpls-te-00,

"Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com> Thu, 21 February 2013 11:43 UTC

From: "Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com>
To: "pce@ietf.org" <pce@ietf.org>, "draft-crabbe-pce-stateful-pce-mpls-te@tools.ietf.org" <draft-crabbe-pce-stateful-pce-mpls-te@tools.ietf.org>
Thread-Topic: Comments draft-crabbe-pce-stateful-pce-mpls-te-00,
Thread-Index: Ac4QKLYVgJbuY7JkSQmREw/b3NX1nQ==
Date: Thu, 21 Feb 2013 11:43:48 +0000
Message-ID: <8DC6547C806B644F998A0566E79E15920F7CFCB2@DEMUMBX006.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Pce] Comments draft-crabbe-pce-stateful-pce-mpls-te-00,
Precedence: list

Hi PCEers

I did not see any reply on my previous comments I repost them with separate threads, as the initial one were big

1. Section 4.1 : The Stateful PCE can populate its LSP-DB from either PCRep or PCRpt, for PCRep this is consistent with section 6.3 of draft-ietf-pce-stateful-pce-02. To match this the PCRpt definition should stop at the <state-report> definition, the rest should be as defined in the Other RFCS.
2. Section 4.1/section 4.2 : you indicate that the report may contains a path descriptor for the primary and one or more the backup path(s), I support the middle should be the primary one, correct? This diverge from the RFC5440 where there is no role associated to the path list, I would suggest to use the PROTECTION-ATTRIBUTE defined in draft-ietf-pce-gmpls-pcep-extensions-07, in addition this seems more or less generic.
3. Section 4.2 : same comment as in section 4.1 : to be consistent with other documents, all definition after <update-request> can be removed.
4. Section 5.1 : this is also quite generic, in draft-ietf-pce-stateful-pce RSVP error spec is considered generic material but here LSP identifier as MPLS-TE specific. I would then rather expect "RSVP" specific extensions but not MPLS RSVP-TE and GMPLS RSVP-TE (a "GMPLS" document can also make use of the LSP Identifier).
5. In general its seems you want to say " use draft-ietf-pce-stateful-pce" and only implement RFC5440 objects, but change some of its semantic, this is a mix of different things which are not very coherent. Having the generic part defining the behavior on non-supported objects (P2MP, GMPLS, inter-layer ..etc) could help focusing the "technology" specific to be better scoped.
6. Section 5.3. LSP Update Error Code TLV : why is it MPLS-TE specific?

If the changes 1 and 3 are applied, this will make the document apply to all current and future RSVP-TE based control plane.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria

Nokia Siemens Networks Optical GmbH
St.Martin-Str. 76
D-81541 München
Germany
mailto:cyril.margaria@nsn.com
Phone: +49-89-5159-16934
Fax: +49-89-5159-44-16934
----------------------------------------------------------------
Nokia Siemens Networks Optical GmbH
Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 197143

[Pce] Comments draft-crabbe-pce-stateful-pce-mpls… Margaria, Cyril (NSN - DE/Munich)