The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] =?windows-1255?q?BUG_in_RFC_4379_=28_MPLS_Ping_/_Tracerou?==?windows-1255?q?te=29_-_or_maybe_not_=96_please_enlighten_me?=
Section 4.4.1 in the RFC describes an algorithm for Fec Validation, i.e. a procedure to verify the compatibility between the incoming label and the FEC tlv that describes it. However, it appears that the RFC writers didn’t notice that there are cases in which there is no 1 to 1 compatibility between the incoming labels and FECs. Specifically let me point out the simple LDP ipv4 FEC tlv which includes only a simple prefix to describe any FEC. An LSR advertising the networks to which it is the egress router may advertise different labels to the same network to different LSRs with which it has opened an LDP sessions. This is especially true to LSRs working in Global label space. In general it appears that the RFC writers didn’t take into consideration the issue of different LDP sessions. Note that although the algorithm described in section 4.4.1 also asks to validate the interface through which the echo request packet arrived, this interface is not an indicator for the LDP session (think of several LSRs found in the same network and are connected by a bridge). It is important to note that there are some FEC TLVs in which this issue is not relevant. An example can be the RSVP ipv4 FEC which includes extended-tunnel-id that marks the ping originator and thus have a full 1 to 1 compatibility between the FEC and the incoming label. When an incoming mpls echo request packet, with an LDP ipv4 FEC, reaches an egress LSR (LER), this LSR needs to match between the incoming packet and one of his opened LDP sessions. There are several options to solve this issue: one would be to change RFC 4379 and to add to the LDP ipv4 FEC described in the RFC a ping originator address (this address should be the originator’s transport address). Another option can be to conclude the LDP session from the source ip address of the echo request packet. The last option in my opinion shouldn’t be the preferred one since it requires matching between the incoming packet and the address-list TLV used in the LDP protocol. However even this last option should have been discussed in the RFC. Please enlighten me with your thoughts. Did I miss something in the RFC. Regards Asaf Henig MRV communications.
_______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|