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

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

Hi Ping,

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 8:05 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> 
> 
> Shahram Davari wrote:
> > 
> > Hi All,
> > 
> > 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 about carrying non-IP traffic through MPLS network. Even if the LSP is initiated via 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 signaled as
Ethernet. In that case the Ethernet packets are encapsulated in MPLS, in other
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 remaining payload  knowing that it is an Ethernet packet. How does the egress LSR know 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 LSP, using the same label which is used for the normal user-plane traffic. When the egress LSR receives this packet, by looking at the NHLFE table, it assumes that 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.

I hope this time I am more clear.

Yours,
-Shahram 

> - Ping

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Jul 2001 06:57:03 -0700

Shahram,

> 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.