Subject: Re: [mpls] Comments: poll on draft-vkst-mpls-tp-te-mib-00.txt

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 9 May 2011 14:58:10 -0400

Hi All,

Yes, the mplsTunnelExtTable is meant for Sparse augmenting the
mplsTunnelTable. i.e. Entries will exist in
the mplsTunnelExtTable only for MPLS_TP tunnels that are based on global ID
and Node ID and/or ICC-ID.
This mplsTunnelExtTable is similar to gmplsTunnelEntry specified in RFC4802.

We understand that gmplsTunnelTable is also sparse augmented only for gmpls
Tunnels.
We understand that RFC4802 is not doing any redefinition of the indices.
Similarly, mplsTunnelExtTable is not meant for redefining the indices.
mplsTunnelExtTable uses the same indices as mplsTunnelTable. Only the
meaning of them is interpreted based on mpls-tp-identifier.
Is it possible to explain the reason behind your question "would the indexes
redefined for TP be acceptable" ?

Cheers,
Venkat.
------------------------------

   - *To*: <loa at pi.nu <[email-masked]>>, <mpls at
ietf.org<[email-masked]>
   - *Subject*: Re: [mpls] Comments: poll on
   draft-vkst-mpls-tp-te-mib-00.txt
   - *From*: "Joan Cucchiara" <jcucchiara at
mindspring.com<[email-masked]>
   - *Date*: Sun, 8 May 2011 17:30:57 -0400
   - *Cc*: rcallon at juniper.net <[email-masked]>,
draft-vkst-mpls-tp-te-mib
   at tools.ietf.org <[email-masked]>
   - *Delivered-to*: mpls at ietfa.amsl.com <[email-masked]>
   - *Domainkey-signature*: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=
   mindspring.com;
   b=cohHsKaK9SRjtdZzjKzUL1x7XcAmurB4x7w9CJ6q/1vFXjIcgOVzAoXTG5+lgANy;
   h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
   - *List-archive*: <http://www.ietf.org/mail-archive/web/mpls>
   - *List-help*:
<mailto:[email-masked]?subject=help<[email-masked]?subject=help>
   - *List-id*: Multi-Protocol Label Switching WG <mpls.ietf.org>
   - *List-post*: <mailto:[email-masked] <[email-masked]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/mpls>, <
   mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>
   - *List-unsubscribe*: <https://www.ietf.org/mailman/options/mpls>, <
   mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>
   - *References*: <833768e1a607dbafe4f3463989757b1a.squirrel at
pi.nu<[email-masked]>

------------------------------

Hi,

While there seems to be a benefit to keeping all the "mpls" tunnels in one
table

(i.e. the mplsTunnelTable in RFC3812).   I have a concern about
what seems to be a redefinition of the indexes for the mplsTunnelTable.

This draft contains a table:  mplsTunnelExtTable which
AUGMENTS the mplsTunnelTable in RFC3812.

The indexes are:
       INDEX {
             mplsTunnelIndex,
              mplsTunnelInstance,
              mplsTunnelIngressLSRId,
              mplsTunnelEgressLSRId
           }

The above indexes seem to be redefined in this draft (quoting from the
DESCRIPTION clause):

        "As per MPLS-TP Identifiers draft,  LSP_ID is

           Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
           Dst-Tunnel_Num::LSP_Num for IP operator and

           Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num
           for ICC operator,

           mplsTunnelTable is reused for forming the LSP_ID as follows,

           Source Tunnel_Num is mapped with mplsTunnelIndex,
           Source node identifier is mapped with
           mplsTunnelIngressLSRId, Destination node identifier is
           mapped with mplsTunnelEgressLSRId LSP_Num is mapped with
           mplsTunnelInstance.

           Source Global identifier/ICC and Destination
           Global identifier/ICC are maintained in the
           mplsNodeConfigTable and mplsNodeConfigLocalNum is used to
           create an entry in mplsTunnelTable."

Additionally,  one now needs to first configure an entry in the
mplsNodeConfigTable in this draft, then
one can create an entry in the mplsTunnelTable (RFC3812).

Adrian Farrel suggested that the mplsTunnelExtTable in this draft was probably
meant to have sparse-augments relationship to the mplsTunnelTable. While I
would agree that

this is probably the case, even with a
sparse-augments relationship, would the indexes redefined for TP be
acceptable?   I think not, although (as mentioned at the beginning), I
do see an advantage for having all mpls-based Tunnels in one table.

Would definitely like to see this discussed prior to accepting this draft
was

a WG group document.

Thank you,
 -Joan

----- Original Message ----- From: <loa at pi.nu>

To: <mpls at ietf.org>
Cc: <rcallon at juniper.net>; <draft-vkst-mpls-tp-te-mib at tools.ietf.org>
Sent: Tuesday, May 03, 2011 1:47 PM
Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

Working Group,

this is to start a two week poll on making

draft-vkst-mpls-tp-te-mib-00.txt

an mpls working group document.

If you support the document becoming a working group document
please respond to this poll with "yes/support"

If you do not support the document becoming a working group
document please respond to this poll with "no/do not support"
and at the same time give the technical reasons why you are
not supporting the document.

If you have technical comments or in any other way want to
discuss the document, please send these comments to the mpls
working group mailing list, but with another subject than what
is on this mail.

The poll ends 2011-05-18.

/Loa

_______________________________________________
mpls mailing list
mpls at ietf.org

https://www.ietf.org/mailman/listinfo/mpls