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

[Tomohiro Otani <[e-mail]>]

Lou,

Yes, that's right.
We will update it shortly with Tom.

Acee, thanks a lot. We can proceed it finally.

Regards,

tomo


<[e-mail]> の、
   "Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib" において、
   "Lou Berger <[e-mail]>"さんは書きました：

> Acee,
> 	Glad to hear this.
> 
> Authors,
> 	Please correct me if I'm mistaken, but I think this was the last open
> issue on the document and that it'll be ready to move forward once the
> update is submitted.  Is this correct?
> 
> Much thanks,
> Lou
> 
> On 3/7/2012 5:56 AM, Acee Lindem wrote:
> > Hi Masanori,
> > Based on our discussion off-list and the definition of tedLinkIndex, this satisfies my concerns 
with the draft.
> > 
> >>> tedLinkIndex OBJECT-TYPE
> >>>   SYNTAX       OCTET STRING (SIZE (0..8))
> >>>   MAX-ACCESS   not-accessible
> >>>   STATUS       current
> >>>   DESCRIPTION
> >>>     "This index indicates a unique index or arbitrary value to
> >>> distinguish between multiple parallel links between routers.
> >>> If OSPF is used, this object contains the value of ospfLsdbID as
> >>> unique index. If ISIS is used, this object represents the value of
> >>> isisLSPID as unique index.
> >>> If a locally configured link is used, this object represents an
> >>> arbitrary value which is locally defined in a router."
> >>> ::= { tedEntry XX }
> >>> ------
> > 
> > 
> > Thanks,
> > Acee
> > 
> > On Mar 7, 2012, at 2:34 AM, Masanori Miyazawa wrote:
> > 
> >> Hi, Acee
> >>
> >> Regarding your comments about the definition of index, we think we have to
> >> redefine new indexes in tedTable. 
> >> Here are my idea. If you have no additional comments, we will modify them
> >> and post the updated draft.
> >>
> >> 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 { tedLinkInformationSource, tedLinkRouterId, tedLinkRemoteRouterID,
> >> tedLinkIndex}
> >> ::= { tedTable 1 }
> >>
> >> tedLinkInformationSource  ->  ospf, isis etc
> >> tedLinkRouterId  ->  the router ID of the node who originated information
> >> about this link
> >> tedLinkRemoteRouterId  -> the router at the remote end of the link 
> >> tedLinkIndex    -> This index indicates a unique index or arbitrary value to
> >> distinguish between multiple parallel links between routers. If OSPF is
> >> used, this object contains the value of ospfLsdbID as unique index. If ISIS
> >> is used, this object represents the value of isisLSPID as unique index.If a
> >> locally configured link is used, this object represents an arbitrary value
> >> which is locally defined in a router."
> >>
> >> Regards,
> >> Masanori
> >>
> >>> -----Original Message-----
> >>> From: Acee Lindem [mailto:[e-mail]]
> >>> Sent: Monday, May 02, 2011 4:32 AM
> >>> To: Masanori Miyazawa
> >>> Cc: Ben Wright; CCAMP
> >>> Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> >>>
> >>> Hi Masanori,
> >>>
> >>>
> >>> On Apr 30, 2011, at 8:50 PM, Masanori Miyazawa wrote:
> >>>
> >>>> 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.
> >>>
> >>>
> >>> What is the definition of the this index? You don't want to leave it up
> >>> to the implementation as this will lead to different semantics.
> >>>
> >>> Also, you should allow 0 in the range for Area IDs as 0 is certainly a
> >> valid
> >>> OSPF area ID.
> >>>
> >>>
> >>>   TedAreaIdTC ::= TEXTUAL-CONVENTION
> >>>          DISPLAY-HINT "d"
> >>>          STATUS       current
> >>>          DESCRIPTION
> >>>             "The area identifier of the IGP. If OSPF is used to
> >>>   advertise LSA, this represents an ospfArea. If ISIS is used, this
> >>>   represents an area address."
> >>>          SYNTAX       Unsigned32 (1..4294967295)
> >>>
> >>> Should be:
> >>>          SYNTAX       Unsigned32 (0..4294967295)
> >>>
> >>>
> >>> Thanks,
> >>> Acee
> >>>
> >>>
> >>>>
> >>>> 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 }
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] [mailto:[e-mail]] 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 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: [e-mail] [mailto:[e-mail]] 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
> >>>>>
> >>>>> 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)
> >>>>> _______________________________________________
> >>>>> CCAMP mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>> _______________________________________________
> >>>>> CCAMP mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>
> > 
> > 
> > 
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
>