Re: [pim] Some questions on RFC 6754

["Heidi Ou (hou)" <[e-mail]>]

Hi Bharat,

Please search for [heidi2] for reply. I will also reply to your comments
on draft-ietf-pim-drlb. But
let's close this discussion first.

On 7/18/13 9:28 PM, "Bharat Joshi" <[e-mail]> wrote:

>Hi Heidi,
>
>        Please see my response in line.
>
>Regards,
>Bharat
>
>>Please find reply inline, search for [heidi]
>>>________________________________________
>>>From: Bharat Joshi
>>>Sent: Monday, July 08, 2013 12:17 PM
>>>To: [e-mail]
>>>Subject: Some questions on RFC 6754
>>>
>>>Hi,
>>>
>>>       I was reading up RFC 6754 to understand the requirement and
>>>solution proposed for ECMP routes handling and I have some basic
>>>questions. It would be great if someone can asnwer them for me.
>>>
>>>Regards,
>>>Bharat
>>>
>>>€ In section 1, in sentence:
>>>
>>>This document introduces the ECMP Redirect, a mechanism to improve the
>>>RPF procedure over ECMP.
>>>
>>>      I did not get what does the term 'RPF procedure over ECMP'
>>>actually means? Can somebody please elaborate the same?
>>[heidi] "RPF procedure" means the algorithm a router runs to find the
>>[heidi] RPF neighbor for a source or RP. The steps include routing table
>>[heidi] lookups and tie break evaluation.
>
>I understand 'RPF procedure' but your explanation above is still not
>enough to explain what does 'RPF procedure over ECMP' means?
>
>My thinking was that this RFC has proposed a mechanism (ECMP redirect) to
>suggest downstream neighbors to select another upstream neighbor for its
>PIM join. I am not sure how it "improces" the RPF procedure over ECMP. It
>bascially direct the downstream neighbor to use another neighbor. Right?

[heidi2] It solves a problem that current mechanism, namely PIM Assert,
can't 
[heidi2] handle well. The potential use cases were discussed at the IETF
meetings
[heidi2] and capture in the proceedings and meeting notes


>
>>>
>>>€ In section 1, in sentence:
>>>
>>>While implementations supporting ECMP have been deployed widely, the
>>>existing RPF selection methods have weaknesses
>>>
>>>      Should 'RPF selection' be 'Upstream PIM neighbor selection'?
>>[heidi] The same meaning.
>
>IMHO, we are selecting upstream PIM neighbor. RPF is a method to do that.
>Right?

[heidi2] We use "RPF procedure" to determine RPF neighbors. These are
[heidi2] fairly common and well accepted terminologies.


>
>>>€ In section 1, in sentence
>>>
>>>For example, there is no straightforward way to tell two downstream
>>>routers to select either the same or different RPF neighbor routers for
>>>the same traffic flows.
>>>
>>>      What are the conditions where downstream routers would want to
>>>choose two different RPF neighbors for the same traffic flows? I was
>>>thinking that we need some method like a hash to make sure that all
>>>downstream router uses the same upstream neighbor so that only one
>>>router forwards traffic for a given channel. This will also avoid need
>>>for assert messages in such scenarios.
>>[heidi] Please refer to the IETF 80 proceedings for more background
>>information.
>>[heidi] But in short, due to different implementations deployed,
>>different
>>tie-break
>>[heidi] algorithms used and/or policies configured, two routers might
>>very
>>well choose
>>[heidi] different RPF neighbors. It is not common but it happens.
>
>I perfectly understand the reason for selecting two different upstream
>neighbors but that issue can be resolved by using a simple hash algorithm
>instead of adding this new PIM ECMP redirect message. In fact, I was
>looking for such a solution and when I found this RFC solves a different
>issue, I have submitted a very small draft to solve this. Please do
>review the draft at
>http://tools.ietf.org/html/draft-joshi-pim-ecmp-neighbor-select-00‎

[heidi2] We believe there are legitimate cases where downstream routers
[heidi2] would select different upstream routers, no matter what hash
[heidi2] algorithm they use. And that is why we believe the solution
[heidi2] should come from upstream router, not from downstream router.
[heidi2] And the implementation has been deployed.

[heidi2] I will comment on your draft once I study it carefully.



>
>>>
>>>€ In Overview, in sentence
>>>
>>>When the RPF neighbor router receives the Join message and finds that
>>>the receiving interface is one of the ECMP interfaces, it will check if
>>>the same flow is already being forwarded out of another ECMP interface.
>>>
>>>      How does a upstream router figures out that the receiving
>>>interface is one of the ECMP interfaces for the downstream router?
>>[heidi] If the router sees Join on an interface, and the interface is
>>one
>>[heidi] of those in the ECMP bundle, the interface is one of the ECMP
>>interface.
>>  
>
>Please bear with me but I still do not understand. How the upstream
>router will be able to find out if downstream router has an ECMP route
>for a specific source/RP?


[heidi2] The upstream router never needs to find out if a downstream
router 
[heidi2] has an ECMP route for a specific source/RP or not. This is not a
[heidi2] requirement. All the upstream router needs to know is that it
[heidi2] receives a PIM Join from an interface A that is part of an ECMP
[heidi2] bundle, and within that bundle, there is another interface B who
[heidi2] has previously received a PIM Join for the same flow.



>
>I sincerely feel that RFC is not clear enough on how this is done? In
>fact, I was later looking at AD and IESG comments and I see that Stewart
>had the same doubt. Please find his question submitted on '2012-06-20' at
>http://datatracker.ietf.org/doc/rfc6754/history/ Unfortunately, I could
>not find the author's response for his questions and so I asked here.


[heidi2] That discussion took place during the IESG review. We did
[heidi2] address the concerns and the reviewers were satisfied by the
[heidi2] answers. But I’m not sure how to retrieve the discussion
[heidi2] from IETF archives. Perhaps the chairs can help here.
[heidi2] Below, I’m including some emails that I happen to keep.
[heidi2] Hope it helps.



>>>
>>>
>>>
>>>===
>>>
>>> Section 2.1: From the statement "a PIM ECMP Redirect message is
>>>sent by
>>> an upstream router to notify downstream routers to redirect PIM
>>>Joins
>>> to the new RPF neighbor via a different interface. . When the
>>> downstream routers receive this message, they SHOULD trigger PIM
>>> Joins toward the new RPF neighbor specified in the packet."
>>>
>>>
>>> It is unclear how the upstream neighbor (preferred upstream router)
>>>determines the alternate neighbor.
>>>
>>[Yiqun Cai]
>>We can actually look at it from two ways.
>>
>>The draft doesn't intend to describe all the possible use cases and
>>what kind of decision a router must make in those situations before
>>sending out an ECMP Redirect. It is impractical to do the first and the
>>information will likely be obsoleted over time. And it does not make
>>much sense to do the second because 1) it is mostly proprietary and 2)
>>whether one follows the same logic or not, interoperability is not
>>affected. So we focus on the description of "bits and bytes", what they
>>mean and how a PIM router would react to that to make sure interoperable
>>implementations are possible.
>>
>>Having said that, the draft does hint a couple of examples how an
>>upstream router might use ECMP Redirect. For example, if the router is
>>forwarding out to ethernet1, it will "redirect" downstream routers
>>joining ethernet2 to "rejoin" ethernet1. It is not a very complicated
>>decision process in this case.
>OK, though it might be best if you explained that in the draft to stop
>others puzzling over the problem. It will only take a few lines.

Right. This was clearly explained in the Overview section, 4th
paragraph,

"When the RPF neighbor router receives the Join message and finds that
the receiving interface is one of the ECMP interfaces, it will check
if the same flow is already being forwarded out of another ECMP
interface. If so, this RPF neighbor router will send a PIM ECMP
Redirect message onto the interface the Join was received on. The
PIM ECMP Redirect message contains the address of the desired RPF
neighbor, an interface ID [RFC6395], along with other parameters used
as tie breakers."


>
>>
>>
>>>Please describe how the proposed algorithm ensures an upstream
>>>neighbor
>>>will be determined if the selection rules aren't consistent or known
>>>among
>>>PIM routers.
>>[Yiqun Cai]
>>This is determined by "preference" and "metric". The process is very
>>similar to the Assert process described by RFC4601. We can highlight
>>that in the draft if you think it will help.
>
>Please do that.


Will add one clarification to the end of sub-section "5.2 Receiving ECMP
Redirect",

"The tie break procedure is the same as that used in PIM Assert processing
described by [RFC4601]."








>
>>>      Also, it is not clear how the upstream route can check if the
>>same
>>>flow is being forwarded out of another ECMP interfaces? Are these
>>>interfaces pointing to the same LAN?
>>>
>>>       Let me try to put a figure and ask this.
>>>
>>>        +------+          +-----+
>>>         |  R1   |            |  R2 |
>>>        +------+          +-----+
>>>             |                     |
>>>   +-----------------------------------+
>>>             |                     |
>>>        +------+          +-----+
>>>         |  R3   |            |  R4 |
>>>        +------+          +-----+
>>[heidi] The ECMP bundles contain interfaces on different LANs. In the
>>digram
>>[heidi] you drew above, all routers are connected to the same LAN,
>>regular
>>PIM
>>[heidi] Assert will take place to determine RPF path.
>
>It is not clear from the text in RFC that we are talking about two
>different LANs. In fact, when I looked through the mailing list, I found
>an e-mail from Adrain who has a similar issue. E-mail is at
>http://www.ietf.org/mail-archive/web/pim/current/msg02396.html.


[heidi2] We also replied that and stated it clearly in Overview

When the RPF neighbor router receives the Join message and finds that
the receiving interface is one of the ECMP interfaces, it will check
if the same flow is already being forwarded out of another ECMP
interface. 




[heidi2] The concept of ECMP bundle is also defined in the Terminology
section.




>
>Overall, IMHO I feel that the text in this RFC needs improvement to
>clearly define the network configuration it is aimed for. A figure
>explainging the same will be very helpful. I am not sure if it will be
>good to file an Errata to cleear this confusion or not. I will leave this
>to Working-Group Chair to decide.


[heidi2] Yes, it is up to the chair. But so far, I don't see any need yet.

[heidi2] Regards,
[heidi2] - Heidi



>
>>Thanks
>>- Heidi
>>>
>>>In above configuration, how R1 would come to know if R3 has an ECMP
>>>route for a source/RP through both R1 and R2? Also, if there is a flow
>>>already exist through R2, how will R1 come that the flow is because of
>>>the ECMP route in R3 and R4?
>>>
>>>Am I missing something here?
>>>
>>>€ Its not clear how will the routers (R1 to R4) create ECMP bundle? Is
>>>it that in this particular case, there will only be one interface in
>>>that ECMP bundle?
>>>
>>>€ It would have been great if a figure was used to describe the
>>>operations. I know its my limitation as I am not able to understand the
>>>text correctly.
>
>**************** CAUTION - Disclaimer *****************
>This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
>solely
>for the use of the addressee(s). If you are not the intended recipient,
>please
>notify the sender by e-mail and delete the original message. Further, you
>are not
>to copy, disclose, or distribute this e-mail or its contents to any other
>person and
>any such actions are unlawful. This e-mail may contain viruses. Infosys
>has taken
>every reasonable precaution to minimize this risk, but is not liable for
>any damage
>you may sustain as a result of any virus in this e-mail. You should carry
>out your
>own virus checks before opening the e-mail or attachment. Infosys
>reserves the
>right to monitor and review the content of all messages sent to or from
>this e-mail
>address. Messages sent to or from this e-mail address may be stored on the
>Infosys e-mail system.
>***INFOSYS******** End of Disclaimer ********INFOSYS***
>