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

[Venkatesan Mahalingam <[e-mail]>]

Mach,

Thanks for the prompt response. Please see inline.


-Venkat.

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

> Hi Venkatesan,
>
> Thanks for your response!
>
> Please see my replies inline...
>
> > From: Venkatesan Mahalingam [mailto:[e-mail]]
> > Sent: Thursday, September 11, 2014 6:40 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
> >
> > 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]> 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]]
> > > Sent: Thursday, August 21, 2014 6:31 PM
> > > To: [e-mail]
> > > Cc: [e-mail]; VIGOUREUX, MARTIN (MARTIN); Joan
> > > Cucchiara; Mach Chen; <[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]
> > > Senior MPLS Expert                          [e-mail] Huawei
> > > Technologies (consultant)     phone: [phone]
>
>