From owner-mpls@UU.NET Mon Dec 1 01:49:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27797 for ; Mon, 1 Dec 2003 01:49:41 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprdr23830 for ; Mon, 1 Dec 2003 06:49:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprdr23711; Mon, 1 Dec 2003 06:49:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQprdq07298 for mpls-outgoing; Mon, 1 Dec 2003 06:33:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprdq07291 for ; Mon, 1 Dec 2003 06:33:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprdp16314 for ; Mon, 1 Dec 2003 06:22:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprdp16896 for ; Mon, 1 Dec 2003 06:22:14 GMT Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQprdp16860 for ; Mon, 1 Dec 2003 06:22:13 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hB16JvJn018378 for ; Mon, 1 Dec 2003 00:22:13 -0600 Received: from OCCLUST03EVS1.ugd.att.com (135.38.164.11) by attrh5i.attrh.att.com (6.5.032) id 3FBBC62E0034F2DA; Mon, 1 Dec 2003 01:21:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B7D3.7537AEA6" Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt Date: Mon, 1 Dec 2003 00:22:12 -0600 Message-ID: <1C9A50113894DC459E8AF995EC23112E053BFECB@OCCLUST03EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt Thread-Index: AcOwMK0OsCaeak9yRoG1a8SfgHQ7pwHoop1w From: "Chung, Li-Jin W, ALABS" To: Cc: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B7D3.7537AEA6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Joan,=20 How are you?=20 Please see my inserted notes below. Since your questions are mostly = related to operations, I made an attempt to provide my personal review = from operations perspective. Please let me know if you have further = comments.=20 Thanks,=20 Li Chung=20 -----Original Message-----=20 From: jcucchiara@mindspring.com = [mailto:jcucchiara@mindspring.com]=20 Sent: Tuesday, November 11, 2003 10:39 AM=20 To: Lai, Wai S (Waisum), ALABS=20 Cc: mpls@uu.net=20 Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt=20 Wai Sum,=20 Could you please directly address the following questions/comments:=20 1) Why does an operator care about a total for Established Sessions=20 and Terminated Sessions on a per Entity basis?=20 These counters are AUGMENTS to the=20 Entity table and I am unclear as to why an operator would deem these=20 counts useful. Please do not tell me that it is helpful for router = resource=20 management and engineering of LDP sessions. Please tell me "how" they=20 address the issue of router resource management and/or engineering of=20 LDP sessions. An Entity is a MIB construct. Keeping totals of all = sessions,=20 which were established or terminated on a per Entity basis=20 over some time frame, does not seem very helpful in my opinion, so=20 I am trying to understand why you think that these are helpful.=20 Li > This data is typically used for traffic management. Given the size = of our network, the typical network management process is to look at the = aggregate view of the network-wide performance first to get a glance of = total counts on attempts, successes and failures. We use the ratio of = failure/attempts and the history data to determine if there is an = abnormal network event (network-wide or per router-wide) that we need to = pay special attention to for trouble shooting or diagnosis. If there is = a network-wide network event identified, we then go to the impacted = network entity(ies) to begin our trouble shooting. At this point, we = might need detailed data to identify root cause of the event. Such = detailed data will be only needed on a certain router or certain = interface; not network-wide. In addition, the ratio of failure/attempt = helps us to prioritize our work as to which network event and which = network entity that we should look at first if there are multiple events = in the network at the same time. In short, augmentation allows us to = have a first order of surveillence to identify the type and the location = of the network events. So, the operators can quickly zoom into the right = locations/routers/switches for trouble shooting. This will save our = Time-to-Diagnosis and Time-to-Repair.=20 2) With regard to the counters which are being proposed to AUGMENT=20 the session table, exactly how do they help with Fault Management unless = an NMS is polling them on every single node, on every LSP from start to=20 end, and the agent is storing some history of these on every node?=20 How does this help with router resources?=20 I would think that such a feature would use quite a bit of router = resources=20 to store this information.=20 Please see my note above. The saving of the router resource is from the = saving of number of objects needs to be reported. The entity-wide = objects obvious will be less than the per interface or per LSP wide = objects.=20 3) Also with regard to the counters which AUGMENT the session table,=20 if/when the LSP goes down, what happens to the information=20 stored in this table. Since it AUGMENTS the session table, the session = is=20 gone, so is this information gone also?=20 This is a flaw of the counter design in my opinion. It is in fact the = current Cisco implementation problem that links the reliabiliity of the = performance counters with the LSP Up/Down status. The counters should be = totally independent of the LSP Up/Down status.=20 thanks,=20 -Joan=20 -----Original Message-----=20 Joan,=20 Thanks for your review of our draft and the comments below.=20 As described in Section 2.1 of our draft, our requirements are very=20 specific, i.e., for the engineering of LDP Sessions and router resource=20 management. To meet this requirement, there is a need to capture the=20 signaling usage/performance of the LDP Entities, and the traffic usage/=20 performance of the LDP Sessions. Another specific requirement for=20 fault management is the need for persistent LSP information that=20 survives LSP failures. The draft currently proposes five additional=20 objects, while the issue of measurement interval and recording counters=20 to maintain persistent history has been left open for further=20 discussion.=20 We would like to hear also other SP's view on our draft. Comments=20 and suggestions on how the above requirements could/should be met are=20 particularly welcome.=20 Thanks, Wai Sum=20 -----Original Message-----=20 From: jcucchiara@mindspring.com = [mailto:jcucchiara@mindspring.com]=20 Sent: Sunday, November 09, 2003 12:13 PM=20 To: Lai, Wai S (Waisum), ALABS=20 Cc: mpls@UU.NET=20 Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt=20 Hi Wai Sum,=20 I have read this draft several times and was confused by it.=20 The requirements are very broad areas (i.e. Performance Management=20 Requirement,=20 Fault Management Requirement), however, the proposed solution of adding=20 5 new=20 objects so as to lessen the burden on the SNMP manager (NMS),=20 did not follow.=20 The objects being proposed are also confusing to me. The Attempted=20 Session counter is already in the MPLS-LDP-STD-MIB and the=20 other 2 are totals don't provide relevant information in my opinion.=20 Why does an operator care about an Entity which is a MIB constuct=20 and not really important to LDP performance?=20 Also, the packet counters are not going to be useful unless you=20 are utilizing an NMS to monitor every node, and every LDP-LSP from=20 start to end. You say you do not want to "burden" the network with=20 additional NMS traffic or increase polling on nodes,=20 but that would be the only way to make these counters useful=20 as far as I can tell.=20 I would like to hear from other operators on this draft.=20 thanks, Joan=20 At 06:29 PM 10/22/03 -0400, Internet-Drafts@ietf.org wrote:=20 >A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.=20 >=20 >=20 > Title : A Supplementary History Module for the MPLS=20 LDP-MIB=20 > Author(s) : W. Lai=20 > Filename : draft-lai-mpls-ldp-hist-mib-00.txt=20 > Pages : 8=20 > Date : 2003-10-22=20 >=20 >In this document, requirements for supplementing the MPLS LDP-MIB=20 >are presented for the support of specific network management needs=20 >for fault and performance management. Based on these requirements,=20 >it describes managed objects in a supplementary history module for=20 >use with the LDP-MIB.=20 >=20 >A URL for this Internet-Draft is:=20 >= http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt=20 >=20 <<<<=20 ------_=_NextPart_001_01C3B7D3.7537AEA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

Joan,

How are you? =

Please see my inserted = notes below.=20 Since your questions are mostly related to operations, I made an = attempt to=20 provide my personal review from operations perspective. Please let me = know if=20 you have further comments.

Thanks,

Li Chung

-----Original Message-----

From: jcucchiara@mindspring.com=20 [<mailto:jcucchiara@mindspring.com>mailto:jcucchiara@mindspring.com]

Sent: Tuesday, November 11, 2003 10:39 AM =

To: Lai, Wai S (Waisum), ALABS

Cc: mpls@uu.net

Subject: Re: I-D = ACTION:draft-lai-mpls-ldp-hist-mib-00.txt=20


Wai Sum,


Could you please directly address the following=20 questions/comments:


1) Why does an operator care about a total for = Established=20 Sessions

and Terminated Sessions on a per Entity basis? =

These counters are AUGMENTS to the

Entity table and I am unclear as to why an operator = would deem=20 these

counts useful. Please do not tell me that it is = helpful for=20 router resource

management and engineering of LDP sessions. Please = tell me=20 "how" they

address the issue of router resource management = and/or=20 engineering of

LDP sessions. An Entity is a MIB construct. Keeping = totals of=20 all sessions,

which were established or terminated on a per Entity = basis=20

over some time frame, does not seem very helpful in = my=20 opinion, so

I am trying to understand why you think that these = are=20 helpful.

Li > This data is = typically used=20 for traffic management. Given the size of our network, the typical = network=20 management process is to look at the aggregate view of the = network-wide=20 performance first to get a glance of total counts on attempts, = successes and=20 failures. We use the ratio of failure/attempts and the history data to = determine if there is an abnormal network event (network-wide or per=20 router-wide) that we need to pay special attention to for trouble = shooting or=20 diagnosis. If there is a network-wide network event identified, we = then go to=20 the impacted network entity(ies) to begin our trouble shooting. At = this point,=20 we might need detailed data to identify root cause of the event. Such = detailed=20 data will be only needed on a certain router or certain interface; not = network-wide. In addition, the ratio of failure/attempt helps us to = prioritize=20 our work as to which network event and which network entity that we = should=20 look at first if there are multiple events in the network at the same = time. In=20 short, augmentation allows us to have a first order of surveillence to = identify the type and the location of the network events. So, the = operators=20 can quickly zoom into the right locations/routers/switches for trouble = shooting. This will save our Time-to-Diagnosis and Time-to-Repair. =



2) With regard to the counters which are being = proposed to=20 AUGMENT

the session table, exactly how do they help with = Fault=20 Management unless

an NMS is polling them on every single node, on = every LSP from=20 start to

end, and the agent is storing some history of these = on every=20 node?

How does this help with router resources? =


I would think that such a feature would use quite a = bit of=20 router resources

to store this information.


Please see my note = above. The saving=20 of the router resource is from the saving of number of objects needs = to be=20 reported. The entity-wide objects obvious will be less than the per = interface=20 or per LSP wide objects.


3) Also with regard to the counters which AUGMENT = the session=20 table,

if/when the LSP goes down, what happens to the = information=20

stored in this table. Since it AUGMENTS the session = table, the=20 session is

gone, so is this information gone also?

This is a flaw of the counter design in my = opinion. It=20 is in fact the current Cisco implementation problem that links the=20 reliabiliity of the performance counters with the LSP Up/Down status. = The=20 counters should be totally independent of the LSP Up/Down status. =


thanks,

-Joan



-----Original Message-----


Joan,

Thanks for your review of our draft and the comments = below.=20

As described in Section 2.1 of our draft, our = requirements are=20 very

specific, i.e., for the engineering of LDP Sessions = and router=20 resource

management. To meet this requirement, there is a = need to=20 capture the

signaling usage/performance of the LDP Entities, and = the=20 traffic usage/

performance of the LDP Sessions. Another specific = requirement=20 for

fault management is the need for persistent LSP = information=20 that

survives LSP failures. The draft currently proposes = five=20 additional

objects, while the issue of measurement interval and = recording=20 counters

to maintain persistent history has been left open = for further=20

discussion.

We would like to hear also other SP's view on our = draft.=20 Comments

and suggestions on how the above requirements = could/should be=20 met are

particularly welcome.

Thanks, Wai Sum


-----Original Message-----

From: jcucchiara@mindspring.com=20 = [<mailto:jcucchiara@mindspring.com>mailto:jcucchiara@mindspring.com= ]=20

Sent: Sunday, November 09, 2003 12:13 PM

To: Lai, Wai S (Waisum), ALABS

Cc: mpls@UU.NET

Subject: Re: I-D = ACTION:draft-lai-mpls-ldp-hist-mib-00.txt=20




Hi Wai Sum,


I have read this draft several times and was = confused by it.=20

The requirements are very broad areas (i.e. = Performance=20 Management

Requirement,

Fault Management Requirement), however, the proposed = solution=20 of adding

5 new

objects so as to lessen the burden on the SNMP = manager (NMS),=20

did not follow.


The objects being proposed are also confusing to me. = The=20 Attempted

Session counter is already in the MPLS-LDP-STD-MIB = and the=20

other 2 are totals don't provide relevant = information in my=20 opinion.

Why does an operator care about an Entity which is a = MIB=20 constuct

and not really important to LDP performance? =


Also, the packet counters are not going to be useful = unless=20 you

are utilizing an NMS to monitor every node, and = every LDP-LSP=20 from

start to end. You say you do not want to "burden" = the network=20 with

additional NMS traffic or increase polling on nodes, =

but that would be the only way to make these = counters useful=20

as far as I can tell.


I would like to hear from other operators on this = draft.=20


thanks, Joan



At 06:29 PM 10/22/03 -0400, Internet-Drafts@ietf.org = wrote:=20

>A New Internet-Draft is available from the = on-line=20 Internet-Drafts

directories.

>

>

> Title : A Supplementary History Module for the = MPLS=20

LDP-MIB

> Author(s) : W. Lai

> Filename : draft-lai-mpls-ldp-hist-mib-00.txt =

> Pages : 8

> Date : 2003-10-22

>

>In this document, requirements for supplementing = the MPLS=20 LDP-MIB

>are presented for the support of specific = network=20 management needs

>for fault and performance management. Based on = these=20 requirements,

>it describes managed objects in a supplementary = history=20 module for

>use with the LDP-MIB.

>

>A URL for this Internet-Draft is:

><http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-h= ist-mib-00.txt>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-= hist-mib-00.txt=20

> =











<<<<





------_=_NextPart_001_01C3B7D3.7537AEA6-- From owner-mpls@UU.NET Mon Dec 1 08:54:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10371 for ; Mon, 1 Dec 2003 08:54:10 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpret28996 for ; Mon, 1 Dec 2003 13:54:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpret28641; Mon, 1 Dec 2003 13:54:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQpres28500 for mpls-outgoing; Mon, 1 Dec 2003 13:37:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQpres28492 for ; Mon, 1 Dec 2003 13:37:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQpres18040 for ; Mon, 1 Dec 2003 13:36:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpres04676 for ; Mon, 1 Dec 2003 13:36:38 GMT Received: from smtp7.hy.skanova.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp7.hy.skanova.net [195.67.199.140]) id QQpres04652 for ; Mon, 1 Dec 2003 13:36:37 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hB1DaV1w007109; Mon, 1 Dec 2003 14:36:31 +0100 (CET) Message-ID: <3FCB43D2.5090401@pi.se> Date: Mon, 01 Dec 2003 14:36:18 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson CC: MPLS wg , George Swallow , Alex Zinin Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document! References: <3FC13CF1.2060802@pi.se> In-Reply-To: <3FC13CF1.2060802@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, we have a consensus on making draft-yasukawa-mpls-p2mp-requirement-01.txt a working group document. Will be published shortly. -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Mon Dec 1 09:01:30 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10619 for ; Mon, 1 Dec 2003 09:01:30 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpreu22489 for ; Mon, 1 Dec 2003 14:01:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpreu22288; Mon, 1 Dec 2003 14:01:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQpres29150 for mpls-outgoing; Mon, 1 Dec 2003 13:44:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQpres29113 for ; Mon, 1 Dec 2003 13:44:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQpres06890 for ; Mon, 1 Dec 2003 13:44:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpres13252 for ; Mon, 1 Dec 2003 13:44:26 GMT Received: from smtp7.hy.skanova.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp7.hy.skanova.net [195.67.199.140]) id QQpres13247 for ; Mon, 1 Dec 2003 13:44:25 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hB1DiH1w012875; Mon, 1 Dec 2003 14:44:17 +0100 (CET) Message-ID: <3FCB45A5.90000@pi.se> Date: Mon, 01 Dec 2003 14:44:05 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Loa Andersson , George Swallow , Alex Zinin , Adrian Farrel Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document References: <3FC13EA6.6030305@pi.se> In-Reply-To: <3FC13EA6.6030305@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, we've the a consensus on making the draft-farrel-mpls-rsvpte-attributes-00.txt an mpls working group document, will be published shortly. /Loa -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Mon Dec 1 10:25:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14587 for ; Mon, 1 Dec 2003 10:25:49 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprez23680 for ; Mon, 1 Dec 2003 15:26:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprez23512; Mon, 1 Dec 2003 15:25:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQprey09992 for mpls-outgoing; Mon, 1 Dec 2003 15:04:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQprey09673 for ; Mon, 1 Dec 2003 15:04:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQprey11111 for ; Mon, 1 Dec 2003 15:04:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprey18387 for ; Mon, 1 Dec 2003 15:04:04 GMT Received: from smtp7.hy.skanova.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp7.hy.skanova.net [195.67.199.140]) id QQprey18368 for ; Mon, 1 Dec 2003 15:04:03 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hB1F2T1w011557; Mon, 1 Dec 2003 16:02:29 +0100 (CET) Message-ID: <3FCB57F9.4090304@pi.se> Date: Mon, 01 Dec 2003 16:02:17 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Alex Zinin , Kireeti Kompella , George Swallow Subject: draft-ietf-mpls-ldp-mtu-extensions-02.txt implementations? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, we have requested an IESG review of draft-ietf-mpls-ldp-mtu-extensions-02.txt to become a proposed standard, the ADs have notified us that we need to have a known implementation in order to progress it. We therefore solicit information on implentations of this spec. /Loa -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Tue Dec 2 20:24:43 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27455 for ; Tue, 2 Dec 2003 20:24:43 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprkf27433 for ; Wed, 3 Dec 2003 01:24:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprkf27232; Wed, 3 Dec 2003 01:24:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQprke06678 for mpls-outgoing; Wed, 3 Dec 2003 01:05:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprke06669 for ; Wed, 3 Dec 2003 01:05:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQprke13404 for ; Wed, 3 Dec 2003 01:05:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprke14198 for ; Wed, 3 Dec 2003 01:05:27 GMT Received: from cerberus.uk.clara.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cerberus.uk.clara.net [195.8.69.103]) id QQprke14190 for ; Wed, 3 Dec 2003 01:05:26 GMT Received: from du-069-0101.access.clara.net ([217.158.132.101] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1ARLSH-0001nB-FD for mpls@UU.NET; Wed, 03 Dec 2003 01:05:25 +0000 Message-ID: <037c01c3b939$929f1740$a9b39ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt Date: Tue, 2 Dec 2003 23:26:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I have published a draft to start the ball rolling in the great hard/soft pre-emption debate. There is no doubt that the draft is rambling and wrong. Please enter into a detailed and heated debate. In summary... The points of contention are: - Should pre-emption cause the associated LSP to be torn down - at the point of pre-emption - at all other LSRs along the LSP? - If it is torn down, is it torn using PathErr and ResvErr? - What is the correct processing of a PathErr after an LSP has been successfully established. - Is it possible for hard and soft pre-emption to co-exist in a network if they both use the same signalling technique? A lot of the answers seem to hang on how admission control is performed. Is it per LSP or is it statistical? It does not appear to be very fruitful to investigate - the 'correct' interpretation of RFC3209 - the motivation for the Path_State_Removed flag in RFC3473 (You are, however, perfectly free to investigate whatever you like!) Cheers, Adrian ----- Original Message ----- From: To: Sent: Tuesday, December 02, 2003 8:35 PM Subject: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Interim Report on MPLS Pre-emption > Author(s) : A. Farrel > Filename : draft-farrel-mpls-preemption-interim-00.txt > Pages : 0 > Date : 2003-12-2 > > This document is an interim report into pre-emption in MPLS systems. > > At the 58th IETF, the MPLS Working Group determined that there are > several interpretations of how pre-emption should be achieved within > MPLS systems. This document is the result of the initial enquiries to > vendors and other implementors into the question of how and why they > offer pre-emption funtion in their MPLS inplementations. > > This document is intended to be a short-lived document and only > exists to document the current findings. It will be superceded or > retired. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-mpls-preemption-interim-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-farrel-mpls-preemption-interim-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-farrel-mpls-preemption-interim-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Tue Dec 2 23:16:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02279 for ; Tue, 2 Dec 2003 23:16:19 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprkr25799 for ; Wed, 3 Dec 2003 04:16:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprkr25402; Wed, 3 Dec 2003 04:16:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQprkp27210 for mpls-outgoing; Wed, 3 Dec 2003 03:58:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprkp27205 for ; Wed, 3 Dec 2003 03:58:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQprkp19379 for ; Wed, 3 Dec 2003 03:53:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprkp03326 for ; Wed, 3 Dec 2003 03:53:08 GMT Received: from kummer.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint2.juniper.net [207.17.136.150]) id QQprkp03309 for ; Wed, 3 Dec 2003 03:53:08 GMT Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hB33r7da048382; Tue, 2 Dec 2003 19:53:07 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hB33r65o048379; Tue, 2 Dec 2003 19:53:06 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 2 Dec 2003 19:53:06 -0800 (PST) From: Kireeti Kompella To: Adrian Farrel cc: "'mpls@uu.net'" Subject: Re: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt In-Reply-To: <037c01c3b939$929f1740$a9b39ed9@Puppy> Message-ID: <20031202195111.T48373@kummer.juniper.net> References: <037c01c3b939$929f1740$a9b39ed9@Puppy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 2 Dec 2003, Adrian Farrel wrote: > Please enter into a detailed and heated debate. I will be helpful and not comment. But it is soooo tempting! :-) Kireeti. ------- From owner-mpls@UU.NET Wed Dec 3 06:44:54 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10098 for ; Wed, 3 Dec 2003 06:44:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprlv16683 for ; Wed, 3 Dec 2003 11:45:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprlv16469; Wed, 3 Dec 2003 11:45:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQprlt26217 for mpls-outgoing; Wed, 3 Dec 2003 11:29:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQprlt26209 for ; Wed, 3 Dec 2003 11:29:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprlt13817 for ; Wed, 3 Dec 2003 11:27:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprlt08221 for ; Wed, 3 Dec 2003 11:27:37 GMT Received: from zephir.uk.clara.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zephir.uk.clara.net [195.8.69.53]) id QQprlt08189 for ; Wed, 3 Dec 2003 11:27:37 GMT Received: from du-069-1009.access.clara.net ([217.158.170.246] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1ARVAN-000BwY-Ka; Wed, 03 Dec 2003 11:27:35 +0000 Message-ID: <042e01c3b990$7caf2c70$a9b39ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kireeti Kompella" Cc: "'mpls@uu.net'" References: <037c01c3b939$929f1740$a9b39ed9@Puppy> <20031202195111.T48373@kummer.juniper.net> Subject: Re: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt Date: Wed, 3 Dec 2003 11:25:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti wrote. > > Please enter into a detailed and heated debate. > > I will be helpful and not comment. But it is soooo tempting! :-) Really? Are you unwell? I do hope your soon restored to your usual, trouble making self. Adrian From owner-mpls@UU.NET Wed Dec 3 11:05:21 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21227 for ; Wed, 3 Dec 2003 11:05:21 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprmm07181 for ; Wed, 3 Dec 2003 16:05:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprmm06955; Wed, 3 Dec 2003 16:05:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQprml03725 for mpls-outgoing; Wed, 3 Dec 2003 15:48:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprml03719 for ; Wed, 3 Dec 2003 15:48:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQprml18926 for ; Wed, 3 Dec 2003 15:45:20 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprml20912 for ; Wed, 3 Dec 2003 15:45:19 GMT Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQprml20814 for ; Wed, 3 Dec 2003 15:45:16 GMT Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Dec 2003 07:46:02 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB3FjBjs016030 for ; Wed, 3 Dec 2003 07:45:13 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEJ72211; Wed, 3 Dec 2003 10:45:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB3FjAA18924 for mpls@uu.net; Wed, 3 Dec 2003 10:45:10 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQprly19227 for ; Wed, 3 Dec 2003 12:40:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprly10664 for ; Wed, 3 Dec 2003 12:38:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprly06679 for ; Wed, 3 Dec 2003 12:38:22 GMT Received: from fep03-mail.bloor.is.net.cable.rogers.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) id QQprly05606 for ; Wed, 3 Dec 2003 12:37:57 GMT Received: from dune ([24.103.66.219]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20031203123729.ZVOU389421.fep03-mail.bloor.is.net.cable.rogers.com@dune>; Wed, 3 Dec 2003 07:37:29 -0500 Message-ID: <001501c3b99a$3dcaaa20$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: "Dave Thaler" , "Mpls \(E-mail\)" Cc: "Bert Wijnen" References: <6886E35B88EA2347A06817D1B1385C0E9E6345@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: DT's review of draft-ietf-mpls-telink-mib-04.txt Date: Wed, 3 Dec 2003 07:37:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID at Wed, 3 Dec 2003 07:37:28 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave, I have studied your response in greater details. I have an issue with the last part of point number 4. Your layering proposal is not in line with the intent of the TE link MIB. TE links are really logical entities used to present a set of one or more network resources with a consistent set of characteristics. By allowing a TE link to be either a TE link or a tunnel, we are breaking this paradigm. TE links would be in some cases logical entities, and in other cases "physical" entities (or should I say real network resources). For consistency, I would like to see tunnels handled the same as other technologies. In the example that you present, I would like to see the layering as follows: +-----------------------------------+ MPLS interface ifType = mpls(166) +-----------------------------------+ TE link ifType = TE link(200) +-----------------------------------+ Component link Tunnel link ifType = tunnel(131) +-----------------------------------+ ifType = ethernetCsmacd(6) +-----------------------------------+ Martin ----- Original Message ----- From: "Dave Thaler" To: "Mpls (E-mail)" Cc: "Bert Wijnen" Sent: Wednesday, November 26, 2003 7:41 PM Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt Bert asked me to post the current status of the telink-mib discussion. Since a new version hasn't been submitted since my initial review, I'll briefly summarize where I think we are on draft-04. 1) Relationship between teLinkLocalIpAddr and ipAddrTable needs to be clarified, and authors agreed. On Oct. 22, 2003, Martin Dubuc wrote: > I will add text in the DESCIRPTION clause to emphasize the > relationship between teLinkLocalIpAddr and ipAddrTable. 2) teLinkIncomingIfId should have SYNTAX Integer32 (0..2147483647) instead of SYNTAX InterfaceIndexOrZero On Oct. 6, 2003, Martin wrote: > I can make this change. 3) teLink{Outgoing,Incoming}IfId descriptions should be more clear: "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." On Oct. 6, 2003, Martin wrote: > I can be explicit as you suggest. 4) Requirements from section 4 of RFC 2863 not met yet in section 8 are: ifRcvAddressTable The media-specific MIB designer MUST specify the applicability of the ifRcvAddressTable. ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. The media-specific MIB designer MUST specify any special conditions of the media concerning the inclusion of framing characters, especially with respect to frames with errors. I have seen no response from the authors yet on this point. 5) On the topic of extending the tunnel MIB, I believe everyone agreed on the following points: a) Some objects are redundant with the IP Tunnel MIB (RFC 2667) in the case where the MPLS TE link is a tunnel over IPv4. These redundant objects are useful when the agent does not support the IP tunnel MIB, or when the tunnel is over IPv6, which is not yet handled by 2667. b) Regardless of what happens with this MIB, RFC 2667 should be updated to handle IPv6. (This was done, draft-thaler-inet-tunnel-mib-00.txt was posted to the ifmib and ipv6 lists, presented in the IPv6 WG in Minneapolis and was accepted as an IPv6 WG item since the IFMIB WG is closed.) c) It would be good to be done with the MPLS TE link MIB now and not be blocked on any other document. To briefly change the subject to an analogous issue, Kireeti, Bert, and I met at IETF to talk about a similar issue in the TEWG MIB. We concluded that the best answer was to allow the MIB to be used both for tunnels (where it can logically extend the tunnel MIB) as well as for non-tunnel objects, where it does not extend the tunnel MIB. This can be done in such a way as to not change anything in the MIB definition itself, just the intro text in the document. I think this same solution can be used in the MPLS TElink MIB, and hence solve the problems of not being able extend the tunnel MIB when an agent supports it. Hence we could add a small subsection to section 8 along the lines of: 8.1 Application of the IP Tunnel MIB to TE Links The IP Tunnel MIB [RFC2667] defines managed objects for managing tunnels over IP. For TE Link interfaces which correspond to tunnels over IP, an agent supporting the IP Tunnel MIB would have entries in that MIB for TE tunnels. Interfaces in the IP Tunnel MIB use ifType = tunnel (131), and have a subtype identifying the actual encapsulation method. Hence, in the case where MPLS is using a single TE tunnel link, the interface stack might appear as (for example): +-----------------------------------+ | MPLS interface ifType = mpls(166) | +-----------------------------------+ | Tunnel link ifType = tunnel(131) | +-----------------------------------+ | Underlying Layer... | | ifType = ethernetCsmacd(6) | +-----------------------------------+ [Note: I'm not sure whether the above stack is correct, since I'm not sure what data encapsulation is used on the wire. The above stack would be correct if an actual data packet on the wire looked like: Ethernet - Outer IPv4 - MPLS - Inner IPv4 - payload If the packet looks different, the stack would be different.] Also update the DESCRIPTION clauses of teLinkEntry, teLinkDescriptorEntry, teLinkSrlgEntry, teLinkBandwidthEntry which all say ifType must be 200, to say 200 or 131. This would allow the TE link mib to be used both ways, and hence allow the benefits of the tunnel MIB, without requiring it or any other changes to an existing implementation. The alternative would be to publish without this now and rev the TE Link MIB at the same time as the Inet Tunnel MIB would go to RFC. -Dave From owner-mpls@UU.NET Thu Dec 4 17:07:48 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20127 for ; Thu, 4 Dec 2003 17:07:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprrc28647 for ; Thu, 4 Dec 2003 22:07:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprrc28407; Thu, 4 Dec 2003 22:07:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQprrb08853 for mpls-outgoing; Thu, 4 Dec 2003 21:46:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQprrb08848 for ; Thu, 4 Dec 2003 21:46:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQprrb15588 for ; Thu, 4 Dec 2003 21:45:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprrb28316 for ; Thu, 4 Dec 2003 21:45:57 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQprrb28296 for ; Thu, 4 Dec 2003 21:45:56 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB4Ljp010013; Thu, 4 Dec 2003 15:45:51 -0600 (CST) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hB4LjoG15646; Thu, 4 Dec 2003 15:45:50 -0600 (CST) Message-ID: <3FCFAB0A.5040206@lucent.com> Date: Thu, 04 Dec 2003 14:45:46 -0700 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,zh MIME-Version: 1.0 To: ccamp , mpls Subject: Re: Last Call: Procedures for Modifying RSVP to a BCP References: <3FCFA9B6.5010404@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > All, > I am not sure I fully understand what is being proposed by this > document in terms of values to be assigned to RSVP entities for > standards organizations outside of IETF. In section 1, there is > the paragraph: > > " A standards body other than the IETF that wishes to obtain an > assignment for an RSVP entity must decide from which type of > name/number space they desire their assignment be made from, and then > submit the appropriate documentation." > > I would suppose that "appropriate documentation" is to leave the > door open that we eventually have a real liaison process by which > an incoming liaison statement has some sort of status within IETF, > and I have no difficulty leaving the language here loose enough to > accomodate this possibility. > > However I have more difficulty later on understanding what ranges > would apply for RSVP entities defined by standards bodies outside > of IETF. These would not seem to meet the "vendor private use" or > "expert review" categories, so by process of elimination, they > would seem to be "standards action" assignments. > > However, it is not generally a good idea to have more than one > normative source for a particular standards element. If a specification > appears in more than one place, it should be clear which is the > controlling document (which one should be paid attention to if > the specifications differ) and where someone should go in order > to propose changes. > > What we have done in the past with these sorts of things is to have > an informational RFC in IETF that references the external standard. > But in reading this document, it seems that "standards action" > codepoints could only be assigned to values for standards track > RFCs within IETF. > > I think the document needs to be clearer about assignment of > codepoints for RSVP entities defined by other standards bodies. > If approving an informational RFC as we have done in the past is > considered to be some kind of standards action, and can therefore > be used for these kinds of assignments, I think a few more words are > needed to clarify that we can still do these things as in the past. > > But if the intent is that any such assignments in the future actually > be in standards track RFCs, then we have the problem of multiple > normative sources, and I think more discussion is needed to make > sure that this is really what we want. > > If the procedures to be followed by other standards organizations are > to change, it will also be necessary to comminucate that change > to those other organizations so that they will know the appropriate > procedure to follow for their applications of RSVP. > Regards, > Steve > From owner-mpls@UU.NET Thu Dec 4 17:35:13 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21555 for ; Thu, 4 Dec 2003 17:35:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprre15332 for ; Thu, 4 Dec 2003 22:35:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprre14994; Thu, 4 Dec 2003 22:35:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQprrd00401 for mpls-outgoing; Thu, 4 Dec 2003 22:15:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQprrc00135 for ; Thu, 4 Dec 2003 22:14:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQprrc22071 for ; Thu, 4 Dec 2003 22:14:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprrc05772 for ; Thu, 4 Dec 2003 22:14:46 GMT Received: from psg.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: psg.com [147.28.0.62]) id QQprrc05759 for ; Thu, 4 Dec 2003 22:14:45 GMT Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS1kD-000Bit-56; Thu, 04 Dec 2003 22:14:45 +0000 Date: Thu, 4 Dec 2003 14:13:32 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <75146475901.20031204141332@psg.com> To: mpls@UU.NET CC: "Wijnen, Bert (Bert)" Subject: IESG on MPLS MIBs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks- The IESG approved the following MIBs at the telechat today: draft-ietf-mpls-lsr-mib draft-ietf-mpls-tc-mib draft-ietf-mpls-mgmt-overview Also, all comments have been addressed for the following documents and they are ready to go to the RFC Editor: draft-ietf-mpls-ldp-mib draft-ietf-mpls-ftn-mib draft-ietf-mpls-te-mib The announcements will go out shortly. I would like to thank the document editors, WG chairs, and Bert Wijnen (who was the actual shepherding AD) for their dedication and hard work. Thank you guys! -- Alex Zinin From owner-mpls@UU.NET Thu Dec 4 21:47:37 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02467 for ; Thu, 4 Dec 2003 21:47:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprqy16893 for ; Thu, 4 Dec 2003 21:09:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprqy16745; Thu, 4 Dec 2003 21:09:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQprqx14126 for mpls-outgoing; Thu, 4 Dec 2003 20:48:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprqx14113 for ; Thu, 4 Dec 2003 20:48:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprqx11720 for ; Thu, 4 Dec 2003 20:47:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprqx00040 for ; Thu, 4 Dec 2003 20:47:43 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQprqx00022 for ; Thu, 4 Dec 2003 20:47:43 GMT Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Dec 2003 12:48:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB4KlbAt019214 for ; Thu, 4 Dec 2003 12:47:38 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEK85652; Thu, 4 Dec 2003 15:47:36 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB4Klar00505 for mpls@uu.net; Thu, 4 Dec 2003 15:47:36 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprqx13730 for ; Thu, 4 Dec 2003 20:45:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQprqx08226 for ; Thu, 4 Dec 2003 20:45:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprqx16426 for ; Thu, 4 Dec 2003 20:45:26 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQprqx16300 for ; Thu, 4 Dec 2003 20:45:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13781 for ; Thu, 4 Dec 2003 15:45:05 -0500 (EST) Message-Id: <200312042045.PAA13781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-p2mp-requirement-00.txt Date: Thu, 04 Dec 2003 15:45:05 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Point to Multipoint extension to RSVP-TE Author(s) : S. Yasukawa Filename : draft-ietf-mpls-p2mp-requirement-00.txt Pages : 20 Date : 2003-12-4 This document presents a set of requirements for Point-to-Multipoint (P2MP) Traffic Engineering (TE) extensions to Multiprotocol Label Switching (MPLS). It specifies functional requirements for RSVP-TE in order to deliver P2MP applications over a MPLS TE infrastructure. It is intended that potential solutions, that specify RSVP-TE procedures for P2MP TE LSP setup, use these requirements as a guideline. It is not intended to specify solution specific details in this document. It is intended that the requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of TDM, lambda and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must be equally applicable to MPLS and GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-p2mp-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-p2mp-requirement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-p2mp-requirement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-requirement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Dec 5 11:17:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11595 for ; Fri, 5 Dec 2003 11:17:38 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprtx02782 for ; Fri, 5 Dec 2003 16:17:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprtx02464; Fri, 5 Dec 2003 16:17:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQprtv26425 for mpls-outgoing; Fri, 5 Dec 2003 15:57:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprtv26418 for ; Fri, 5 Dec 2003 15:57:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQprtv22304 for ; Fri, 5 Dec 2003 15:56:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprtv14294 for ; Fri, 5 Dec 2003 15:56:49 GMT Received: from smtp2.fre.skanova.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.fre.skanova.net [195.67.227.95]) id QQprtv14260 for ; Fri, 5 Dec 2003 15:56:48 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with ESMTP id hB5FuboJ005755; Fri, 5 Dec 2003 16:56:37 +0100 (CET) Message-ID: <3FD0AAB0.3040808@pi.se> Date: Fri, 05 Dec 2003 16:56:32 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: George Swallow , Alex Zinin , "David Allan" Subject: Future of the feed and query drafts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I asked the mailing list for implementations of draft-ietf-mpls-lsp-query-09.txt draft-ietf-mpls-te-feed-06.txt I've had no response on this. I've been informed that there is one implementation, but "exactly according to spec, and that it therefore needs to be se-spun". The query draft has been sent to IESG with a request that it should be published as proposed standard. Due to the lack of implementations I've asked the IESG/ADs that this drafts is taken out of the IESG review and returned to the working group. I should also want to know if there is a continued interest to keep these two drafts a working group documents. A simple yes or no per document is sufficent. /Loa -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Fri Dec 5 11:56:33 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13552 for ; Fri, 5 Dec 2003 11:56:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprtz03381 for ; Fri, 5 Dec 2003 16:56:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQprtz03201; Fri, 5 Dec 2003 16:56:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQprty07978 for mpls-outgoing; Fri, 5 Dec 2003 16:34:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQprty07971 for ; Fri, 5 Dec 2003 16:34:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprty23755 for ; Fri, 5 Dec 2003 16:33:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprty05786 for ; Fri, 5 Dec 2003 16:33:32 GMT Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86]) id QQprty05767 for ; Fri, 5 Dec 2003 16:33:31 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hB5GXSrX004715 for ; Fri, 5 Dec 2003 08:33:28 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEL41539; Fri, 5 Dec 2003 11:33:26 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB5GXQ610767 for mpls@uu.net; Fri, 5 Dec 2003 11:33:26 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprty07915 for ; Fri, 5 Dec 2003 16:32:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprty09551 for ; Fri, 5 Dec 2003 16:31:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprty02322 for ; Fri, 5 Dec 2003 16:31:29 GMT Received: from asgard.ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: asgard.ietf.org [132.151.6.40]) id QQprty02307 for ; Fri, 5 Dec 2003 16:31:28 GMT Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ASIoZ-0004Ob-Nh; Fri, 05 Dec 2003 11:28:23 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)' to Proposed Standard Message-Id: Date: Fri, 05 Dec 2003 11:28:23 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved following documents: - 'Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) ' as a Proposed Standard - 'Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base ' as a Proposed Standard - 'Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base ' as a Proposed Standard These documents are products of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The documents define MPLS-related MIB modules for use with network management protocols in the Internet community. In particular, managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP), Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings,and objects for Multiprotocol Label Switching (MPLS) based traffic engineering Working Group Summary There was a concensus within the WG to advance these documents Protocol Quality The documents have been reviewed for the IESG by Bert Wijnen and Mike MacFaden. RFC-Editor notes - In document pls use proper names of tables on page 130: OLD: o the mplsLdpEntityTable, mplsLdpPeerTable, mplsLdpSesTable and mplsLdpSesStatsTable collectively show the LDP LSP network NEW: o the mplsLdpEntityTable, mplsLdpPeerTable, mplsLdpSessionTable and mplsLdpSessionStatsTable collectively show the LDP LSP network - In document pls use parentheses instead of double quotes (Security Considerations section, pages 130-133). There are some 11 occurences. The authors took this from MIB security Guidelines, but their WORD processor turned the parentheses into double quotes... Oh well. - In document pls use parentheses instead of double quotes (Security Considerations section, page 63). There are some 6 occurences. The authors took this from MIB security Guidelines, but their WORD processor turned the parentheses into double quotes... Oh well. From owner-mpls@UU.NET Fri Dec 5 17:06:32 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28900 for ; Fri, 5 Dec 2003 17:06:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpruu23314 for ; Fri, 5 Dec 2003 22:06:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpruu23135; Fri, 5 Dec 2003 22:06:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQprus10549 for mpls-outgoing; Fri, 5 Dec 2003 21:44:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQprus10514 for ; Fri, 5 Dec 2003 21:44:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQprus17243 for ; Fri, 5 Dec 2003 21:43:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprus24179 for ; Fri, 5 Dec 2003 21:43:46 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQprus24145 for ; Fri, 5 Dec 2003 21:43:45 GMT Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2003 13:44:39 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB5Lhgjq012098 for ; Fri, 5 Dec 2003 13:43:42 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEL72568; Fri, 5 Dec 2003 16:43:41 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB5LhfZ15399 for mpls@uu.net; Fri, 5 Dec 2003 16:43:41 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQprus10457 for ; Fri, 5 Dec 2003 21:42:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQprus01771 for ; Fri, 5 Dec 2003 21:41:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQprus24206 for ; Fri, 5 Dec 2003 21:41:54 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQprus24157 for ; Fri, 5 Dec 2003 21:41:52 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hB5Lfv2F092023; Fri, 5 Dec 2003 16:42:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200312052142.hB5Lfv2F092023@workhorse.fictitious.org> To: "Adrian Farrel" cc: "'mpls@uu.net'" Reply-To: curtis@fictitious.org Subject: Re: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt In-reply-to: Your message of "Tue, 02 Dec 2003 23:26:42 GMT." <037c01c3b939$929f1740$a9b39ed9@Puppy> Date: Fri, 05 Dec 2003 16:41:57 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <037c01c3b939$929f1740$a9b39ed9@Puppy>, "Adrian Farrel" writes: > All, > > I have published a draft to start the ball rolling in the great hard/soft pre > -emption > debate. > There is no doubt that the draft is rambling and wrong. > > Please enter into a detailed and heated debate. Since Kireeti declined, I'll fulfill your request. > In summary... > > The points of contention are: > - Should pre-emption cause the associated LSP to be torn down > - at the point of pre-emption > - at all other LSRs along the LSP? > - If it is torn down, is it torn using PathErr and ResvErr? > - What is the correct processing of a PathErr after an LSP has > been successfully established. > - Is it possible for hard and soft pre-emption to co-exist in a > network if they both use the same signalling technique? > > A lot of the answers seem to hang on how admission control is performed. Is i > t per LSP or > is it statistical? > > It does not appear to be very fruitful to investigate > - the 'correct' interpretation of RFC3209 > - the motivation for the Path_State_Removed flag in RFC3473 > (You are, however, perfectly free to investigate whatever you like!) > > Cheers, > Adrian Overall its a good description of the problem. Section 4 is close but not quite right. But the whole section is irrelevant. Soft preemption only makes sense if hard reservations are not made up to the point where resources are exhausted. What you describe as pure statistical admission control is on one end of the spectrum but there is middle ground between hard reservations and none at all. In section 5 - the preempted LSP need not use best effort. If there are multiple services using at higher priority (lower numeric holding priority) may still fit or the preempted service may need be downgraded, but not to best effort. For example, consider a network where priority 3 is very low delay EF and allowed to reserve 5% of bandwidth and 4 is low delay EF and sum of priority 3 and 4 EF is allowed to reserve 10% of link bandwidth, priority 5 is an AF service and the sum of the EF and AF is allowed to reserve 30% of link bandwidth, and prior 7 is best effort but to keep congestion loss low, the best effort too is limited (though perhaps allowed to exceed 100% of link bandwidth). If an additional priority 3 arrives, taking the absolute shortest path available, then a priority 4 LSP may be displaced. Since the limit of 10% is only an administrative goal, the priority 4 LSP can be soft preempted and continue to consume EF resources. It need not be downgraded to AF and lose the delay characteristics. If a priority 3 or 4 LSP is added a priority 5 LSP may be preempted. If may continue to use AF service since doing so will only put a further squeeze on best effort. In either case, if the soft preempt does not result in a reroute by the ingress then a hard preempt should occur. If no resources are reserved, then the above does not apply. However the case where no resources are reserved is not the only case where soft preemption makes sense, contrary to what you've written. The whole point of doing soft preemption is to give the ingress the option to do a prompt make-before-break reroute. You could probably replace all of section 4 and 5 with that statement and this draft would be no worse for it (and probably better). Otherwise you have lots of fixing up to do because you have painted the world black and white. The whole problem that resulted in the current implementations use of hard preemption and the need for an explicit soft-preemption mechanism is summarized in section 5.5: There is no way to distinguish from the received message whether the pre-emption point performed soft or hard pre-emption. Even with soft preemption the midpoint LSR need a way to tell the ingress that the soft preeemption grace period has expired. Definition of the path err with state removal and notify occurred *after* many implementation were written and some deployed. The result has been that path err is still assumed to be hard preemption by many implementations. The set of solutions for soft preemption is in section 7. Maybe you should just skip sections 4 and 5 which are not entirely correct anyway and catalog the solution space. The soft preempt draft provides an interoperable solution given that some routers in the field will tear down on path err. The problem with just sending patherr is that the ingress needs to know which LSR are genuinely out of resources and which ones are still holding resources. It is silly to propose a solution that works for the simple case where one new LSP is added but is unsatisfactory for the common case where a link failure occurs and many preemptions occur simulataneously. So it makes sense to look at that case. If the minimum number of LSPs are to be displaced then each LSR both forward and back in the path should know when another LSR has done a preemption on a LSP so that LSR can select the same one. Therefore a single LSP will have lost resources (from an administrative standpoint only) at multiple midpoint LSR. If a make-before-break is to be done by the ingress, the ingress must know which links no longer have resources and which do. The information in the RRO summarizes this for a given LSP. Noting that zero bandwidth is available on a specific link for a given holding priority does not provide adequate information because it must be known whether that full link includes the bandwidth of the LSP being replaced or if that link is among those for which bandwidth is no longer being reserved for that LSP. It is also worth noting that there is no significant network disruption after a fault if FRR is in use and very little if standby LSP (fully disjoint backup LSP signaled from the ingress) or disjoint multipath (fully disjoint LSP signaled from the ingress with load spliting that temporarily falls back to using one less path after a fault). With soft preemption the reallocation of resources can be orderly and involve no further disruption, except for any brief delay discontinuity resulting from make-before-break reroutes. After a fault, LSP can be rerouted in a way that tends toward close to optimal use of resources without significant disruption during this reoptimization. With any of the backup traffic methods mentioned above, the reoptimization need not be rushed (ie: it need not occur faster than feedback on change in network usage can be provided by reflooding if no loss is occurring except limited congestion for best effort traffic). Curtis From owner-mpls@UU.NET Fri Dec 5 17:40:12 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00637 for ; Fri, 5 Dec 2003 17:40:12 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpruw18693 for ; Fri, 5 Dec 2003 22:40:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpruw18530; Fri, 5 Dec 2003 22:40:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQpruv02471 for mpls-outgoing; Fri, 5 Dec 2003 22:18:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQpruv02466 for ; Fri, 5 Dec 2003 22:17:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQpruu06211 for ; Fri, 5 Dec 2003 22:13:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpruu01463 for ; Fri, 5 Dec 2003 22:13:22 GMT Received: from cerberus.uk.clara.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cerberus.uk.clara.net [195.8.69.103]) id QQpruu01435 for ; Fri, 5 Dec 2003 22:13:22 GMT Received: from du-069-0290.access.clara.net ([217.158.145.36] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1ASOCO-000DJv-Uo for mpls@UU.NET; Fri, 05 Dec 2003 22:13:21 +0000 Message-ID: <087901c3bb7d$0850b940$a9b39ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: draft-ietf-mpls-rsvpte-attributes-00.txt Date: Fri, 5 Dec 2003 22:12:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm pretty sure I didn't see an announcement for this. http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-00.txt Stand by for some improvements to the document. Cheers, Adrian From owner-mpls@UU.NET Mon Dec 8 11:55:55 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17994 for ; Mon, 8 Dec 2003 11:55:55 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsfb04893 for ; Mon, 8 Dec 2003 16:56:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpsfb04649; Mon, 8 Dec 2003 16:56:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQpsfa27384 for mpls-outgoing; Mon, 8 Dec 2003 16:35:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQpsfa27379 for ; Mon, 8 Dec 2003 16:35:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQpsfa04135 for ; Mon, 8 Dec 2003 16:32:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsfa04635 for ; Mon, 8 Dec 2003 16:32:45 GMT Received: from smtp7.hy.skanova.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp7.hy.skanova.net [195.67.199.140]) id QQpsfa04623 for ; Mon, 8 Dec 2003 16:32:45 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hB8GVqP7013381; Mon, 8 Dec 2003 17:31:52 +0100 (CET) Message-ID: <3FD4A766.8050802@pi.se> Date: Mon, 08 Dec 2003 17:31:34 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Allison Mankin , George Swallow Subject: RSVP Change - Last Call] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS-WG, we have been notified that the draft-kompella-rsvp-change-01.txt has been last called for BCP, please comment directly to the IESG on iesg@ietf.org or ietf@ietf.org mailing lists by 2003-12-29. /Loa ------------------forwarded message ------------------------------- The IESG has received a request from an individual submitter to consider Procedures for Modifying RSVP as a BCP. This has been reviewed in the IETF and particular interest was expressed by the Transport Working Group (tsvwg), but it was not developed as the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-12-29. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-kompella-rsvp-change-01.txt ------- End of Forwarded Message -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Mon Dec 8 14:23:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25584 for ; Mon, 8 Dec 2003 14:23:10 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsfl06757 for ; Mon, 8 Dec 2003 19:23:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpsfl06475; Mon, 8 Dec 2003 19:23:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQpsfk05526 for mpls-outgoing; Mon, 8 Dec 2003 19:06:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQpsfk05471 for ; Mon, 8 Dec 2003 19:06:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQpsfk23069 for ; Mon, 8 Dec 2003 19:04:43 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsfk12703 for ; Mon, 8 Dec 2003 19:04:43 GMT Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86]) id QQpsfk12678 for ; Mon, 8 Dec 2003 19:04:42 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB8J4cDM023904 for ; Mon, 8 Dec 2003 14:04:38 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEM71819; Mon, 8 Dec 2003 14:04:37 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB8J4a506140 for mpls@uu.net; Mon, 8 Dec 2003 14:04:36 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQpsfk27376 for ; Mon, 8 Dec 2003 19:02:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQpsfk11561 for ; Mon, 8 Dec 2003 19:00:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsfk08079 for ; Mon, 8 Dec 2003 19:00:55 GMT Received: from asgard.ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: asgard.ietf.org [132.151.6.40]) id QQpsfk08049 for ; Mon, 8 Dec 2003 19:00:54 GMT Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATQcm-0008Kj-J7; Mon, 08 Dec 2003 14:00:52 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base' to Proposed Standard Message-Id: Date: Mon, 08 Dec 2003 14:00:52 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved following document: - 'Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The document defines MIB objects for MPLS Label Switching Router Working Group Summary There was a WG consensus to progress this document Protocol Quality The document has been review for the IESG by Bert Wijnen and Mike MacFaden From owner-mpls@UU.NET Tue Dec 9 17:20:02 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20271 for ; Tue, 9 Dec 2003 17:20:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsjp21978 for ; Tue, 9 Dec 2003 22:20:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpsjp21739; Tue, 9 Dec 2003 22:20:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQpsjo17572 for mpls-outgoing; Tue, 9 Dec 2003 22:03:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQpsjo17493 for ; Tue, 9 Dec 2003 22:03:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQpsjo20693 for ; Tue, 9 Dec 2003 22:01:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsjo22660 for ; Tue, 9 Dec 2003 22:01:35 GMT Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQpsjo22650 for ; Tue, 9 Dec 2003 22:01:34 GMT Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2003 14:03:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB9M1VBN007516 for ; Tue, 9 Dec 2003 14:01:32 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEN76663; Tue, 9 Dec 2003 17:01:30 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hB9M1UD18329 for mpls@uu.net; Tue, 9 Dec 2003 17:01:30 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQpsjo08431 for ; Tue, 9 Dec 2003 22:00:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQpsjn16513 for ; Tue, 9 Dec 2003 21:59:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsjn23397 for ; Tue, 9 Dec 2003 21:59:46 GMT Received: from asgard.ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: asgard.ietf.org [132.151.6.40]) id QQpsjn23379 for ; Tue, 9 Dec 2003 21:59:46 GMT Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATptF-0001Dl-Qk; Tue, 09 Dec 2003 16:59:33 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management' to Proposed Standard Message-Id: Date: Tue, 09 Dec 2003 16:59:33 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the following documents: - 'Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management ' as a Proposed Standard - 'Multiprotocol Label Switching (MPLS) Management Overview ' as an Informational RFC These documents are products of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The documents describe a MIB module with Textual Conventions to represent commonly used MPLS management information that would be used in other MPLS related MIB modules, as well as the management architecture for MPLS that indicates the inter-relationships between the different MIB modules used for MPLS network management. Working Group Summary There was a WG consensus to advance these documents Protocol Quality The documents have been reviewed for the IESG by Bert Wijnen From owner-mpls@UU.NET Tue Dec 9 17:47:22 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21477 for ; Tue, 9 Dec 2003 17:47:22 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsjr04736 for ; Tue, 9 Dec 2003 22:47:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpsjr04550; Tue, 9 Dec 2003 22:47:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQpsjp24761 for mpls-outgoing; Tue, 9 Dec 2003 22:28:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQpsjp24756 for ; Tue, 9 Dec 2003 22:28:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQpsjp15236 for ; Tue, 9 Dec 2003 22:27:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsjp05943 for ; Tue, 9 Dec 2003 22:27:43 GMT Received: from smtp7.hy.skanova.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp7.hy.skanova.net [195.67.199.140]) id QQpsjp05932 for ; Tue, 9 Dec 2003 22:27:42 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hB9MRfYE006045 for ; Tue, 9 Dec 2003 23:27:41 +0100 (CET) Message-ID: <3FD64C5D.2030208@pi.se> Date: Tue, 09 Dec 2003 23:27:41 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg Subject: MPLS MIBs to be prublished as RFCs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I've just seen the last note to the RFC-editor from the IESG requesting that our MIB documents are published as RFCs. Management Overview as informational and the ftn-mib, ldp-mib, lsr-mib, tc-mib and te-mib as Proposed Standard. Please join me in congratulating all the authors and in my thanks to all the people that has been involved in commenting and reviewing the documents. I won't mention anyone in particular because it has been an effort involvning quite a number of people. Thanks everyone! /Loa -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Wed Dec 10 06:07:44 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07252 for ; Wed, 10 Dec 2003 06:07:44 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpslo00512 for ; Wed, 10 Dec 2003 11:07:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQpslo00413; Wed, 10 Dec 2003 11:07:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQpsln14509 for mpls-outgoing; Wed, 10 Dec 2003 10:50:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQpsln14504 for ; Wed, 10 Dec 2003 10:50:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQpsln29467 for ; Wed, 10 Dec 2003 10:49:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQpsln09902 for ; Wed, 10 Dec 2003 10:49:47 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bay8-f6.bay8.hotmail.com [64.4.27.6]) id QQpsln09881 for ; Wed, 10 Dec 2003 10:49:47 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Dec 2003 02:49:46 -0800 Received: from 57.250.229.136 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 10 Dec 2003 10:49:46 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. ELK" To: mpls@UU.NET Subject: MPLS-FTN-MIB and ECMP Date: Wed, 10 Dec 2003 10:49:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Dec 2003 10:49:46.0593 (UTC) FILETIME=[53AD7D10:01C3BF0B] Sender: owner-mpls@UU.NET Precedence: bulk Hi posted below in mpls-ops list and got no reply (may be the question's are so dum ) ,hopefully i will have better chance in mpls list . Brgds 1- Say an entry in mplsFTNTable pointing to an LSP(s) in mplsXCTable (assuming LDB) ,how we could specify that such entry in mplsFTNtable could be pointing to say 2 LSP for ECMP (Equal Cost Multi Path) . 2- Could it be done this way : the value mplsFTNActionpointer to be set to say mplsXCLspId.500.0.0 in the mplsXCtable we create the following 2 entry entry 1 : mplsXCindex= 500 mplsInsegementIndex=0 mplsOutSegmentIndex=6000 entry 2 : mplsXCindex= 500 mplsInsegementIndex=0 mplsOutSegmentIndex=7000 ie: the mplsFTNActionPointer point to a "GROUP" of LSP's (the group is identified by having several row in mplsXctable with the same value of mplsXCindex ) . 3- In case point "2" above is a (theoretical) valid option . in CSCO implem of LSR-MIB they took the convention to set the value of mplsXCindex to be equal to mplsOutSegmentIndex value so point "2" above will not be the way for CSCO to implement ECMP so what other way(s) available to speify a ECMP for certain entry in mplsFTNTable . Brgds _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-mpls@UU.NET Thu Dec 18 17:38:56 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25296 for ; Thu, 18 Dec 2003 17:38:56 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptqw17100 for ; Thu, 18 Dec 2003 22:38:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQptqw16993; Thu, 18 Dec 2003 22:38:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQptqu09617 for mpls-outgoing; Thu, 18 Dec 2003 22:12:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQptqu09612 for ; Thu, 18 Dec 2003 22:12:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQptqu24234 for ; Thu, 18 Dec 2003 22:08:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptqu11052 for ; Thu, 18 Dec 2003 22:08:33 GMT Received: from smtp5.hy.skanova.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp5.hy.skanova.net [195.67.199.134]) id QQptqu11017 for ; Thu, 18 Dec 2003 22:08:32 GMT Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hBIM7ber028822; Thu, 18 Dec 2003 23:07:37 +0100 (CET) Message-ID: <3FE22525.2020300@pi.se> Date: Thu, 18 Dec 2003 23:07:33 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com, MPLS wg , te-wg@ops.ietf.org CC: "'Maarten.Vissers@alcatel.de'" , stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org Subject: Re: [802.1] Re: [PWE3] Next Generation CO-PS layer network technology? References: <3FE02FEC.8020208@cisco.com> In-Reply-To: <3FE02FEC.8020208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS and TEWG, this is a mail that has been on the PWE3 mailings list, since it concerns the tewg and mpls wg, I'm forwarding it the working group mailing lists also. As Stewart says it is interesting, but I often find it more interesting to read things I disaggree with, than things I aggree with. My take is that CO-MPLS is out of scope for the MPLS WG also. /Loa Stewart Bryant wrote: > > Maarten > > Although this is interesting work, it does not seem to fall > within the charter of PWE3. > > The PWE3 charter is concerned with the emulation of services > over the PSN infrastructure for which the IETF is the design > authority. PWE3 would be the right place to consider EMULATING > CO-MPLS over an IETF specified PSN, but it is not the right > place to design CO-MPLS. > > This work would seem to be better directed at the MPLS or > TEWG working groups. > > - Stewart > > Akiva Sadovski wrote: > >> Hi Maarten, >> thank you for very interesting NG CO-PS summary. 1) However i'm >> wondering whether we really need *both* SNCP and SPRing at >> initial stages of >> NG CO-PS development. >> 2) As far as i know, there were some SNCP-like mechanisms for >> Ethernet under >> development, like draft-shah-extreme-eaps-00.txt >> >> My 2c, >> Akiva Sadovski >> >> >>> -----Original Message----- >>> From: Maarten.Vissers@alcatel.de [mailto:Maarten.Vissers@alcatel.de] >>> Sent: Friday, December 12, 2003 3:05 PM >>> To: stds-802-1@ieee.org; tsg15q12@itu.int; pwe3@ietf.org >>> Subject: [PWE3] Next Generation CO-PS layer network technology? >>> >>> >>> As we are approaching the end of the year 2003 and many of use looking >>> forward to one or more weeks of vacation (to get rid of all left over >>> vacation days), I would like to provide some food for your thoughts >>> under the Christmas tree. >>> >>> INTRODUCTION >>> ------------ >>> I have the feeling that 2004 will become known in history as the year >>> in which we selected/developed the Next Generation Connection Oriented >>> Packet Switched (NG CO-PS) layer network technology, which will be the >>> successor of FR and ATM. I would therefore like to initiate a >>> discussion >>> on this topic. >>> >>> CURRENT LANDSCAPE >>> ----------------- >>> When I look at the current NG CO-PS landscape, I see four alternatives >>> that are being considered, discussed, investigated, developped and/or >>> installed: >>> >>> 1) CO-PS MPLS (switched MPLS) >>> 2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN) >>> 3) CO-PS GFP (switched GFP) >>> 4) something new. >>> >>> The first three alternatives have as starting point the >>> re-use/multi-use of existing popular frame/packet formats: >>> 1) MPLS packet with its shim header (label, EXP, S, TTL): >>> 2) tagged MAC frame (ethertype, VLAN ID, priority, CFI) >>> 3) GFP-F frame with linear extension header (Channel ID, spare). >>> >>> BASIC NG CO-PS CHARACTERISTICS >>> ------------------------------ >>> NG CO-PS frame/packet format needs to support the following fields: >>> a) tributary slot identifier (label, VLAN ID, channel ID) >>> b) class of service/dropping precedence (EXP, priority) >>> >>> NG CO-PS frame/packet format needs to support the following >>> networking capability: >>> c) multi-level hierarchy (tunneling) capability to allow it to >>> be used in (metro-)access, metro(-core) and core networks. >>> >>> NG CO_PS technology needs to support connection monitoring according >>> the G.805 paradigm; this includes: >>> d) connection monitoring for each (tunnel) level in the hierarchy >>> e) multi-level (nested) connection monitoring capability for user >>> connections, to allow dedicated connection monitoring for user, >>> service provider and network operator(s) as well as for protection >>> and restoration. >>> f) pro-active fault management and performance monitoring OAM for >>> user connections and hierarchy levels (tunnels) >>> g) on-demand fault localisation OAM for user connections and >>> hierarchy levels. >>> Note: Non intrusive monitoring of any connection monitoring level at >>> an intermediate point in the connection for the service provider is a >>> requirement for today's SDH/SONET and OTH networks, in the absence of a >>> standard "service management" architecture. With the work on the >>> Architecture for Services Management (G.asm) being started in Q.12/15, >>> the NG CO-PS may not require this non-intrusive connection >>> monitoring of any connection monitoring level. This removes a >>> significant requirement. >>> >>> NG CO-PS technology needs to support connection oriented protection >>> and restoration; this includes: >>> h) subnetwork connection protection (SNCP) >>> i) ring protection (SPRing). >>> >>> NG CO-PS layer network needs to support: >>> j) client/server relationships (mapping, network interworking) >>> k) G.805 layer network interworking (service interworking) >>> with existing CO-PS layer network technologies. >>> >>> >>> EVALUATION OF CURRENT FRAME FORMATS >>> ----------------------------------- >>> The MPLS packet format is considered as it provides the closest >>> match with >>> the basic characteristics required for the NG CO-PS technology. >>> a) trib slot id: 20-bit label >>> b) CoS/DP: 3-bit EXP >>> c) hierarchy: infinite tunneling capability >>> d) tunnel conn. mon.: MPLS OAM >>> e) nested conn. mon.: MPLS OAM >>> f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI) >>> g) on-demand fault loc.: MPLS OAM (ping) >>> h) SNCP: MPLS protection switching >>> Further enhancements/extensions are required. >>> i) SPRing: to be developed >>> j) mapping: IP: available, ATM, FR, ETH: under development >>> k) LN IW: MPLS/ATM, MPLS/FR under development. >>> By using MPLS as the NG CO-PS packet format, the "M" in MPLS gets a >>> second >>> meaning; this "M" originally referred to it being a protocol that >>> can ride >>> over multiple server layer protocols, with the deployment as NG >>> CO-PS it also refers to multiple client layer protocols that can >>> ride over it. >>> >>> >>> The Ethernet MAC tagged frame format is considered due to the low cost >>> of today's ethernet interface ports. The Ethernet MAC frame is >>> developed >>> for use in bridged-ethernet networks; its use as NG CO-PS would >>> require a >>> number of extensions: >>> a) trib slot id: 12-bit VLAN ID >>> b) CoS/DP: 3-bit priority >>> c) hierarchy: potential VLAN stacking capability >>> Requires new CO-PS VLAN tags to be defined; QTag and >>> STag should not be used as these are for bridged-ethernet, >>> not >>> for switched-ethernet/VLAN. >>> d) tunnel conn. mon.: to be developed >>> e) nested conn. mon.: to be developed >>> f) pro-active fm/pm: to be developed >>> g) on-demand fault loc.: to be developed. >>> The current bridged-ETH OAM development in Q.3/13 may be >>> the basis for d) to f) >>> h) SNCP: to be developed >>> i) SPRing: to be developed >>> j) mapping: IP, MPLS: available, ATM, FR: ? >>> k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed? >>> x) development of connection oriented VLAN switching. >>> Switched-Ethernet/VLAN will use the ethernet MAC frame as encapsulation >>> format for multiple client signals. The implication of this is to be >>> understood. >>> >>> >>> The GFP-F frame format is considered as it is the latest frame format >>> developed within the standards organisation (ITU-T) that traditionally >>> defines connection oriented layer technologies. GFP-F is an >>> encapsulation >>> frame format and its use as NG CO-PS would require a number of >>> extensions: >>> a) trib slot id: 8-bit channel ID >>> D.371 (SG15, 04/02) proposes a 20-bit Flow ID. >>> b) CoS/DP: to be developed >>> D.370 (SG15, 04/02) proposes a 3-bit Priority field. >>> c) hierarchy: to be developed >>> Requires capability to support stacking in the extension >>> header. >>> 58 bytes are available in the extension header area for such >>> purpose. With e.g. 3-bytes per level (20-bit label, 3-bit >>> CoS/DP, 1-bit bottom of stack), 19 levels can be supported. >>> d) tunnel conn. mon.: to be developed >>> e) nested conn. mon.: to be developed >>> f) pro-active fm/pm: to be developed >>> g) on-demand fault loc.: to be developed. >>> h) SNCP: to be developed >>> i) SPRing: to be developed >>> j) mapping: to be developed >>> k) LN IW: to be developed >>> x) development of connection oriented GFP switching. >>> >>> >>> CO-EXISTENCE >>> ------------ >>> For the case we will select one of the three existing frame/packet >>> formats >>> as basis for the NG CO-PS layer network, it will have to peacefully >>> co-exist >>> with the original application; i.e. the NG CO-PS development should >>> not hijack >>> the frame/packet format. This requires cooperation and recognition >>> of the needs >>> of both the original and the new NG CO-PS application. >>> >>> If the current "owners" of the frame/packet formats (MPLS: IEFT, >>> MAC: IEEE 802, >>> GFP-F: ITU-T SG15) are not able/do not want to share their >>> frame/packet format >>> with the new NG CO-PS application, that frame/packet format should >>> not be >>> considered as a NG CO-PS frame/packet format candidate. >>> >>> I am therefore very interested to hear the opinion of the >>> participants of IETF, IEEE 802 and ITU-T SG15 on the multi-use of >>> their frame/packet format as NG CO-PS >>> frame/packet format. >>> >>> >>> EQUIPMENT >>> --------- >>> The NG CO-PS layer network will introduce one additional switching >>> technology or >>> switching technology profile in the multi service switching >>> platforms (MSSPs). >>> >>> Some existing MSSPs may already support elements of the NG CO-PS >>> and/or may be >>> upgradable to support NG CO-PS. Others may not support any element >>> of the NG CO-PS >>> and may not be upgradable. That's just how life is; it should not >>> play a major role >>> in the decision process for the NG CO-PS in my opinion. >>> >>> >>> Up to so far. Looking forward to your opinions on this item. >>> >>> Regards, >>> Maarten >>> >>> >>> --------------------------------------------------------------------- >>> Maarten Vissers >>> Network and Product Strategy - Optical Networks Division >>> Alcatel SEL AG Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany >>> Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands >>> Mobile: +31 65 141 8140 >>> Email:Maarten.Vissers@alcatel.de >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > > =>IEEE 802.1 Email List user information: > http://www.ieee802.org/1/email-pages/ > > -- Loa Andersson mobile +46 739 81 21 64 From owner-mpls@UU.NET Thu Dec 18 18:37:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28591 for ; Thu, 18 Dec 2003 18:37:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptra02890 for ; Thu, 18 Dec 2003 23:37:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQptra02791; Thu, 18 Dec 2003 23:37:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQptqz03587 for mpls-outgoing; Thu, 18 Dec 2003 23:15:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQptqz03582 for ; Thu, 18 Dec 2003 23:15:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQptqz21250 for ; Thu, 18 Dec 2003 23:15:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptqz23030 for ; Thu, 18 Dec 2003 23:15:01 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQptqz22999 for ; Thu, 18 Dec 2003 23:15:01 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBINFE607824 for ; Thu, 18 Dec 2003 17:15:31 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 19 Dec 2003 00:13:58 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155032D9B71@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Loa Andersson , stbryant@cisco.com, MPLS wg , te-wg@ops.ietf.org Cc: "'Maarten.Vissers@alcatel.de'" , stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org Subject: RE: [802.1] Re: [PWE3] Next Generation CO-PS layer network techno logy? Date: Fri, 19 Dec 2003 00:13:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The only thing I REALLY HOPE for is that we will NOT GET a lot of cross-posting on this/these topics. I do not believe that the topic belongs on TEWG, but I will let the TEWG chairs speak too. In any event, the TEWG is preparing to close down. I wish people create a new mlist for this and use that SINGLE list for discussions. Thanks, Bert From owner-mpls@UU.NET Fri Dec 19 16:52:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29158 for ; Fri, 19 Dec 2003 16:52:34 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptul20547 for ; Fri, 19 Dec 2003 21:52:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQptul20413; Fri, 19 Dec 2003 21:52:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQptuk07974 for mpls-outgoing; Fri, 19 Dec 2003 21:38:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQptuk07969 for ; Fri, 19 Dec 2003 21:38:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQptuk28080 for ; Fri, 19 Dec 2003 21:37:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptuk03572 for ; Fri, 19 Dec 2003 21:37:47 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQptuk03549 for ; Fri, 19 Dec 2003 21:37:46 GMT Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Dec 2003 13:41:23 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBJLbhC6005804 for ; Fri, 19 Dec 2003 13:37:43 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEU59520; Fri, 19 Dec 2003 16:37:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hBJLbgw28495 for mpls@uu.net; Fri, 19 Dec 2003 16:37:42 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQptuk07918 for ; Fri, 19 Dec 2003 21:36:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQptuk15826 for ; Fri, 19 Dec 2003 21:34:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQptuk05692 for ; Fri, 19 Dec 2003 21:34:37 GMT Received: from sj-iport-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87]) id QQptuk05675 for ; Fri, 19 Dec 2003 21:34:36 GMT Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 19 Dec 2003 21:35:21 +0000 Received: from cisco.com (lir.cisco.com [161.44.172.144]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBJLYYK6018193; Fri, 19 Dec 2003 16:34:34 -0500 (EST) Message-Id: <200312192134.hBJLYYK6018193@rtp-core-2.cisco.com> To: proceedings@ietf.org Cc: mpls@UU.NET Subject: MPLS WG Minutes X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.1.1 Date: Fri, 19 Dec 2003 16:34:34 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS Working Group WG Chairs: George Swallow , Loa Andersson Tom Nadeau took the minutes - Thanks Tom! NOTE: [NNG] means that the speakers name was not given at the mike. 1. Agenda Bashing/Update Loa -- MPLS has been rechartered within routing area. MIB modules/management overview have been sent to the IESG. 2. Encoding of Attributes for LSP Establishment Using RSVP-TE Adrian Farrel Adrian -- Asked to make this a WG document? George -- Room support? (no hands) non-support (no hands) Continue discussion on the list. 3. RSVP Graceful Restart Extension Reshad Rahman Adrian Farrel -- Should this be in CCAMP? George -- They didn't ask me, but I suggest it goes in CCAMP. The only rationale for MPLS might be that there is slightly lower work load here. Rahul -- Why isn't it enough to just recover. Why do we need this? Reshad -- If a node preforms ERO expansion prior to the restart, it may not have sufficient information to construct the some ERO expansion. After a bit of discussion and polling the room, it would appear that there is a fair amount of interest and that the work belongs in CCAMP. 4. TTL-Based Security Option for LDP Hello Message Albert Tian Alex Zinin -- You cannot negotiate security messages with an insecure mechanism. There are DOS attack potentials. Albert -- The multicast addresses are harder to spoof. Alex -- I understand how the TTL hack works. But the fact that you are trying to negotiate the usage using insecure messages is the problem. Albert -- "secure" is relative here. Alex -- Take to list. George -- are there any SPs that feel there is a need for this? (silence) 5. LDP signaled LSPs for external prefixes Ina Minei Eric -- I see no advantage to do this. Dangerous to distribute routing information w/ non-routing protocols. Yakov -- We have seen this movie before. There are no issues with overloading LDP. Luca -- You are adding more state to your core routers to support this. Why not use iBGP to do this? George -- Asked a question about label withdraw times in the event of a failue. Won't that slow convergence? Alex -- If you have more than one originator injecting more than one FEC, how do you break the tie? Ina -- You consider this and do something smarter at the tail end. Alex -- External prefixes are injected into LDP. Have you compared the overhead of this versus that of using IGPs? Ina -- don't see why this is an issue. Alex -- This assumes external prefixes are injected into an IGP. How much state will routers have to maintain versus in the normal ibgp case. Ina -- If you are trying to compare an IGP to an LDP solution. Luca -- Clarification. In an IBGP you don't have to run this anywhere but in the edge routers (BGP free core). There is less state in the core. Using your solution you add more state to the core. Ina -- but it has more danger of misconfiguring your distribution. Vach -- Best for Luca to resubmit his BGP short-cuts draft which would fix this problem. If I wanted such a solution I would rather do this than the current one. George -- Continue this on the list. 6. Requirements for Point to Multipoint extension to RSVP-TE Seisho Yasukawa Loa -- Comments? Yiqun Cai -- ID is taqlking about requirement of P2MP lsps (TE), but also describes an extension to RSVP-TE. This seems that the WG has already decided to extend RSVP_TE. The better way would be to split them, and address both requirements separately. Second, this talks about mcast deployment in a service provider environment. I think this needs to be presented in the MWG and discussed. Dave Meyer -- I had discussed this with George, but ran out of agenda time. This should be discussedin MWG. James Miles -- Dmitri's earlier point talked about whether this was a requirements document? Are we going to extend this? What is the scope of the document? Seems that the next step is that providers need to run RSVP-Te to the edge. Loa -- When we wrote this it was to describe how p2mp TE LSPs worked. Loa -- Could I see the support in the room to make this a WG document. A fiar number. Oppositoion. A few. Need to confirm on the list that there is good support w/ a few opposing. People that were opposed should speak at the Mike. Toerless -- I don't understand how this framework is supposed to work. The document seems to jump over one architectural element (p2mp). Yiqun -- The document tries to address mcast vpn and other items. We need to discuss whether or not this best solves this problem usiung p2mp RSVP-TE LSPs or something else. George -- I would tend to agree with that last comment. 7. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels Seisho Yasukawa/Allan Killberg [Update on state of draft] George -- Can't do anything on this on the next draft until we get the requirments accepted. 8. IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core Rahul Aggarawal George -- When the RPE gets an indication of the interface, how does that count? Rahul -- The SPE sends a joint ack message. George -- what goes into it? Rahul -- it contains a set of messages including the PTMP ids. George --- you are keeping labels at the last hop to keep context? Rahul -- this is just the session object. George -- If you have more than one tunnel, you would have to turn PHP off. [NNG] -- Are the labels interface or global space? Rahul -- doesn't matter. [NNG] -- The way you use labels to distinguish label states. Does this support PIMSM, but you did not describe how these are forwarded. Rahul -- Sure, I can add that. George -- Please show up at 1 to continue discussion (PIM?) 9. Requirements for multicast service using a group label over MPLS Min Suk Sung George -- Discussion on the draft... Andy Malis -- When we sections 4.5, this is not a requirements draft; it contains protocol specifications. There are requirements in section 4.3, but these assume a mechanism (group label) and just reverse engineer that. Really doesn't talk about requirements. George -- Other point that Loa made is that originally when we started MPLS, we made an architectural decision to not have globally unique labels. We would need to change this to accomodate this draft. Min -- We tried to consider where is the relevant location of the labels. George -- Continue on list. 10. MPLS over Layer 2 Tunneling Protocol (Version 3) Mark Townsley Yakov -- One significant subtle distinction between GRE and L2TP. Neither IP or GRE require signaling, but L2TP requires signaling. Don't combine into two documents. Loa -- I rule that out betcause we have IP/GRE document in WG last call. Yakov -- To have a multi-vendor interop implementation requires specification of both signaling and protocol in standards track at same time. Mark -- Both are specified in two documents in IDR. Yakov -- They are not WG documents. If you want to provide BGP as a signaling mechanism for L2TPvp3. Mark -- There is a section on this. Please read the document. Yakov -- In this case, 2547 is just an example of p2mp signaling (so is VPLS). When you do this, so should signaling be done in BGP? Mark -- Depends on what your VPLS network is using for signling. In general when you want to reach a PE over IP and you say "this is the IP addr of my PE" and you use BGP or wahthave you to signal this, even w/o L2TPv3 encap, when you advertise this normally -- you imply use this PE IP address w/ this protocol ID. I am also saying to also use the cookie in addition to these things. Yakov -- Need another document ot explain that BGP can be used for signaling. On your last point: talk about security that L2TP provides. Before this is a WG document, the security team should review this to make sure that the statements are ok. Eric -- I would like a very small document that explained the encap. Put cookie stuff into security considerations. I disagree w/ Yakov's statement. The cookie value is different depending on how it is signaled. We don't want to start an L2TP signaling paradigm. Yakov -- this document doesn't have to contain signaling. doesn't make sense to progress encap w/ signaling document. Eric -- Signaling is application dependent. George -- Get a sense of the room, not for this draft, but for MPLS/L2TP as an encap type. How many think we need to do this. We have several opposed and several in favor. Continue on list. 11. A Framework for MPLS Data Plane OAM Don Fedyk Eric Rosen -- This is taking MPLS and trying to make it ATM. I recommend starting over. Tom -- I agree w/ Eric. Lets start over. George -- I don't think that we need to throw away everything, but we should be focusing on describing a framework within which we can define tools that meet operational requirements. Loa -- This is why I wanted Dave/Tom to do the edits. Jerry -- I think the document covers the entire solution space. Craig White -- I would like to underscore what the chairs just said. I am not particularly interested in where the technology comes from, but more of what does it do for me. I feel like we are going to end up with hacks to address requirements, but lets document this somewhere. Loa will work to form a design team to create a combined draft between this and the nadeau draft. 12. Detecting MPLS Data Plane Failures Kireeti Kompella / George Swallow Kireeti -- Reviewed latest changes. Draft is nearly complete. A new version will be posted resolving the last few issues. Hope to go to last call prior to Seoul 13. LSR Self Test George Swallow George -- The draft is mostly complete. A few issues are hanging contigent on the lsp ping draft. More discussion on list. 14. BFD For MPLS LSPs Rahul Aggarawal Rahul -- Since BFD is light weight, you can turn on fault-detection on a larger number of LSPs. Subsecond fault detection can be possible (i.e.: bypass LSPs). Alex -- Did you think through the convergence issues w/ subsecond detection and IGP level second-level detection? How are you going to react to the failures found by BFD. Rahul -- The answer is the same as with LSP ping. The operator can take the same action. Alex -- We need to think throught the case where IGPs are notified. Yakov -- One possible scenario. When bypass tunnels go away, you can use the other one. [NNG] -- Since you are doing this over multiple hops. How do you handle congestion in the network and variable delays? George -- BFD allows you to adjust your timers. Lets continue on list. 15. A Supplementary History Module for the MPLS LDP-MIB Wai Sum Lai Tom -- There have been scalability and other technical concerns raised on the list. I suggest that we hear from other SPs. Waisum -- Can you give an example? Tom -- PE with 800 directed LDP sessions. That seems to be a lot of memory/processing to keep track of this, especially over a long period of time. Waisum -- But we are only adding 5 counters. George -- Well, there is more to it than just 5 counters. You are asking us to hold informations forever on expired sessions. The long term implications for memory and CPU need to be considered. Craig White -- I would rather count packets/bytes than fwd packets. However, I don't want to eat all of the memory to do this. I don't want to have fewer VRFs on a PE to keep track of this stuff, for example. Bert -- If you want to look at the scalability of keeping the information needs to be seriously examined. George -- The sense of the room is that something along these lines is useful, but we need to refine the requirements on the list. 16. Hybrid data forwarding for Economy Class Services in MPLS Hyeon Park George - We're out of time - discuss on the list. Meeting Concludes