Hi Mark,
Not sure what is incorrect in what I mentioned.
Checksum neutrality is a distinct issue than the original question from Joel.
That was discussed in the RFCs cited in the previous message.
That’s said, I’m not sure that’s an issue for SRH given that the encap will
need to be updated an
Hi Joel , all,
C-SID is no more than another mechanism that relies on some algorithmic mapping
embedded in the IPv6 address. We do have already many of such algorithmic
approaches: RFC6052, RFC7597, etc.
The internal structure would be problematic if it requires that every
intermediate node
Hi all,
As a co-author, I confirm that I don't have any IPR nor I'm aware of any
related to this draft.
It seems that we missed to include some MTU considerations in the text.
Although these issues are not specific to this spec, but reminding the issues
would be helpful. Adding a pointer to Se
Chairs, all,
I don’t have any IPR nor I’m aware of any related to this I-D.
Cheers,
Med
De : Rob Shakir [mailto:ro...@google.com]
Envoyé : jeudi 27 juin 2019 08:14
À : draft-guichard-spring-nsh...@ietf.org; SPRING WG List
Objet : IPR Poll: draft-guichard-spring-nsh-sr
Hi Authors, SPRING WG,
In
Hi Daniel,
I’m afraid that the comparison with DC routing is misleading here. It is still
possible to use your favorite transport encapsulation with the approach
endorsed by the IETF in 8300.
Re-using NSH instead of mimic it in each individual transport protocol is much
more pragmatic. It avoi
Jim,
You said that you “simply need SR to realize the chain”, but actually if you
want a path to be steered relying upon some information conveyed in the packet
and to invoke specific SFs, then you need to define the structure of such
information and its meaning.
That is another piece of speci
Dear Avinash,
But these various encapsulation options (VXLAN, IP-in-IP,..) are already there
thanks to the transport-agnostic approach endorsed by the SFC WG.
An alternative approach would be to mimic NSH for each of the mechanisms you
listed. That approach is suboptimal, IMO.
FWIW, we used to
Re-,
This is really a matter of taste.
Jim, whatever scheme we use for identifying service chains, there are
requirements/constraints/new practices/new OAM procedures that need to be
supported/honored for service chaining purposes.
Those are not simple nor complex in MPLS vs. NSH over MPLS. I’
Re-,
I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without
any code upgrade.
NSH does provide the simple functionality you need; that is the information to
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with
length is 0x2.
Of course you can enc
Hi Jim,
Perhaps I missed your point, but I’m not asking to disallow whatever transport
encapsulation scheme deployed in a network for SFC purposes.
What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a
transport-agnostic approach that can be deployed in conjuncti
Hi all,
Wim has a point here.
For all these proposals, a new behavior is needed to be followed by SFC-aware
nodes. What differs is the channel used to signal a chain and to supply
additional data for SFC purposes.
Leveraging on existing code/capabilities is good for a vendor/implementer, bu
11 matches
Mail list logo
