Ron,

Ok. Let me try to be open-minded and understand why you have a concern that 
no-one else is sharing:

I guess that your concern is that since we do not have a second FIB lookup, 
hence you believe that we would just cross-connect the packet. Is this correct?
The fact that we set the egress adjacency as part of the End.X pseudocode does 
not mean that we skip the IPv6 processing, and as part of the IPv6 processing 
we would not forward such packet.

Thanks,
Pablo.

-----Original Message-----
From: Ron Bonica <rbon...@juniper.net>
Date: Tuesday, 10 December 2019 at 00:03
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, Ron Bonica 
<rbonica=40juniper....@dmarc.ietf.org>, "Darren Dukes (ddukes)" 
<ddu...@cisco.com>
Cc: SPRING WG <spring@ietf.org>, Bob Hinden <bob.hin...@gmail.com>, Mark Smith 
<markzzzsm...@gmail.com>
Subject: RE: [spring] SRv6 Network Programming and Link Local Source Addresses

    Pablo,
    
    Let us agree to disagree.
    
    Chairs,
    
    Please do not close this issue.
    
                              Ron
    
    
    
    Juniper Business Use Only
    
    -----Original Message-----
    From: spring <spring-boun...@ietf.org> On Behalf Of Pablo Camarillo 
(pcamaril)
    Sent: Monday, December 9, 2019 10:16 AM
    To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; Darren Dukes 
(ddukes) <ddu...@cisco.com>
    Cc: SPRING WG <spring@ietf.org>; Bob Hinden <bob.hin...@gmail.com>; Mark 
Smith <markzzzsm...@gmail.com>
    Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
Addresses
    
    Ron,
    
    I agree with Bob, Darren and Kamran that the existing IPv6 processing rules 
are followed in Network Programming and do not need to be re-stated.
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: spring <spring-boun...@ietf.org> on behalf of Ron Bonica 
<rbonica=40juniper....@dmarc.ietf.org>
    Date: Friday, 6 December 2019 at 17:17
    To: "Darren Dukes (ddukes)" <ddu...@cisco.com>
    Cc: SPRING WG <spring@ietf.org>, Bob Hinden <bob.hin...@gmail.com>, Mark 
Smith <markzzzsm...@gmail.com>
    Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
Addresses
    
        Darren,
        
        If the draft adhered strictly to RFC 4291 and RFC 8200 in all other 
respects, I would agree with you and Bob. However, it doesn't.
        
        As it stands, the reader is left to guess when the draft adheres to 
previous specifications, but doesn't say so explicitly, and when it is taking 
liberties with previous specifications.
        
                                                                                
       Ron
        
        
        
        
        Juniper Business Use Only
        
        -----Original Message-----
        From: Darren Dukes (ddukes) <ddu...@cisco.com> 
        Sent: Friday, December 6, 2019 10:53 AM
        To: Ron Bonica <rbon...@juniper.net>
        Cc: Bob Hinden <bob.hin...@gmail.com>; SPRING WG <spring@ietf.org>; 
Mark Smith <markzzzsm...@gmail.com>
        Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
Addresses
        
        Hi Ron, I agree with Bob here.
        
        Section 4.2 pseudocode simply says an implementation would use a 
predetermined egress adjacency instead of performing a FIB lookup to find one.  
        It specifies the SID processing, not the entire IPv6 data path.
        
        It has no text that would indicate RFC4291 text on link-local addresses 
and routers would not apply.
        
        As a side note, every routing header currently defined (even those now 
deprecated) do not re-state the RFC4291 text.
        
        Thanks,
          Darren
        
        
        > On Dec 2, 2019, at 10:58 AM, Ron Bonica 
<rbonica=40juniper....@dmarc.ietf.org> wrote:
        > 
        > Bob,
        > 
        > Before we debate presentation too much, we should let Pablo answer 
the original question. Will the packet be dropped or forwarded?
        > 
        > If the packet will be dropped, how is the reader of Section 4.2 to 
know this? Normally, pseudocode is taken literally, and the pseudocode in 
Section 4.2 suggests that the packet will be forwarded.
        > 
        > One way to wiggle out of this problem is to include a sentence at the 
beginning of Section 4 saying, "When the following pseudocode contradicts RFC 
4291 or 8200, RFCs 4291 and 8200 take precedence.
        > 
        >                                                                       
                                       
        > Ron
        > 
        > 
        > 
        > 
        > Juniper Business Use Only
        > 
        > -----Original Message-----
        > From: Bob Hinden <bob.hin...@gmail.com>
        > Sent: Monday, December 2, 2019 10:47 AM
        > To: Ron Bonica <rbon...@juniper.net>
        > Cc: Bob Hinden <bob.hin...@gmail.com>; Mark Smith 
        > <markzzzsm...@gmail.com>; SPRING WG <spring@ietf.org>
        > Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
        > Addresses
        > 
        > Ron,
        > 
        >> On Dec 2, 2019, at 7:36 AM, Ron Bonica <rbon...@juniper.net> wrote:
        >> 
        >> Bob,
        >> 
        >> Take a look at Section 4.2. The pseudocode is pretty specific.
        > 
        > Please explain.  I don’t see that.
        > 
        > Thanks,
        > Bob
        > 
        > 
        >> 
        >>                                           Ron
        >> 
        >> 
        >> 
        >> Juniper Business Use Only
        >> 
        >> -----Original Message-----
        >> From: Bob Hinden <bob.hin...@gmail.com>
        >> Sent: Sunday, December 1, 2019 5:56 PM
        >> To: Ron Bonica <rbon...@juniper.net>
        >> Cc: Bob Hinden <bob.hin...@gmail.com>; Mark Smith 
        >> <markzzzsm...@gmail.com>; SPRING WG <spring@ietf.org>
        >> Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
        >> Addresses
        >> 
        >> Ron,
        >> 
        >>> On Dec 1, 2019, at 2:47 PM, Ron Bonica <rbon...@juniper.net> wrote:
        >>> 
        >>> Mark, Bob,
        >>> 
        >>> Yes, I agree that routers should not forward packets with link 
local source addresses.
        >> 
        >> or Destination addresses.
        >> 
        >>> 
        >>> Pablo,
        >>> 
        >>> Maybe we should update section 4.2 of the network programming draft 
to reflect this?
        >> 
        >> I was thinking that unless network programming has text that might 
cause one to think it overrides the defined behavior from rfc4291 for 
link-local addresses, I am not sure it has to be mentioned.
        >> 
        >> Bob
        >> 
        >> 
        >>> 
        >>>                                                                Ron
        >>> 
        >>> 
        >>> From: Mark Smith <markzzzsm...@gmail.com>
        >>> Sent: Sunday, December 1, 2019 5:31 PM
        >>> To: Bob Hinden <bob.hin...@gmail.com>
        >>> Cc: Ron Bonica <rbon...@juniper.net>; SPRING WG <spring@ietf.org>
        >>> Subject: Re: [spring] SRv6 Network Programming and Link Local 
Source 
        >>> Addresses
        >>> 
        >>> 
        >>> 
        >>> On Mon, 2 Dec 2019, 08:35 Bob Hinden, <bob.hin...@gmail.com> wrote:
        >>> Ron,
        >>> 
        >>>> On Nov 30, 2019, at 12:36 PM, Ron Bonica 
<rbonica=40juniper....@dmarc.ietf.org> wrote:
        >>>> 
        >>>> Pablo,
        >>>> 
        >>>> 
        >>>> 
        >>>> Consider the packet (SA,DA) (S3, S2, S1; SL) where:
        >>>> 
        >>>> 
        >>>> 
        >>>>     • SA is link-local (fe80)
        >>>>     • DA, S3, S2, and S1 are all END.X
        >>>> 
        >>>> 
        >>>> Section 4.2 suggests that this packet will be delivered over 
multiple hops to its destination, regardless of its link-local source address.
        >>> 
        >>> I would think that RFC2460 Section 2.5.6. "Link-Local IPv6 Unicast 
Addresses” covers this:
        >>> 
        >>>  Link-Local addresses are for use on a single link.  Link-Local  
        >>> addresses have the following format:
        >>> 
        >>>  |   10     |
        >>>  |  bits    |         54 bits         |          64 bits           |
        >>>  +----------+-------------------------+----------------------------+
        >>>  |1111111010|           0             |       interface ID         |
        >>>  +----------+-------------------------+----------------------------+
        >>> 
        >>>  Link-Local addresses are designed to be used for addressing on a  
        >>> single link for purposes such as automatic address configuration,  
        >>> neighbor discovery, or when no routers are present.
        >>> 
        >>>  Routers must not forward any packets with Link-Local source or  
        >>> destination addresses to other links.
        >>> 
        >>> I think that's RFC4291.
        >>> 
        >>> RFC4007, "IPv6 Scoped Address Architecture" does too, more 
generally and probably more formally, in particular section 9, "Forwarding".
        >>> 
        >>> Regards,
        >>> Mark.
        >>> 
        >>> 
        >>> 
        >>> Bob
        >>> 
        >>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> Is this the case?
        >>>> 
        >>>> 
        >>>> 
        >>>>                                                            Ron
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> 
        >>>> Juniper Business Use Only
        >>>> _______________________________________________
        >>>> spring mailing list
        >>>> spring@ietf.org
        >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/s
        >>>> pring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1
        >>>> fsLwpCkacVdsltFrrl$
        >>> 
        >>> _______________________________________________
        >>> spring mailing list
        >>> spring@ietf.org
        >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
        >>> ring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fs
        >>> LwpCkacVdsltFrrl$
        >>> 
        >>> Juniper Business Use Only
        > _______________________________________________
        > spring mailing list
        > spring@ietf.org
        > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
        > 
ng__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fsLwpCkacVdsltFrrl$
        _______________________________________________
        spring mailing list
        spring@ietf.org
        
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$
 
        
    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$
 
    

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to