rillo (pcamaril)"
Cc: Ron Bonica , "spring@ietf.org"
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Seems like you're saying that if the SID is not an anycast SID it is as though
it were unicast and therefore 4443/2.2/a applies, i.e. the SID is th
;
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *spring on behalf of Ron Bonica 40juniper@dmarc.ietf.org>
> *Date: *Tuesday, 14 January 2020 at 20:28
> *To: *"Pablo Camarillo (pcamaril)"
> *Cc: *"spring@ietf.org"
> *Subject: *Re: [spring]
logic to be able
to choose in between A and B.
Cheers,
Pablo.
From: spring on behalf of Ron Bonica
Date: Tuesday, 14 January 2020 at 20:28
To: "Pablo Camarillo (pcamaril)"
Cc: "spring@ietf.org"
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selec
maril)
Sent: Tuesday, January 14, 2020 12:43 PM
To: j...@joelhalpern.com; Ron Bonica
Cc: spring@ietf.org
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Joel,
I think you might be mistaken.
RFC8402:
SRv6 SID: an IPv6 address explicitly associated wit
To: Ron Bonica
Cc: spring@ietf.org
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Ron,
As a matter of fact we cannot "unequivocally state that a SID is a unicast
address" always. Simple reason: RFC8402 - "3.3. IGP-Anycast Segment
(Anycast-SID)&q
spring@ietf.org"
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection
Pablo,
The problem isn’t a statement in the network programming draft. It is an
omission in the network programming draft.
If the network programming draft unequivocally stated that a SID is a uni
> Pablo.
>
> *From: *Ron Bonica
> *Date: *Friday, 10 January 2020 at 20:09
> *To: *"Pablo Camarillo (pcamaril)"
> *Cc: *"spring@ietf.org"
> *Subject: *RE: [spring] SRv6 Network Programming - ICMP Source Address
> Selection
the ICMP
> > considerations are changed with respect to the SRH? I believe there is
> none.
> >
> > Thank you,
> >
> > Pablo.
> >
> > *From: *Ron Bonica
> > *Date: *Friday, 10 January 2020 at 20:09
> > *To: *"Pablo Camarillo (pcamaril)
Ron
Juniper Business Use Only
From: Pablo Camarillo (pcamaril)
Sent: Monday, January 13, 2020 12:31 PM
To: Ron Bonica
Cc: spring@ietf.org
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Ron,
You cannot pre-select or enforce one of the two options you refer
: *"Pablo Camarillo (pcamaril)"
*Cc: *"spring@ietf.org"
*Subject: *RE: [spring] SRv6 Network Programming - ICMP Source Address
Selection
Pablo,
So, in Section 4.1, Line S03, an SRv6 node sends an ICMP Parameter
Problem Message. What is the source address in that
"
Cc: "spring@ietf.org"
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection
Pablo,
So, in Section 4.1, Line S03, an SRv6 node sends an ICMP Parameter Problem
Message. What is the source address in that message?
Is it the destination address of the offen
?
Ron
Juniper Business Use Only
From: Pablo Camarillo (pcamaril)
Sent: Friday, January 10, 2020 11:54 AM
To: Ron Bonica
Cc: spring@ietf.org
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Ron,
There is no
standards.
Thanks,
Pablo.
From: Ron Bonica
Date: Tuesday, 7 January 2020 at 19:07
To: "Pablo Camarillo (pcamaril)"
Cc: SPRING WG
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection
Pablo,
Let me try to ask the question another way:
1) Is it generally acce
rom: Pablo Camarillo (pcamaril)
Sent: Tuesday, January 7, 2020 4:18 AM
To: Ron Bonica
Cc: SPRING WG
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Ron,
It's good to see agreement on the fact that SRH follows RFC4443 Section 2.2
with respect to how the ICMP So
is no such text.
Thanks,
Pablo.
From: Ron Bonica
Date: Saturday, 21 December 2019 at 20:59
To: "Pablo Camarillo (pcamaril)"
Cc: "spring@ietf.org"
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection
Pablo,
Section 2.2 of RFC 4443 offers t
Ron
Juniper Business Use Only
From: Pablo Camarillo (pcamaril)
Sent: Friday, December 20, 2019 12:30 PM
To: Ron Bonica
Cc: spring@ietf.org
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
Ron,
I guess that draft-ietf-6man-segment-routing-header does not contai
-network-programming that changes
such behavior.
Happy Holidays,
Pablo.
From: spring on behalf of Ron Bonica
Date: Thursday, 19 December 2019 at 14:59
To: "Pablo Camarillo (pcamaril)" , "spring@ietf.org"
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Addr
Pablo,
Can you provide a specific reference into
draft-ietf-6man-segment-routing-header? I can't find the answer to my question
in there.
Ron
Juniper Business Use Only
From: Pablo Camarillo (pcamaril)
Ron,
This is exactly the same as in the SRH.
There is no text in draft-ietf-spring-srv6-network-programming that changes
this.
Cheers,
Pablo.
From: Ron Bonica
Date: Monday, 9 December 2019 at 23:48
To: "Pablo Camarillo (pcamaril)" , SPRING WG
, 6man <6...@ietf.org>
Subject: RE: SRv6 Network P
Pablo,
Section 2.2 of RFC 4443 offers two options. If you think that a SID is a
unicast address, the first option is applicable. If you think that a SID is not
a unicast address, the second option is applicable.
Which did you choose?
Ron,
As you pointed out in your email, RFC4443 Section 2.2 is very clear about how
to select the source address.
draft-ietf-spring-srv6-network-programming does not change this.
Thanks,
Pablo.
From: ipv6 on behalf of Ron Bonica
Date: Friday, 6 December 2019 at 17:40
To: SPRING WG , 6man <6..
Authors,
When an SRv6 node sends an ICMP message, how does it select the ICMP message's
source address?
Section 2.2 of RFC 4443 offers two options. If you think that a SID is a
unicast address, the first option is applicable. If you think that a SID is not
a unicast address, the second option
22 matches
Mail list logo
