5, 2020 4:57 PM
To: Ron Bonica
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
Hi Ron,
So what in your opinion would happen with the below if there is no Routing
Header at all and I still modify DA at each segment endpoint ?
Hi Ron,
So what in your opinion would happen with the below if there is no Routing
Header at all and I still modify DA at each segment endpoint ?
Can I still put two Destination options ?
Or reading the RFC8200 verbatim first DOH must be placed before RH hence to
have more then one DOH in a pack
: Ron Bonica ; Tom Herbert ; Brian
E Carpenter
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?
[External Email. Be cautious of content]
Hi Ron,
Thank you to share the facts of RFC8200.
Could you please explain how CRH supports
; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?
Folks,
I think that we are all talking past one another. RFC 8200 recommends specific
ordering of extension headers for a reason.
IPv6 extension header are ordered as follows:
- Headers processed at
-
From: Tom Herbert
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter
Cc: Robert Raszuk ; Ron Bonica ;
spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
[External Email. Be cautious of content]
On Sun, May 24, 2020 at 2:51 PM B
--Original Message-
From: Joel M. Halpern
Sent: Sunday, May 24, 2020 7:53 PM
To: James Guichard
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
We did construct (and describe in an I-D) a version of the PSSI that c
integrate with NSH.
Jim
-Original Message-
From: Joel M. Halpern
Sent: Sunday, May 24, 2020 7:53 PM
To: James Guichard
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
We did construct (and describe in an I-D) a version
On Sun, May 24, 2020 at 2:51 PM Brian E Carpenter
wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote:
> >>
> >> Hi Ron,
> >>
> >> I have one small question on the Destination Option Header you keep
> >> referencing to carry for example VPN d
Raszuk
*Sent:* Sunday, May 24, 2020 5:03 PM
*To:* Brian E Carpenter
*Cc:* Ron Bonica ;
spring@ietf.org; 6man <6...@ietf.org>
*Subject:* Re: [spring] How CRH support SFC/Segment Endpoint option?
Hi Brian,
No playing with words intended at all.
But as you very well know half of the room read R
routing header and note 3 is for DOH after
routing header.
Jim
From: spring On Behalf Of Robert Raszuk
Sent: Sunday, May 24, 2020 5:03 PM
To: Brian E Carpenter
Cc: Ron Bonica ; spring@ietf.org; 6man
<6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
Hi Bria
There can be a destination options header before the routing header.
And there can be one after the routing header. The former is examined
at every addressed destination. The later is examined when the routing
header reaches its final destination.
That is the RFC 8200 defined behavior.
Yours
On 25-May-20 09:08, Tom Herbert wrote:
> On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote:
>>
>> Hi Ron,
>>
>> I have one small question on the Destination Option Header you keep
>> referencing to carry for example VPN demux instructions.
>>
>> As DOH follows Fragment Header it is indeed inspe
Hi Tom,
Thank you !
That confirms my understanding ie that DOH will be examined at each segment
endpoint hop if DOH is present.
So just like PSSI or TPF suggest a build in filtering (for example by
target ID) is required to avoid misuse.
Kind regards,
Robert.
> Robert,
>
> Look at Destinatio
On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote:
>
> Hi Ron,
>
> I have one small question on the Destination Option Header you keep
> referencing to carry for example VPN demux instructions.
>
> As DOH follows Fragment Header it is indeed inspected before CRH.
>
> So please kindly clarify wh
Hi Brian,
No playing with words intended at all.
But as you very well know half of the room read RFC8200 verbatim to what
the definition of destination node is. Clearly segment endpoint address
would be the "local" destination of the packet when it receives it.
It seems very clear that RFC8200 a
Hi Robert,
On 24-May-20 22:22, Robert Raszuk wrote:
> Hi Ron,
>
> I have one small question on the Destination Option Header you keep
> referencing to carry for example VPN demux instructions.
>
> As DOH follows Fragment Header it is indeed inspected before CRH.
>
> So please kindly clarify
Hi Ron,
I have one small question on the Destination Option Header you keep
referencing to carry for example VPN demux instructions.
As DOH follows Fragment Header it is indeed inspected before CRH.
So please kindly clarify what is there in the IPv6 packet header which
would stop each segment en
Cheng,
The CRH is a building block. It has exactly one function. That is, to steer a
packet along its delivery path.
The CRH does not attempt to deliver parameters or metadata to service function
instances. It relies on other mechanisms. One possibility is a destination
options header that pre
Chengli (Cheng Li) wrote on 23/05/2020 18:27:
Sure, you are right, we can use CRH and NSH, but personally, I don't think this
is a good idea.
As an operator, I agree - this sounds like a foolish thing to do.
Fortunately, both CRH and NSH processing are disabled by default. I.e.
this is only
Hi Joel,
Sure, you are right, we can use CRH and NSH, but personally, I don't think this
is a good idea.
CRH introduce the mapping table to the nodes, and NSH introduce per-SFC/flow
mapping state again, it is not we want in source routing.
We want to maintain the states on the edge nodes only
there are a number of Internet Drafts describing a range of ways of
using SFC NSH with MPLS. The same choices appear to be available with
CRH. If folks are interested, once CRH progresses, it should be a
simple task to document that.
Yours,
Joel
On 5/23/2020 12:59 PM, Chengli (Cheng Li) wro
Hi Ron,
Thanks for your reply.
Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation
between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that
the NSH packet should visit?
Regarding using the first DOH, how to do that without th
Shuping,
The CRH can appear in a packet along with any valid combination of extension
headers.
Ron
Juniper Business Use Only
From: ipv6 On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, May 22, 2020 11:12 AM
To: Ron Bonica ;
SFC NSH is not a DOH. SFC is a next-header. And the preferred way to
carry the VPN information for SFC is to use an SFC metadatum, since that
is already supported. The VPN destination option is for the non-SFC case.
Yours,
Joel
On 5/22/2020 11:11 AM, Pengshuping (Peng Shuping) wrote:
Hi Ro
If you want to support IETF SFC, use the IETF Proposed Standard, NSH.
Yours,
Joel
On 5/22/2020 2:56 AM, Chengli (Cheng Li) wrote:
Hi Ron,
When reading the CRH draft, I have a question about how CRH support SFC?
For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC
related SID
Hi Ron,
If using DOH, then we would have DOH (VPN) + DOH (SFC) + RH per packet in some
circumstances, right? What if more (ever-emerging) services are required? Not
sure about the forwarding efficiency.
Best regards,
Shuping
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Se
Hi James,
> This separation of architecture is not new; see
> https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ in the SPRING WG.
My apologies, I didn't mean to imply that all SPRING drafts did not specify a
good architecture. The ones that don't have gotten me frustrated, and that
fr
spring@ietf.org; Chengli (Cheng Li)
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
Hi,
> The sole purpose of a Routing header is to steer a packet along a specified
> path to its destination. It shouldn’t attempt to do any more than that.
>
> The CRH does not
Hi,
> The sole purpose of a Routing header is to steer a packet along a specified
> path to its destination. It shouldn’t attempt to do any more than that.
>
> The CRH does not attempt to deliver service function information to service
> function instances. However, it is compatible with:
>
>
Cheng,
The sole purpose of a Routing header is to steer a packet along a specified
path to its destination. It shouldn't attempt to do any more than that.
The CRH does not attempt to deliver service function information to service
function instances. However, it is compatible with:
* The
Hi Ron,
When reading the CRH draft, I have a question about how CRH support SFC?
For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related
SID, how to indicate that? By PSSI? [1]
But how to know which segment endpoint node/egress node should process this
PSSI? At the beginn
31 matches
Mail list logo
