Subject: RE: draft-ietf-mpls-ftn-mib-00.txt is now available

From: Cheenu Srinivasan <[email-masked]>
Date: Fri, 22 Sep 2000 09:40:45 -0400

Marcus Brenner wrote:
>
> In order to be as generic as possible, I think the IP ToS 
> field (DS) and
> the IPv6 flowid should be included in the MplsFTNEntry.
> 

Marcus,

Thanks for the feedback. All diffserv related classification
actions can be defined using the diffserv MIB. Please see:

http://search.ietf.org/internet-drafts/draft-ietf-diffserv-mib-04.txt

Thanks,
Cheenu

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 22 Sep 2000 16:38:05 +0200

Cheenu,

IP src, dest address, src port number, dest port number are also
specified in the DiffServ  MIB, and you do it again, so why not the ToS
field? Are you assuming MPLS edge nodes with plain IP capabilities only?

Marcus

> Cheenu Srinivasan wrote:

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 22 Sep 2000 10:57:45 -0400

Hi Marcus,

>field? Are you assuming MPLS edge nodes with plain IP capabilities only?

         We are not presuming that edge LSRs have diffServ
capabilities. This MIB is solely designed to show packets
which have been queued for label imposition, regardless of
DiffServ capabilties. The idea is that if you wish
to use DiffServ on your edge LSR, then you use the DiffServ
Packet Classifier to impose diff-serv classification. Once
this is complete and the rules are satisfied, the packet
is queued somewhere and is ready for label imposition. This
is the point at which the FTN MIB takes over.

         --Tom

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 22 Sep 2000 17:43:17 +0200

Thomas,

So this means it depends on the hardware architecture of the router. If
you use an output buffered router/switch, only packets already found
their way by other means to the output can be classified. Right? I think
it is not a very general solution but we will see what other think.

However, the question about the IPv6 flow label still remains.

Marcus

-- 

Dr. Marcus Brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 22 Sep 2000 11:47:29 -0400

Hi,

>it is not a very general solution but we will see what other think.

         I don't think it depends on the hardware, and I wouldn't
call it classification, per se. The point of the FTN-MIB is to expose
the FEC to NHLFE mapping which has to happen on all edge LSRs where
IP traffic enters the MPLS cloud and labels must be imposed. How the
prefixes get to MPLS is not an issue; the point is showing
how they enter MPLS once is time to impose labels.

         --Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Sep 2000 13:55:03 -0400

In message <[email-masked]>, "Thomas D. Nad

Thomas,

The DSCP, or more correctly a 64 bit DSCP mask, with one bit per
possible DSCP value should be part of the FEC.  Other implementations
(will) allow different DSCP values for the same IP prefix to be routed
onto different LSP.  Where all DSCP values map into a single LSP, then
the mask is all ones.  (The MIB should not be constrained to match a
specific vendors implementation limitations.)  There is no way to
apply different setup and holding priorities, different adaptivity
parameters, and local protect to some DSCP values and not to other
DSCP values without this capability.

Address ranges should not be used.  Instead CIDR address prefixes
should be used.

In mplsFTNMapIfIndex, is this the physical interface that the LSP goes
out on or is it the ifindex applied to the LSP for implementations
that map an ifindex onto an LSP?

Curtis