The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

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

I'm not sure what you mean here?

there is only one VC label associated with one VC ID (unless you use the
same VC ID with different VC types.)

The wildcard label withdrawl is for a group ID wildcard.  Each end of a
VC knows the local and remote group IDs for the VC.  So if a PE gets a
wildcard withdraw from a peer PE it can delete every VC to that peer PE
with a matching remote group 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.

yes.  The VC label advertisement should be accepted even though there is
no tunnel.  Again this is a form of liberal retention - we hold onto the
FEC even though we can't use it yet.

And in fact the local LSR may advertise a VC label to the remote LSR
even if it has no tunnel to the remote LSR.  As Toby has indicated there
was a fair bit of discussion on this point, and the upshot is that Luca 
was persuaded to remove the requirement for a tunnel from A->B before A
advertised a VC label to B.

The reasoning for removing the requirement was that we don't want to see
labels being withdrawn and then readvertised when a routing transient
occurs.

So in fact it is valid to have a draft-martini circuit which is "up" -
in the sense that the two ends have exchanged labels, but which is not
used by one LSR because it has no tunnel to reach the remote LSR.  Given
that the VC labels are likely to be advertised over the tunnel LSP this
should only be a transient condition.  But of course this is another
reason why it is "a good thing" to have LDP signalled LSPs as a last
resort even when you are using RSVP-TE for your tunnel LSPs (as JP
mentioned in his post on the "RSVP and LDP in the same MPLS domain"
thread yesterday.)

Giles

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

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