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

["Adrian Farrel" <[e-mail]>]

Hi Ben,

Many thanks for reading.

> 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?

The precise words in section 2 are thrust upon us. They form boilerplate for 
MIB module I-Ds and we dare not whisper of changing this text.

Oddly (?) the three listed RFCs combine to form STD 58. See 
http://www.rfc-editor.org/rfc-index.html

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

Good catch.

I'll add something similar and rework the section a little for more clarity.

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

Yes.
Actually, the same question applies to Path messages.
I have added a reference to [RFC4875] and pointed out that on the upstream 
segment there could be one or two Path and Resv messages depending on 
implementation.

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

Yes. That is also a good catch as well.
Added material to the discussion of GMPLs in section 4.

> 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/

All excellent.

 > 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/

I've made those changes and we'll see what happens.
I think these two are errors in the boilerplate :-(

Many thanks,
Adrian 


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