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:shivakumar@juniper.net]
> Sent: Friday, October 22, 2010 12:15 PM
> To: Shaleen Saxena (ssaxena)
> Cc: mpls@ietf.org; 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:ssaxena@cisco.com]
> |Sent: Thursday, October 21, 2010 6:28 PM
> |To: Shivakumar Channalli
> |Cc: mpls@ietf.org; 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:shivakumar@juniper.net]
> |Sent: Thursday, October 21, 2010 2:10 AM
> |To: Shaleen Saxena (ssaxena)
> |Cc: mpls@ietf.org; 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:ssaxena@cisco.com]
> ||Sent: Wednesday, October 20, 2010 9:59 PM
> ||To: Shivakumar Channalli
> ||Cc: mpls@ietf.org; 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:shivakumar@juniper.net]
> ||Sent: Tuesday, October 19, 2010 8:41 AM
> ||To: Shaleen Saxena (ssaxena)
> ||Cc: mpls@ietf.org; 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:ssaxena@cisco.com]
> |||Sent: Tuesday, October 19, 2010 5:08 PM
> |||To: Shivakumar Channalli
> |||Cc: mpls@ietf.org; 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:shivakumar@juniper.net]
> |||Sent: Tuesday, October 19, 2010 2:00 AM
> |||To: Shaleen Saxena (ssaxena)
> |||Cc: mpls@ietf.org; 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: 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