The MPLS WG Archive

["Martin Dubuc" <dubuc.consulting@rogers.com>]

----- Original Message -----
From: "Martin Dubuc" <dubuc.consulting@rogers.com>
To: "Dave Thaler" <dthaler@windows.microsoft.com>
Cc: "Thomas Nadeau" <tnadeau@cisco.com>; "Bert Wijnen" <bwijnen@lucent.com>;
"Sudheer Dharanikota" <sudheer@ieee.org>; "Jonathan Lang" <jplang@ieee.org>;
"Loa Andersson" <loa@pi.se>
Sent: Monday, October 20, 2003 10:33 PM
Subject: Re: DT's review of draft-ietf-mpls-telink-mib-04.txt


> Dave,
>
> See comments below. I will make an update to the document to address your
> comments.
>
> Martin
>
> ----- Original Message -----
> From: "Dave Thaler" <dthaler@windows.microsoft.com>
> To: <tnadeau@cisco.com>; "Martin Dubuc" <dubuc.consulting@rogers.com>;
> "Wijnen, Bert (Bert)" <bwijnen@lucent.com>; <sudheer@ieee.org>;
> <jplang@ieee.org>
> Sent: Monday, October 06, 2003 10:11 PM
> Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
>
>
> Sorry for the delay, but I've been reading a bunch of relevant documents
> so I can help resolve the issue.  Besides the mpls-telink-mib and the
> tewg-mib, I've now read all of the following in entirety:
>
> [RFC2702] "Requirements for Traffic Engineering Over MPLS"
> [OSPF-TE] "Traffic Engineering Extensions to OSPF Version 2"
> [LSP-HIER] "LSP Hierarchy with Generalized MPLS TE"
> [BUNDLE] "Link Bundling in MPLS Traffic Engineering"
> [GMPLS-ROUTING] "Routing Extensions in Support of Generalized MPLS"
>
> as well as some portions of other documents such as [MPLS-TE-STD-MIB]
> and [GMPLS-ARCH].
>
> Even after all that, the address model was not really cleared up for me.
> [LSP-HIER], [OSPF-TE], and [BUNDLE] all contain language related
> to the local and remote IP address.
>
> I'm back to my original question about:
> > it is unclear whether the IP addresses are those used for
> > encapsulation (i.e. like MAC addresses from the point of
> > view of the teLink interface), or those assigned to the inside.
> > I'm assuming the former, since the latter would definitely be
> redundant
> > with the inet address table like on any other interface.
>
> In the email below I had assumed the former.  After reading the
> documents above, I'm more inclined to believe it's the latter.
> Can someone confirm this?  Put another way:
>
> Q: If you look in the ipAddrTable for the corresponding entry for the IP
> address in a teLinkLocalIpAddr object on a numbered TE link, what is the
> value of ipAdEntIfIndex?  What is the relationship of that interface to
> the TE link?
> (e.g. in the example on page 12, is it the ifIndex of the mpls
> interface,
> the teLink interface, or the opticalTransport interface?  Previously I
> had assumed the answer would be the opticalTransport interface, but now
> I'm more inclined to believe it's one of the others in which case
> Thomas'
> summary of my misunderstanding below would be more or less accurate.
> In any case, none of the documents listed above give a clear answer to
> this question.)
>
> [Martin] You are right, it is the latter. The IP address is the IP address
> of
> the teLink interface. It is redundant with ipAddrTable, but we would like
> not
> to have to rely on the presence of ipAddrTable to get access to this
> information.
>
>
> In addition, I will add the following items to my review of the
> document:
>
> 1) teLinkIncomingIfId
>     SYNTAX InterfaceIndexOrZero
> Problem: RFC2863 defines InterfaceIndex as
> "A unique value, greater than zero, for each interface or interface
> sub-layer in the managed system."  However, this is a number which is
> not for an interface _in the managed system_.  Hence the use of this
> TC is inappropriate.  I believe it should instead use
>     SYNTAX Integer32 (0..2147483647)
> so that management stations will not look for a corresponding entry
> in the ifTable.
>
> [Martin] I can make this change.
>
>
> 2) teLinkOutgoingIfId
>        "If the link is unnumbered, the outgoing interface identifier is
>         set to the outgoing interface identifier chosen for the TE link
>         by the advertising LSR. For numbered links, the address is
>         stored in the teLinkLocalIpAddr instead."
> It is unclear what is meant by "instead".  If the value here should be
> 0,
> say that explicitly, as in:
>        "If the link is unnumbered, the outgoing interface identifier is
>         set to the outgoing interface identifier chosen for the TE link
>         by the advertising LSR. If the link is numbered, the value is
> 0."
> (same comment on teLinkIncomingIfId)
> Also maybe add DEFVAL {0} ?
>
> [Martin] I can be explicit as you suggest. I don't think we should
> assume a default value here. I can't really tell if it is more likely
> that implementor will implement numbered or unnumbered
> TE links.
>
>
> 3) For teLinkAddressType, teLinkLocalIpAddr, teLinkRemoteIpAddr,
> add DEFVALs for unknown(0), ''H, and ''H, respectively?
>
> [Martin] I don't think we should assume a default value here either.
>
>
> -Dave
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Wednesday, September 24, 2003 12:11 PM
> > To: Dave Thaler; 'Martin Dubuc'; 'Wijnen, Bert (Bert)';
> sudheer@ieee.org;
> > jplang@ieee.org
> > Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> >
> >
> > Hi All,
> >
> > I wanted to summarize the conversation
> > we have been having to try to come to closure
> > on the points brought forth by Dave. The issue
> > raised by Dave was that he thought the TE-LINK MIB
> > needed to extend RFC2863 rather than re-define
> > some objects. I think this came because he misunderstood
> > how the TE-LINK MIB was supposed to be used. The TE-LINK
> > MIB is used to manage configured TE links/interfaces/
> > and or link-bundles, irrespective of whether
> > any TE tunnels are riding over those entities.
> > So it seems that the TE-LINK MIB's constructs
> > are required and have different application
> > than those defined in RFC2863.
> >
> > The actions as I see it are that we need
> > to improve the description/overview of the TE-LINK
> > MIB so that this misunderstanding does not occur
> > in the future, but that the objects that are
> > presently in the TE-LINK MIB should remain.
> > If we all agree, I will post this as a response
> > to Dave's original posting on the mailing list.
> >
> > --Tom
> >
> >
> > >-----Original Message-----
> > >From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> > >Sent: Tuesday, September 23, 2003 5:35 PM
> > >To: Martin Dubuc; Wijnen, Bert (Bert); tnadeau@cisco.com;
> > >sudheer@ieee.org; jplang@ieee.org
> > >Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> > >
> > >
> > >Martin,
> > >
> > >I didn't understand that scenario, can you elaborate?
> > >If it's not a tunnel, what would the values of teLinkLocalIpAddr and
> > >teLinkRemoteIpAddr be?  From my reading of the doc, and a
> > >search through
> > >[GMPLS-ARCH], it looks to be like they're only non-empty for tunnels.
> > >(If this is not the intent then the documents need to be much more
> > >clear.)
> > >
> > >-Dave
> > >
> > >> -----Original Message-----
> > >> From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> > >> Sent: Tuesday, September 23, 2003 4:34 AM
> > >> To: Dave Thaler; Wijnen, Bert (Bert); tnadeau@cisco.com;
> > >sudheer@ieee.org;
> > >> jplang@ieee.org
> > >> Subject: Re: DT's review of draft-ietf-mpls-telink-mib-04.txt
> > >>
> > >> Dave,
> > >>
> > >> Even though the teLinkRowStatus, teLinkLocalIpAddr and
> > >teLinkRemoteIpAddr
> > >> may be redundant when tunnels are involved in the definition of TE
> > >links,
> > >> we
> > >> cannot remove these objects from the MIB because when entities that
> > >are
> > >> not
> > >> tunnels are used in the construction of TE links, this
> > >information may
> > >not
> > >> be captured anywhere (for instance, this can be the case for
> optical
> > >> networks).
> > >>
> > >> Best regards,
> > >>
> > >> Martin
> > >>
> > >> ----- Original Message -----
> > >> From: "Dave Thaler" <dthaler@windows.microsoft.com>
> > >> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>;
> > >> <dubuc.consulting@rogers.com>; <tnadeau@cisco.com>;
> > ><sudheer@ieee.org>;
> > >> <jplang@ieee.org>
> > >> Sent: Saturday, September 13, 2003 4:16 PM
> > >> Subject: DT's review of draft-ietf-mpls-telink-mib-04.txt
> > >>
> > >>
> > >> I've completed a review of draft-ietf-tewg-mib-06.txt at Bert's
> > >request,
> > >> concentrating on the relationships with the Interfaces MIB and the
> > >> IPv4 Tunnel MIB.
> > >>
> > >> Relationship with IF-MIB:
> > >>
> > >>  This is in pretty good shape.  Section 8 meets most of the
> > >requiements
> > >>  outlined in section 4 of RFC 2863.  The only requirements not met
> > >> appear
> > >>  to be the ones regarding ifRcvAddressTable and the conditions (if
> > >any)
> > >>  relating to ifXxxOctets with respect to frames with errors.
> > >>
> > >> Relationship with IPv4 Tunnel MIB:
> > >>
> > >>  This MIB has no text on the relationship with the IPv4 Tunnel MIB,
> > >and
> > >>  does not explain why it does not extend that MIB.  Of course this
> > >>  document is not IPv4-specific, but we know we need a corresponding
> > >IPv6
> > >>
> > >>  Tunnel MIB (or perhaps a generic IP Tunnel MIB) anyway.  Given
> that,
> > >it
> > >>
> > >>  is unclear whether there is sufficient justification (certainly
> none
> > >in
> > >>
> > >>  the draft) to not extend it/them.
> > >>
> > >>  The argument to extend it/them is twofold:
> > >>  a) you are consistent with other tunnel management schemes, rather
> > >than
> > >>     confusing people with multiple conflicting schemes, and
> > >>  b) that you get a number of things currently missing,
> specifically:
> > >>     tunnelIfHopLimit, tunnelIfSecurity, tunnelConfigEncapsMethod,
> > >>     tunnelIfTOS, and the ability to look up a tunnel index by its
> > >>     endpoints.
> > >>
> > >>  teLinkRowStatus - redundant with tunnelConfigStatus?
> > >>
> > >>  The real issue is how to handle the teLinkLocalIpAddr and
> > >>  teLinkRemoteIpAddr.  The 'numbered' and 'unnumbered' link
> > >terminology
> > >>  appears to come from [GMPLS-ARCH], but from a quick glance at that
> > >>  document, is is unclear whether the IP addresses are those used
> for
> > >>  encapsulation (i.e. like MAC addresses from the point of view of
> the
> > >>  teLink interface), or those assigned to the inside.  I'm
> > >assuming the
> > >>  former, since the latter would definitely be redundant with the
> inet
> > >>  address table like on any other interface.
> > >>
> > >>  So there are currently three cases, as I understand it:
> > >>  1) it's tunneling using IPv4 addresses.  In this case I see
> > >no reason
> > >>     to not extend the IPv4 Tunnel MIB.  teLinkLocalIpAddr
> > >>     and teLinkRemoteIpAddr are redundant with
> > >tunnelIfLocalAddress and
> > >>     tunnelIfRemoteAddress, respectively.
> > >>  2) it's tunneling using IPv6 addresses.  In this case it can
> > >>     extend an IPv6 Tunnel MIB (or perhaps an Inet Tunnel MIB).
> > >>     teLinkLocalIpAddr and teLinkRemoteIpAddr would be redundant
> with
> > >>     objects in that MIB.
> > >>  3) it's not tunneling using either one.  In this case
> > >>     teLinkLocalIpAddr and teLinkRemoteIpAddr are empty.
> > >>
> > >> Hence, I'd propose the following actions:
> > >>  1) this document remove the teLinkLocalIpAddr and
> teLinkRemoteIpAddr
> > >>     objects (leaving teLinkAddressType is fine).
> > >>  2) we (the OPS area) write the IPv6 or Inet Tunnel MIB asap.
> > >>     I had volunteered for this but it was lower priority.
> > >If this MIB
> > >>     takes a dependency on it, I think it could be done fairly
> quickly
> > >>     since it's just adapting the existing RFC 2667.
> > >>     In that document we define a new tunnelIfEncapsMethod for MPLS.
> > >>  3) If the unnumbered case does not do tunneling over IP, then an
> > >>     ifType of teLink(200) could identify this case (only).
> > >>     Numbered links would use an ifType of tunnel, with an encaps
> > >>     method of mpls.  This would give the benefits of using the
> tunnel
> > >> mib.
> > >>
> > >> -Dave
> > >>
> > >
> >
>
>