Subject: RE: draft-pan-lsp-ping-00.txt

From: "Wadhwa, Sanjay" <[email-masked]>
Date: Tue, 10 Jul 2001 16:13:35 -0400

Hi Shahram
  Broken fiber would effect the rsvp control path. If the rsvp control path
is healthy, then not getting the LSP-echo object in the RESV (after a
certain amount of time beyond sending the echo-request) would point to
messed up switch table entry in an LSR along the way, which is what this
draft seems to be addressing I think..

-Sanjay

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 3:51 PM
> To: 'Sanjay Wadhwa'; [email-masked]'
> Subject: RE: draft-pan-lsp-ping-00.txt
> 
> 
> Hi Sanjay,
> 
> 
> > -----Original Message-----
> > From: Sanjay Wadhwa [mailto:[email-masked]]
> > Sent: Tuesday, July 10, 2001 3:39 PM
> > To: Shahram Davari; [email-masked]'
> > Subject: RE: draft-pan-lsp-ping-00.txt
> > 
> > 
> > Hi Shahram
> > I am not sure I understand your concern. Maybe I missed your point.
> > Since the rsvp control path (which is used for response) is 
> alive i.e.
> > RESV w/o LSP_ECHO are being received fine (after sending the echo
> > request) by the ingress, but is not getting echo response 
> in the RESV,
> > ingress can conclude that the lsp data plane is broken, which 
> > is what I
> > think the scheme is trying to achieve. The end result in this case
> > would be to consider the LSP as down.
> 
> This is correct. But for diagnostic purpose you want to know why the
> LSP is down. Is it because there was an error in one of the 
> switching tables
> in its path, or because for example a fiber was broken.
> 
> -Shahram
> 
> > However, if the wrong egress does ip forward the packet 
> (u'r original
> > concern), the ingress has no way to figure that LSP data plane is
> > broken. 
> > 
> > -Sanjay
> > 
> > 
> > --- Shahram Davari <[email-masked]> wrote:
> > > Hi Sanjay,
> > > 
> > > Seems like a good solution. But the only problem is that 
> the source
> > > won't find out why the LSP has connectivity problem, is it due to
> > > mis-routing or is it due to lower level failures. 
> > > 
> > > Yours,
> > > -Shahram
> > > 
> > > > -----Original Message-----
> > > > From: Sanjay Wadhwa [mailto:[email-masked]]
> > > > Sent: Tuesday, July 10, 2001 11:37 AM
> > > > To: Shahram Davari; [email-masked]'
> > > > Subject: Re: draft-pan-lsp-ping-00.txt
> > > > 
> > > > 
> > > > The ingress could send this packet with IP ttl of 1 since the 
> > > > intention
> > > > is to never ip forward this packet. The wrong egress in this 
> > > > case would
> > > > drop it which is the desired behaviour.
> > > > 
> > > > -Sanjay
> > > > 
> > > > 
> > > > --- Shahram Davari <[email-masked]> wrote:
> > > > > Hi,
> > > > > 
> > > > > An observations/question:
> > > > > 
> > > > > The draft says that the LSP ping packets are sent to 
> the egress
> > > LSR
> > > > > with UDP encapsulation. I assume the IP address of the Ping
> > > packets
> > > > > are set to the IP address of the desired egress LSR. 
> > What happens
> > > if
> > > > > a ping packet is delivered to an undesired egress 
> LSR? From the
> > > MPLS
> > > > > architecture point of view, it seems that the undesired egress
> > > LSR
> > > > > will probably try to forward the Ping packet to the desired 
> > > > LSR using
> > > > > the IP address in the Ping packet, which eventually could send
> > > > > echo-reply back to source. Therefore although the LSP 
> > has a wrong
> > > > > path the source will never find out. 
> > > > > 
> > > > > Yours,
> > > > > Shahram Davari
> > > > > 
> > > > >  <<Shahram Davari.vcf>> 
> > > > > 
> > > > 
> > > > > ATTACHMENT part 2 application/octet-stream name=Shahram
> > > Davari.vcf
> > > > 
> > > > 
> > > > 
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Get personalized email addresses from Yahoo! Mail
> > > > http://personal.mail.yahoo.com/
> > > > 
> > > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> > 
>