Cheng,
The CRH doesn't attempt the address SFC. That is beyond the scope or a routing
header.
Ron
Juniper Business Use Only
-Original Message-
From: Chengli (Cheng Li)
Sent: Sunday, May 24, 2020 11:44 PM
To: Ron
Hi Ron,
Thank you to share the facts of RFC8200.
Could you please explain how CRH supports SFC by the first Destination Options
header as you mentioned in you previous email?
Or how to support performing a specific behavior at a specify node along the
path by using CRH?
You know, when we
Ketan,
Please consider an operator who:
- Wants a way to steer IPv6 packets through a specified path that includes many
nodes (>8)
- Does not want any of the following:
- A new VPN encapsulation technique
- A new service function chaining technique
- Network programming
No, there probably is no IETF reference. The techniques I can think of
do not have interoperability issues, and therefore are not IETF
standards. They are just operations on a controller, where the
controller manages resource allocations. These were discussed in slide
presentations in the
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 every node along the delivery path
- Hop-by-hop
- Headers processed at every segment
Hi Joel,
Could you provide some reference in IETF to the "existing ways to do resource
reservation with SR" you mentioned?
Regarding the term isolation, my suggestion is to keep that generic discussion
in TEAS. In the context of this draft, as described in the draft and mails, the
meaning is
Cheng,
IPv6 defines many Routing headers. The Routing header is designed to steer
packets along a delivery path. Other headers are designed to deliver
information to nodes along the delivery path.
The Routing header should not attempt to subsume the function of other IPv6
extension headers.
that is only a problem if one needs different options aimed at different
service functions. Even NSH does not actually do that.
So define a destination option to carry service parameters. Put it in a
destination option before the CRH. then every addressed entity examines
it. It is marked as
Hi Joel,
I have a vague recollection of that and will do some digging. However, it seems
fair to say that CRH in its current form can only support complex service
chaining by utilizing NSH unlike SRv6 that has the capability to encode as many
services as you want in the SRH, or if you prefer
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
We did construct (and describe in an I-D) a version of the PSSI that
carried multiple instructions, with marking as to which SL values
applied to which instructions. Tom Herbert constructed a different
workable encoding for this functionality. No one seemed interested.
So rather than worry
It seems to me that RFC8200 could not be clearer when it states that there is
an order to how extension headers are processed (see [1]) and if a DOH precedes
a routing header then *every* node in the routing header must process the DOH;
which leads me to wonder how a service chain could be
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.
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
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
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
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, Joel:
No, not the two things that you mentioned. These are distributed only protocols
and are difficult to differentiate the traffic in near real time.
What I worried is that CRH may not bypass the constraint of source routing
mechanism(must put the segment list within every packet of the
Aijun, I am not sure I properly understand your request.
In some qys, it sounds like what you are asking for is conventional MPLS.
In other ways, it sounds like you are asking for Ross Callon's old
writeup on adjusting routing metrics to achieve traffic engineering.
Are those objections to
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
Hi,
We know the advantages of these proposals. But we also pay more attention to
their deployment in large network.
Considering the flows that needs to be steered away the default path are often
small packets, adding the path list overhead on it is not efficient. And we
need to add these
21 matches
Mail list logo
