The MPLS WG Archive[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
Adrian, Adrian Farrel <mailto:adrian@olddog.co.uk> 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: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|