The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

Narasimha Swamy wrote:
> 
> 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.

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.

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

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
> be sent?

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

> 
> regards
> swamy

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