Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt

From: Shahram Davari <[email-masked]>
Date: Mon, 16 Jul 2001 07:13:34 -0700

Hi Yakov,

Good suggestion. However, I think due to periodic transmission of ping packets, and due to possibility of many LSPs being pinged at the same time, the processing overhead of UDP/IP is large and may limit the scalability. Using another reserved label for Ping (or OAM packets in general) could eliminate the use of UDP/IP and could reduce the processing burden at the egress LSR.

Yours,
-Shahram

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 9:57 AM
> To: Shahram Davari
> Cc: 'Ping Pan'; [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt 
> 
> 
> Shahram,
> 
> > > > How can the LSP-Ping work if the LSP is setup to carry 
> > > > non-IP traffic?
> > > > 
> > > > In an egress LSR there is a binding between an LSP and the 
> > > > L3 protocol that it is supposed to carry.
> > > > If anything other than IP is carried in an LSP, and we 
> > > > inject ping packets in to that LSP, the egress 
> > > > LSR has no means of parsing that packet. How is this 
> > > > addressed in this draft?
> > > > 
> > > 
> > > Shahram,
> > > 
> > > If the LSP (IP or non-IP) is initiated via RSVP-TE, then
> > > draft-pan-lsp-ping-00.txt can be used to check the LSP. 
> In this case,
> > > the egress can parse the echo-requests. You are right, it 
> > > won't work in
> > > a non-IP network.
> > 
> > This is not correct. I am not talking about non-IP networks, I am
> > talking abo ut carrying non-IP traffic through MPLS network. Even
> > if the LSP is initiated v ia RSVP-TE, you still could have the
> > problem that I described. For example assume that an LSP is setup
> > via RSVP-TE to carry Ethernet traffic (Here I am assuming only one
> > label is used, which is different from Martini drafts). The L3PID
> > will be sig naled as Ethernet. In that case the Ethernet packets
> > are encapsulated in MPLS, in othe r words a label belonging to that
> > LSP is pushed before the Ethernet header.  Now the egress LSR,
> > first pops the top label and then does process the remain ing
> > payload  knowing that it is an Ethernet packet. How does the egress
> > LSR kno w that the payload is Ethernet? by looking at the NHLFE
> > context which was build up during RSVP-TE signaling.
> > 
> > Now what you are suggesting is that we send a Ping packet through
> > the same LS P, using the same label which is used for the normal
> > user-plane traffic. When t he egress LSR receives this packet, by
> > looking at the NHLFE table, it assumes t hat the payload is 
> Ethernet,
> > while your payload is UDP/IP. So the ping packet won't be processed
> > correctly.
> > 
> > Therefore you need an identifier that says this is a ping packet,
> > regardless of what the LSP is carrying. One possible method is to
> > use an extra label from the reserved label space.
> 
> Explicit IPv4 NULL.
> 
> Yakov.
>

---

From: Ping Pan <[email-masked]>
Date: Mon, 16 Jul 2001 09:23:28 -0700

Shahram Davari wrote:
> 
> Hi Yakov,
> 
> Good suggestion. However, I think due to periodic transmission of ping packets, and due 
> to possibility of many LSPs being pinged at the same time, the processing overhead of UDP/IP 
> is large and may limit the scalability. 

Shahram,

That's why we choose a two-step ping: ICMP ping's followed by LSP
ping's. Normally, the ingress sends the regular ICMP ping's to check
LSP's. Only when there is no reply on ICMP ping's, LSP-ping messages are
sent to detect if the failure is on the forwarding or the reverse LSP.
The reason for using UDP is to allow the egress LSR's to regulate the
LSP-ping traffic.... Don't think there is a scalability problem here.

> Using another reserved label for Ping 
> (or OAM packets in general) could eliminate the use of UDP/IP and could reduce the processing burden at 
> the egress LSR.
>

How? At egress, ping packets need to be processed anyway. You still have
to somehow limit the amount of probing traffic.

BTW, I will add the idea of using Explicit IPv4 NULL for non-IP traffic
in the next version.

- Ping