Re: [mpls] update of draft-ietf-mpls-lsp-ping-relay-reply-04

["Lizhong Jin" <[e-mail]>]

Hi Joel,
cc to mpls list as AD requested.
In your example, only when B, C, D, E with K bit set, then will relay to E, to D, to C, then to B.
This is the intention of K bit which is inherited from draft-ietf-mpls-interas-lspping (a merged draft), and when K bit is set, the address will be a relay node. 
In the draft, it says in section 3.2
"The address with K bit set will
always be a relay node address for the Relayed Echo Reply"

But the next relay address selection mechanism does need to be updated, which has led to misunderstanding.



Regards
Lizhong Jin
 
From: Joel M. Halpern
Date: 2014-10-31 21:54
To: Lizhong Jin; 'Carlos Pignataro (cpignata)'; 'draft-ietf-mpls-lsp-ping-relay-reply'
CC: 'adrian'; 'loa'; 'Jari Arkko'
Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
That is indeed a different algorithm, and does not depend upon whether
the K bit is set on the origin.
 
It does have an important result that is VERY different from your
earlier algorithm.  It is an acceptable result to me, but you should
make sure it is your intention.  The reply will now go back to the
closest reliable reverse, rather than the furthest.  So if the LSP goes
through ASBRs B, C, D, and E, the earlier algorithm would send a reply
from F to B to be relayed to the originator.  The new algorithm will
send a reply to E, to be relayed to D, thence to C, thence to B, and
thence to the originator.  This is far more robust.  But it is a
dramatic change in behavior.  I think that such a change really needs
working group review and approval.
 
Yours,
Joel
 
On 10/30/14, 11:13 PM, Lizhong Jin wrote:
> Hi Joel,
> It is not necessary to require to unset K bit for the originator. It is
> required for the border node to add address entry with K bit set, then the
> Echo Reply could be relayed back.
> Back to the example in section 5, if P1 add non-routable address entry with
> K bit set, it is OK. ASBR1 will add IP1 with K bit unset, and IP2 with K bit
> set in the stack. Then P2/ASBR2 will first send Echo Reply to ASBR1, then
> ASBR1 send Echo Reply to P1. Even if the non-routable P1 address is also
> routable in AS2, the node in AS2 will still select ASBR1 as the next relay
> node.
> 
> I read section 4.3 again, and not correctly use word "first", and lead your
> misunderstanding:
> OLD:
> To find out the next relay node address, the node SHOULD check the
>     address items in Relay Node Address Stack TLV in sequence from top to
>     down, and find the first IP routable address, e.g., A, and the first
>     address with K bit set, e.g., B.
> NEW:
> To find out the next relay node address, the node SHOULD check the
>     address items in Relay Node Address Stack TLV in sequence from top to
>     down, and find the first IP routable address, e.g., A, and the last
>     address with K bit set, e.g., B.
> 
> Regards
> Lizhong
> 
>> -----Original Message-----
>> From: Joel Halpern Direct [mailto:[e-mail]]
>> Sent: 2014年10月31日 0:10
>> To: Lizhong Jin; Carlos Pignataro (cpignata);
> draft-ietf-mpls-lsp-ping-relay-
>> reply
>> Cc: adrian; loa; Jari Arkko
>> Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>
>> Not quite:
>>
>> 1) You still have not fixed 4.2.  So if the originator puts on its address
> with the
>> K bit unset, the entry will be removed.  But in order to make the rest of
> your
>> logic work, the originator whose address is not reachable needs to put on
> the
>> entry with the k bit unset.
>>
>> 2) The case I wanted added in section 5 was when P1, the request
> originator,
>> has a non-routable address.  Then when it originates the request, it has
> to
>> provide a stack with its own address with the K bit unset.  Otherwise the
> rest
>> of the logic won't work.
>>
>> Yours,
>> Joel
>>
>> On 10/30/14, 11:31 AM, Lizhong Jin wrote:
>>> Hi Joel,
>>> Thanks for the comments, I made the following changing. Please check
>>> if they are confortable for you.
>>>
>>> In Section 3.2:
>>> Delete: How a node determines to set the K bit is outside the scope of
>>> this document.
>>> Add: One application scenario of K bit is given out in section 5.
>>>
>>> In Section 4.3:
>>> Add: If there is no B existed, then use A as the next relay node
> address.
>>>
>>> In section 5:
>>> Add: In the case that the interface address of ASBR1 to P1 is IP1
>>> which maybe an IPv4 private address and not IP routable for AS2, and
>>> the loopback address on ASRB1 is IP2 which is routable for AS2. Then
>>> when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1 without
>>> K bit set in the Relay Node Address Stack TLV, and then add
>>> IP2 with K bit set in the stack TLV. Then ASBR2/P2 could relay the
>>> Relayed Echo Reply back first to IP2 which is routable for ASBR2/P2,
>>> then ASBR1 will send Echo Reply to PE1. Thanks for the K bit, the
>>> ASBR1 will not be skipped for message relay.
>>>
>>> ----------------------------------------------------------------------
>>> --
>>> Regards
>>> Lizhong Jin
>>>
>>>      *From:* Joel M. Halpern <mailto:[e-mail]>
>>>      *Date:* 2014-10-30 11:15
>>>      *To:* Lizhong Jin <mailto:[e-mail]>; 'Carlos Pignataro
>>>      (cpignata)' <mailto:[e-mail]>;
>>>      'draft-ietf-mpls-lsp-ping-relay-reply'
>>>      <mailto:[e-mail]>
>>>      *CC:* 'adrian' <mailto:[e-mail]>; 'loa'
>>>      <mailto:[e-mail]>; Jari Arkko <mailto:[e-mail]>
>>>      *Subject:* Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>      As I tried to say in my previous reply, your solution to sources who
> are
>>>      not reachable, but for which the routing table may claim
> reachability
>>>      (due to private address duplication or firewalling of sub-blocks
> within
>>>      an advertised region, or...) seems to depend both upon such sources
> not
>>>      setting the k bit in their (first) entry, and on such entries
> surviving
>>>      the intermediate processing.
>>>      Given that this is central to the purpose of the draft, the bit
> setting
>>>      really needs to be described.  And given that this preservation
>>>      contradicts current text, it must be spelled out.
>>>      Yours,
>>>      Joel
>>>      On 10/29/14, 10:28 PM, Lizhong Jin wrote:
>>>       > Hi Joel,
>>>       > Thank you for the prompt reply.
>>>       >
>>>       > The scenario you raised could be solved by setting K bit for a
>>>      routable
>>>       > address. Let me give you the detail.
>>>       > PE1----P1----ASBR1-----ASBR2-----P2-----PE2
>>>       > The initiator is PE1, and the interface address of ASBR1 to P1 is
>>>      Addr1
>>>       > which maybe a private address, and the routable address on ASRB1
>>>      is Addr2.
>>>       > Then when ASBR1 send a relayed echo reply, it will firstly add
>>>      Addr1 in the
>>>       > stack, and then add Addr2 with K bit set in the stack.
>>>       > Then P2 could relay the echo reply back first to Addr2, then
>>>      Addr1 by ASBR1.
>>>       >
>>>       > I consider above as an application case of K bit, so I did not
>>>      give out the
>>>       > detail. But I could add some text about above example in section
>>>      5 if you
>>>       > insist.
>>>       > In the document, it says:
>>>       > Some nodes could be configured to always set the K bit,
>>>       >     or the module handling MPLS echo requests could discover its
>>>      K bit
>>>       >     use through topology awareness.  How a node determines to set
>>>      the K
>>>       >     bit is outside the scope of this document.
>>>       >
>>>       > But I forget to add the sentence in section 4.2 which I promise
>>>      to Carlos to
>>>       > add:
>>>       > A second or more address entries could also be added if
>>>      necessary, which
>>>       > depends on implementation.
>>>       >
>>>       > Regards
>>>       > Lizhong
>>>       >
>>>       >
>>>       >> -----Original Message-----
>>>       >> From: Joel M. Halpern [mailto:[e-mail]]
>>>       >> Sent: 2014年10月30日 0:24
>>>       >> To: Lizhong Jin; Carlos Pignataro (cpignata);
>>>       > draft-ietf-mpls-lsp-ping-relay-
>>>       >> reply
>>>       >> Cc: adrian; loa
>>>       >> Subject: Re: update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>
>>>       >> This revision does not seem to address my comments from October
>>>      24.  The
>>>       >> assumption that sources will set K in certain ways is still
>>>      implici rather
>>>       > than
>>>       >> explicit, as far as I can tell.
>>>       >>
>>>       >> More importantly, if sources do not set the K bit on their own
> stack
>>>       > entry, so
>>>       >> as to enable the improved relay selection logic to work, then
>>>      the soure
>>>       > entry
>>>       >> will be removed by the logic in 4.2.
>>>       >>
>>>       >> Yours,
>>>       >> Joel
>>>       >>
>>>       >> PS: Here is the body of what I wrote on the 24th:
>>>       >>
>>>       >> We are getting close.
>>>       >> I believe that the intent is that if a node has reason to
>>>      believe that its
>>>       > address
>>>       >> will be NATed or firewalled at the domain edge, then it should
>>>      put in its
>>>       >> address, but not set the K bit.
>>>       >> If the originator does this, then other folks within his domain
> will
>>>       > respond
>>>       >> directly, while anyone past the domain edge will relay to the
>>>      border node,
>>>       >> who will set the K bit.
>>>       >>
>>>       >> If that is the intent, then there are two things that are
> needed:
>>>       >> 1) We need to actually say that, and not leave the implementor
>>>      guessing.
>>>       >> 2) In section 4.2 it needs to be noted that the originator
>>>      address must
>>>       > not be
>>>       >> removed even if the K bit is not set on that address.
>>>       >>
>>>       >> On 10/29/14, 11:17 AM, Lizhong Jin wrote:
>>>       >>> Hi, all,
>>>       >>> The cut-off time of draft submission has been passed. I will
> upload
>>>       >>> the new version once it is reopened.
>>>       >>> Please check if the new version is OK for you all. Thank you.
>>>       >>>
>>>       >>>
>>>
> ----------------------------------------------------------------------
>>>       >>> --
>>>       >>> Regards
>>>       >>> Lizhong Jin
>>>       >>>
>>>       >>>      *发件人：* Lizhong Jin <mailto:[e-mail]>
>>>       >>>      *发送时间：* 2014-10-25 00:03
>>>       >>>      *收件人：* jmh <mailto:[e-mail]>; loa
>>>       >> <mailto:[e-mail]>;
>>>       >>>      Carlos Pignataro (cpignata) <mailto:[e-mail]>
>>>       >>>      *抄送：* draft-ietf-mpls-lsp-ping-relay-reply
>>>       >>>
> <mailto:[e-mail]>
>>>       >>>      *主题：* update of draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>      Hi Joel, Carlos
>>>       >>>      The new version attached is sending to you for
>>>      confirmation, before
>>>       >>>      publishing. Thank you again for your comments.
>>>       >>>
>>>       >>>
>>>       >
>>>
> ------------------------------------------------------------------------
>>>       >>>      Regards
>>>       >>>      Lizhong Jin
>>>       >>>
>>>       >>>          *发件人：* Joel M. Halpern
> <mailto:[e-mail]>
>>>       >>>          *发送时间：* 2014-10-23 22:25
>>>       >>>          *收件人：* Loa Andersson <mailto:[e-mail]>;
>>>      [e-mail]
>>>       >>>          <mailto:[e-mail]>
>>>       >>>          *主题：* Re: [mpls] [Gen-art] review:
>>>       >>>          draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>          It has converged to the degree that Lizhong believes
>>>      he can make
>>>       > the
>>>       >>>          changes needed to address my concerns.  I believe he
>>>      understands
>>>       > the
>>>       >>>          concerns.  I do not understand some of the important
>>>      aspects of
>>>       > his
>>>       >>>          proposal, but look forward to seeing the draft.
>>>       >>>          Yours,
>>>       >>>          Joel
>>>       >>>          On 10/23/14, 10:17 AM, Loa Andersson wrote:
>>>       >>>           > Lizhong and Joel,
>>>       >>>           >
>>>       >>>           > Should I interpret this as that the discussion has
>>>      converged
>>>       > on a
>>>       >>>           > solution that you both are comfortable with?
>>>       >>>           >
>>>       >>>           > /Loa
>>>       >>>           >
>>>       >>>           > On 2014-10-22 16:05, [e-mail] wrote:
>>>       >>>           >> Joel, thank you for the review. We will send out a
> new
>>>       >>>          version soon to reflect the discussion.
>>>       >>>           >>
>>>       >>>           >> Regards
>>>       >>>           >> Lizhong
>>>       >>>           >>
>>>       >>>           >>
>>>       >>>           >>
>>>       >>>           >>> 在 2014年10月22日，下午9:30，Joel Halpern Direct
>>>       >>>          <[e-mail]> wrote：
>>>       >>>           >>>
>>>       >>>           >>> It would be good to see a revision that clearly
>>>      spelled out
>>>       >>>          what the
>>>       >>>           >>> draft was solving, how the initial end-point knew
>>>      what to
>>>       >>>          create, and
>>>       >>>           >>> how the responder knew what to use.  It may well
>>>      be that
>>>       >>>          there is an
>>>       >>>           >>> effective solution to the problems here.  I look
>>>      forward to
>>>       >>>          seeing it in
>>>       >>>           >>> writing.
>>>       >>>           >>>
>>>       >>>           >>> Yours,
>>>       >>>           >>> Joel
>>>       >>>           >>>
>>>       >>>           >>>> On 10/22/14, 12:46 AM, Lizhong Jin wrote:
>>>       >>>           >>>> Hi Joel,
>>>       >>>           >>>> The things may not be that bad. You could add a
>>>      second
>>>       >>>          address (address B in
>>>       >>>           >>>> our example) with K bit set. The address entry
>>>      with K bit
>>>       >>>          set must be as a
>>>       >>>           >>>> relay node, and could not be skipped.
>>>       >>>           >>>> Section 4.4 should be changed to: Find the first
>>>      routable
>>>       >>>          address A, and the
>>>       >>>           >>>> first address B with K bit set. If address A is
>>>      before
>>>       >>>          address B in the
>>>       >>>           >>>> stack, then use address B as the relay address.
>>>      Otherwise,
>>>       >>>          use address A as
>>>       >>>           >>>> the relay address.
>>>       >>>           >>>> In that case, if A is the private address, the
>>>      packet will
>>>       >>>          be firstly
>>>       >>>           >>>> relayed to address B. And address A and B belong
>>>      to one
>>>       >>>          router. Here I
>>>       >>>           >>>> assume one router at least has one routable
>>>      address for
>>>       >>>          another AS.
>>>       >>>           >>>>
>>>       >>>           >>>> Regards
>>>       >>>           >>>> Lizhong
>>>       >>>           >>>>
>>>       >>>           >>>>> -----Original Message-----
>>>       >>>           >>>>> From: Joel M. Halpern
> [mailto:[e-mail]]
>>>       >>>           >>>>> Sent: 2014年10月22日 11:14
>>>       >>>           >>>>> To: Lizhong Jin
>>>       >>>           >>>>> Cc: [e-mail]; [e-mail]; ietf@ietf.
> org;
>>>       >>>           >>>> 'draft-ietf-mpls-lsp-ping-
>>>       >>>           >>>>> relay-reply.all'
>>>       >>>           >>>>> Subject: Re: [mpls] [Gen-art] review:
>>>       >>>           >>>> draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>           >>>>>
>>>       >>>           >>>>> ou are saying that this is only for the case
>>>      where an AS
>>>       >>>          is using public
>>>       >>>           >>>>> addresses for its internal numbering, but is
> not
>>>       >>>          distributing that address
>>>       >>>           >>>> block
>>>       >>>           >>>>> externally?
>>>       >>>           >>>>>
>>>       >>>           >>>>> If so, you need to state that very clearly.
>>>       >>>           >>>>> I believe a far more common case is one where
> the
>>>       >>>          numbering is from a
>>>       >>>           >>>>> portion of a publicly allocated space, but
>>>      firewalled.
>>>       >>>          Which would
>>>       >>>           >>>> produce
>>>       >>>           >>>>> the same problem, but would not be amenable to
> this
>>>       > solution.
>>>       >>>           >>>>> And it is well known that many ISPs do internal
>>>      number
>>>       >>>          assignment from
>>>       >>>           >>>>> private blocks.
>>>       >>>           >>>>>
>>>       >>>           >>>>> So what you are now saying is that this draft
>>>      solves a
>>>       >>>          very small portion
>>>       >>>           >>>> of the
>>>       >>>           >>>>> problem?  But it works for that small portion?
>>>      If so, at
>>>       >>>          the very least
>>>       >>>           >>>> you
>>>       >>>           >>>>> need to be VERY clear about what cases this
>>>      works for and
>>>       >>>          what cases it
>>>       >>>           >>>> does
>>>       >>>           >>>>> not.  And I fear that even if you are clear, it
>>>      is going
>>>       >>>          to be very
>>>       >>>           >>>> confusing for
>>>       >>>           >>>>> folks who are trying to use it.
>>>       >>>           >>>>>
>>>       >>>           >>>>> Yours,
>>>       >>>           >>>>> Joel
>>>       >>>           >>>>>
>>>       >>>           >>>>>> On 10/21/14, 10:51 PM, Lizhong Jin wrote:
>>>       >>>           >>>>>> Hi Joel,
>>>       >>>           >>>>>> I now see your concern. The "private" word in
>>>      draft is
>>>       >>>          not correct, I
>>>       >>>           >>>>>> will remove it. The original motivation of
>>>       >>>          "draft-relay-reply" is from
>>>       >>>           >>>>>> the scenario where IP address distribution is
>>>      restricted
>>>       >>>          among AS or IGP
>>>       >>>           >>>>> area.
>>>       >>>           >>>>>> And the IP address is not private address. As
>>>      I know,
>>>       >>>          most deployed
>>>       >>>           >>>>>> inter-AS or inter-area MPLS LSP is in the
> network
>>>       >>>          without private IP
>>>       >>>           >>>> address.
>>>       >>>           >>>>>>
>>>       >>>           >>>>>> Regards
>>>       >>>           >>>>>> Lizhong
>>>       >>>           >>>>>>
>>>       >>>           >>>>>>
>>>       >>>           >>>>>>> -----Original Message-----
>>>       >>>           >>>>>>> From: Joel M. Halpern
>>>      [mailto:[e-mail]]
>>>       >>>           >>>>>>> Sent: 2014年10月22日 10:15
>>>       >>>           >>>>>>> To: Lizhong Jin
>>>       >>>           >>>>>>> Cc: [e-mail]; [e-mail];
>>>      [e-mail];
>>>       >>>           >>>>>> 'draft-ietf-mpls-lsp-ping-
>>>       >>>           >>>>>>> relay-reply.all'
>>>       >>>           >>>>>>> Subject: Re: [mpls] [Gen-art] review:
>>>       >>>           >>>>>> draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>> The problem is that the original source A,
>>>      that we are
>>>       >>>          trying to
>>>       >>>           >>>>>>> reach
>>>       >>>           >>>>>> with a
>>>       >>>           >>>>>>> reply, has an address that appears to the
>>>      responder X
>>>       >>>          to be routable.
>>>       >>>           >>>>>>> But the destination that is reached by that
>>>      address is
>>>       >>>          either a black
>>>       >>>           >>>>>>> hole or
>>>       >>>           >>>>>> some
>>>       >>>           >>>>>>> other entity using the same address.
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>> The reason for the duplication is that, as
>>>      described in
>>>       >>>          the draft,
>>>       >>>           >>>>>>> the
>>>       >>>           >>>>>> source
>>>       >>>           >>>>>>> address for A is a private address.  That
>>>      same address
>>>       >>>          may well be
>>>       >>>           >>>>>> reachable
>>>       >>>           >>>>>>> according to the routing table at X.  But it
>>>      won't get
>>>       >>>          to A.
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>> If the problem is something other than
> private
>>>       >>>          addressing preventing
>>>       >>>           >>>>>>> reachability, it is likely there is still a
>>>      mistaken
>>>       >>>          routability
>>>       >>>           >>>>>>> problem,
>>>       >>>           >>>>>> but I can
>>>       >>>           >>>>>>> not illustrate the failure without some other
>>>      case
>>>       >>>          being described.
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>> Yours,
>>>       >>>           >>>>>>> Joel
>>>       >>>           >>>>>>>
>>>       >>>           >>>>>>>> On 10/21/14, 10:06 PM, Lizhong Jin wrote:
>>>       >>>           >>>>>>>> Inline, thanks.
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>>> -----Original Message-----
>>>       >>>           >>>>>>>>> From: Joel M. Halpern
>>>      [mailto:[e-mail]]
>>>       >>>           >>>>>>>>> Sent: 2014年10月22日 0:06
>>>       >>>           >>>>>>>>> To: [e-mail]
>>>       >>>           >>>>>>>>> Cc: [e-mail]; [e-mail];
>>>      [e-mail];
>>>       >>>           >>>>>>>> draft-ietf-mpls-lsp-ping-
>>>       >>>           >>>>>>>>> relay-reply.all
>>>       >>>           >>>>>>>>> Subject: Re: [mpls] [Gen-art] review:
>>>       >>>           >>>>>>>> draft-ietf-mpls-lsp-ping-relay-reply-04
>>>       >>>           >>>>>>>>>
>>>       >>>           >>>>>>>>> In line.
>>>       >>>           >>>>>>>>>
>>>       >>>           >>>>>>>>>> On 10/21/14, 10:36 AM, [e-mail]
>>>      wrote:
>>>       >>>           >>>>>>>>>> Hi Joel, see inline below, thanks.
>>>       >>>           >>>>>>>>>>
>>>       >>>           >>>>>>>>>> Lizhong
>>>       >>>           >>>>>>>>>>
>>>       >>>           >>>>>>>>>>
>>>       >>>           >>>>>>>>>>> 2014.10.21，PM9:30，Joel M. Halpern
>>>       >>>          <[e-mail]>
>>>       >>>           >>>>> wrote ：
>>>       >>>           >>>>>>>>>>>
>>>       >>>           >>>>>>>>>>> If the process for this draft is to use
>>>      the top
>>>       >>>          address that can
>>>       >>>           >>>>>>>>>>> be reached in the routing table, then
>>>      there is a
>>>       >>>          significant
>>>       >>>           >>>>>>>>>>> probability that the original source
>>>      address, which
>>>       >>>          is always at
>>>       >>>           >>>>>>>>>>> the top of the list, will be used.  As
>>>      such, the
>>>       >>>          intended problem
>>>       >>>           >>>>>>>>>>> will not be solved.
>>>       >>>           >>>>>>>>>> [Lizhong] let me give an example to
>>>      explain: the
>>>       >>>          source address A
>>>       >>>           >>>>>>>>>> is firstly added to the stack, then a
> second
>>>       >>>          routable address B
>>>       >>>           >>>>>>>>>> for replying AS is also added. The reply
>>>      node will
>>>       >>>          not use address
>>>       >>>           >>>>>>>>>> A since it's not routable, then it will
>>>      use address
>>>       >>>          B. So it will
>>>       >>>           >>>>>>>>>> work and I don't see the problem.
>>>       >>>           >>>>>>>>>
>>>       >>>           >>>>>>>>> The whole point of this relay mechanism, as
> I
>>>       >>>          understand it, is to
>>>       >>>           >>>>>>>>> cope
>>>       >>>           >>>>>>>> with
>>>       >>>           >>>>>>>>> the case when the responder X can not
>>>      actually reach
>>>       >>>          the source A.
>>>       >>>           >>>>>>>>>      Now suppose that the packet arrives at
>>>      X with
>>>       >>>          the Address stack
>>>       >>>           >>>>>>>>> A, B,
>>>       >>>           >>>>>> ...
>>>       >>>           >>>>>>>> X
>>>       >>>           >>>>>>>>> examines the stack.  The domain of A was
>>>      numbered
>>>       >>>          using net 10.
>>>       >>>           >>>>>>>>> The domain of X is numbered using net 10.
> A's
>>>       >>>          address is probably
>>>       >>>           >>>>>>>> routable
>>>       >>>           >>>>>>>>> in X's routing table.  The problem is, that
>>>      routing
>>>       >>>          will not get to
>>>       >>>           >>>>>>>>> A.  X
>>>       >>>           >>>>>>>> examines
>>>       >>>           >>>>>>>>> the stack, determines that A is "routable",
>>>      and sends
>>>       >>>          the packet.
>>>       >>>           >>>>>>>>> This
>>>       >>>           >>>>>>>> fails to
>>>       >>>           >>>>>>>>> meet the goal.
>>>       >>>           >>>>>>>> [Lizhong] The source A you are referring is
> the
>>>       >>>          initiator, right?
>>>       >>>           >>>>>>>> The goal of relay mechanism is to reach the
>>>      initiator.
>>>       >>>          If X is
>>>       >>>           >>>>>>>> routable to the initiator (address A), then
>>>      it is
>>>       >>>          great, other relay
>>>       >>>           >>>>>>>> node in the stack will be skipped.
>>>       >>>           >>>>>>>> If the source A you are referring is the
>>>      interface
>>>       >>>          address of one
>>>       >>>           >>>>>>>> intermediate node, then I do not understand
>>>      "routing
>>>       >>>          will not get to
>>>       >>>           >>>>>>>> A.  X examines the stack, determines that A
> is
>>>       >>>          "routable", and sends
>>>       >>>           >>>>>>>> the
>>>       >>>           >>>>>>> packet".
>>>       >>>           >>>>>>>> Why routing will not get to A, but A is
>>>      routable?
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>> Regards
>>>       >>>           >>>>>>>> Lizhong
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>>>
>>>       >>>           >>>>>>>>> Yours,
>>>       >>>           >>>>>>>>> Joel
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>>>
>>>       >>>           >>>>>>
>>>       >>>           >>>>
>>>       >>>           >>
>>>       >>>           >
>>>       >>>
>>>       >
>>>       >
>>>