From: Robert Shearman <rshearma@brocade•com>
To: "Eric W. Biederman" <ebiederm@xmission•com>
Cc: "davem@davemloft•net" <davem@davemloft•net>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>
Subject: Re: [PATCH net-next v2 3/5] mpls: Differentiate implicit-null and unlabeled neighbours
Date: Mon, 23 Mar 2015 11:47:45 +0000 [thread overview]
Message-ID: <550FFD61.8050708@brocade.com> (raw)
In-Reply-To: <87h9tc4u9y.fsf@x220.int.ebiederm.org>
On 22/03/15 21:06, Eric W. Biederman wrote:
> ebiederm@xmission•com (Eric W. Biederman) writes:
>
>> Robert Shearman <rshearma@brocade•com> writes:
>>
>>> The control plane can advertise labels for neighbours that don't have
>>> an outgoing label. RFC 3032 s3.22 states that either the remaining
>>> labels should be popped (if the control plane can determine that it's
>>> safe to do so, which in light of MPLS-VPN, RFC 4364, is never the case
>>> now) or that the packet should be discarded.
>>
>> I can not figure out what you are referring to. There is no section 3.2
>> in RFC3022.
>
> I have found it. That is is RFC3021 Section 3.22. This is something
> the code already does. If the label can not be looked up with
> mpls_route_input_rcu the packet is dropped.
No, the existing code handles the lack of an incoming label. s3.22 is
stating what should be done with the lack of an outgoing label.
> Beyond that I believe the rest of my comments still stand. If you want
> to do this explicitly some form of explicit blackhole route needs to be
> supported. Either just allowing a route to be configured with no output
> device or an explicit RTN_BLACKHOLE route.
No, that isn't going to address the problem this patch solves.
>
>>> Therefore, if the peer is unlabeled and the last label wasn't popped
>>> then drop the packet. The peer being unlabeled is signalled by an
>>> empty label stack. However, implicit-null still needs to be supported
>>> (i.e. penultimate hop popping) where the incoming label is popped and
>>> no labels are put on and the packet can still go out labeled with the
>>> unpopped part of the stack. This is achieved by the control plane
>>> specifying a label stack consisting of the single special
>>> implicit-null value.
>>
>> As I understand it you want to handle the case for a label for which
>> there is no next hop, and the packet should be black-holed.
>>
>> In struct mpls_route such routes are currently represented by routes
>> that have no network device. And in rtnetlink should be represented
>> with routes of type RTN_BLACKHOLE which I do not currently support
>> parsing. But that should be simple enough to correc.t
>>
>> With respect to Implicit NULL it should be an error to accept a route
>> that has an RTA_NEWDST that includes an implicit NULL.
>>
>> The rtnetlink is not ldp nor should it have ldp semantics and be made
>> complicated by those semantics.
This isn't specific to LDP - it is used by MP-BGP as well, or indeed
would be perfectly valid to be specified in static configuration. As per
RFC3031 s4.1.5 (https://tools.ietf.org/html/rfc3031#section-4.1.5) this
signals that penultimate hop popping should be done, as opposed to
dropping the packet if it would go out as MPLS (s3.22).
Thanks,
Rob
>> The semantics of RTA_NEWDST are the labels to push on after the top most
>> label has been popped off. I see no reason to include other mechanisms
>> into that processing when it is easy enough to add or tweak other
>> attributes to have those semantics.
>>
>> Certainly it is not something that I think is worth special casing on
>> the fast path in mpls_forward.
next prev parent reply other threads:[~2015-03-23 11:47 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 21:32 [PATCH net-next 0/5] mpls: Behaviour-changing improvements Robert Shearman
2015-03-19 21:32 ` [PATCH net-next 1/5] mpls: Use definition for reserved label checks Robert Shearman
2015-03-20 0:41 ` Eric W. Biederman
2015-03-20 14:12 ` Robert Shearman
2015-03-19 21:32 ` [PATCH net-next 2/5] mpls: Remove incorrect PHP comment Robert Shearman
2015-03-19 21:32 ` [PATCH net-next 3/5] mpls: Differentiate implicit-null and unlabeled neighbours Robert Shearman
2015-03-19 21:32 ` [PATCH net-next 4/5] mpls: Per-device enabling of packet forwarding Robert Shearman
2015-03-19 21:32 ` [PATCH net-next 5/5] mpls: Allow payload type to be associated with label routes Robert Shearman
2015-03-20 15:42 ` [PATCH net-next v2 0/5] mpls: Behaviour-changing improvements Robert Shearman
2015-03-20 15:42 ` [PATCH net-next v2 1/5] mpls: Use definition for reserved label checks Robert Shearman
2015-03-22 19:09 ` Eric W. Biederman
2015-03-20 15:42 ` [PATCH net-next v2 2/5] mpls: Remove incorrect PHP comment Robert Shearman
2015-03-22 19:12 ` Eric W. Biederman
2015-03-23 11:32 ` Robert Shearman
2015-03-23 18:16 ` Eric W. Biederman
2015-03-24 15:18 ` Robert Shearman
2015-03-24 18:43 ` Vivek Venkatraman
2015-03-20 15:42 ` [PATCH net-next v2 3/5] mpls: Differentiate implicit-null and unlabeled neighbours Robert Shearman
2015-03-22 19:49 ` Eric W. Biederman
2015-03-22 21:06 ` Eric W. Biederman
2015-03-23 11:47 ` Robert Shearman [this message]
2015-03-20 15:42 ` [PATCH net-next v2 4/5] mpls: Per-device enabling of packet forwarding Robert Shearman
2015-03-22 20:02 ` Eric W. Biederman
2015-03-22 20:34 ` Eric W. Biederman
2015-03-23 13:42 ` Robert Shearman
2015-03-23 13:10 ` Robert Shearman
2015-03-20 15:42 ` [PATCH net-next v2 5/5] mpls: Allow payload type to be associated with label routes Robert Shearman
2015-03-22 20:56 ` Eric W. Biederman
2015-03-23 14:02 ` Robert Shearman
2015-03-30 18:15 ` [PATCH net-next v3 0/4] mpls: Behaviour-changing improvements Robert Shearman
2015-03-30 18:15 ` [PATCH net-next v3 1/4] mpls: Use definition for reserved label checks Robert Shearman
2015-03-30 18:15 ` [PATCH net-next v3 2/4] mpls: Differentiate implicit-null and unlabeled neighbours Robert Shearman
2015-04-07 16:56 ` Eric W. Biederman
2015-04-08 17:08 ` Robert Shearman
2015-03-30 18:15 ` [PATCH net-next v3 3/4] mpls: Per-device enabling of packet input Robert Shearman
2015-04-07 17:02 ` Eric W. Biederman
2015-04-08 14:29 ` Robert Shearman
2015-04-08 14:44 ` Eric W. Biederman
2015-03-30 18:15 ` [PATCH net-next v3 4/4] mpls: Allow payload type to be associated with label routes Robert Shearman
2015-04-07 17:19 ` Eric W. Biederman
2015-04-08 14:03 ` Robert Shearman
2015-04-01 19:30 ` [PATCH net-next v3 0/4] mpls: Behaviour-changing improvements David Miller
2015-04-01 21:14 ` Eric W. Biederman
2015-04-01 23:49 ` Robert Shearman
2015-04-06 20:02 ` David Miller
2015-04-14 22:44 ` [PATCH net-next v4 0/6] " Robert Shearman
2015-04-14 22:44 ` [PATCH net-next v4 1/6] mpls: Use definition for reserved label checks Robert Shearman
2015-04-14 22:44 ` [PATCH net-next v4 2/6] mpls: Per-device MPLS state Robert Shearman
2015-04-14 22:45 ` [PATCH net-next v4 3/6] mpls: Per-device enabling of packet input Robert Shearman
2015-04-14 22:45 ` [PATCH net-next v4 4/6] mpls: Allow payload type to be associated with label routes Robert Shearman
2015-04-14 22:45 ` [PATCH net-next v4 5/6] mpls: Differentiate implicit-null and unlabeled neighbours Robert Shearman
2015-04-14 22:45 ` [PATCH net-next v4 6/6] mpls: Prevent use of implicit NULL label as outgoing label Robert Shearman
2015-04-21 20:34 ` [PATCH 0/3] mpls: ABI changes for security and correctness Robert Shearman
2015-04-21 20:34 ` [PATCH 1/3] mpls: Per-device MPLS state Robert Shearman
2015-04-21 20:34 ` [PATCH 2/3] mpls: Per-device enabling of packet input Robert Shearman
2015-04-21 20:34 ` [PATCH 3/3] mpls: Prevent use of implicit NULL label as outgoing label Robert Shearman
2015-04-22 0:29 ` [PATCH 0/3] mpls: ABI changes for security and correctness Eric W. Biederman
2015-04-22 2:12 ` David Miller
2015-04-22 10:10 ` Robert Shearman
2015-04-22 10:14 ` [PATCH v2 " Robert Shearman
2015-04-22 10:14 ` [PATCH v2 1/3] mpls: Per-device MPLS state Robert Shearman
2015-04-22 15:25 ` Eric W. Biederman
2015-04-22 10:14 ` [PATCH v2 2/3] mpls: Per-device enabling of packet input Robert Shearman
2015-04-22 16:27 ` Eric W. Biederman
2015-04-22 10:14 ` [PATCH v2 3/3] mpls: Prevent use of implicit NULL label as outgoing label Robert Shearman
2015-04-22 16:32 ` Eric W. Biederman
2015-04-22 16:47 ` [PATCH v2 0/3] mpls: ABI changes for security and correctness Eric W. Biederman
2015-04-22 18:25 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=550FFD61.8050708@brocade.com \
--to=rshearma@brocade$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ebiederm@xmission$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox