Subject: RE: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

From: <[email-masked]>
Date: Fri, 2 Jun 2006 15:04:16 +0100

Adrian,

Adrian Farrel <mailto:[email-masked]> wrote:
> Please review, comment, implement (!) and tell us what we have done
> wrong. 

A couple of comments:

Section 4.1, bullet 1 states "P2MP Tunnel table (mplsP2mpTunnelTable)
that sparse augments the MPLS-TE Tunnel table".  I'm not exactly sure
what "sparse augments" means.

Section 4.2, second paragraph - "When an MPLS-TE tunnel is a P2MP
tunnel, certain objects in the mplsTunnelTable are have new meanings",
remove the extraneous "are".

Section 6, states "The nature of P2MP tunnels is such that an LSR that
is crossed by a tunnel may either be the ingress of that tunnel or have
precisely one upstream LSP segment (also known as in-segment [RFC3812])
for that LSP." and "A single P2MP cross-connect has zero or one
in-segment."

draft-ietf-mpls-rsvp-te section 18.1.1 states "There are two approaches
to dealing with re-merge case.  In the first, the node detecting the
re-merge case, i.e., the re-merge node, allows the re-merge case to
persist but data from all but one incoming interface is dropped at the
re-merge node." and "When configured to allow a re-merge case to
persist, the re-merge node receives data associated with the P2MP LSP on
multiple incoming interfaces, but it may only send the data from one of
these interfaces to its outgoing interfaces, i.e., the node MUST drop
data from all but one incoming interface."

So, if I understand correctly there is no way to detect a re-merge in a
P2MP LSP using the MIB specified in draft-farrel-mpls-p2mp-te-mib?

-- 
Ben Niven-Jenkins
Network Architect, BT Exact
  
E-mail: [email-masked] 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 8 Jun 2006 12:36:29 +0200

Benjamin

You asked about sparse augments.

AUGMENTS in SMI [RFC2578] is an alternative to INDEX for a new table with
conceptual rows in one-to-one correspondence with those in an existing, base,
table.  When a row in the base table exists, a row in the augmenting table
exists.  This is widely used in enterprise mibs, when, for example, a maker of
large servers finds the columns in the standard TCP connection table inadequate
and wishes to add information on a per connection basis.

As [RFC2578] points out, this is appropriate when there is a one-to-one
correspondence.  When the new table is sparse compared to the existing one, then
there should be a new table with the same INDEX clause.  mplsP2mpTunnelTable
falls into the latter category.

Re-merge I cannot help you with, but should that reference be to
draft-ietf-mpls-rsvp-te-p2mp-05.txt?.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 02, 2006 4:04 PM
Subject: RE: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

Adrian,

A couple of comments: