Alex,
Will try and get you some captures off the devices I've been testing on - in
order to make sure I understood this draft properly, and in light of the
deployment status draft, I decided to play a lot more deeply and setup a bit of
a lab. I'm still doing tests and soon as I have some
Hi, Jeff.
Consider a headend that can perform 1 of the following 2 modes(but not
both):
1) Plain IPv4: 6 transport labels + 0 service label => traffic can be
steered into a 6-label SR-TE policy.
2) Any type of VPN: 3 transport labels + 1~3 service labels => traffic
cannot be steered into a
I’m not aware of any undisclosed IPR related to this document.
Rgds,
-- Kamran
On 2019-12-16, 12:31 PM, "spring on behalf of Satish Mynam"
wrote:
As contributor, I’m not aware of any undisclosed IPR related to this
document.
Thanks,
Satish
On 12/5/19, 8:50
Thanks Jeff!!
Both SR-MPLS & SRv6 in general I am guessing most deployments have been
centralized controller based model to take advantage of PCEP and SR-TE
policy as necessary automatically instead of statically defined explicit
paths.
For small deployments I guess you could get away with non
Gyan,
MSD is only relevant for a device that either imposes the label stack
(head-end) or manipulates it (BSID anchor). There are some other constrains
when it comes to entropy labels and ERLD, please read the respective drafts.
In general, SID stack would grow when TE is in use (any time you
On Mon, 16 Dec 2019, 21:07 Ketan Talaulikar (ketant),
wrote:
> Hi Mark,
>
>
>
> Could you share references which says it is illegal to refer to 0.0.0.0 or
> :: as IP addresses?
>
>
>
> Many (if not most) implementations use these representations of IP
> addresses when provisioning a default
Pablo,
Your point is well-taken. We should remind the reader to abide by *all* RFC
4291 and RFC 8200 validation rules, not just source address validation . I
recommend that you make the following change to Section 4.2:
OLD>
S15. Set the packet's egress adjacency to a member of J
S15. Set
As contributor, I’m not aware of any undisclosed IPR related to this document.
Thanks,
Satish
On 12/5/19, 8:50 AM, "bruno.decra...@orange.com"
wrote:
Hi SPRING WG,
In parallel to the WGLC for draft-ietf-spring-srv6-network-programming, we
would like to poll for IPR.
HI Pablo:
Replies in-line prefaced with DA>
-Original Message-
From: spring On Behalf Of Pablo Camarillo (pcamaril)
Sent: Saturday, December 14, 2019 1:57 AM
To: Xiejingrong (Jingrong) ; Joel M. Halpern
; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Dave,
Thank
Hi, SPRINGers,
This is my first post to this list.
This is about draft-ietf-spring-srv6-network-programming-06
more precisely the T.Encaps section 5.2.
Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
Alex,
The precise definition T.Encaps is done in section 5.1 [5.2 now] of
Hi, SPRINGers,
My comments on SRv6 relate to a worry about modifying packets in transit.
In order to better explain myself, or maybe to remove the worry
altogether, I would like to ask for packet dumps of SRv6.
By looking at the packet contents that go into the network it is much
easier to
Hi Ketan,
I think Mark is right here.
I went through this document again and it seems that it defines endpoint to
be used as either "address" or "prefix". See there is nothing wrong with
using prefix ... but "address" is normally referred to what is in the
packet.
Moreover your examples of
Dear WG,
We just submitted a new revision of draft-dong-spring-sr-for-enhanced-vpn to
solve the comments and suggestions received both during IETF106 and on the mail
list.
The major changes are:
1. Following the chairs' suggestion, we reduced the description about network
slicing and
Hi Mark,
Could you share references which says it is illegal to refer to 0.0.0.0 or ::
as IP addresses?
Many (if not most) implementations use these representations of IP addresses
when provisioning a default static route and there is nothing wrong with doing
so.
The link you shared
Hi all,
We have updated SRv6 deployment status draft with the information from Iliad
and Noia.
The contents would be much more informative than previous version. Especially
for operators, who are interested in SRv6, you can find that interoperability
between multiple implementaions, and size
15 matches
Mail list logo
