Subject: [mpls] Shepherds for MPLS MIB modules

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Aug 2014 12:31:03 +0200

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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Fri, 22 Aug 2014 10:57:35 +0200

Working Group,

We have now also assigned Young Lee as the Document Shepherd for
draft-ietf-mpls-tp-te-mib.

/Loa
for the mpls wg chairs

--

---

From: Mach Chen <[email-masked]>
Date: Fri, 29 Aug 2014 09:18:00 +0000

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 .

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. 

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. 

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

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

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.

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.

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

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

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?

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?

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 6:31 PM
> To: [email-masked]
> Cc: [email-masked]; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara;
> Mach Chen; <[email-masked]>
> 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.
> 
> Further shepherd assignments will be done as soon as the details are sorted out.
> 
> 
> /Loa
> for the mpls wg chairs
> --
> 
>