Subject: RE: [Isis-wg] IS-IS TE Question

From: "Don Fedyk" <[email-masked]>
Date: Fri, 15 Sep 2000 10:30:16 -0400

All
 
Just to add one thing to the time stamping idea. We do not consider it
necessary since 
the database is still really maintained by the IGP flood. (Which does not
use timestamps
but sequence numbers). The feedback is more targeted information that is
used in the 
interim. Although there are small windows of opportunities for the feedback
to be miss ordered 
this is still leagues ahead of not having feedback. By the way, the most
likely misordering is an
old LSP (LSA) announcing more bandwidth than actually exists and overwriting
a feedback message
that has reported less bandwidth. This could result in a LSP signaling that
has to learn from feedback 
again. (We prefer to deal with the timing issues not pray they will not
happen!).
Relying on timestamps or sequence numbers for feedback requires
synchronization between peers 
and designers of IGPs have way more years of experience and code to deal
with this.
 
Don

 -----Original Message-----
From: Skalecki, Darek [CAR:CS56:EXCH] 
Sent: Friday, September 15, 2000 8:49 AM
To: ben abarbanel
Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk,
Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: Re: [Isis-wg] IS-IS TE Question

ben abarbanel wrote: 

Matthew and Darek: 
  I kind of like the feedback mechanism defined in 
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or

Darek can add it to their spec is that a timestamp be added to both the 
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also

the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the 
reservation denial and bandwidth sample was taken from the rejecting LSR. As

the message is returned to the ingress LSR its bandwidth will be overwritten

into the linkstate database, since its the most up to date information. 

I can see a race condition where IGP converging link state information might

have older data then Reservation Release/Withdrawl messages containing the 
same (feedback) data. Thus its possible for the ingress LSR IGP to 
momentarily over-write newer bandwidth with bad/older bandwidth into the 
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp 
in the database with its current LSA/LSP packet and only update the 
bandwidth value if it has the newer timestamp in the LSA/LSP packet. 

regards, 
Ben 

Ben Abarbanel,  Software Engineering, 

Phone:  703 456 2982 
FAX:      703 456 2952 

IPOptical, Inc. 
11480 Sunset Hills Road 
Suite #200E 
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote
any learned  information into a database, 
whether the information was from feedback or flooding. You are right that
more-up-to-date feedback information 
may be then overwritten by older flooding information but in that case we
may  simply re-learn newer information via feedback when needed so we never
implemented timestamping. 

Darek 

-- 

Darek Skalecki

Nortel 

(613) 765-2252

---

From: "ben abarbanel" <[email-masked]>
Date: Fri, 15 Sep 2000 14:30:50 -0400

Don:
 Comments below

Ben

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

  ----- Original Message ----- 
  From: Don Fedyk 
  To: Darek Skalecki ; ben abarbanel 
  Cc: Matthew Kontoff ; isis-wg ; Peter Ashwood-Smith ; Bilel Jamoussi 
  Sent: Friday, September 15, 2000 10:30 AM
  Subject: RE: [Isis-wg] IS-IS TE Question

  All
   
  Just to add one thing to the time stamping idea. We do not consider it necessary since 
  the database is still really maintained by the IGP flood. (Which does not use timestamps
  but sequence numbers). The feedback is more targeted information that is used in the 
  interim. Although there are small windows of opportunities for the feedback to be miss ordered 
  this is still leagues ahead of not having feedback. By the way, the most likely misordering is an
  old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message
  that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback 
  again. (We prefer to deal with the timing issues not pray they will not happen!).
  Relying on timestamps or sequence numbers for feedback requires synchronization between peers 
  and designers of IGPs have way more years of experience and code to deal with this.
   
  I only mentioned timestamp cause I did not think we can use the IGP sequence number as it is picked for
  IGP flooding for LSP signalling. The timestamp is only relevent to the router that is originating the LSA/LSP 
  so there is no synchronization requirements between peers/neighbors.  I think eventually the IGP flooding mechanism 
  will adjust to the correct value, but in the interim the routers in the domain could drift of actual capacities and thus
  create more LSP reservation failures. It would be nice to cover this hole no matter how small with a solution in
  the specification and leave it up to the implementor to choose. I guess since you guys went this far in trying to close
  down the inaccuracies between the routers in the domain.

  Regards,
  Ben

   -----Original Message-----
  From: Skalecki, Darek [CAR:CS56:EXCH] 
  Sent: Friday, September 15, 2000 8:49 AM
  To: ben abarbanel
  Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
  Subject: Re: [Isis-wg] IS-IS TE Question

    ben abarbanel wrote: 
      Matthew and Darek: 

      regards, 
      Ben 

      Phone:  703 456 2982 
      FAX:      703 456 2952 

      IPOptical, Inc. 
      11480 Sunset Hills Road 
      Suite #200E 
      Reston, VA 20190

    Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database, 
    whether the information was from feedback or flooding. You are right that more-up-to-date feedback information 
    may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping. 
    Darek 

-- 
Darek Skalecki
Nortel 
(613) 765-2252

---

From: Tony Li <[email-masked]>
Date: Fri, 15 Sep 2000 15:07:56 -0700 (PDT)

Folks,

About 99% of this conversation is about signaling and crankback and not
about IS-IS.  Could we take it to a more appropriate mailing list, please?

Thanks,
Tony
co-chair

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "ben abarbanel" <[email-masked]>
Date: Fri, 15 Sep 2000 18:35:31 -0400

Sure, I think I am done.

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "ben abarbanel" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>; "Darek Skalecki"
<[email-masked]>; "Matthew Kontoff" <[email-masked]>;
"isis-wg" <[email-masked]>; "Peter Ashwood-Smith"
<[email-masked]>; "Bilel Jamoussi" <[email-masked]>
Sent: Friday, September 15, 2000 6:07 PM
Subject: Re: [Isis-wg] IS-IS TE Question