Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

From: Eric Gray <[email-masked]>
Date: Tue, 9 Aug 2011 09:05:17 -0400

Forwarding in plain text...

________________________________

From: Spike Curtis [mailto:[email-masked]] 
Sent: Monday, August 08, 2011 5:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

Hi Venkat & all, 

I've read the draft and have a question and then some comments.  I'm happy to be of assistance with any of what follows, and/or with working on other MIB drafts that we need to fill out the gaps identified in draft-ietf-mpls-tp-mib-management-overview.

MPLS-TP Identifiers:

I understand that one of the purposes of this draft is to allow configuration using MPLS-TP identifiers.  Presumably, there are at least three ways this could be accomplished:

1.     Define a brand new tunnel table for MPLS-TP, based on the mplsTunnelTable, but with the MPLS-TP identifiers as indices.

2.     Redefine the existing mplsTunnelTable indexing, adding GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" values to allow back-compatibility.

3.     Create a separate set of tables which maps the old identifiers to the new MPLS-TP identifiers.

This draft takes the third strategy, but it's not immediately clear to me why this is preferable to the other two. (2) seems the least complicated because it does away extra mapping and inverse mapping tables.  It's also difficult to guarantee that local identifiers (which don't have configuration or signalling significance) will not change in the case of graceful restart or configuration replay.  Was option (3) chosen to avoid back-compatibility issues, or for other reasons?

A comment on tunnels:

I'd like to clarify how unidirectional, associated bidirectional and co-routed bidirectional paths are modelled in the MIB, and how exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields.  My preference is as follows.

*         Unidirectional LSPs in MPLS-TP are very similar to "normal" MPLS, but with different identifiers.  Tunnels of this type do not have any entries in the mplsTunnelExtTable.

*         In associated bidirectional LSPs, the transport directions are set up and monitored independently, so each transport direction should be a separate row in the mplsTunnelTable.

*         In co-routed bidirectional LSPs, both transport directions are set up and monitored together.  This means we should have only one row in the mplsTunnelTable to represent a tunnel of this type.  This is not how the draft is currently structured, where the example in Section 9 creates two rows in the mplsTunnelTable.

About gaps:

Lastly, I think the MIB is still missing some configuration that we'll need in order to satisfy MPLS-TP requirements.  These include

*         Bidirectional tunnels with asymmetric resource requirements

*         OAM configuration.  Presumably this will be a reference to yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM profiles.

Let me know if I can be of further assistance.

Cheers,

Spike

________________________________

*	To: i-d-announce at ietf.org <mailto:[email-masked]>  
*	Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt 
*	From: internet-drafts at ietf.org <mailto:[email-masked]>  
*	Date: Fri, 17 Jun 2011 07:24:45 -0700 
*	Cc: mpls at ietf.org <mailto:[email-masked]>  
*	Delivered-to: mpls at ietfa.amsl.com <mailto:[email-masked]>  
*	List-archive: <http://www.ietf.org/mail-archive/web/mpls> 
*	List-help: <mailto:[email-masked]?subject=help> 
*	List-id: Multi-Protocol Label Switching WG <mpls.ietf.org> 
*	List-post: <mailto:[email-masked]> 
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:[email-masked]?subject=subscribe> 
*	List-unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:[email-masked]?subject=unsubscribe>

________________________________

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.
 
        Title           : MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)
        Author(s)       : Venkatesan Mahalingam
                          Kannan KV Sampath
                          Huawei Technologies
                          Thomas D. Nadeau
        Filename        : draft-ietf-mpls-tp-te-mib-00.txt
        Pages           : 39
        Date            : 2011-06-17
 
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects of Tunnels, Identifiers,
   Label Switch Router and Textual conventions for Multiprotocol Label
   Switching (MPLS) based Transport Profile (TP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt
________________________________

*	Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 <http://www.ietf.org/mail-archive/web/mpls/current/msg06570.html>  
*	Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 <http://www.ietf.org/mail-archive/web/mpls/current/msg06572.html>  
*	Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 <http://www.ietf.org/mail-archive/web/mpls/current/msg06570.html>  
*	Next by thread: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-00.txt <http://www.ietf.org/mail-archive/web/mpls/current/msg06573.html>  
*	Index(es): 

	*	Date <http://www.ietf.org/mail-archive/web/mpls/current/maillist.html#06571>  
	*	Thread <http://www.ietf.org/mail-archive/web/mpls/current/threads.html#06571> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 9 Aug 2011 10:40:11 -0400

Spike,

Wanted to comment on your 3 suggestions for indexing.

Suggestion #1 is also my preference.   This is the most straightforward and 
least complex
design in my opinion.    Additionally, the CLI, Web, NMS, etc could display 
both MPLS
Tunnels and MPLS-TP Tunnels in the same table if wanted.   So the complexity 
of the
mapping is not in the MIB (or agent).

Suggestion #2 is not allowed because redefining indices is not allowed in 
the SMI.
(We had a few emails about this during the time that the MIB was being 
adopted by the WG.)

Suggestion #3:  allows MPLS and MPLS-TP tunnels to exist in the same table.
While this goal may have some benefits, the design to accomplish the goal is 
more complex than #1
as you point out.  I have asked the authors to ensure that there are no 
backwards compatibility issues
with the design  so that the MPLS Tunnel Table is already populated
and then MPLS-TP Tunnel indices are created such that they do not conflict 
with already
existing tunnel indices.    In a nutshell, the problem I have with this 
design is that there are 2 ways of creating indices
for the same Table, one which is legacy and has been around since 2004 and 
now a second way.

There may be a #4 Suggestion which is to implement design #1 but also have 
an additional (optional?) table
which is a superset of Tunnels, this could be indexed by a type field.

Thanks,
   -Joan

----- Original Message ----- 
From: "Eric Gray" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 09, 2011 9:05 AM
Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

> I've read the draft and have a question and then some comments.  I'm happy 
> to be of assistance with any of what follows, and/or with working on other 
> MIB drafts that we need to fill out the gaps identified in 
> draft-ietf-mpls-tp-mib-management-overview.
>
>
>
>
>
> MPLS-TP Identifiers:
>
> I understand that one of the purposes of this draft is to allow 
> configuration using MPLS-TP identifiers.  Presumably, there are at least 
> three ways this could be accomplished:
>
> 1.     Define a brand new tunnel table for MPLS-TP, based on the 
> mplsTunnelTable, but with the MPLS-TP identifiers as indices.
>
> 2.     Redefine the existing mplsTunnelTable indexing, adding GlobalID and 
> ICC for ingress and egress nodes, and using 0 as "not used" values to 
> allow back-compatibility.
>
> This draft takes the third strategy, but it's not immediately clear to me 
> why this is preferable to the other two. (2) seems the least complicated 
> because it does away extra mapping and inverse mapping tables.  It's also 
> difficult to guarantee that local identifiers (which don't have 
> configuration or signalling significance) will not change in the case of 
> graceful restart or configuration replay.  Was option (3) chosen to avoid 
> back-compatibility issues, or for other reasons?
>
>
>
> A comment on tunnels:
>
> I'd like to clarify how unidirectional, associated bidirectional and 
> co-routed bidirectional paths are modelled in the MIB, and how exactly the 
> MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. 
> My preference is as follows.
>
>
>
> *         Unidirectional LSPs in MPLS-TP are very similar to "normal" 
> MPLS, but with different identifiers.  Tunnels of this type do not have 
> any entries in the mplsTunnelExtTable.
>
>
>
> *         In associated bidirectional LSPs, the transport directions are 
> set up and monitored independently, so each transport direction should be 
> a separate row in the mplsTunnelTable.
>
>
>
> *         In co-routed bidirectional LSPs, both transport directions are 
> set up and monitored together.  This means we should have only one row in 
> the mplsTunnelTable to represent a tunnel of this type.  This is not how 
> the draft is currently structured, where the example in Section 9 creates 
> two rows in the mplsTunnelTable.
>
>
>
> About gaps:
>
> Lastly, I think the MIB is still missing some configuration that we'll 
> need in order to satisfy MPLS-TP requirements.  These include
>
> *         OAM configuration.  Presumably this will be a reference to 
> yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM 
> profiles.
>
>
>
> * List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, 
> <mailto:[email-masked]?subject=subscribe>
> * List-unsubscribe: <https://www.ietf.org/mailman/options/mpls>, 
> <mailto:[email-masked]?subject=unsubscribe>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the Multiprotocol Label 
> Switching Working Group of the IETF.
>
> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's 
> Statement about IPR related to draft-ietf-mpls-loss-delay-03 
> <http://www.ietf.org/mail-archive/web/mpls/current/msg06570.html>
> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's 
> Statement about IPR related to RFC 5919 
> <http://www.ietf.org/mail-archive/web/mpls/current/msg06572.html>
> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., 
> Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 
> <http://www.ietf.org/mail-archive/web/mpls/current/msg06570.html>
> * Next by thread: [mpls] I-D Action: 
> draft-ietf-mpls-ldp-ip-pw-capability-00.txt 
> <http://www.ietf.org/mail-archive/web/mpls/current/msg06573.html>
> * Index(es):
>
> * Date 
> <http://www.ietf.org/mail-archive/web/mpls/current/maillist.html#06571>
> * Thread 
> <http://www.ietf.org/mail-archive/web/mpls/current/threads.html#06571>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 9 Aug 2011 10:47:05 -0400

On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote:

> Suggestion #1 is also my preference.   This is the most straightforward and least complex
> design in my opinion.    Additionally, the CLI, Web, NMS, etc could display both MPLS
> Tunnels and MPLS-TP Tunnels in the same table if wanted.   So the complexity of the

	That is the idea we were after. We want a new table that shows "TP tunnels" 
as a (proper) subset of those defined globally. That is, the indexing "extends" those in
the MplsTunnelTable.

> Suggestion #2 is not allowed because redefining indices is not allowed in the SMI.
> (We had a few emails about this during the time that the MIB was being adopted by the WG.)

	Spot on. The only way to take this approach is to deprecate RFC3811, 12, and 13 as 
well as the GMPLS and PWE3 MIB RFCs that are also based on these.

> While this goal may have some benefits, the design to accomplish the goal is more complex than #1
> as you point out.  I have asked the authors to ensure that there are no backwards compatibility issues
> and then MPLS-TP Tunnel indices are created such that they do not conflict with already
> existing tunnel indices.    In a nutshell, the problem I have with this design is that there are 2 ways of creating indices
> for the same Table, one which is legacy and has been around since 2004 and now a second way.

	Don't you get both "existing at the same time in the same table" by using the 'extends' relationship?

> There may be a #4 Suggestion which is to implement design #1 but also have an additional (optional?) table

	The MIB provides mapping tables *in addition to* the basic table that extends the MplsTunnelTable.
This is provided as a convenience for the E/NMS to speed table traversal/manipulation.

	--Tom

> 
> Thanks,
>  -Joan
> 
> 
> ----- Original Message ----- From: "Eric Gray" <[email-masked]>
> To: <[email-masked]>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 10 Aug 2011 10:26:13 -0400

----- Original Message ----- 
From: "Thomas Nadeau" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 09, 2011 10:47 AM
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

> This is provided as a convenience for the E/NMS to speed table 

Tom,

That wasn't clear (at least to me), could this be clarified in next rev?

Also, may be more beneficial to make these mapping tables optional -- not 
every vendor  will need to
implement them, since they are for E/NMS.

Thanks,
  -Joan

>>> I've read the draft and have a question and then some comments.  I'm 
>>> happy to be of assistance with any of what follows, and/or with working 
>>> on other MIB drafts that we need to fill out the gaps identified in 
>>> 2.     Redefine the existing mplsTunnelTable indexing, adding GlobalID 
>>> and ICC for ingress and egress nodes, and using 0 as "not used" values 
>>> to allow back-compatibility.
>>>
>>> This draft takes the third strategy, but it's not immediately clear to 
>>> me why this is preferable to the other two. (2) seems the least 
>>> complicated because it does away extra mapping and inverse mapping 
>>> tables.  It's also difficult to guarantee that local identifiers (which 
>>> don't have configuration or signalling significance) will not change in 
>>> the case of graceful restart or configuration replay.  Was option (3) 
>>> chosen to avoid back-compatibility issues, or for other reasons?
>>>
>>>
>>>
>>> A comment on tunnels:
>>>
>>> co-routed bidirectional paths are modelled in the MIB, and how exactly 
>>> the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB 
>>> fields. My preference is as follows.
>>>
>>>
>>>
>>> set up and monitored independently, so each transport direction should 
>>> be a separate row in the mplsTunnelTable.
>>>
>>>
>>>
>>> set up and monitored together.  This means we should have only one row 
>>> in the mplsTunnelTable to represent a tunnel of this type.  This is not 
>>> how the draft is currently structured, where the example in Section 9 
>>> creates two rows in the mplsTunnelTable.
>>>
>>>
>>>
>>> About gaps:
>>>
>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., 
>>> Ltd's Statement about IPR related to RFC 5919

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 10 Aug 2011 10:58:11 -0400

On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote:

> 
> ----- Original Message ----- From: "Thomas Nadeau" <[email-masked]>

	Yes, of course! 8)

> Also, may be more beneficial to make these mapping tables optional -- not every vendor  will need to

	That is possible, but as you know is up to the working group. It is my personal preference as a vendor of management applications, 
to avoid optional things where possible, as they are unlikely to ever get implemented on devices and make things more difficult for 
applications.

	--Tom

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 11 Aug 2011 11:49:36 -0400

Tom,

Thank you for adding additional info about how the mappping tables
should/could be used.

Of course, what working group wants is fine by me wrt making the
mapping tables optional or not.

I have considered your preference and think that keeping the
mapping tables with the agent may be reasonable for larger devices which
should have the resources to support them and have an E/NMS to
take advantage of these tables.

Thanks,
  -Joan

----- Original Message ----- 
From: "Thomas Nadeau" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 10, 2011 10:58 AM
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

Yes, of course! 8)

> implement them, since they are for E/NMS.

That is possible, but as you know is up to the working group. It is my 
personal preference as a vendor of management applications,
to avoid optional things where possible, as they are unlikely to ever get 
implemented on devices and make things more difficult for
applications.

--Tom

>>>> configuration using MPLS-TP identifiers.  Presumably, there are at 
>>>> least three ways this could be accomplished:
>>>>
>>>> *         In associated bidirectional LSPs, the transport directions 
>>>> are set up and monitored independently, so each transport direction 
>>>> should be a separate row in the mplsTunnelTable.
>>>>
>>>>
>>>>
>>>> *         In co-routed bidirectional LSPs, both transport directions 
>>>> are set up and monitored together.  This means we should have only one 
>>>> row in the mplsTunnelTable to represent a tunnel of this type.  This is 
>>>> not how the draft is currently structured, where the example in Section 
>>>> 9 creates two rows in the mplsTunnelTable.
>>>>
>>>>
>>>>
>>>> About gaps:
>>>>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 11 Aug 2011 11:56:46 -0400

Cool. Thanks!

---

From: Spike Curtis <[email-masked]>
Date: Mon, 15 Aug 2011 08:58:28 +0000

Hi Joan and Tom,

What I meant by (1) was not to extend the mplsTunnelTable, but define a new table.  That is to say, a tunnel can appear in either the new MPLS-TP tunnel table or the old mplsTunnelTable, not both.  As Joan suggests, both tables could be straightforwardly presented together at the user interface level.

With option 2 (modified indexing) ruled out, (1) becomes my preference as well.

As I mentioned, my main concern is with extra identifiers with only local significance.  There are cases where rows in the table will be auto-created, for example at LSP egress when the tunnel is signalled.  The difficulty is then to ensure they don't change if the tunnel is taken down and recreated, or over a graceful restart.  Indices to the mplsTunnelTable are referenced in other MIBs like the pseudowire to MPLS tunnel binding and the mplsXCExtTable.

-Spike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Thursday, August 11, 2011 4:57 PM
To: Joan Cucchiara
Cc: [email-masked]
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

Cool. Thanks!

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 15 Aug 2011 09:39:57 -0400

> What I meant by (1) was not to extend the mplsTunnelTable, but define a new table.  That is to say, a tunnel can appear in either the new MPLS-TP tunnel table or the old mplsTunnelTable, not both.…

	Why would that approach be better than extending the existing table?

> As I mentioned, my main concern is with extra identifiers with only local significance.  There are cases where rows in the table will be auto-created, for example at LSP egress when the tunnel is s…

	That is a bit of an implementation detail, and is also why in general, no one relies on SNMP for provisioning.

	--Tom

---

From: Spike Curtis <[email-masked]>
Date: Tue, 16 Aug 2011 09:04:32 +0000

Hi Tom,

I hear what you're saying.  Is it a requirement that the MIB can be used for provisioning?  If not, then why don't we make the whole thing read-only?

-Spike

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Monday, August 15, 2011 2:40 PM
To: Spike Curtis
Cc: Joan Cucchiara; [email-masked]
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 16 Aug 2011 07:31:05 -0400

> I hear what you're saying.  Is it a requirement that the MIB can be used for provisioning?  If not, then why don't we make the whole thing read-only?

	The read-write capability is up to the WG, but my preference is to avoid provisioning via SNMP altogether as its a pretty rare use case.

	--Tom

---

From: Spike Curtis <[email-masked]>
Date: Thu, 18 Aug 2011 11:08:14 +0000

Hi Tom, 

I'm also happy to drop provisioning as a use case for the MIB.  The issues with local identifiers I mentioned aren't relevant if we don't support provisioning.  I do think we should be explicit about this.  If there aren't objections from the WG, then we should change the MIB to be read-only.

-Spike

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 12:31 PM
To: Spike Curtis
Cc: [email-masked]
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 18 Aug 2011 07:42:33 -0400

We will need a consensus call from the WG chairs on this, as this choice will be questioned during the MIB doctor and IESG reviews.
	
	--Tom

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 22 Aug 2011 16:39:50 -0400

Tom,

Speaking as a MIB Dr., as long as:
1)  the WG is agreeable to a read-only MIB (i.e. no running consensus for 
wanting MIB objects for configuration),
2) the document clearly states that the scope of the document is for a 
read-only MIB, i.e. configuration is outside of
the scope of the document,
3) the objects' names, DESCRIPTION clauses and conformance statements, etc. 
are all consistent with read-only, and
4) Security section also speaks to the MIB being read-only.

then this will significantly reduce the amount of questions about the MIB 
being used for configuration.
I think if there are inconsistencies in the above 1-4, which sometimes 
happens,  that is when questions occur.

Probably obvious, but if hints/considerations about configuration do make 
there way into the draft, then
would be probably be okay, but would suggest putting them in a  specific 
section (maybe as future work (?)).

Thanks,
  -Joan

----- Original Message ----- 
From: "Thomas Nadeau" <[email-masked]>
To: "Spike Curtis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 18, 2011 7:42 AM
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt

>
> We will need a consensus call from the WG chairs on this, as this choice 
> will be questioned during the MIB doctor and IESG reviews.
>
> --Tom
>
>
>> Hi Tom,
>>
>> I'm also happy to drop provisioning as a use case for the MIB.  The 
>> issues with local identifiers I mentioned aren't relevant if we don't 
>> support provisioning.  I do think we should be explicit about this.  If 
>> there aren't objections from the WG, then we should change the MIB to be 
>> read-only.
>>
>> -Spike
>>
>>> I hear what you're saying.  Is it a requirement that the MIB can be used 
>>> for provisioning?  If not, then why don't we make the whole thing 
>>> read-only?
>>
>> The read-write capability is up to the WG, but my preference is to avoid 
>> provisioning via SNMP altogether as its a pretty rare use case.
>>
>> --Tom
>>
>>
>>>
>>> -Spike
>>>
>>>> What I meant by (1) was not to extend the mplsTunnelTable, but define a 
>>>> new table.  That is to say, a tunnel can appear in either the new 
>>>> MPLS-TP tunnel table or the old mplsTunnelTable, not both.  As Joan 
>>>> suggests, both tables could be straightforwardly presented together at 
>>>> the user interface level.
>>>
>>>> As I mentioned, my main concern is with extra identifiers with only 
>>>> local significance.  There are cases where rows in the table will be 
>>>> auto-created, for example at LSP egress when the tunnel is signalled. 
>>>> The difficulty is then to ensure they don't change if the tunnel is 
>>>> taken down and recreated, or over a graceful restart.  Indices to the 
>>>> mplsTunnelTable are referenced in other MIBs like the pseudowire to 
>>>> MPLS tunnel binding and the mplsXCExtTable.
>>>
>>>>>>>> existing tunnel indices.    In a nutshell, the problem I have with 
>>>>>>>> this design is that there are 2 ways of creating indices
>>>>>>>> There may be a #4 Suggestion which is to implement design #1 but 
>>>>>>>> also have an additional (optional?) table
>>>>> to avoid optional things where possible, as they are unlikely to ever 
>>>>> get implemented on devices and make things more difficult for
>>>>> applications.
>>>>>
>>>>> --Tom
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> -Joan
>>>>>>
>>>>>>
>>>>>>
>>>>>>> --Tom
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Joan
>>>>>>>>
>>>>>>>>
>>>>>>>>> I've read the draft and have a question and then some comments. 
>>>>>>>>> I'm happy to be of assistance with any of what follows, and/or 
>>>>>>>>> with working on other MIB drafts that we need to fill out the gaps 
>>>>>>>>> identified in draft-ietf-mpls-tp-mib-management-overview.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> MPLS-TP Identifiers:
>>>>>>>>>
>>>>>>>>> 2.     Redefine the existing mplsTunnelTable indexing, adding 
>>>>>>>>> GlobalID and ICC for ingress and egress nodes, and using 0 as "not 
>>>>>>>>> used" values to allow back-compatibility.
>>>>>>>>>
>>>>>>>>> 3.     Create a separate set of tables which maps the old 
>>>>>>>>> identifiers to the new MPLS-TP identifiers.
>>>>>>>>>
>>>>>>>>> This draft takes the third strategy, but it's not immediately 
>>>>>>>>> clear to me why this is preferable to the other two. (2) seems the 
>>>>>>>>> least complicated because it does away extra mapping and inverse 
>>>>>>>>> mapping tables.  It's also difficult to guarantee that local 
>>>>>>>>> identifiers (which don't have configuration or signalling 
>>>>>>>>> significance) will not change in the case of graceful restart or 
>>>>>>>>> configuration replay.  Was option (3) chosen to avoid 
>>>>>>>>> I'd like to clarify how unidirectional, associated bidirectional 
>>>>>>>>> and co-routed bidirectional paths are modelled in the MIB, and how 
>>>>>>>>> exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map 
>>>>>>>>> onto MIB fields. My preference is as follows.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *         Unidirectional LSPs in MPLS-TP are very similar to 
>>>>>>>>> "normal" MPLS, but with different identifiers.  Tunnels of this 
>>>>>>>>> type do not have any entries in the mplsTunnelExtTable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *         In associated bidirectional LSPs, the transport 
>>>>>>>>> directions are set up and monitored independently, so each 
>>>>>>>>> transport direction should be a separate row in the 
>>>>>>>>> mplsTunnelTable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *         In co-routed bidirectional LSPs, both transport 
>>>>>>>>> directions are set up and monitored together.  This means we 
>>>>>>>>> should have only one row in the mplsTunnelTable to represent a 
>>>>>>>>> tunnel of this type.  This is not how the draft is currently 
>>>>>>>>> structured, where the example in Section 9 creates two rows in the 
>>>>>>>>> mplsTunnelTable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> About gaps:
>>>>>>>>>
>>>>>>>>> Lastly, I think the MIB is still missing some configuration that 
>>>>>>>>> we'll need in order to satisfy MPLS-TP requirements.  These 
>>>>>>>>> include
>>>>>>>>>
>>>>>>>>> *         OAM configuration.  Presumably this will be a reference 
>>>>>>>>> to yet-to-be-defined OAM MIBs so that tunnels can be easily 
>>>>>>>>> assigned OAM profiles.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., 
>>>>>>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies 
>>>>>>>>> Co., Ltd's Statement about IPR related to RFC 5919 
>>>>>>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies 
>>>>>>>>> Co., Ltd's Statement about IPR related to 
>>>>>>>>> draft-ietf-mpls-loss-delay-03 
>>>>>>>>> Note: Messages sent to this list are the opinions of the senders 
>>>>>>>>> and do not imply endorsement by the IETF.
>>>>>>>>>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 22 Aug 2011 17:39:09 -0400

agreed.  all I was saying is that it should be explicitly on the record.

Tom 

On Aug 22, 2011, at 4:39 PM, "Joan Cucchiara" <[email-masked]> wrote:

> 1)  the WG is agreeable to a read-only MIB (i.e. no running consensus for wanting MIB objects for configuration),
> 2) the document clearly states that the scope of the document is for a read-only MIB, i.e. configuration is outside of
> 3) the objects' names, DESCRIPTION clauses and conformance statements, etc. are all consistent with read-only, and
> then this will significantly reduce the amount of questions about the MIB being used for configuration.
> I think if there are inconsistencies in the above 1-4, which sometimes happens,  that is when questions occur.
> 
> Probably obvious, but if hints/considerations about configuration do make there way into the draft, then
> would be probably be okay, but would suggest putting them in a  specific section (maybe as future work (?)).
> 
> Thanks,
> -Joan
> 
>