The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Forwarding to MPLS WG list

Thanks,
Bert 

-----Original Message-----
From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
Sent: dinsdag 7 oktober 2003 4:12
To: tnadeau@cisco.com; Martin Dubuc; Wijnen, Bert (Bert);
sudheer@ieee.org; jplang@ieee.org
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.)

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.

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

3) For teLinkAddressType, teLinkLocalIpAddr, teLinkRemoteIpAddr,
add DEFVALs for unknown(0), ''H, and ''H, respectively?

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