The MPLS WG Archive

["Manikantan Srinivasan" <manis@futsoft.com>]

Dear David

Thanks for your replies.

Yes, an enterprise MIB is a good suggestion to use if the
Extended tunnel id is different from the Sender's IP Address.
and I would take that way.

Thanks again.

regards
mani

> -----Original Message-----
> From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David
> Charlap
> Sent: Monday, October 14, 2002 3:33 PM
> To: IETF MPLS List
> Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt
>
>
> Manikantan Srinivasan wrote:
> >
> > Regarding Extended Tunnel ID (in SESSION object), I agree from your
> > clarification, that this need not be the ingress address. Might be zero.
> > But if this is non-zero, can we assume that it will be sender
> IP Address?
>
> According to RSVP (RFC 2205) and RSVP-TE (RFC 3209), you can't.  The
> extended tunnel ID may be any value that uniquely identifies the sender.
>   By convention, the sender's IP address is used, because that's the
> easiest way to guarantee uniqueness.
>
> In actual practice, I think it's safe to assume that non-zero values
> will match an IP address on the sender node.  I don't know if it's safe
> to assume that it will match the address used in the SENDER_TEMPLATE
> object, however.
>
> > Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt
> > be extended to contain the 5 tuples you have mentioned?
>
> I haven't read the draft very thoroughly yet, but I think extended
> tunnel ID should be present in the LSP subobject.  Otherwise the draft
> will impose new restrictions on the rest of RSVP-TE.
>
> > As you rightly said, the current MIBs does not have the support for
> > the 5 tuples to determine a unique LSP in RSVP-TE context. Do you
> > think it as worthwhile to add these in the MIB for total solution?
>
> This has been discussed in the working group on many occasions in
> the past.
>
> The group's consensus is that nobody (or almost nobody) will want to use
> and extended tunnel ID that differs from the sender address, so there's
> no need to accommodate this feature in the MIB.
>
> I disagree, but mine is a minority opinion.  I doubt anybody will be
> changing the MIB at this point, especially since it's a key field that
> would have to change.
>
> If you think this is an important thing to have in the MIB, I think the
> best thing to do is to implement a private MIB in addition to the
> standard one.  Your private one can accommodate the extra key field.
>
> -- David
>