[mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Shaleen,
Please find the mail thread, where in we had a discussed about PHP
scenario.

$hiv...

-----Original Message-----
From: Shivakumar Channalli 
Sent: Tuesday, June 01, 2010 6:17 PM
To: 'Shaleen Saxena (ssaxena)'; Santiago Alvarez (saalvare); Nitin
Bahadur
Cc: mpls@ietf.org
Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail

PHP will happen before tail (T i.e pure egress) also.
In the example T is pure egress, so packet should be processed by T, but
in case of B (bud node) it should be dropped.

That's why it should be clearly specified as 

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

In other words, "if a bud node receives a unlabelled packets , then it
should be dropped"

|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?

I guess, there should not be any problems as such.

|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.

That's correct. The packets should be dropped only if T bit is set.
Other wise in ping mode of operation, we may not get reply at all if we
apply this rule to all packets.

...$hiv

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:ssaxena@cisco.com]
|Sent: Tuesday, June 01, 2010 5:51 PM
|To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
|Cc: mpls@ietf.org; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|
|Hi Shiv, Nitin,
|
|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail
|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?
|
|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.
|
|Thanks,
|Shaleen
|
|
|> -----Original Message-----
|> From: Shivakumar Channalli [mailto:shivakumar@juniper.net]
|> Sent: Saturday, May 29, 2010 11:13 AM
|> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> (ssaxena)
|> Cc: mpls@ietf.org
|> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|>
|>
|> |> 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:saalvare@cisco.com]
|> |Sent: Saturday, May 29, 2010 6:03 AM
|> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |Cc: mpls@ietf.org; 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
|Behalf
|> |Of
|> |> Nitin Bahadur
|> |> Sent: Friday, May 28, 2010 4:52 PM
|> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |> Cc: mpls@ietf.org
|> |> 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
|> |> mpls@ietf.org
|> |> https://www.ietf.org/mailman/listinfo/mpls