The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] error handling in l2vpn
Toby Smith wrote: > > Giles Heron <giles@packetexchange.net> writes: > > > > ...which I think is the correct approach, and I think that's best > > > served by simply maintaining the received mapping with the mismatched > > > MTU and reconfiguring one of the boxes based on the information that > > > the user can see in the sent & received label mappings show commands, > > > instead of having an LSR send a release as soon as it receives a > > > mapping with an MTU it doesn't expect, and then having to figure out a > > > way to get the released mappings back again later. > > > > but if you retain the received mapping then presumably the circuit will > > start "working"? > > No, not at all. Luca is very sage, and accounts for this in the trans > draft: > > - Interface MTU > > A 2 octet value indicating the MTU in octets. This is the Maximum > Transmission Unit, excluding encapsulation overhead, of the > egress packet interface that will be transmitting the > decapsulated PDU that is received from the MPLS network. This > parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, > and is REQUIRED for these VC types. If this parameter does not > match in both directions of a specific VC, that VC MUST NOT be > enabled. > > So, we can happily retain the mismatched label mapping without fear of > any forwarding taking place, and still have the information available > for the user to perform diagnosis. As a benefit, when the problem's > resolved, one of the LSRs will issue a withdraw/mapping to convey the > modified MTU, and things will start working. ah. My bad. I misread "MUST NOT be enabled" as "MUST be released". Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =================================================================
|
|