Subject: l2vpn(martini drafts) questions

From: Narasimha Swamy <[email-masked]>
Date: Thu, 29 Nov 2001 18:28:04 +0530

1. In martini draft, it says, vc-id together with vc-type uniquely
identifies a particular VC. does this mean two VCs can have same vc-id but
different vc-type? I don't think this should be the case, because group-id
exists for higher hierarchy and vc-id should be different for each l2vpn
circuit.

2. In case of vc-label withdraw, 4 messages have to be exchanged between 2
peers(first one being label withdraw for label corr. to this vc-id, then
label release from its peer. Then label withdraw from its peer for vc-label
at its end for this vc-id and lastly label release for this withdrawl).
Instead, is it not better way, for one lsr to send label withdraw with vc-id
set in new fec element(rather than vc-label) and its peer reply with
release(implying it also is withdrawing vc-label at its end). In this way
only 2 messages are exchanged.

3. what should be done if tunnel path doesn't exist, any notification msg to
be sent?
 
regards
swamy

---

From: Giles Heron <[email-masked]>
Date: Thu, 29 Nov 2001 14:37:27 +0000

> exists for higher hierarchy and vc-id should be different for each l2vpn

it is valid to have "overlapping" VC ID values, as long as (VC type, VC
ID) is unique for a peer PE.

however it is also (AFAIK) a perfectly valid decision to implement your
code such that VC ID is unique.  Nobody is forcing you to support two
VCs with the same VC ID but different VC types :)  This is completely
interoperable, the network operator just assigns a unique VC ID to each
circuit between two PEs.

also, please remember that while it is true to an extent that group ID
creates a hierarchy, that there is no requirement for the group IDs to
match at the two ends of the VC.

So on a single VC, one PE could use a group id of 100, and use this to
indicate a local physical interface whilst the far end could use VC 200
and use it to indicate a virtual tunnel between the two PEs.

> only 2 messages are exchanged.

I don't think you need to send 4 messages?  Typically the far end PE
doesn't need to send a VC label withdraw in response to a VC label
withdraw from the PE that discovers a problem.

If, for example, a PE discovers that a local physical port has gone down
it will send a VC label withdraw (which may be a wildcard for a group ID
in the case where group ID is used to indicate a physical interface.)

The remote PEs presumably all still have active local interfaces, and
will be ready to send traffic over their VCs as soon as the local PE
sends a new label mapping (as a result of the interface coming back up
in this example.)  So it is easiest for the local PE to hold onto their
label mappings.

Note that draft-martini specifies liberal label retention.

> 3. what should be done if tunnel path doesn't exist, any notification msg to

No.

the issue in the general case is that you don't know whether the far end
has a tunnel to reach you.  So it is hard to use that as a basis for
advertising/withdrawing labels.  And even in cases where you do know if
the far end has a tunnel to reach you (e.g. when using RSVP-TE for the
tunnels) you wouldn't really want to be "flapping" the VC labels while
the far end was busy resignalling a tunnel label?

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: 29 Nov 2001 09:44:40 -0500

Narasimha Swamy <[email-masked]> writes:

> different vc-type?

Yes.

> I don't think this should be the case, because group-id

Group ID has nothing to do with uniquely identifying a VC at signaling
time; it exists only as a convenient way in which one LSR may signal
the withdrawal of many VCs at once.

> at its end for this vc-id and lastly label release for this withdrawl).

Reception of a withdraw from one LSR does not instigate the generation
of a withdraw by the receiving LSR.  The LSR receiving the withdraw
will continue to advertise the VC information it has already sent
(unless there's been a local change to the VC configuration of
interface oper status).

> 3. what should be done if tunnel path doesn't exist, any notification msg to

No; the signaling of the VCs is independent of the availability of an
underlying data path.  There was some churn on this topic on the
martini draft list some time back, and this was the conclusion
reached.

Regards,
Tob