Hi Ron,
You raised an interesting question, but I think it might be already discussed
in the DT. In my understanding, this question is just more related the usecases
and requirements but the solutions. In a SRv6 domain, the header compression
effection depends on the SID informaion redundencies due to the reasonable SID
planning with the SRv6 compatible solution. I think it's meanless to compress
the SRv6 header in the case of random SID format. Besides other solution
without engouth SRv6 compatible such as Unified SID could be used to resolve
the usecase you mentioned. I believe that had been discussed and compared
within the DT and the one solution compatible with SRv6 is preferred, that is
the CSID draft.
Best Regards,
Aihua
原始邮件
发件人：RonBonica
收件人：Robert Raszuk;
抄送人：SPRING WG;
日 期 ：2021年10月02日 21:39
主 题 ：Re: [spring] CSID Question
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
Folks,
Now that Robert and I have provided some entertainment, could someone answer
the technical question that initiated this thread?
Does the document recommend against using Next-C-SId and Replace-C-Sid in the
same domain for ease of operation or because they don’t work well together? If
the former, please provide the example described below.
Ron
Sent from my iPhone
On Oct 1, 2021, at 5:07 PM, Robert Raszuk <[email protected]> wrote:
[External Email. Be cautious of content]
Hi Ron,
Can we say that they are a single behavior ?
No. And neither RFC8986 defines a single behavior or single flavor. Yet the
bounds are clearly set what is the SRv6 data plane.
For some strange reason I am observing here an attempt to squeeze different
data plane into the room which is not compliant to [RFC8402], [RFC8754] and
[RFC8986]. Do you think anyone will be so naive to accept it ?
Now I am going to rest assured and enjoy the rest of this show.
Best,
Robert
On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica <[email protected]> wrote:
Robert,
I do remember that quote. And that is exactly why I ask the question!
If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:
Can we say that they are a single behavior ?
Can we justify both because each is optimized for a different kind of network?
Can we justify another behavior either because it is optimized for yet another
type of network or because it does relatively well in all network types?
However, if this is just an “ease of operation” thing, as stated in the draft,
the authors are obliged to answer my question.
Ron
P.S. Rest assured that I have read the draft. However, your concern is greatly
appreciated 😉
Juniper Business Use Only
From: Robert Raszuk <[email protected]>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica <[email protected]>
Cc: SPRING WG <[email protected]>
Subject: Re: [spring] CSID Question
[External Email. Be cautious of content]
Hi Ron,
Have you read this draft ?
Quote from it:
It is recommended for ease of operation that a single compressed encoding
flavor be used in a given SRv6 domain. However, in a multi- domain
deployment, different flavors can be used in different domains.
On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica
<[email protected]> wrote:
CSID Authors,
Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.
Please provide an example that shows us:
What the SRH looks like as it arrives at the first segment endpoint
What the IPv6 Destination Address looks like at each segment endpoint,
including information required to parse the Destination Address
Ron
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
