Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt

"Naidu, Venkata" <Venkata.Naidu@MARCONI.COM> Fri, 09 August 2002 15:28 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29906 for <ospf-archive@LISTS.IETF.ORG>; Fri, 9 Aug 2002 11:28:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006C95A3@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 11:29:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86350 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 11:29:41 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 11:29:41 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18963 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 9 Aug 2002 11:29:41 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28164 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 9 Aug 2002 11:29:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99S2K5>; Fri, 9 Aug 2002 11:29:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <39469E08BD83D411A3D900204840EC557632D4@vie-msgusr-01.dc.fore.com>
Date: Fri, 09 Aug 2002 11:29:41 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Naidu, Venkata" <Venkata.Naidu@MARCONI.COM>
Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Acee,

-> My least favorite alternative is allowing the setting of the
-> E bit to be optional since it requires implementation of the
-> Path-Comp-Server reachability checking in both OSPF and the
-> the Path-Comp-Clients.

  Your take is "do or don't" but not in between option, fine :)

  From my access networks experience I would like to make
  a suggestion. There is no application level checking about
  reachability of any address (look at any transport level
  protocol, for that matter any distributed applications,
  for example, MGC-MG communication in MEGACO etc etc)

  Applications never bother about internal workings of
  lower layers (ie whether address is dynamic reachable or not)

  PCC application does one of the following:
  1. Limited number of retries with exponential backoff
  2. Unlimited number of retries till manual intervention
  3. Alternative retries between primary and backup
     (if there is a backup-PCS configured)

  Practically there won't be any *reachability checking* in
  PCC or PCS.

  Guys, I think the problem is a very simple one. We have
  had very fruitful discussion. Take is authors. I give up :)

--
Venkata