[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I have submitted this I-D updated after IESG review.
The changes are as follows.
Lars Eggert - Comment
Section 1.1., paragraph 2:
LSRs may be migrated to model and manage their TE LSPs using the MIB
modules in this document in order to migrate the LSRs to GMPLS
support, or to take advandtage of additional MIB objects defined in
Section 8., paragraph 185:
If the value of
gmplsTunnelErrorLastErrorType is protocol (2) the error should
be interpreted in the context of the signling protocol
Section 8., paragraph 198:
The notification rate applies to the sum
of all notificaitons in the MPLS-TE-STD-MIB and
Section 9., paragraph 7:
if the network itself is secure (for example by using IPSec), even
Section 12.1., paragraph 22:
[GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
Conventions for Multiprotocol Label Switching (MPLS)
Management", draft-ietf-ccamp-gmpls-tc-mib, work in
Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced
Russ Housley - Discuss
I don't understand gmplsTunnelLinkProtection. I gather it is
described in RFC3471. However it seems like this ought to be
discussed in the security considerations.
Explanation in email to Russ resulted in this response. No editorial action
I had a DISCUSS based on this comment. Thank for the explanation. I've
cleared the DISCUSS.
At 12:34 PM 8/29/2006, Adrian Farrel wrote:
1. I don't understand the gmplsTunnelLinkProtection whose function is
described in RFC3471. Since this document describes the MIB to
configure the field it probably shouldn't be an issue for this document.
However it would be good to know if the authors considered any
additional security considerations associated with this variable.
"Protection" here refers to the establishment of a secondary LSP that can
be used to carry the traffic in the event of the failure of the primary
LSP. It is not related to the Security use of the same term.
For more on GMPLS protection terminology you can read RFC4327.
Dan Romascanu - Discuss
ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module
transmission. That seems weird. By convention, transmission assignments
correspond to ifType values, which would result in a "Relationship to the
MIB" section of the document. If they don't define a new ifType value, I
why it should be under transmission. If, on the other hand, this is
intended to be the
MIB for ifType = mpls (166), then it should have a "Relationship to the
MIB" section. I think it would be better to put this under the mib-2 tree
or under the
After discussion, we determine that the module in question is
We agreed that this module should be under the mib-2 tree. The document has
been updated accordingly.