Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

From: George Swallow <[email-masked]>
Date: Thu, 27 May 2010 18:43:08 -0400

This begins a two week last call on the follow two drafts.

Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-05
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-
05.txt 

and

Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label
Switching (MPLS) 
- Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-10.txt

The last call ends June 10, 2010 24:00 UTC

George & Loa

---

From: Shivakumar Channalli <[email-masked]>
Date: Fri, 28 May 2010 11:41:18 +0530

Hi all,

I have some doubts regarding "section 3.4. Respond Only If TTL Expired
Flag"
In draft-ietf-mpls-p2mp-lsp-ping-10.txt

The section mentions that 
"If the T flag is set to 1, then the receiver SHOULD reply only if the
 TTL of the incoming MPLS label is equal to 1; if the TTL is more than
 1, then no response should be sent back."

But it doesn't specifies anything about a case where in the packet is
received without any label (NULL label)

Example:
Just think, all the penultimate hops in a p2mp LSP are doing PHP,
And we are using "Egress Address P2MP Responder Identifier"  to trace
p2mp LSP egress "F"

As per 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs: 
"A node that receives an echo request with this Sub-TLV present MUST
 respond only if the node lies on the path to the address in the
 Sub-TLV."

          ttl-1        ttl-2       ttl-3      ttl-4      ttl-5
         Bud node    Bud node    Bud node    Bud node Pure-egress
A-----------B-----------C-----------D-----------E----------F
|-----------| lsp1
|-----------------------| lsp2
|-----------------------------------| lsp3
|-----------------------------------------------| lsp4
|----------------------------------------------------------| lsp5

>From the figure above, we can see that all the bud nodes are on the path
to the egress node F. So with each TTL increment, we start getting
multiple responses from all the bud nodes.

To understand the problem, just think we are currently tracing with TTL
5.
And in the ping request contains down map that of F.

When we send out this trace message, each of the bud nodes will receive
a copy of the trace packet, as it's a p2mp LSP. But the packets received
by the bud nodes ++don't contain any label as PHP is in use++.

As a result when a bud node does processing of the packet, interface and
label validations will fail, and they will send out send out error
responses.

So basically "section 3.4" doesn't really help in such cases

[Suggestions]
"In p2mp LSP case, if a node (other than pure egress) receives a LSP
ping packet, without any label, then we should drop the packet without
processing"

Reason: In trace route mode we want packets to reach control plane due
to TTL expiry, but in PHP p2mp mode packets are also received by bud
nodes due the PHP. As a result we can conclude that the packet received
by control plane is not due to TTL expiry, and drop the packets.

...$hiv

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
George Swallow
Sent: Friday, May 28, 2010 4:13 AM
To: [email-masked]
Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

This begins a two week last call on the follow two drafts.
Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-05
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-ds
map-05.txt 

and

George & Loa

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 28 May 2010 08:18:01 -0500

Hi Shivakumar:

In P2MP trees, for both P2MP TE and Multicast LDP, PHP is not used. The
packet should always have the label.

Regards,
Shaleen

> -----Original Message-----
> Shivakumar Channalli
> Sent: Friday, May 28, 2010 2:11 AM
> To: George Swallow (swallow); [email-masked]
> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> 
> Hi all,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 28 May 2010 10:05:31 -0700

Hi Shaleen,

   I have a comment regarding the p2mp-lsp-ping draft.
Since node sub-tlv can identify any type of node, why should the node have like an egress node?
Shouldn't it behave like an egress + branch node?
I recommend that for traceroute, the bud-node should add the DDMAP to indicate that it does have
something beyond it....it will simplify the ingress procedure of determining if a node is a bud-node or not.

Thanks
Nitin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Thursday, May 27, 2010 3:43 PM
To: [email-masked]
Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-05
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-05.txt

and

Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS)
- Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-10.txt

George & Loa

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 28 May 2010 10:08:18 -0700

Shaleen,

Can u point me to the relevant section in some RFC that specifics that PHP
should not be used with RSVP P2MP-TE.

Thanks
Nitin  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shaleen Saxena (ssaxena)
> Sent: Friday, May 28, 2010 6:18 AM
> To: Shivakumar Channalli
> Cc: [email-masked]
> In P2MP trees, for both P2MP TE and Multicast LDP, PHP is not 
> used. The packet should always have the label.
> 
> Regards,
> Shaleen
> 
> 
> 
> > Just think, all the penultimate hops in a p2mp LSP are 
> doing PHP, And 
> > we are using "Egress Address P2MP Responder Identifier"  to 
> trace p2mp 
> > LSP egress "F"
> > 
> > From the figure above, we can see that all the bud nodes are on the 
> > path to the egress node F. So with each TTL increment, we start 
> > getting multiple responses from all the bud nodes.
> > 
> > a copy of the trace packet, as it's a p2mp LSP. But the packets 
> > received by the bud nodes ++don't contain any label as PHP is in 
> > use++.
> > 
> > As a result when a bud node does processing of the packet, 
> interface 
> > and label validations will fail, and they will send out 
> send out error 
> > responses.
> >

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 28 May 2010 13:39:30 -0500

Hi Nitin:

I was referring to
http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-04
. Do you have an application where you use PHP? Is P2MP TE with PHP
going to be deployed in service provider networks?

Regards,
Shaleen

> From: Nitin Bahadur [mailto:[email-masked]]
> Sent: Friday, May 28, 2010 1:08 PM
> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
> Cc: [email-masked]
> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> Shaleen,
> 
> Behalf
> > Of
> > > To understand the problem, just think we are currently tracing
with
> > TTL
> Behalf
> > Of
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-
> enhanced-
> > > ds
> > > map-05.txt
> > >
> > > and

---

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Fri, 28 May 2010 12:30:47 -0700

In addition, non-PHP is required to avoid packet replication by a
penultimate hop when it precedes a bud node. 
Cheers.

SA
--

> Shaleen Saxena (ssaxena)
> Sent: Friday, May 28, 2010 11:39 AM
> To: Nitin Bahadur; Shivakumar Channalli
> Cc: [email-masked]
> > Can u point me to the relevant section in some RFC that specifics
> that
> > PHP
> > > > Detecting Data Plane Failures in Point-to-Multipoint
> Multiprotocol
> > > > Label Switching (MPLS)
> > > > - Extensions to LSP Ping
> > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-
> ping-
> > > > 10.txt
> > > >
> > > >

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 28 May 2010 16:52:21 -0700

Shaleen,

> http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-

This draft does not say that PHP *must not* be used ever for RSVP P2MP.
This draft specifies a requirement for non-PHP behavior and solves that problem.

> . Do you have an application where you use PHP? Is P2MP TE 
> with PHP going to be deployed in service provider networks?

Yes...we have customers (in deployment) using P2MP with PHP.

nitin

---

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Fri, 28 May 2010 17:32:56 -0700

It seems to me that, in order to find PHP acceptable for P2MP LSPs, one
the these two need to be acceptable:
1. precluding bud node support
2. bud node receiving duplicate traffic (label and unlabeled)
Cheers.

SA
--
> Nitin Bahadur
> Sent: Friday, May 28, 2010 4:52 PM
> This draft specifies a requirement for non-PHP behavior and solves
that
> problem.

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 28 May 2010 19:10:27 -0700

Well said and I agree.

Bud-node is not a common place in many customer topologies I have seen.

Nitin

---

From: Shivakumar Channalli <[email-masked]>
Date: Sat, 29 May 2010 20:43:21 +0530

|> 1. precluding bud node support
Another way is to try to solve bud node issue in case of PHP 

|> 2. bud node receiving duplicate traffic (label and unlabeled)
|> Cheers.
Receiving unlabelled packet in case of PHP can be solved by following a
simple rule.

"In p2mp LSP case, if a node (other than pure egress) receives a +MPLS
LSP trace packet+, without any label, then we should drop the packet
without processing"

Reason: In trace route mode we want packets to reach control plane due
to TTL expiry, but in PHP p2mp mode packets are also received by bud
nodes due the PHP. As a result we can make an assumption that, the
packet received by control plane is not due to TTL expiry, and drop the
packets.

...$hiv

|-----Original Message-----
|From: Santiago Alvarez (saalvare) [mailto:[email-masked]]
|Sent: Saturday, May 29, 2010 6:03 AM
|To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
|Cc: [email-masked]; Santiago Alvarez (saalvare)
|Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|
|It seems to me that, in order to find PHP acceptable for P2MP LSPs, one
|the these two need to be acceptable:
|1. precluding bud node support
|2. bud node receiving duplicate traffic (label and unlabeled)
|Cheers.
|
|SA
|--
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On Behalf
|Of
|> Nitin Bahadur
|> Sent: Friday, May 28, 2010 4:52 PM
|> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|> Cc: [email-masked]
|> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|>
|>
|> Shaleen,
|>
|> > I was referring to
|> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
|> > mapping-04
|>
|> This draft does not say that PHP *must not* be used ever for RSVP
|P2MP.
|> This draft specifies a requirement for non-PHP behavior and solves
|that
|> problem.
|>
|> > . Do you have an application where you use PHP? Is P2MP TE
|> > with PHP going to be deployed in service provider networks?
|>
|> Yes...we have customers (in deployment) using P2MP with PHP.
|>
|> nitin
|> _______________________________________________
|> mpls mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mpls