Hi Martin,
For the matched LFIB entry with unlabeled outgoing forwarding information, I
agree your opinion that public traffic need to be forwarded.
I think the above LFIB entry can easiely drop VPN traffic according to no
bottom flag of incomming LDP/SR label.
Regards,
PSF
Hi all,
We have just posted revision 18 of draft-ietf-spring-srv6-network-programming.
This revision addresses the comments received from Mirja Kühlewind (TSVART
review) [1], Dan Romascanu (OPSDIR review) [2, 3] and Brian Carpenter [4, 5].
Thank you for the reviews and comments.
Regards,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the
IETF.
Title : SRv6 Network Programming
Authors : Clarence Filsfils
Pablo
Martin,
> it follows an IGP default route to a central device,
So putting aside that such default must point domian wide to the same
address (could be anycast if you are careful) once this "central device"
receives a packet and does a BGP full table lookup it will again try to
encapsulate it in
Hi Martin,
I share your position.
Thanks,
Ketan
-Original Message-
From: spring On Behalf Of Martin Horneffer
Sent: 27 August 2020 16:05
To: spring@ietf.org
Subject: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)
Hello everyone,
may I come back the the question
Hello everyone,
may I come back the the question below? Or rather let me update it a little:
In case an SR-MPLS path is broken, should a node rather drop the packet,
or forward it?
This can happen whenever the IGP points to a certain next hop, but that
neither supplies a valid SID, nor allows
Hi,
I fully agree with Ketan.
For (a), it is obvious that if the next-hop and locator belong to the same
prefix, we minimize the prefixes to be advertised, hence we’ll have smaller
route tables. But it is up to the user to decide that. The spec should support
both.
Similar for (b). There may
Hi Rajesh,
Please check inline below.
From: spring On Behalf Of Rajesh M
Sent: 27 August 2020 12:26
To: gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
rob...@raszuk.net; bruno.decra...@orange.com; zhuangshun...@huawei.com;
jorge.raba...@nokia.com
Cc: spring@ietf.org
Subject: Re:
Sending it again.
Juniper Business Use Only
From: spring On Behalf Of Rajesh M
Sent: Saturday, August 22, 2020 8:43 AM
To: gdawra.i...@gmail.com; cfils...@cisco.com; rob...@raszuk.net;
bruno.decra...@orange.com; zhuangshun...@huawei.com; jorge.raba...@nokia.com
Cc: spring@ietf.org
Subject:
Thanks Pablo, that clarifies the point for me.
Regards
Brian Carpenter
On 27-Aug-20 17:10, Pablo Camarillo (pcamaril) wrote:
> Hi Brian,
>
> The PSP behavior is only applied to received packets when (Segments Left =1 &
> Destination Address = PSP SID).
> The PSP behavior pseudocode
10 matches
Mail list logo
