Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib

From: Lou Berger <[email-masked]>
Date: Mon, 18 Apr 2011 15:19:27 -0400

This mail begins a 2nd WG last call on:

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08

The draft has been updated after the earlier working group primarily
based on MIB Dr. review and discussion on the ccamp list.

This working group last call ends on May 2nd. This LC will be announced
on the MPLS, OSPF, and ISIS WG lists.  Please send comments to
the CCAMP mailing list.

Lou (and Deborah)

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Apr 2011 08:17:56 -0400

Authors,
	Please treat this as a LC comment.

Please send replies/follow-ups to ccamp (and Wenhu) only. (OSPF cc'ed on
this message so they may know where the conversation has moved.)

Much thanks,
Lou

On 4/18/2011 5:55 PM, Wenhu Lu wrote:
> Page 7:
> TedAreaIdTC has SYNTAX Unsigned32.
> For ISIS, the area address is of variable length. Please refer to ISO 10589 2002 Figure 4 on page 16 and change the SYNTAX accordingly.
> 
> Similar comments for TedRouterIdTC, TedLinkStateIdTC when applied to ISIS.
> Also it looks like the REFERENCE only cites OSPFv2 and OSPFv3.
> 
> Thanks,
> -wenhu
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
> Sent: Monday, April 18, 2011 2:02 PM
> To: OSPF WG List
> Subject: [OSPF] Fwd: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> FYI for those not subscribed to the CCAMP mailing list - Please consider reviewing this draft if you are involved with Traffic Engineering.
> Thanks,
> Acee
> 
> Begin forwarded message:
> 
> From: Lou Berger <[email-masked]<mailto:[email-masked]>>
> Date: April 18, 2011 3:19:27 PM EDT
> To: CCAMP <[email-masked]<mailto:[email-masked]>>
> Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list.
> 
> This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists.  Please send comments to the CCAMP mailing list.
> 
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
> 
> 
> 
>

---

From: Ben Wright <[email-masked]>
Date: Thu, 21 Apr 2011 10:32:05 +0100

Hi Masanori et al, 

I have a few minor comments on draft-ietf-ccamp-gmpls-ted-mib-08.  

* 	I agree with Wenhu's comments on the OSPF mailing list - we need to update the Textual Conventions to take into account ISIS syntax. 

*	The tedTable structure doesn't make it easy for network administrators to query just the TED entries that are learned from, say, OSPFv2 (rather than ISIS).  An easy fix for this would be to make the primary index field the information source (OSPFv2, ISIS etc).  This would also make the interpretation of the syntax of the remaining index fields straightforward for MIB agents.  

*	The tedLocalIfAddrTable and tedRemoteIfAddrTable both use an arbitrary index to distinguish between the different IP addresses on a given link.  Is there a reason why we can't just use the address type and address as index fields instead?  That would guarantee, for a given set of IP addresses, the ordering of rows in the table is entirely predictable. 

Thanks, 

Ben 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of labn - Lou Berger
Sent: 18 April 2011 20:19
To: CCAMP
Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib

Lou (and Deborah)

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Fri, 22 Apr 2011 09:50:53 +0900

Hi, Wenhu,

Thank you for your comments.

I agree the SYNTAX of TCs should be updated to take into account IS-IS, so,
I think it will be changed to Octet String (O..20). 

Also, the Reference will be revised to include ISIS.

Thank you,
Masanori

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: Tuesday, April 19, 2011 9:18 PM
> To: [email-masked]
> Cc: OSPF WG List; CCAMP
> Subject: Re: [OSPF] Fwd: [CCAMP] 2nd WG last call on
> draft-ietf-ccamp-gmpls-ted-mib
> 
> Authors,
> > For ISIS, the area address is of variable length. Please refer to ISO
> 10589 2002 Figure 4 on page 16 and change the SYNTAX accordingly.
> >
> > FYI for those not subscribed to the CCAMP mailing list - Please consider
> reviewing this draft if you are involved with Traffic Engineering.
> > Thanks,
> > Acee
> >
> > Begin forwarded message:
> >
based
> on MIB Dr. review and discussion on the ccamp list.
> >
> on the MPLS, OSPF, and ISIS WG lists.  Please send comments to the CCAMP
> mailing list.
> >
> > Lou (and Deborah)

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Sun, 1 May 2011 09:50:17 +0900

Hi, Ben

Thank you for your comments.
I have my answer for your comments inline below.
If you have any comments, please let us know.

With best Regards,
Masanori

> *	The tedTable structure doesn't make it easy for network
> administrators to query just the TED entries that are learned from, say,
> OSPFv2 (rather than ISIS).  An easy fix for this would be to make the
primary
> index field the information source (OSPFv2, ISIS etc).  This would also
> make the interpretation of the syntax of the remaining index fields
> straightforward for MIB agents.

To simplify the index field, we define a new primary index (e.g. tedIndex)
and use it as index in the tedTable as below. Then, I think you have
accessibility to TE link information.  

tedEntry OBJECT-TYPE
    SYNTAX       TedEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
    "This entry contains TED information commonly utilized in both MPLS and
GMPLS."
   INDEX { tedIndex }
::= { tedTable 1 }

TedEntry ::= SEQUENCE {
    tedIndex                     Unsigned32,
    tedAreaId                    TedAreaIdTC,
    tedRouterId                  TedRouterIdTC,
    tedLinkStateId               TedLinkStateIdTC,
    tedLinkInformationSource     INTEGER,
    tedLinkInformationData       RowPointer,
    tedLinkState                 INTEGER,
    tedLinkType                  INTEGER,
    tedRouterIdAddrType          InetAddressType,
    tedRouterIdAddr              InetAddress,
    tedLinkIdAddrType            InetAddressType,
    tedLinkIdAddr                InetAddress,
    tedMetric                    Integer32,
    tedMaxBandwidth              Unsigned32,
    tedMaxReservableBandwidth    Unsigned32,
    tedUnreservedBandwidthPri0   Unsigned32,
    tedUnreservedBandwidthPri1   Unsigned32,
    tedUnreservedBandwidthPri2   Unsigned32,
    tedUnreservedBandwidthPri3   Unsigned32,
    tedUnreservedBandwidthPri4   Unsigned32,
    tedUnreservedBandwidthPri5   Unsigned32,
    tedUnreservedBandwidthPri6   Unsigned32,
    tedUnreservedBandwidthPri7   Unsigned32,
    tedAdministrativeGroup       Integer32,
    tedLocalId                   Integer32,
    tedRemoteId                  Integer32,
    tedLinkProtectionType        BITS
    }

> *	The tedLocalIfAddrTable and tedRemoteIfAddrTable both use an
> arbitrary index to distinguish between the different IP addresses on a
given
> link.  Is there a reason why we can't just use the address type and
address
> as index fields instead?  That would guarantee, for a given set of IP
> addresses, the ordering of rows in the table is entirely predictable.

As you know, note that tedLocalIfAddrTable and tedRemoteIfAddrTable are
independently defined, because the Interface IP Address sub-TLV may appear
more than once within the same Link-TLV. Therefore, if the address type and
the address are used as index, another arbitrary index, such as tedIndex,
would be also needed to represent the relationship with tedTable as below,

tedLocalIfAddrTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF TedLocalIfAddrEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
      "This table contains the IP address information of a local TE link."
::= { tedObjects 2 }

tedLocalIfAddrEntry OBJECT-TYPE
    SYNTAX       TedLocalIfAddrEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
      "This entry contains the IP address information of the local TE link."
    INDEX { tedIndex, tedLocalifAddr }
::= { tedLocalIfAddrTable 1 }

TedLocalIfAddrEntry ::= SEQUENCE {
    tedLocalIfAddrType    InetAddressType,
    tedLocalIfAddr        InetAddress
    }

tedLocalIfAddrType OBJECT-TYPE
    SYNTAX       InetAddressType
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
"This object indicates the address type of the local TE link. Only values
unknown(0), ipv4(1) or ipv6(2) have to be supported." 
::= { tedLocalIfAddrEntry 2 }

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Wright
> Sent: Thursday, April 21, 2011 6:32 PM
> To: CCAMP
> Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> 
> Hi Masanori et al,
> 
> * 	I agree with Wenhu's comments on the OSPF mailing list - we need
> to update the Textual Conventions to take into account ISIS syntax.
> 
> *	The tedTable structure doesn't make it easy for network
> administrators to query just the TED entries that are learned from, say,
> OSPFv2 (rather than ISIS).  An easy fix for this would be to make the
primary
> index field the information source (OSPFv2, ISIS etc).  This would also
> make the interpretation of the syntax of the remaining index fields
> straightforward for MIB agents.
> 
> *	The tedLocalIfAddrTable and tedRemoteIfAddrTable both use an
> arbitrary index to distinguish between the different IP addresses on a
given
> link.  Is there a reason why we can't just use the address type and
address
> as index fields instead?  That would guarantee, for a given set of IP
> addresses, the ordering of rows in the table is entirely predictable.
> 
> Thanks,
> 
> Ben