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

From: Shivakumar Channalli <[email-masked]>
Date: Tue, 19 Oct 2010 11:29:33 +0530

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: [email-masked]
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:[email-masked]]
|Sent: Tuesday, June 01, 2010 5:51 PM
|To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
|Cc: [email-masked]; 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:[email-masked]]
|> Sent: Saturday, May 29, 2010 11:13 AM
|> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> (ssaxena)
|> Cc: [email-masked]
|> 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:[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

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Tue, 19 Oct 2010 06:38:15 -0500

Hi Shivakumar:

I did not put the suggested text after discussions with other authors.
The behavior you suggest does not solve the problem of receiving
multiple responses from various bud and tail nodes during traceroute.

As per your suggestion, when T flag is used in a PHP scenario:
- Bud nodes will never respond, even if it is their turn to do so,
- Tail nodes will keep responding to all echo requests where TTL is
greater than their depth.

I am not sure how this behavior can be helpful to traceroute.

The original problem is that bud and tail nodes keep responding to
traceroute requests, for TTL greater than their depth. The extra
responses can be prevented if the nodes check for label expiry. However
without the label, traceroute packets for various TTL values look the
same. If you have a suggestion on how to solve this problem in a PHP
scenario, I will be willing to put it in the draft.

Regards,
Shaleen

-----Original Message-----
From: Shivakumar Channalli [mailto:[email-masked]] 
Sent: Tuesday, October 19, 2010 2:00 AM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]; Nitin Bahadur
Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Shaleen,

$hiv...

-----Original Message-----
From: Shivakumar Channalli 
Sent: Tuesday, June 01, 2010 6:17 PM
To: 'Shaleen Saxena (ssaxena)'; Santiago Alvarez (saalvare); Nitin
Bahadur
Cc: [email-masked]

|

...$hiv

---

From: Shivakumar Channalli <[email-masked]>
Date: Tue, 19 Oct 2010 18:10:45 +0530

Shaleen,

||  H - M1 - B - M2 - T
||
||Here:
|| H: Head
|| M1, M2: Two mid-point nodes
|| B: Bud
|| T: Tail

|As per your suggestion, when T flag is used in a PHP scenario:
|- Bud nodes will never respond, even if it is their turn to do so,

Let me explain it again. If a packet is sent with TTL 2
Bud node B receives 2 packets:
1) Labeled packet, due to TTL expiry (for which it would normally
perform a  swap and send it to M2)
2) unlabelled packet, which arrives due to PHP done at M1

The suggestion is to drop the unlabelled packet(2) at bud, if "TTL
expiry flag" is set, because it landed in B due to PHP done at M1, not
due to label TTL expiry.

|- Tail nodes will keep responding to all echo requests where TTL is
|greater than their depth.
|
|I am not sure how this behavior can be helpful to traceroute.

Tail nodes will always get a single copy of the packet unlike bud nodes.

More ever, if the responder-id tlv is present a node would never respond
back, unless the criterions for responder-id tlv are met correctly.

|The original problem is that bud and tail nodes keep responding to
|traceroute requests, for TTL greater than their depth. The extra
|responses can be prevented if the nodes check for label expiry. However
|without the label, traceroute packets for various TTL values look the
|same. If you have a suggestion on how to solve this problem in a PHP
|scenario, I will be willing to put it in the draft.

This problem can be solved by dropping +unlabelled packets+ at +bud
node+, if TTL expiry flag is set in the request. 

$hiv...

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|Sent: Tuesday, October 19, 2010 5:08 PM
|To: Shivakumar Channalli
|Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi Shivakumar:
|
|I did not put the suggested text after discussions with other authors.
|The behavior you suggest does not solve the problem of receiving
|multiple responses from various bud and tail nodes during traceroute.
|
|As per your suggestion, when T flag is used in a PHP scenario:
|- Bud nodes will never respond, even if it is their turn to do so,
|- Tail nodes will keep responding to all echo requests where TTL is
|greater than their depth.
|
|I am not sure how this behavior can be helpful to traceroute.
|
|The original problem is that bud and tail nodes keep responding to
|traceroute requests, for TTL greater than their depth. The extra
|responses can be prevented if the nodes check for label expiry. However
|without the label, traceroute packets for various TTL values look the
|same. If you have a suggestion on how to solve this problem in a PHP
|scenario, I will be willing to put it in the draft.
|
|Regards,
|Shaleen
|
|-----Original Message-----
|From: Shivakumar Channalli [mailto:[email-masked]]
|Sent: Tuesday, October 19, 2010 2:00 AM
|To: Shaleen Saxena (ssaxena)
|Cc: [email-masked]; Nitin Bahadur
|Subject: [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: [email-masked]
|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:[email-masked]]
||Sent: Tuesday, June 01, 2010 5:51 PM
||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
||Cc: [email-masked]; 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:[email-masked]]
||> Sent: Saturday, May 29, 2010 11:13 AM
||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
||> (ssaxena)
||> Cc: [email-masked]
||> 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:[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

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Wed, 20 Oct 2010 11:29:25 -0500

Hi,

I understand your PHP usage better now. However changing the behavior of
T bit will not prevent multiple responses from tail nodes. If you plan
to use Responder Identifier TLV to limit that, then it will work for bud
nodes as well (unless bud node itself is the target). So changing the
behavior of the T bit for PHP is only a partial solution to the problem.

Shaleen

-----Original Message-----
From: Shivakumar Channalli [mailto:[email-masked]] 
Sent: Tuesday, October 19, 2010 8:41 AM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]; Nitin Bahadur
Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Shaleen,

||  H - M1 - B - M2 - T
||
||Here:
|| H: Head

$hiv...

---

From: Shivakumar Channalli <[email-masked]>
Date: Thu, 21 Oct 2010 11:39:55 +0530

Shaleen,

For tail nodes we don't get 2 copies of the same packet unlike bud
nodes.
Its just a particular case of bud nodes that we have to solve here.

$hiv...

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|Sent: Wednesday, October 20, 2010 9:59 PM
|To: Shivakumar Channalli
|Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi,
|
|I understand your PHP usage better now. However changing the behavior
of
|T bit will not prevent multiple responses from tail nodes. If you plan
|to use Responder Identifier TLV to limit that, then it will work for
bud
|nodes as well (unless bud node itself is the target). So changing the
|behavior of the T bit for PHP is only a partial solution to the
problem.
|
|Shaleen
|
|
|-----Original Message-----
|From: Shivakumar Channalli [mailto:[email-masked]]
|Sent: Tuesday, October 19, 2010 8:41 AM
|To: Shaleen Saxena (ssaxena)
|Cc: [email-masked]; Nitin Bahadur
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Shaleen,
|
|||  H - M1 - B - M2 - T
|||
|||Here:
||| H: Head
||| M1, M2: Two mid-point nodes
||| B: Bud
||| T: Tail
|
||As per your suggestion, when T flag is used in a PHP scenario:
||- Bud nodes will never respond, even if it is their turn to do so,
|
|Let me explain it again. If a packet is sent with TTL 2
|Bud node B receives 2 packets:
|1) Labeled packet, due to TTL expiry (for which it would normally
|perform a  swap and send it to M2)
|2) unlabelled packet, which arrives due to PHP done at M1
|
|The suggestion is to drop the unlabelled packet(2) at bud, if "TTL
|expiry flag" is set, because it landed in B due to PHP done at M1, not
|due to label TTL expiry.
|
|
||- Tail nodes will keep responding to all echo requests where TTL is
||greater than their depth.
||
||I am not sure how this behavior can be helpful to traceroute.
|
|Tail nodes will always get a single copy of the packet unlike bud
nodes.
|
|More ever, if the responder-id tlv is present a node would never
respond
|back, unless the criterions for responder-id tlv are met correctly.
|
|
||The original problem is that bud and tail nodes keep responding to
||traceroute requests, for TTL greater than their depth. The extra
||responses can be prevented if the nodes check for label expiry.
However
||without the label, traceroute packets for various TTL values look the
||same. If you have a suggestion on how to solve this problem in a PHP
||scenario, I will be willing to put it in the draft.
|
|
|This problem can be solved by dropping +unlabelled packets+ at +bud
|node+, if TTL expiry flag is set in the request.
|
|
|
|
|$hiv...
|
|
|
||-----Original Message-----
||From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
||Sent: Tuesday, October 19, 2010 5:08 PM
||To: Shivakumar Channalli
||Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
||
||Hi Shivakumar:
||
||I did not put the suggested text after discussions with other authors.
||The behavior you suggest does not solve the problem of receiving
||multiple responses from various bud and tail nodes during traceroute.
||
||As per your suggestion, when T flag is used in a PHP scenario:
||- Bud nodes will never respond, even if it is their turn to do so,
||- Tail nodes will keep responding to all echo requests where TTL is
||greater than their depth.
||
||I am not sure how this behavior can be helpful to traceroute.
||
||The original problem is that bud and tail nodes keep responding to
||traceroute requests, for TTL greater than their depth. The extra
||responses can be prevented if the nodes check for label expiry.
However
||without the label, traceroute packets for various TTL values look the
||same. If you have a suggestion on how to solve this problem in a PHP
||scenario, I will be willing to put it in the draft.
||
||Regards,
||Shaleen
||
||-----Original Message-----
||From: Shivakumar Channalli [mailto:[email-masked]]
||Sent: Tuesday, October 19, 2010 2:00 AM
||To: Shaleen Saxena (ssaxena)
||Cc: [email-masked]; Nitin Bahadur
||Subject: [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: [email-masked]
||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:[email-masked]]
|||Sent: Tuesday, June 01, 2010 5:51 PM
|||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
|||Cc: [email-masked]; 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:[email-masked]]
|||> Sent: Saturday, May 29, 2010 11:13 AM
|||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|||> (ssaxena)
|||> Cc: [email-masked]
|||> 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:[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

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Thu, 21 Oct 2010 07:57:49 -0500

Hi Shiv,

I understand that tails do not get two copies the packet. My question is
about the subsequent iterations in the traceroute. For increasing values
of TTL, all the tail nodes that have replied previously will keep on
responding. If I understand your previous email correctly, you said that
you want to use Responder-Identifier to limit that. Is it not correct?
If this is correct, then won't that solution work for your bud nodes?

Shaleen

-----Original Message-----
From: Shivakumar Channalli [mailto:[email-masked]] 
Sent: Thursday, October 21, 2010 2:10 AM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]; Nitin Bahadur
Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Shaleen,

$hiv...

---

From: Shivakumar Channalli <[email-masked]>
Date: Fri, 22 Oct 2010 21:44:40 +0530

Hi Shaleen ,

|I understand that tails do not get two copies the packet. My question
is
|about the subsequent iterations in the traceroute. For increasing
values
|of TTL, all the tail nodes that have replied previously will keep on
|responding. If I understand your previous email correctly, you said
that
|you want to use Responder-Identifier to limit that. Is it not correct?
|If this is correct, then won't that solution work for your bud nodes?

It'll work.
If we have Responder-Identifier , then we might not need "TTL expire
flag" as well right ?

The suggestion I was proposing prevents a bud node from getting 2 copies
of the same packet, and replying back twice, which may/may not create
problems at ingress.

Also, it makes the operation of PHP and UHP modes of tracing at +BUD
nodes+ almost same, as they now need to respond back, only for labeled
packets.

I am not saying that, whatever the current draft is saying is wrong. I
am trying to +improvise+ the BUD node scenario in case of PHP mode,
Which I think is not thought about in the draft.

The basic idea behind dropping the +unlabelled packet+ at BUD is that,
it reached due to PHP and not because of TTL expiry.

In tail anyways we get a single copy of the packet, so we should not be
doing anything.

If we don't include this rule, it causes some more problems.

In PHP mode:

-----LSP1----
-----------LSP2---------
A-----B------C----D----E
            BUD

Just consider, when a request reaches B, B +might+ respond in 2 ways
a) With 2 down maps 1 containing label 3 and another containing actual
label, As one can reach C, with or without label.
b) With a single down map containing an actual label.

Both the responses are valid. For simplicity let's consider that B
replied back with only 1 downmap (b)

Now consider, we send a request to C with a downmap containing actual
label.
C ends up receiving 2 copies of the same packet, one with label and
another without label. (if we don't apply the rule I mentioned)

In this case, label validation will fail for the packet received without
label. Because the downmap contains a label and we received a packet
without label.

So we send out success as well as failure responses for the same request
message received, which is not correct.

The only way we can prevent this scenario is, by applying the suggested
rule. 

This is actually what I trying to prevent.

$hiv...

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|Sent: Thursday, October 21, 2010 6:28 PM
|To: Shivakumar Channalli
|Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi Shiv,
|
|I understand that tails do not get two copies the packet. My question
is
|about the subsequent iterations in the traceroute. For increasing
values
|of TTL, all the tail nodes that have replied previously will keep on
|responding. If I understand your previous email correctly, you said
that
|you want to use Responder-Identifier to limit that. Is it not correct?
|If this is correct, then won't that solution work for your bud nodes?
|
|Shaleen
|
|-----Original Message-----
|From: Shivakumar Channalli [mailto:[email-masked]]
|Sent: Thursday, October 21, 2010 2:10 AM
|To: Shaleen Saxena (ssaxena)
|Cc: [email-masked]; Nitin Bahadur
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Shaleen,
|
|For tail nodes we don't get 2 copies of the same packet unlike bud
|nodes.
|Its just a particular case of bud nodes that we have to solve here.
|
|
|
|$hiv...
|
|
|
||-----Original Message-----
||From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
||Sent: Wednesday, October 20, 2010 9:59 PM
||To: Shivakumar Channalli
||Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
||
||Hi,
||
||I understand your PHP usage better now. However changing the behavior
|of
||T bit will not prevent multiple responses from tail nodes. If you plan
||to use Responder Identifier TLV to limit that, then it will work for
|bud
||nodes as well (unless bud node itself is the target). So changing the
||behavior of the T bit for PHP is only a partial solution to the
|problem.
||
||Shaleen
||
||
||-----Original Message-----
||From: Shivakumar Channalli [mailto:[email-masked]]
||Sent: Tuesday, October 19, 2010 8:41 AM
||To: Shaleen Saxena (ssaxena)
||Cc: [email-masked]; Nitin Bahadur
||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
||
||Shaleen,
||
||||  H - M1 - B - M2 - T
||||
||||Here:
|||| H: Head
|||| M1, M2: Two mid-point nodes
|||| B: Bud
|||| T: Tail
||
|||As per your suggestion, when T flag is used in a PHP scenario:
|||- Bud nodes will never respond, even if it is their turn to do so,
||
||Let me explain it again. If a packet is sent with TTL 2
||Bud node B receives 2 packets:
||1) Labeled packet, due to TTL expiry (for which it would normally
||perform a  swap and send it to M2)
||2) unlabelled packet, which arrives due to PHP done at M1
||
||The suggestion is to drop the unlabelled packet(2) at bud, if "TTL
||expiry flag" is set, because it landed in B due to PHP done at M1, not
||due to label TTL expiry.
||
||
|||- Tail nodes will keep responding to all echo requests where TTL is
|||greater than their depth.
|||
|||I am not sure how this behavior can be helpful to traceroute.
||
||Tail nodes will always get a single copy of the packet unlike bud
|nodes.
||
||More ever, if the responder-id tlv is present a node would never
|respond
||back, unless the criterions for responder-id tlv are met correctly.
||
||
|||The original problem is that bud and tail nodes keep responding to
|||traceroute requests, for TTL greater than their depth. The extra
|||responses can be prevented if the nodes check for label expiry.
|However
|||without the label, traceroute packets for various TTL values look the
|||same. If you have a suggestion on how to solve this problem in a PHP
|||scenario, I will be willing to put it in the draft.
||
||
||This problem can be solved by dropping +unlabelled packets+ at +bud
||node+, if TTL expiry flag is set in the request.
||
||
||
||
||$hiv...
||
||
||
|||-----Original Message-----
|||From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|||Sent: Tuesday, October 19, 2010 5:08 PM
|||To: Shivakumar Channalli
|||Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|||
|||Hi Shivakumar:
|||
|||I did not put the suggested text after discussions with other
authors.
|||The behavior you suggest does not solve the problem of receiving
|||multiple responses from various bud and tail nodes during traceroute.
|||
|||As per your suggestion, when T flag is used in a PHP scenario:
|||- Bud nodes will never respond, even if it is their turn to do so,
|||- Tail nodes will keep responding to all echo requests where TTL is
|||greater than their depth.
|||
|||I am not sure how this behavior can be helpful to traceroute.
|||
|||The original problem is that bud and tail nodes keep responding to
|||traceroute requests, for TTL greater than their depth. The extra
|||responses can be prevented if the nodes check for label expiry.
|However
|||without the label, traceroute packets for various TTL values look the
|||same. If you have a suggestion on how to solve this problem in a PHP
|||scenario, I will be willing to put it in the draft.
|||
|||Regards,
|||Shaleen
|||
|||-----Original Message-----
|||From: Shivakumar Channalli [mailto:[email-masked]]
|||Sent: Tuesday, October 19, 2010 2:00 AM
|||To: Shaleen Saxena (ssaxena)
|||Cc: [email-masked]; Nitin Bahadur
|||Subject: [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: [email-masked]
|||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:[email-masked]]
||||Sent: Tuesday, June 01, 2010 5:51 PM
||||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
||||Cc: [email-masked]; 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:[email-masked]]
||||> Sent: Saturday, May 29, 2010 11:13 AM
||||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
||||> (ssaxena)
||||> Cc: [email-masked]
||||> 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:[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

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 22 Oct 2010 14:05:28 -0500

Hi,

Good to know that responder-identifier will work for you at the bud
nodes. Now for the new point you raised, regarding DDMAP label
validation, please refer to section 4.3.4. "Use of Downstream Detailed
Mapping TLV in Echo Request"
(http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-12#section-4.3
.4). It states: 

   In the echo request packet, the "Downstream IP Address" field,
   of the Downstream Detailed Mapping TLV, SHOULD be set to the
   ALLROUTERS multicast address.

Let's consider the new topology you sent:
-----LSP1----
-----------LSP2---------
A-----B------C----D----E
            BUD

So after B has sent its response, the new request should contain the
ALLROUTERS address. This will prevent the DDMAP label validation
failures you are referring to. Moreover, if you have a responder
identifier, then you will not run into the label validation issue.

BTW I see another issue with your suggestion. There are other possible
implementations for PHP. Let's go back to your first topology.

  H - M1 - B - M2 - T

Here:
 H: Head
 M1, M2: Two mid-point nodes
 B: Bud
 T: Tail

In your implementation, B has offloaded the packet duplication to M1.
Now M1 has to take in one packet and send out two copies. One copy will
have label and the other without label. (Hence, there will be double
bandwidth usage on M1-B link.) Now B will consume the unlabeled packet
and forward the labeled packet. Your suggestion will prevent B from
responding to the unlabeled packet at all.

A different vendor can have a different implementation with PHP where B
does the packet duplication itself. So M1 sends an unlabeled packet to
B. Then B does the duplication: consumes one copy and sends the other
copy to downstream router. If we go with your suggestion, then B will
never respond to any OAM packet for this implementation, as it receives
only unlabeled packets. This is not a valid behavior.

Regards,
Shaleen

-----Original Message-----
From: Shivakumar Channalli [mailto:[email-masked]] 
Sent: Friday, October 22, 2010 12:15 PM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]; Nitin Bahadur
Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Hi Shaleen ,

It'll work.

In PHP mode:

-----LSP1----
-----------LSP2---------
A-----B------C----D----E
            BUD

$hiv...

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 22 Oct 2010 13:45:39 -0700

Hi Shaleen,

>    ALLROUTERS multicast address.

But if one sets that, then validation will not be performed by downstream
router. So it's not a good option.

> B.

This is not possible. It breaks P2MP MPLS forwarding model. If B receives an
unlabeled packet, then it needs to do 2 things:
- Consumes one packet
- Push a label (by doing an IP lookup).

B has to receive a labeled packet for it to send it down towards T.
Only possible way for B to do replication is that it receives a labeled
packet and does 2 things:
- Consumes one copy
- Swaps other copy and sends it downstream

Let me know if Shivakumar's proposal does not address this case.

Thanks
Nitin

> Then B does the duplication: consumes one copy and sends the other

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Tue, 26 Oct 2010 06:24:34 -0500

Hi Nitin, Shivakumar,

I will update the section to read as follows. There has been some
rearrangement of statements. The new information is the last paragraph:

   The T (Respond Only If TTL Expired) flag SHOULD be set only in the
   echo request packet by the sender.  This flag SHOULD NOT be set in
   the echo reply packet.  If this flag is set in an echo reply packet,
   then it MUST be ignored.

   If the T flag is set to 0, then the receiver SHOULD reply as per
   regular processing.

   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.

   If the T flag is set to 1 and there are no incoming MPLS labels on
   the echo request packet, then a bud node with PHP configured MAY
   choose to not respond to this echo request.  All other nodes SHOULD
   ignore this bit and respond as per regular processing.

Thanks,
Shaleen

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Friday, October 22, 2010 4:46 PM
To: Shaleen Saxena (ssaxena); Shivakumar Channalli
Cc: [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Hi Shaleen,

>    ALLROUTERS multicast address.

But if one sets that, then validation will not be performed by
downstream
router. So it's not a good option.

> does the packet duplication itself. So M1 sends an unlabeled packet to

This is not possible. It breaks P2MP MPLS forwarding model. If B
receives an
unlabeled packet, then it needs to do 2 things:
- Consumes one packet
- Push a label (by doing an IP lookup).

Thanks
Nitin

---

From: Shivakumar Channalli <[email-masked]>
Date: Fri, 29 Oct 2010 22:14:55 +0530

Shaleen,
Thanks for considering the suggestion.

$hiv...

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|Sent: Tuesday, October 26, 2010 4:55 PM
|To: Nitin Bahadur; Shivakumar Channalli
|Cc: [email-masked]; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi Nitin, Shivakumar,
|
|I will update the section to read as follows. There has been some
|rearrangement of statements. The new information is the last paragraph:
|
|
|   The T (Respond Only If TTL Expired) flag SHOULD be set only in the
|   echo request packet by the sender.  This flag SHOULD NOT be set in
|   the echo reply packet.  If this flag is set in an echo reply packet,
|   then it MUST be ignored.
|
|   If the T flag is set to 0, then the receiver SHOULD reply as per
|   regular processing.
|
|   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.
|
|   If the T flag is set to 1 and there are no incoming MPLS labels on
|   the echo request packet, then a bud node with PHP configured MAY
|   choose to not respond to this echo request.  All other nodes SHOULD
|   ignore this bit and respond as per regular processing.
|
|
|Thanks,
|Shaleen
|
|-----Original Message-----
|From: Nitin Bahadur [mailto:[email-masked]]
|Sent: Friday, October 22, 2010 4:46 PM
|To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|Cc: [email-masked]
|Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi Shaleen,
|
|> Good to know that responder-identifier will work for you at the bud
|> nodes. Now for the new point you raised, regarding DDMAP label
|> validation, please refer to section 4.3.4. "Use of Downstream
Detailed
|> Mapping TLV in Echo Request"
|>
|(http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-12#section-4.
3
|> .4). It states:
|>
|>    In the echo request packet, the "Downstream IP Address" field,
|>    of the Downstream Detailed Mapping TLV, SHOULD be set to the
|>    ALLROUTERS multicast address.
|
|But if one sets that, then validation will not be performed by
|downstream
|router. So it's not a good option.
|
|> Let's consider the new topology you sent:
|> -----LSP1----
|> -----------LSP2---------
|> A-----B------C----D----E
|>             BUD
|>
|> So after B has sent its response, the new request should contain the
|> ALLROUTERS address. This will prevent the DDMAP label validation
|> failures you are referring to. Moreover, if you have a responder
|> identifier, then you will not run into the label validation issue.
|>
|>
|> BTW I see another issue with your suggestion. There are other
possible
|> implementations for PHP. Let's go back to your first topology.
|>
|>   H - M1 - B - M2 - T
|>
|> Here:
|>  H: Head
|>  M1, M2: Two mid-point nodes
|>  B: Bud
|>  T: Tail
|>
|> In your implementation, B has offloaded the packet duplication to M1.
|> Now M1 has to take in one packet and send out two copies. One copy
|will
|> have label and the other without label. (Hence, there will be double
|> bandwidth usage on M1-B link.) Now B will consume the unlabeled
packet
|> and forward the labeled packet. Your suggestion will prevent B from
|> responding to the unlabeled packet at all.
|>
|> A different vendor can have a different implementation with PHP where
|B
|> does the packet duplication itself. So M1 sends an unlabeled packet
to
|> B.
|
|This is not possible. It breaks P2MP MPLS forwarding model. If B
|receives an
|unlabeled packet, then it needs to do 2 things:
|- Consumes one packet
|- Push a label (by doing an IP lookup).
|
|B has to receive a labeled packet for it to send it down towards T.
|Only possible way for B to do replication is that it receives a labeled
|packet and does 2 things:
|- Consumes one copy
|- Swaps other copy and sends it downstream
|
|Let me know if Shivakumar's proposal does not address this case.
|
|Thanks
|Nitin
|
|> Then B does the duplication: consumes one copy and sends the other
|> copy to downstream router. If we go with your suggestion, then B will
|> never respond to any OAM packet for this implementation, as it
|receives
|> only unlabeled packets. This is not a valid behavior.
|>
|>
|> Regards,
|> Shaleen
|>
|>
|>
|> -----Original Message-----
|> From: Shivakumar Channalli [mailto:[email-masked]]
|> Sent: Friday, October 22, 2010 12:15 PM
|> To: Shaleen Saxena (ssaxena)
|> Cc: [email-masked]; Nitin Bahadur
|> Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|>
|> Hi Shaleen ,
|>
|> |I understand that tails do not get two copies the packet. My
question
|> is
|> |about the subsequent iterations in the traceroute. For increasing
|> values
|> |of TTL, all the tail nodes that have replied previously will keep on
|> |responding. If I understand your previous email correctly, you said
|> that
|> |you want to use Responder-Identifier to limit that. Is it not
|correct?
|> |If this is correct, then won't that solution work for your bud
nodes?
|>
|> It'll work.
|> If we have Responder-Identifier , then we might not need "TTL expire
|> flag" as well right ?
|>
|> The suggestion I was proposing prevents a bud node from getting 2
|copies
|> of the same packet, and replying back twice, which may/may not create
|> problems at ingress.
|>
|> Also, it makes the operation of PHP and UHP modes of tracing at +BUD
|> nodes+ almost same, as they now need to respond back, only for
labeled
|> packets.
|>
|> I am not saying that, whatever the current draft is saying is wrong.
I
|> am trying to +improvise+ the BUD node scenario in case of PHP mode,
|> Which I think is not thought about in the draft.
|>
|> The basic idea behind dropping the +unlabelled packet+ at BUD is
that,
|> it reached due to PHP and not because of TTL expiry.
|>
|> In tail anyways we get a single copy of the packet, so we should not
|be
|> doing anything.
|>
|>
|> If we don't include this rule, it causes some more problems.
|>
|> In PHP mode:
|>
|> -----LSP1----
|> -----------LSP2---------
|> A-----B------C----D----E
|>             BUD
|>
|> Just consider, when a request reaches B, B +might+ respond in 2 ways
|> a) With 2 down maps 1 containing label 3 and another containing
actual
|> label, As one can reach C, with or without label.
|> b) With a single down map containing an actual label.
|>
|> Both the responses are valid. For simplicity let's consider that B
|> replied back with only 1 downmap (b)
|>
|> Now consider, we send a request to C with a downmap containing actual
|> label.
|> C ends up receiving 2 copies of the same packet, one with label and
|> another without label. (if we don't apply the rule I mentioned)
|>
|> In this case, label validation will fail for the packet received
|without
|> label. Because the downmap contains a label and we received a packet
|> without label.
|>
|> So we send out success as well as failure responses for the same
|request
|> message received, which is not correct.
|>
|> The only way we can prevent this scenario is, by applying the
|suggested
|> rule.
|>
|> This is actually what I trying to prevent.
|>
|>
|>
|>
|>
|>
|> $hiv...
|>
|>
|>
|> |-----Original Message-----
|> |From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|> |Sent: Thursday, October 21, 2010 6:28 PM
|> |To: Shivakumar Channalli
|> |Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|> |Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|> |
|> |Hi Shiv,
|> |
|> |I understand that tails do not get two copies the packet. My
question
|> is
|> |about the subsequent iterations in the traceroute. For increasing
|> values
|> |of TTL, all the tail nodes that have replied previously will keep on
|> |responding. If I understand your previous email correctly, you said
|> that
|> |you want to use Responder-Identifier to limit that. Is it not
|correct?
|> |If this is correct, then won't that solution work for your bud
nodes?
|> |
|> |Shaleen
|> |
|> |-----Original Message-----
|> |From: Shivakumar Channalli [mailto:[email-masked]]
|> |Sent: Thursday, October 21, 2010 2:10 AM
|> |To: Shaleen Saxena (ssaxena)
|> |Cc: [email-masked]; Nitin Bahadur
|> |Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|> |
|> |Shaleen,
|> |
|> |For tail nodes we don't get 2 copies of the same packet unlike bud
|> |nodes.
|> |Its just a particular case of bud nodes that we have to solve here.
|> |
|> |
|> |
|> |$hiv...
|> |
|> |
|> |
|> ||-----Original Message-----
|> ||From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|> ||Sent: Wednesday, October 20, 2010 9:59 PM
|> ||To: Shivakumar Channalli
|> ||Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|> ||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|> ||
|> ||Hi,
|> ||
|> ||I understand your PHP usage better now. However changing the
|behavior
|> |of
|> ||T bit will not prevent multiple responses from tail nodes. If you
|plan
|> ||to use Responder Identifier TLV to limit that, then it will work
for
|> |bud
|> ||nodes as well (unless bud node itself is the target). So changing
|the
|> ||behavior of the T bit for PHP is only a partial solution to the
|> |problem.
|> ||
|> ||Shaleen
|> ||
|> ||
|> ||-----Original Message-----
|> ||From: Shivakumar Channalli [mailto:[email-masked]]
|> ||Sent: Tuesday, October 19, 2010 8:41 AM
|> ||To: Shaleen Saxena (ssaxena)
|> ||Cc: [email-masked]; Nitin Bahadur
|> ||Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|> ||
|> ||Shaleen,
|> ||
|> ||||  H - M1 - B - M2 - T
|> ||||
|> ||||Here:
|> |||| H: Head
|> |||| M1, M2: Two mid-point nodes
|> |||| B: Bud
|> |||| T: Tail
|> ||
|> |||As per your suggestion, when T flag is used in a PHP scenario:
|> |||- Bud nodes will never respond, even if it is their turn to do so,
|> ||
|> ||Let me explain it again. If a packet is sent with TTL 2
|> ||Bud node B receives 2 packets:
|> ||1) Labeled packet, due to TTL expiry (for which it would normally
|> ||perform a  swap and send it to M2)
|> ||2) unlabelled packet, which arrives due to PHP done at M1
|> ||
|> ||The suggestion is to drop the unlabelled packet(2) at bud, if "TTL
|> ||expiry flag" is set, because it landed in B due to PHP done at M1,
|not
|> ||due to label TTL expiry.
|> ||
|> ||
|> |||- Tail nodes will keep responding to all echo requests where TTL
is
|> |||greater than their depth.
|> |||
|> |||I am not sure how this behavior can be helpful to traceroute.
|> ||
|> ||Tail nodes will always get a single copy of the packet unlike bud
|> |nodes.
|> ||
|> ||More ever, if the responder-id tlv is present a node would never
|> |respond
|> ||back, unless the criterions for responder-id tlv are met correctly.
|> ||
|> ||
|> |||The original problem is that bud and tail nodes keep responding to
|> |||traceroute requests, for TTL greater than their depth. The extra
|> |||responses can be prevented if the nodes check for label expiry.
|> |However
|> |||without the label, traceroute packets for various TTL values look
|the
|> |||same. If you have a suggestion on how to solve this problem in a
|PHP
|> |||scenario, I will be willing to put it in the draft.
|> ||
|> ||
|> ||This problem can be solved by dropping +unlabelled packets+ at +bud
|> ||node+, if TTL expiry flag is set in the request.
|> ||
|> ||
|> ||
|> ||
|> ||$hiv...
|> ||
|> ||
|> ||
|> |||-----Original Message-----
|> |||From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|> |||Sent: Tuesday, October 19, 2010 5:08 PM
|> |||To: Shivakumar Channalli
|> |||Cc: [email-masked]; Nitin Bahadur; Shaleen Saxena (ssaxena)
|> |||Subject: RE: [mpls] I-D
Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|> |||
|> |||Hi Shivakumar:
|> |||
|> |||I did not put the suggested text after discussions with other
|> authors.
|> |||The behavior you suggest does not solve the problem of receiving
|> |||multiple responses from various bud and tail nodes during
|traceroute.
|> |||
|> |||As per your suggestion, when T flag is used in a PHP scenario:
|> |||- Bud nodes will never respond, even if it is their turn to do so,
|> |||- Tail nodes will keep responding to all echo requests where TTL
is
|> |||greater than their depth.
|> |||
|> |||I am not sure how this behavior can be helpful to traceroute.
|> |||
|> |||The original problem is that bud and tail nodes keep responding to
|> |||traceroute requests, for TTL greater than their depth. The extra
|> |||responses can be prevented if the nodes check for label expiry.
|> |However
|> |||without the label, traceroute packets for various TTL values look
|the
|> |||same. If you have a suggestion on how to solve this problem in a
|PHP
|> |||scenario, I will be willing to put it in the draft.
|> |||
|> |||Regards,
|> |||Shaleen
|> |||
|> |||-----Original Message-----
|> |||From: Shivakumar Channalli [mailto:[email-masked]]
|> |||Sent: Tuesday, October 19, 2010 2:00 AM
|> |||To: Shaleen Saxena (ssaxena)
|> |||Cc: [email-masked]; Nitin Bahadur
|> |||Subject: [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: [email-masked]
|> |||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:[email-masked]]
|> ||||Sent: Tuesday, June 01, 2010 5:51 PM
|> ||||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin
|Bahadur
|> ||||Cc: [email-masked]; 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:[email-masked]]
|> ||||> Sent: Saturday, May 29, 2010 11:13 AM
|> ||||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> ||||> (ssaxena)
|> ||||> Cc: [email-masked]
|> ||||> 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:[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