Re: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - EXTENDED

[Ben Niven-Jenkins <[e-mail]>]

Although no MIB expert, the MIB module itself looks good to me, however I
have the following comments on the document itself.

Section 2 presents references differently to the rest of the document
section 2 uses the format RFCxxx [RFCxxx] but elsewhere the format used is
[RFCxxx].  Also STD 58 has no reference.

Section 2: In the list of documents that describe SMIv2 why is STD58 listed
three times?

Section 4 refers to a P2MP path being made up of LSPs (plural) - I think
there is an implicit assumption by the authors that a P2MP LSP is modelled
as a set of sub-LSPs that when joined together at the branch LSRs form the
complete P2MP LSP tree.  I would suggest that this assumption is stated at
the beginning of section 4 and that RFC4875 for a more detailed description.

I suggest the authors could use something like the following text "This
document models a P2MP LSP as comprising of multiple source-to-leaf (S2L)
sub-LSPs.  These S2L sub-LSPs are set up between the ingress and egress LSRs
and are appropriately combined by the branch LSRs to result in a P2MP TE
LSP. See [RFC4875] for a more detailed description of S2L LSPs and how they
are combined to form a P2MP TE LSP"

Section 5.2, 4th paragraph - I would suggest the authors make it explicit
whether LSR B sends a single or multiple Resv messages to LSR A.

As the P2MP TE MIB can be used for both P2MP MPLS & GMPLS LSPs and as P2MP
LSPs are always unidirectional the document should probably specify that
when using the MIB to configure P2MP GMPLS LSPs that gmplsTunnelDirection
should always be set to forward(0).


Purely editorial comments:
ToC: Two sections 4.3 & no 4.4.

Section 4.2 3rd paragraph - I think you mean "supplementary to" not
"supplementary for" Or do you mean the text supplants/supercedes/replaces
that in RFC3812?

Section 4.2.2 mplsTunnelMaxHops s/mximum/maximum/ s/legac/legacy/

Section 5.1 step 2 s/-- This table entry is created by configuration no
signaling/-- This table entry is created by configuration not signaling/

Section 5.2 4th paragraph, 1st line s/LSR/LSR B/

Section 5.2 the paragraph above the mplsTeP2mpTunelTable example
s/speicific/specific/

Section 5.2 the paragraph above mplsTunnelHopTable s/spearated/separated/

Section 8 paragraph 11 the "even then" is redundant and should be removed
leaving the following sentence: "Even if the network itself is secure (for
example by using IPSec), there is no control as to who on the secure network
is allowed to access and GET/SET (read/change/create/delete) the objects in
this MIB module."

I would also suggest the authors consider s/there is no control/there is
still no control/


Ben


On 15/04/2008 12:39, "Loa Andersson" <[e-mail]> wrote:

> All,
> 
> we have been running this wg last call for two weeks, but we
> have not seen any comments; the wg last call is therefore
> extended to April 25.
> 
> Loa and George
> 
> 
> 
> Loa Andersson wrote:
>> Hi MPLS chairs,
>> 
>> This is to initiate a working group last call on
>> P2MP MPLS-TE MIB module
>> <draft-ietf-mpls-p2mp-te-mib-06.txt>.
>> 
>> The MIB module has been through an earl  MIB Dr. review and
>> there has also been comments from experienced MIB implementors.
>> This resulted in various updates and version - 06 is the
>> result of this process.
>> 
>> Please send your comments to the working group mailing list or
>> to the working group chairs not later than April 13.
>> 
>> Loa and George
>> 
> 

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls