The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Aug> msg00007



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "Adrian Farrel" <adrian@olddog.co.uk>
  • Date: Sat, 5 Aug 2006 11:51:33 +0100
  • Organization: Old Dog Consulting
  • X-OriginalArrivalTime: 05 Aug 2006 12:45:30.0957 (UTC)FILETIME=[091F17D0:01C6B88D]

Hi Ben, Tom,

Sorry for a belated reply...

> 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.

I think Tom has covered this in his answer.

> 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".

Yup.

> 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?

This is a *really* good point, and we do need to fix it.

The best way, I think, will be to have a special new type of in-segment in 
the LSR MIB. We do not want to show this cross-connected (because it isn't) 
but we do want it to be visible.

Actually, this gives us more of a problem in the TE MIB where we need to 
allow the same LSP to be present on two incoming interfaces.

Cheers,
Adrian



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls