Fernando, Zhenqiang,
You both have valid points. Maybe I am becoming too tolerant of deviations from
the specification.
Ron
Juniper Business Use Only
From: li zhenqiang
Sent: Wednesday, September 4, 2019
Hello all,
I don't think we can infer from RFC 8200 that something is mandated and
something is strongly suggested. If guys with different interests can infer
from an "Internet Standard" what they are interested, the standard is ambiguous
and deserves a bis.
If the standard is clear, we MUST
On 4/9/19 21:27, Ron Bonica wrote:
> Ole,
>
> Yes, a deep breath and some introspection are always a good thing.
>
> First, I think that we need to make a distinction between the "spirit" and
> "letter" of the law. Next, we need to make a statement regarding good
> engineering practice.
>
>
On 4/9/19 09:58, Ole Troan wrote:
> Fernando,
>
Since there have been plenty of attempts to do EH insertion or
leave the IPv6 standard ambiguous in this respect, and the IETF has
had consensus that EH insertion is not allowed, I think it would be
bad, wastefull, tricky, and
Hi All,
The following things in the drafts referenced in the subject line are questions
that I feel need to be addressed - since having gone through these drafts
closely in light of some of the comments on the spring list and cross
referenced and checked a number of things - there are a number
Hi WG Folks,
Its not clear on why the SRv6 has to alter the address semantics and
push the service functions into v6 address space. Maybe rationale on
why this was done would help to appreciate why this path was chosen.
>From my understanding the SRv6+ spec shows these defined service
functions
Ole,
Yes, a deep breath and some introspection are always a good thing.
First, I think that we need to make a distinction between the "spirit" and
"letter" of the law. Next, we need to make a statement regarding good
engineering practice.
RFC 8200 mandates some things. For example, In an IPv6
Ketan,
Apologies.
Probably looked up a wrong version of the draft.
However, the question about compliance with RFC 8200 remains open IMHO.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
From: Ketan Talaulikar (ketant)
Sent: Wednesday,
Hi Sasha,
My references were correct :
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-4.13
The section also refers to the individual draft in 6man
(I-D.voyer-6man-extension-header-insertion) which covers the insertion.
You may also want to refer to this
Ketan,
Lots of thanks for a prompt response.
It seems that the sections in the draft should be 4.9 (Insert) and 4.11 (encap)
and not as in the email.
With regard to the Insert use case, the pseudocode in the draft suggest
insertion of an additional SRH between the IPv6 header and the SRH in
Hi Sasha,
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01
covers the pseudocode BSID for SRv6. Please refer to section 4.13-16 which
describe both the insert and encap versions.
Thanks,
Ketan
From: spring On Behalf Of Alexander Vainshtein
Sent: 04 September 2019
Rob, Bruno and all,
I have a naive question based, most probably, on insufficient understanding of
SRv6 (not to mention SRv6+).
This question has been prompted by the complaints (on the Beyond SRv6 thread)
about problems with supporting long lists of 128-bits of SIDs in the IPv6
Segment Routing
Fernando,
>>> Since there have been plenty of attempts to do EH insertion or
>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>> had consensus that EH insertion is not allowed, I think it would be
>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>
13 matches
Mail list logo
