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

[Shivakumar Channalli <[e-mail]>]

Shaleen,
Thanks for considering the suggestion.



$hiv...


|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[e-mail]]
|Sent: Tuesday, October 26, 2010 4:55 PM
|To: Nitin Bahadur; Shivakumar Channalli
|Cc: [e-mail]; 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:[e-mail]]
|Sent: Friday, October 22, 2010 4:46 PM
|To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|Cc: [e-mail]
|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:[e-mail]]
|> Sent: Friday, October 22, 2010 12:15 PM
|> To: Shaleen Saxena (ssaxena)
|> Cc: [e-mail]; 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:[e-mail]]
|> |Sent: Thursday, October 21, 2010 6:28 PM
|> |To: Shivakumar Channalli
|> |Cc: [e-mail]; 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:[e-mail]]
|> |Sent: Thursday, October 21, 2010 2:10 AM
|> |To: Shaleen Saxena (ssaxena)
|> |Cc: [e-mail]; 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:[e-mail]]
|> ||Sent: Wednesday, October 20, 2010 9:59 PM
|> ||To: Shivakumar Channalli
|> ||Cc: [e-mail]; 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:[e-mail]]
|> ||Sent: Tuesday, October 19, 2010 8:41 AM
|> ||To: Shaleen Saxena (ssaxena)
|> ||Cc: [e-mail]; 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:[e-mail]]
|> |||Sent: Tuesday, October 19, 2010 5:08 PM
|> |||To: Shivakumar Channalli
|> |||Cc: [e-mail]; 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:[e-mail]]
|> |||Sent: Tuesday, October 19, 2010 2:00 AM
|> |||To: Shaleen Saxena (ssaxena)
|> |||Cc: [e-mail]; 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: [e-mail]
|> |||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:[e-mail]]
|> ||||Sent: Tuesday, June 01, 2010 5:51 PM
|> ||||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin
|Bahadur
|> ||||Cc: [e-mail]; 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:[e-mail]]
|> ||||> Sent: Saturday, May 29, 2010 11:13 AM
|> ||||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> ||||> (ssaxena)
|> ||||> Cc: [e-mail]
|> ||||> 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:[e-mail]]
|> ||||> |Sent: Saturday, May 29, 2010 6:03 AM
|> ||||> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar
|Channalli
|> ||||> |Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]]
On
|> ||||Behalf
|> ||||> |Of
|> ||||> |> Nitin Bahadur
|> ||||> |> Sent: Friday, May 28, 2010 4:52 PM
|> ||||> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|> ||||> |> Cc: [e-mail]
|> ||||> |> 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
|> ||||> |> [e-mail]
|> ||||> |> https://www.ietf.org/mailman/listinfo/mpls