The MPLS WG Archive

[Narasimha Swamy <NarasimhaS@netbrahma.com>]

> 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.
then is itn't necessary for wild-card  vc-id label withdrawl!(all vc-labels
associated with this vc-id)

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

> > 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?
does this mean that vc-label advertisement should be accepted eventhough
tunnel from this LSR is not there. This should be ok, as anyway this LSR
wouldn't be advertising vc-label without first having tunnel, and there
won't be any data exchanged on a VC unless it is configured from both sides.


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