Re: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules

[Mach Chen <[e-mail]>]

Hi Venkat,

Thanks for the updates, I will review it soon.

Best regards,
Mach

From: Venkatesan Mahalingam [mailto:[e-mail]]
Sent: Thursday, December 04, 2014 8:55 AM
To: Mach Chen
Cc: [e-mail]; [e-mail]; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; <[e-mail]>; [e-mail]
Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules

Mach,

We have addressed your comments and uploaded the new version 06. Please review again and provide your feedback.

http://tools.ietf.org/id/draft-ietf-mpls-tp-oam-id-mib-06.txt

-MPLS OAM MIB Team

On Wed, Sep 10, 2014 at 6:55 PM, Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Venkat,

Thanks for considering my comments and your prompt response!

Looking forward to see the updates.

Best regards,
Mach

From: Venkatesan Mahalingam [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, September 11, 2014 9:45 AM

To: Mach Chen
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules

Mach,

Thanks for the prompt response. Please see inline.


-Venkat.

On Wed, Sep 10, 2014 at 6:36 PM, Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Venkatesan,

Thanks for your response!

Please see my replies inline...

> From: Venkatesan Mahalingam [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, September 11, 2014 6:40 AM
> To: Mach Chen
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>
> Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds
> for MPLS MIB modules
>
> Hi Mach,
>
> Thanks for your thorough review. Please find below our responses in-lined.
>
> -MPLS OAM MIB team
>
> On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Authors/Editors,
>
> I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG chairs and
> Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-mib.
>
> I have reviewed version 05 of the draft, here are my comments and some
> questions, please consider.
>
> 1.
> Extract the acronym when first use, for example, LSP in the Introduction, and it's
> not necessary to extract an acronym when each uses, for example, MPLS in
> section 1 and section 3.2 .
> Thanks, will change it in the next version.
>
> 2.
> In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPLS-TP
> co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP
> Pseudowires Identifiers and Section Identifiers. And in Section 5 of RFC6370,
> there are some text that describes the difference between "MPLS tunnel" and
> "MPLS LSP". In this draft, there are many usages of "tunnel" in section 4, 5 and 6,
> and actually it should be "LSP". I know that sometimes people alternatively use
> tunnel and LSP, but it's better to use the term in an accurate way hence to reduce
> the confusion.
> Yes, will state that explicitly in the next version.
>
> In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw and
> section listed), it implies that the MPLS-TP point-to-point Tunnels identifiers are
> actually precluded in this document. Is my understanding right? If so, it needs
> look through the document and refine the text to state it clearly.
>  mplsOamIdMegServicePointerType object is defined generically to handle any
> kind of service pointer (Tunnel, LSP, PW) these service pointers can be used for
> MPLS/MPLS-TP path.
Here, I am not prefer to the difference between MPLS and MPLS-TP.

Of cause, if the intention is to apply this MIB to both MPLS and MPLS-TP path, it's better to add some text to explicitly state this (e.g., in the Abstract and/or Introduction section).

Actually, the above question related to the definition of mplsOamIdMegServicePointerType, it's defined as below:
       mplsOamIdMegServicePointerType OBJECT-TYPE
          SYNTAX        INTEGER {
                            lsp (1),
                            pseudowire (2),
                            section (3)
                        }
Here, only lsp, pw and section listed, based on the fact that Tunnel is not the same thing as LSP. If MPLS Tunnel is included, then there may need the fourth item: tunnel (4), right?
Got it. Yes, Thanks.

>
> Here are some example that may need updates:
>
> Section 4.
>
> OLD:
> "
> The MIB module supports configuration of OAM identifiers for
>          point-to-point, co-routed bidirectional, associated
>          bidirectional MPLS tunnels and MPLS Pseudowires.
> "
> NEW:
> "
> The MIB module supports configuration of OAM identifiers for
>          MPLS-TP co-routed bidirectional LSPs, associated
>          bidirectional LSPs, Sections and Pseudowires.
> "
> As mentioned above. we dont need to change the text (MPLS to MPLS-TP), will
> enhance the existing text to make the intention of this MIB clear.

OK, I am fine with the idea to make this MIB generally apply to MPLS and MPLS-TP, but as said above, some intention text may needed.

In addition, when you begin to enhance the text, please consider which paths(e.g., Tunnel, LSP, PW and Section) you intend to include and make all relevant text consistent.
Sure. will update in the next version.

>
> Section 5.
>
> s/...configurations for MPLS Tunnels and Pseudowires/...configurations for
> MPLS-TP LSPs, Sections and Pseudowires
>
> Section 5.1
>
> s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and
> Pseudowires.
>
> Section 6
>
> s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirectional LSP
>
> s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed
> bidirectional LSP are illustrated here Same as above.

OK, same as above, the difference between Tunnel and LSP.
ACK.

>
> 3.
>
> For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe
> following items?
>        mplsOamIdMeProactiveOamPhbTCValue = 0,
>        mplsOamIdMeOnDemandOamPhbTCValue  = 0,
>
> It seems that they should not belong to this MIB, maybe better in other MIB.
> PHB TC values are defined in this MIB to basically use these values in
> Proactive(BFD)/OnDemand(LSP Ping) sessions.

I know they are useful, I am just not sure whether they should belong to this MIB, since this MIB is just an OAM identifier MIB.
Will discuss internally and decide on this.
>
> 4.
>
> mplsOamIdMegPathFlow OBJECT-TYPE
>           SYNTAX        INTEGER {
>                           unidirectionalPointToPoint (1),
>                           coRoutedBidirectionalPointToPoint (2),
>                           associatedBidirectionalPointToPoint (3),
>                           unidirectionalPointToMultiPoint (4)
>
> Seems RFC6370 does not define how to identify a
> unidirectionalPointToMultiPoint path, and from the Introduction of this
> document, the P2MP seems not be included.
>
> We will add more information for P2MP in the next version after the internal
> discussion.

OK, please do.
ACK
>
> 5.
>
> mplsOamIdMegSubOperStatus OBJECT-TYPE
>           SYNTAX       BITS {
>                         megDown (0),
>                         meDown (1),
>                         oamAppDown (2),
>                         pathDown (3)
>                        }
>                The bit 0 (megDown) indicates the MEG is down.
>                The bit 1 (meDown) indicates the ME table is
>                down.
>                The bit 2 (oamAppDown) indicates that the
>                OAM application has notified that the entity (LSP or PW)
>                monitored by this MEG is down. Currently, BFD is the
>                only supported OAM application.
>                The bit 3 (pathDown) indicates that the underlying
>                LSP or PW is down."
>
> I am not sure what's the mean of "down" here, especially the mean of "MEG is
> down", "ME table is down" and "LSP and PW is down"?
> We defined this object to notify the operational status of MEG, ME, OAM app
> and the MPLS/MPLS-TP path, will add more information in the next version.

OK, please do.
ACK
>
> 6.
>
> mplsOamIdMeServicePointer OBJECT-TYPE
>
>           SYNTAX        RowPointer
>           MAX-ACCESS    read-create
>           STATUS        current
>           DESCRIPTION
>             "This variable represents a pointer to the MPLS-TP
>              transport path. This value MUST point at an entry in the
>              mplsTunnelEntry if mplsOamIdMegServicePointerType
>              is configured as lsp (1) or at an entry in the pwEntry if
>              mplsOamIdMegServicePointerType is configured
>              as pseudowire (2).
>
> How about mplsOamIdMegServicePointerTypesection is configured as section
> (3)?
> Section is not yet taken care in this MIB. Will add missing information after
> internal discussion.

OK, please do.
ACK
>
> And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP
> tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry
> and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry?
> No,Tunnel & PW entries are augmented to have the extra fields in the new tables
> for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP path to
> OAM config association.

OK.
ACK

>
> 7.
> mplsOamIdMegServicePointerType OBJECT-TYPE
>
>           SYNTAX        INTEGER {
>                             lsp (1),
>                             pseudowire (2),
>                             section (3)
>                         }
>           MAX-ACCESS    read-create
>           STATUS        current
>           DESCRIPTION
>             "Indicates the service type for the MEG.
>              If the service type indicates lsp, the service pointer
>              in mplsOamIdMeTable points to an entry in
>              the mplsTunnelTable [RFC3812].
>
> Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP
> Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable and
> reference be draft-ietf-mpls-tp-te-mib-08?
> No, as stated above, this MIB is mainly defined to provide OAM configs for MPLS
> & MPLS-TP paths.

OK.
ACK

Best regards,
Mach

>
> Best regards,
> Mach
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:[e-mail]<mailto:[e-mail]>]
> > Sent: Thursday, August 21, 2014 6:31 PM
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>; VIGOUREUX, MARTIN (MARTIN); Joan
> > Cucchiara; Mach Chen; <[e-mail]<mailto:[e-mail]>>
> > Subject: Shepherds for MPLS MIB modules
> >
> > Working Group,
> >
> > We have for some time been looking for someone to help us shepherding
> > our MIB modules. I'm happy to announce that Mach Chen and Young Lee
> > has agreed to help us.
> >
> > Please help Mach and Young as they start working with the documents.
> >
> > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib.
> >
> > Further shepherd assignments will be done as soon as the details are sorted
> out.
> >
> >
> > /Loa
> > for the mpls wg chairs
> > --
> >
> >
> > Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> > Senior MPLS Expert                          [e-mail]<mailto:[e-mail]> Huawei
> > Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>