Subject: error handling in l2vpn

From: Narasimha Swamy <[email-masked]>
Date: Wed, 21 Nov 2001 12:47:59 +0530

Hi,
In case of L2VPN sessions configuration, it is possible for an edge LSR to
receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn
session. 
What type of message should be sent in this case to indicate this error. If
notification message is sent, what will be the Status Code. 

regards
swamy.

---

From: Giles Heron <[email-masked]>
Date: Wed, 21 Nov 2001 10:17:49 +0000

> receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn

By L2VPN here do you mean draft-martini?

If so then yes - it is possible for the edge LSR to receive unmatched
MTU or vc-type from the peer edge LSR.

> notification message is sent, what will be the Status Code.

A label release should be sent.  I'm not sure what the status code
should be.  Luca can probably tell us...

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Toby Smith <[email-masked]>
Date: 21 Nov 2001 08:47:44 -0500

Giles Heron <[email-masked]> writes:

> A label release should be sent.

Hi,

Are you sure about this last bit?  If one LSR has a configured MTU of
1400, and receives information from its peer for the same VC ID &
interface type, but with an advertised MTU of 1500, I would think that
this situation would be better served by maintaining the received
mapping and relaying this status to the local user, who has a better
chance of configuring the local interface to a matching MTU (or fixing
things up on the remote side).

If a release is sent instead, it then opens up the issue of having the
LSR who issued the release later send a request for that mapping.

Either that, or the remote LSR who receives the release from the local
LSR now has enough information to pick a new MTU that might be more
amenable to the LSR which sent the release.  But now we're talking
about MTU negotiation, aren't we.

Regards,
Tob

---

From: Giles Heron <[email-masked]>
Date: Wed, 21 Nov 2001 14:28:16 +0000

> about MTU negotiation, aren't we.

exactly.

And from my memory of the discussion I think we decided to try and avoid
getting into negotiation for this parameter.

So we decided to depend on the SP managing to configure a matching MTU
size as well as VC ID and VC type at both ends...

In general I'd expect vendors to default the MTU to something sensible
for that encaps (e.g. 1500 for Ethernet, 1500 or 4470 for PPP, and so
on.)  So most of the time (assuming the SP has a core which can
transport this default MTU) no further action should be necessary from
the SP.

I think I argued for putting default MTU values in the draft?  I can't
remember why we didn't put them in?

Giles

---

From: Toby Smith <[email-masked]>
Date: 21 Nov 2001 09:40:23 -0500

> > about MTU negotiation, aren't we.

Excellent.  So, are you backing down from your statement about sending

> size as well as VC ID and VC type at both ends...

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

> transport this default MTU) no further action should be necessary from

Hopefully, yeah.  :)

> remember why we didn't put them in?

Seems like a good idea that might save someone the hassle of first
discovering the defaults during some interop event.  :)

Regards,
Tob

---

From: Giles Heron <[email-masked]>
Date: Wed, 21 Nov 2001 14:52:47 +0000

> a release?  After all, you say:

I didn't say that ;-)

> way to get the released mappings back again later.

but if you retain the received mapping then presumably the circuit will
start "working"?

Whereas if the circuit fails to come up the user will figure out that
something is wrong.  Hopefully when (s)he turns on debug there will be a
tell-tale message saying "MTU size mismatch".

There is, I believe, a precedent for this.  Doesn't OSPFv2 fail to
establish an adjacency unless the MTUs match?
 
> discovering the defaults during some interop event.  :)

okay.  Let's poll the other authors to see what we get...

Giles

---

From: Toby Smith <[email-masked]>
Date: 21 Nov 2001 09:59:45 -0500

> but if you retain the received mapping then presumably the circuit will

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.

Regards,
Tob

---

From: Giles Heron <[email-masked]>
Date: Wed, 21 Nov 2001 15:01:49 +0000

> modified MTU, and things will start working.

ah.  My bad.  I misread "MUST NOT be enabled" as "MUST be released".

Giles