The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Requesting your feedback - issues/errors/clarification s
Title: RE: [mpls] Requesting your feedback - issues/errors/clarification s Let's put the VPN network aside for a bit and suppose we were dealing with a pure IP network. Now here is what is going to happen: 1- Using the independent mode of operation, B associates L10 with the loop back address of node Z and sends a label mapping (L10, Z) to node A. 2- A transmits packets destined to Z using L10. 3- B receives the labeled packet, pops the label, resumes normal IP forwarding and forwards the packet based on its DA. Now, RFC 3031 as Bob mentioned in his e-mail advices against such a practice and suggests that the safest thing to do is to drop the packet. But I think we should be very explicit in the spec. My point is that DU and independent mode of operation at best can result in packet drop. So, we might want to advice against it or at least mention this in RFC 3036. Please find my other comments below: Arashmid -----Original Message-----
In addition to Bob's observation, one of the "known bugs" with MPLS/BGP is that the BGP peers MUST know (in some un-specified way) that there is a continuous LSP from peer to peer before they can use the LSP to carry MPLS/BGP labeled packets. In this case, the ingress PE should not have forwarded the packet using the MPLS/BGP label without "knowing" that the LSP was continuous peer to peer. An example technique might rely on the Hop-Count loop detection mechanism, possibly in conjunction with an IGP routing protocol. [Arashmid]
[Arashmid] As Bob points out, if the LSP is incomplete, the LSR where it terminates SHOULD discard the labeled packets it receives. Remembering that the LSR in the example gave the label L10 out for a FEC for Z, that LSR SHOULD be anticipating that it would forward the enclosed packet toward Z. Finding that the underlying packet is not - as expected - an un-labeled packet (it SHOULD expect this, because it does not have a downstream mapping for a FEC corresponding to Z), it SHOULD discard the packet without processing further. This would result in black-holing the packets, rather than mis- directing them - and would actually be because of a misguided MPLS/BGP implementation, rather than an LDP problem. [Arashmid] Given that the same setup would have worked correctly in a pure IP network, I think the key point in your statement is that the underlying packet is not an un-labeled packet. As such, since node B does not have a downstream mapping for the FEC, it must drop the packet. I agree with your pint here, but again the use of DU and ordered mode would have bettered guaranteed the existence of the downstream mapping. [Arashmid] Even if the LSR did do further processing, it is NOT correct for the LSR to
any such label from the next hop for FEC Z, either, and would then discard the packet. If the LSR pops a label expecting to have terminated an LSP (in other words, not as a result of PHP) associated with an IPv4 FEC, it should expect the underlying packet to be an IPv4 packet and discard it if it is not. We should write specifications to tell people what they need to do the right thing, not to tell them all the wrong things they should not do. [Arashmid]
{Arashmid] > -----Original Message-----
_______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|