Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

From: "David Allan" <[email-masked]>
Date: Wed, 6 Nov 2002 11:01:44 -0500

Hi George:

Thanks for the clarification, tells me I shouldn't have been the person to
answer this question as I appear to be confusing tunnel ID and LSP ID.

rgds
Dave

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 10:18 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: George Swallow; Der-Hwa Gan; Gray, Eric; [email-masked];
> [email-masked]
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability 
> issue" (fwd)
> 
> 
> 
> > I was envisioning a case where a bandwidth change was not a 
> separate tunnel
> > setup, the LSP ID changed without any interruption or change in the
> > conntectivity of the path . If there is build the new then 
> tear down the
> > old, then there is no gap in any monitoring case.
>  
> If you change the LSP-ID, that changes the sender-template.  Ipso
> facto a new setup.
> 
> > As for TTSI, it's simply a node specific LSP Identifier 
> that allows for an
> > IPv4/v6 LSR ID and 32 bits for an LSP identifier. The 
> assumption is that the
> > originating LSR most usefully administers LSP-IDs 
> independently of the
> > individual control protocol used. The initial draft of 
> Y.1711 was focused on
> > P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the 
> stipulation that the
> > first two bytes of the LSP-ID were padded with zeros to 
> align with LSP-ID as
> > defined in the signalling protocols. If there is a problem 
> with this, it is
> > not leaping out at me....
> 
> As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel.  We
> just use it as an instance number and increment it when we reroute or
> change bandwidth.  If I setup five tunnels they will have five
> different tunnel-IDs, but they can *all* have the same LSP-ID.
> 
> To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in
> the session and sender-template objects.  That why we carry those in
> LSP ping.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>

---

From: Francois Lemarchand <[email-masked]>
Date: Wed, 6 Nov 2002 13:29:58 -0800

Ok,

Then it's maybe not a technical argument as such
but a best practice to reduce the number of special
cases : changing the LSP-ID for bandwidth increase/
decrease regardless of a path change.

Although it's not optimal it didn't prevent using FF
style. So I didn't see a contradiction by generalising
this LSP-ID change while keeping FF as one of the
reservation style.

Francois

-----Original Message-----
From: Jim Boyle [mailto:[email-masked]]
Sent: mardi 5 novembre 2002 14:33
To: Francois Lemarchand
Cc: [email-masked]
Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

Yes, we all agree that as the spec states, when the path changes the LSP
ID should be changed.

The issue is that one implementation has issues if the LSP ID of
a transit LSP does not change when the bandwidth decreases.  Alternatively
you could state that the issue is that one (or two) implementations are
unique in that they don't change the LSP ID when they decrease the
bandwidth.

So the options at this point are:

o) address the implementation with transit issue when bandwidth decreases
and LSP ID is not changed.

o) require LSP ID change during BW decrease in the spec and address the
implementation(s) which currently don't do this.

We've had a few people weigh in on both sides of this, so I'm not sure
if there is any resolution.

Jim

On Mon, 4 Nov 2002, Francois Lemarchand wrote:

> Hello !
>
> For re-optimisation I guess. If there is a need to change
> the path when bandwidth increase then it's probably usefull
> to return to the old path when bandwidth decrease (probably
> more optimal).
>
> So changing path probably justify make-before-break and
> LSP-ID change.
>
> Did I miss somthing ?
>
> Francois
>
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: lundi 4 novembre 2002 20:27
> To: [email-masked]
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)
>
>
>
> Hi All,
>
> I'd like to re-iterate Der-Hwa's question:
>
> On Thu, 31 Oct 2002, Der-Hwa Gan wrote:
>
> > It is perhaps more appropriate to ask what is the technical reason that
a
> > new ID is required to get bandwidth decrease?
>
> Is there a technical reason that someone can articulate?  Along the
> same lines, is make-before-break needed on bandwidth *decrease*?
>
> Thanks,
> Kireeti.
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 7 Nov 2002 04:34:46 -0500

George:

You are misunderstanding some of the intent of Y.1711 CV in your example. It
is designed to do path availability measurement/path failure detection for
the tunnel and possibly facilitate path based protection switching. It does
not do ad-hoc ping verification from arbitrary points in the tunnel to
support FRR, that is a more complex function (see below).

So in your example lets add LSR 'E' which is where the tunnel terminates.
A,1,1 is working fine and CV flows from A to E. At some point B switches
traffic to the backup path also terminating at E (or remerging with the
original tunnel somewhere downstream) , and CV continues to flow from A to E
(with a slight detour ;-). This assumes the protection works perfectly. If
it did not, then CV would be interrupted, and the failed LSR-ID/Tunnel ID
would be flagged to mgmt or for some other corrective action. CV does not
need to have sufficient information to disambiguate ping flows from
arbitrary points in the network.

This would bring to mind an interesting question which I wouldn't mind your
answer for my education. In FRR, let's add 'D' which is a merge point for
detours upstream of the egress. 
              ST   SO
		(A,1)(E,1)->
	A------------B-----------D-------------E
			  \_________/

			   ST    SO
			  (B,1)  (D or E,1)

A detour set up from B to D presumably only propagates the backup paths
session object and sender template as far as 'D', so that the existence of
the backup path B-D is not known to E. Any ping for ad-hoc verification of
the backup path would flow B-E, so a change in the sender template that B
would use when pinging for the path would not be known to E. So in this case
E needs some extra logic to pry 'A' out of the extended tunnel ID and figure
out that this ping is from 'B' for the LSP originating at 'A'? In other
words, if the extended tunnel ID is not zero then it effectively overrides
the ID in the sender template for the purposes of identifying what is being
tested and the sender template identifies who is doing the testing and some
of the LSP details? DO I have this correct?

thks
Dave

> -----Original Message----
> Sent: Wednesday, November 06, 2002 5:27 PM
> To: Shahram Davarion 
> Cc: [email-masked]
> Shahram -
> Just realized that I mis-spoke when I said:
> 
> > > The LSP-ID defined in Y.1711 is essentially a combination 
> of LSP-ID + Tunnel-ID
> > > as defined in RSVP-TE.  
> > > 
> > > In the current version of Y.1711, 4 bytes are assigned to
> > > this. However the current version of Y.1711 sets the 
> first 2 octets of
> > > this field to zero for future use. Therefore two methods 
> are possible:
> > > 
> > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes 
> > 
> > This uses up all the space.  If RSVP-TE is the only application for
> > Y.1711 then this would be acceptable.  But since it's 
> called MPLS OAM,
> > I assume there were other apps in mind as well.
> 
> This is not even sufficient for RSVP-TE.  When I set up backup paths,
> the means of identification is to keep the same 
> Session_Object, and the
> same LSP-ID.  The source_IP address is set to the router setting up
> the backup tunnel.  Thats the only change.  
> 
> So suppose (a most common situation)
> 
> router A has tunnel number 1, LSP number 1.
>   this tunnel passes through some other router B
> 
> router B has its own tunnel number 1, LSP number 1.
> 
> router B sets up a backup to protect tunnel A,1,1.
> 
> it would like to ping (i.e. verify connectivity) the backup tunnel
> after it is set up to make certain that it is working
> 
> It can't set the TTSI to B,1,1 - since that is the ID for his own
> tunnel.  He can't set it to A,1,1 because that is the working path and
> he wants to check the protect path.
> 
> So the TTSI does not seem to be sufficient even for RSVP-TE!
> 
> ...George
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 7 Nov 2002 04:56:03 -0500

George, 

ignore the question al the end of my last message, I answered it myself ;-)

rgds
Dave

> From: Allan, David [CAR:NS00:EXCH] 
> Sent: Thursday, November 07, 2002 4:35 AM
> To: George Swallow; Shahram Davari
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 7 Nov 2002 10:02:56 -0000

Dave....small point, please in-line below.  regards, Neil

David Allan wrote 07 November 2002 09:35
> would be flagged to mgmt or for some other corrective action.
NH=> This is quite correct.....in fact anything else would not be.  The
example shows subnetwork protection.  Further, all of the link-connections
between adajacent pairs of nodes will be served by lower layer trails (maybe
SDH VC4 say).  One would *not* require a client trail to go changing any of
its identifiers for topology changes in any lower server network
layers...and this case is architecturally no different.  Indeed, the only
thing that is relevant for the LSP fault management is the verification that
the correct source point is connected to the correct sink point....arbitrary
lower layer routing changes should not (and indeed must not) have any impact
on the client (unless any prot-sw therein fails to react in some time T,
after which the client trail will detect a failure (missing CV with correct
TTSI) and can take its own action....but *please* don't make T too small,
like <1s, else you will end up uncessarily switching on each/every error
event at the client level....compounded for those who think
bumping/pre-emption is a good idea).
<snipped to end NH>

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 7 Nov 2002 09:23:35 -0500

David,

	Some questions/comments below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> From: David Allan [mailto:[email-masked]]
> So in your example lets add LSR 'E' which is where the tunnel 
> terminates.  A,1,1 is working fine and CV flows from A to E. 
> At some point B switches traffic to the backup path also 
> terminating at E (or remerging with the original tunnel somewhere
> downstream), ...

What does this mean?  Downstream of where?  Surely not downstream
of E which is the egress for the tunnel...

> ... and CV continues to flow from A to E (with a slight detour ;-). 
> This assumes the protection works perfectly. If it did not, then 
> CV would be interrupted, and the failed LSR-ID/Tunnel ID would be 
> flagged to mgmt or for some other corrective action. CV does not

This sounds like correct and expected behavior.  CV is interrupted
as a result of a failure.  Is there something wrong with this?  :-)

> 
> This would bring to mind an interesting question which I wouldn't 
> mind your answer for my education. In FRR, let's add 'D' which is 
> a merge point for detours upstream of the egress.
>               ST   SO
> 		(A,1)(E,1)->
> A detour set up from B to D presumably only propagates the backup 
> paths session object and sender template as far as 'D', so that 
> the existence of the backup path B-D is not known to E. Any ping 
> for ad-hoc verification of the backup path would flow B-E, so a 
> change in the sender template that B would use when pinging for 
> the path would not be known to E. So in this case E needs some 
> extra logic to pry 'A' out of the extended tunnel ID and figure
> out that this ping is from 'B' for the LSP originating at 'A'? 
> In other words, if the extended tunnel ID is not zero then it 
> effectively overrides the ID in the sender template for the 
> purposes of identifying what is being tested and the sender 
> template identifies who is doing the testing and some of the
> LSP details? DO I have this correct?

Wouldn't you expect D - as the merge point - to convert the tunnel
information to something known in common with its downstream E?

---

From: "David Allan" <[email-masked]>
Date: Thu, 7 Nov 2002 10:52:02 -0500

Hi Eric:

> > You are misunderstanding some of the intent of Y.1711 CV in 
> your example.
> > It
> > the tunnel and possibly facilitate path based protection 
> switching. It
> > does

No certainly not downstream of E. Re-merges somewhere between B and E is
more precise.

> as a result of a failure.  Is there something wrong with this?  :-)

Nope.

> information to something known in common with its downstream E?

yes, I figured out the piece I was missing (reading and understanding being
unsynched).....it just took a second to grok when extended tunnel ID is zero
and when you use it. And how it would work with LSP PING (which except in
traceroute mode will not stop to sightsee at 'D' but then B can fix that).

rgds
Dave